Servicing Plans in Configuration Manager

Servicing Plans in System Center Configuration Manager (ConfigMgr/SCCM) offer ConfigMgr admins the ability to automatically schedule the download and deployment of Windows 10 feature updates. This post is about why you should not be using them. Yes, that’s correct, you should not be using servicing plans to deploy feature updates. This post isn’t about using task sequences to deploy feature updates though, that’s the subject for a different post.

First, I need to expand on why servicing plans were created and what they actually do. In the beginning, the beginning of Windows 10, Microsoft painted this wonderful picture of upgrading Windows 10 on all systems. Specifically, we would upgrade every 4-6 months, that the upgrade wouldn’t impact end-users excessively, and we wouldn’t have to do extensive testing on these upgrades. Basically, we could treat feature updates like normal updates and thus deploy them as normal updates. To this end, the ConfigMgr product group created an extension to the Automatic Deployment Rule (ADR) feature set to automatically download and deploy feature updates for us. This extension is called servicing plans.

At their core, servicing plans do exactly what ADRs do including downloading and deploying feature updates automatically (by creating update groups and deployments on those update groups) using criteria to only select the desired updates. This is great for a recurring, relatively hands-off process like deploying normal updates on a monthly basis. This does not describe how organizations are deploying feature updates though. The three premises above about feature updates simply don’t hold true: every 4-6 months, unobtrusive, little testing. Note that these may be true at some point in the future as Microsoft continues to strive towards this, but as of today, these aren’t [completely] true.

Instead, what all organizations do is deploy a single, chosen feature update in a controlled manner after extensive testing and coordination with their user population. This is not explicitly based on when the feature update was released or when Microsoft declared it to be SAC. Thus, using an automatic scheduling and selection mechanism makes no sense and simply adds a layer of unnecessary complexity that must often be tinkered with and troubleshot separately.

You know what feature update that you want to deploy and you know when you want to deploy it so just right-click on it and deploy it.

This kicks off a Deploy Software Updates Wizard that has all of the usual options for downloading, scheduling, and targeting the feature update. You could alternatively add the feature update to an update group first and then deploy the update group. I don’t see a lot of value in this except that places all of your update deployment-related objects under the Update Groups node. Both approaches are valid and technically identical so which you choose is based on your preferences.

Adding criteria to select a specific update for a one-time deployment in a servicing plan simply doesn’t make sense. It’s like setting up a rule in Outlook to move a single e-mail to new folder — just move the single e-mail manually instead of wasting time crafting criteria so that only that one e-mail gets selected. The best answer is always the same: just deploy the feature update that you know you want to deploy.

Ultimately, servicing plans do work, but are best used for automatic, recurring selection and deployment of all feature updates (past and future). I don’t know of any organization that wants to do this today though and rightly so as feature update deployment is a one-time task. If you are fiddling with the criteria in any way to only deploy a specific feature update, then you are causing yourself more work (and harm) without any benefit whatsoever. Just deploy the feature update that you want. Done.