Managing Software Updates in Configuration Manager 2012

[Yvette O'Meally]

First published on CLOUDBLOGS on Feb 20, 2012
Recently we had a software update administrator, who we’ll call Kevin, come to us with questions about how his organization should manage software updates in the upcoming Configuration Manager 2012 release. Kevin explained that since the release of SMS 2003, he has been refining how he manages software updates, with a lot of trial-and-error to get the process right.

For example, limitations in SMS 2003 forced him to use the sustainer-package model, which he persisted into CM07. Later, realizing he didn’t really need to do that anymore, Kevin moved to a model where he added monthly updates to a deployment every month. When the number of updates got close to the 500 update limit, he’d roll those into an update-deployment grouped by year (or half-year) and then start the process over again.

Hearing about changes coming in Configuration Manager 2012, such as Auto Deployment Rules, update groups, and the new 1,000 update-limit per-deployment, Kevin contacted us wanting to know how we’d recommend using software updates in Configuration Manger 2012. Primarily, Kevin wanted to avoid months of trial-and-error in getting his process aligned to new functionality. We’ve captured the conversation with Kevin to share with other administrators, who may also be wondering about best-practices for managing software updates in the upcoming release.

Q&A Session with Kevin

So tell me, how am I supposed to manage my patch process in Configuration Manager 2012?

Well, first off, you need to start by grouping all of the past updates that you require in your environment so you can measure and remediate non-compliance on all clients against those groups of updates. You can build these initial groups either through the migration feature, bringing in your update lists and deployments from Configuration Manager 2007 as update groups in Configuration Manager 2012, or by creating new update groups in Configuration Manager 2012 for groups of all past updates, by year or product, for example. These update groups can then be used for both measuring compliance and/or monitoring the deployment of those updates to any clients against which they are applicable and need to be installed.

Why do I need to group them? I understand the limit has been raised to 1,000 per deployment, but why can’t I just create one update-group deployment of all previously released updates? I guess I don’t understand the need for a limit.

Yes, the update limit has been increased to 1,000, and this is a hard limit – unlike Configuration Manager 2007 where it was a documented limit (of 500 updates). This limit exists for good reason — it is set to mitigate performance degradation, both server-side (for summarizing such large deployments, and for rendering reports), as well as on client-side, for clients processing large policy-bodies containing more than 1,000 updates. As for the server-side piece, there is a tremendous amount of SQL processing required to correlate deployment and compliance states across all updates in a group, relative to all clients in your environment. This limit is to help keep that summarization processing under control, hence the requirement of creating deployed update groups that do not exceed this limit. Also, you really want to avoid frequently modifying deployed update-groups by adding/removing updates to them, as this causes a lot of overhead client-side with policy processing, and server-side with SQL processing.

Okay, that makes sense, I guess. But what if I want to check my entire environment’s compliance for all systems, or for a specific set of systems, for ALL updates that I care about. Can I do that?

Yes, you can create a compliance group (update-group NOT deployed) to measure all-up compliance. In-console that aggregated compliance will be shown for “All Systems” or you can break it down by collection using reports. Also, you can see specific compliance numbers for each update that comprises the group, through the in-console list-view, by looking at specific reports to show you per-update compliance against selected update groups and collections. The summarization hit here isn’t as much of an issue because the system is not summarizing the complex states that make up a deployment. Rather, it’s just a summary view of overall compliance per-machine / per-update. It is still recommended that you do some logical grouping of updates – even if it is just for measuring compliance (like all updates in a particular year) – to optimize summarization performance. However, there is no hard limit on the number of updates in an update group used for measuring compliance (not deployed). Like with deployments, you also want to avoid making high-frequency changes to these groups as to avoid the server-side hit on SQL processing.

Okay, I can see how that would work. But I also have delegated admins that need to deploy all of these large groups of past updates in their own way. How do I do that?

The great thing about update-groups is that they can have multiple deployments associated with them. For example, if your server team needs their deployment to suppress restarts except during maintenance windows, they can create their own deployment of the “All 2010 Software Updates” group, with their unique deployment settings. Through the new role-based access feature in ConfigMgr 2012, you can also make sure they can only modify deployments targeted to collections to which they have rights.

Okay, that sounds good for managing past updates, but what do I do moving forward? How do I manage month-to-month updates, on Patch Tuesday for example?

For monthly updates, you have a couple of options: Auto Deployment Rules (ADRs) or the Distribute Software Update Wizard. ADRs can be setup to simply look for new updates and download them each month, using an advanced filter expression to identify precisely the updates you want. Additionally, ADRs can be set to create the deployment as disabled, so you can sanity check the results before you green-light it for production by simply enabling the deployment created by the rule. Optionally, you can use the new search capability to find the updates you need each month, and use the Distribute Software Updates Wizard to create and deploy update groups each month manually. The key is that you don’t need to roll those into yearly deployments. You just keep creating monthly updates over time, and you add the updates from each monthly deployment group into a compliance group (again, an update group that’s not deployed), on a monthly, quarterly, or bi-annual basis. This gives you an aggregate overview of your compliance through the year, but doesn’t induce the overhead and deployment summarization caused by adding updates to existing deployments, or modifying deployments in any way. This also keeps any deployment troubleshooting in the context of a month of updates, and isn’t complicated by having a huge deployment of hundreds of updates, for which troubleshooting on non-compliant clients is much more challenging.

For cleanup, identifying expired updates and their group memberships is simple. Just search for all expired updates, select all, choose to edit membership, and uncheck any boxes that are checked against the update groups in the list.

Wait a second, what if a laptop is pulled out of a drawer and turned on after not being used for a couple of years or someone uses an old image, and I have two years-worth of deployments that a client has to sort through and apply updates from. Does that mean I have 24 reboots to deal with?

No, not at all. Past deadline deployments are all bundled and installed, and only a single reboot is required. On rare occasions, an update may require a hard reboot, meaning nothing else can install until that’s done, but that’s not a common case. Even if your client finds updates that are applicable across many months of deployments, you should still just need to perform one reboot. Additionally, the end-user will see all of these updates listed together in Software Center, so they don’t have to navigate through some complex list of update deployments. And the client actually performs better processing multiple deployments with a smaller number of updates than it would processing very large update-group deployments.

Summary Points

• Create update group deployments of all previously released updates that you require, but don’t exceed the new update limit of 1000 updates in any of those groups.
• Use migration from Configuration Manager 2007 to move your existing update lists and deployments over as groups, or create these update groups new in Configuration Manager 2012. Migrations of update deployments with more than 1000 updates will be blocked.
• Create an overall compliance group (update group not deployed) of all updates you require and want to measure overall compliance against.
• Moving forward from your Day 0 implementation of Configuration Manager, use Auto Deployment Rules to create new update groups and deployments for each month of updates (Patch Tuesday groups).
• Note: If you’re using SUM and ADRs to deliver definition updates, then you want to set the rule to use the existing update group each time the rule runs. You don’t want a new update group for definitions created every day, and the natural expiration cycle of every 5 ^th update (always 1 active and 3 superseded) keeps the update group membership at a maximum of 4 definition updates (1 active and 3 superseded).
• Add the updates each month to the overall compliance group (or a compliance group for that year of updates), but do not re-create, move, or combine those existing monthly deployments.

Jason Githens
Sr. Program Manager
System Center Configuration Manager