Managing Software Updates in SCCM 2012

Let us first discuss about best practices for managing Software updates through SCCM 2012

How will I manage by updates deployment process in SCCM 2012?

Well, first of all, we need to start by grouping all of the past updates that we require in our environment so that we can measure and remediate non-compliance on all clients against those groups of updates. we can create these initial groups either through the migration feature, fetching  update lists and deployments from SCCM 2007 as update groups in Configuration Manager 2012, or by creating new update groups in SCCM 2012  for groups of all past updates, by year or product. 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.

What is the limit of update deployment in SCCM 2012?

The update limit has been increased to 1,000, and this is a hard limit. In SCCM 2007 where it was documented limit (of 500 updates). This limit exists is set to mitigate performance degradation, both server-side (Becomes easier 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 is concerned, 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 helps us to keep that summarization processing under control, hence the requirement of creating deployed update groups that do not exceed this limit. Its always better 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.

What is the best practice to check entire environment update compliance for all systems or for a system collection?

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 it can be beaked  down by collection using reports. It also displays specific compliance numbers for each update that comprises the group, through the in-console list-view, by looking at specific reports displaying per-update compliance against selected update groups and collections. The summarization is  just a summary view of overall compliance per-machine / per-update. It is still recommended that we 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, we can also avoid making high-frequency changes to these groups as to avoid the server-side hit on SQL processing.

What are the advantages of creating update groups?

The great thing about update-groups is that they can have multiple deployments associated with them. For example, if the server admin teams need 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 SCCM 2012, you can also make sure that delegated admin’s   can only modify deployments targeted to collections to which they have rights.

How do I manage month-to-month updates, on Patch Tuesday for example?

For monthly updates, we 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 we want. Additionally, ADRs can be set to create the deployment as disabled, so that we can check the results before enabling the deployment created by the rule. Optionally, we can use the new search capability to find the updates we 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. Creating monthly updates over time, and adding 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 us an aggregate overview of  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.

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 there is 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 the client finds updates that are applicable across many months of deployments, it 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 process very large update-group deployments.