Deploying Updates through SCCM 2012

Deploying Updates through SCCM 2012

Once WSUS & Software Update Point installed and SUP is configured.  We have update definitions downloaded and ready to deploy updates out to our clients.

Before that let us be familiar with the forms of Updates and discuss on Update icons which have been synchronized from WSUS

The Normal Icon

The icon with the green arrow represents a normal software update.

Description:
Normal software updates have been synchronized and are available for software deployment.
Operational Concerns:
There are no operational concerns.

The Expired Icon

The icon with the black X represents an expired software update. You can also identify expired software updates by viewing the Expired column for the software update when it displays in the Configuration Manager console.

Description:
Expired software updates were previously deployable to client computers, but once a software update is expired, new deployments can no longer be created for the software updates. Expired software updates contained in active deployments continue to be available to clients.
Operational Concerns:
Replace expired software updates when possible. When software updates become expired, Configuration Manager does not remove the software updates contained within active software update deployments. Configuration Manager continues to assess software update compliance on expired software updates in deployments, but they are considered “not required” for reporting purposes.

The Superseded Icon

The icon with the yellow star represents a superseded software update. You can also identify superseded software updates by viewing the Superseded column for the software update when it displays in the Configuration Manager console.

Description:
Superseded software updates have been replaced with newer versions of the software update. Typically, a software update that supersedes another software update does one or more of the following:

Enhances, improves, or adds to the fix provided by one or more previously released software updates.

Improves the efficiency of its software update file package, which clients install if the software update is approved for installation. For example, the superseded software update might contain files that are no longer relevant to the fix or to the operating systems now supported by the new software update, so those files are not included in the superseding software update's file package.

Updates newer versions of a product, or in other words, is no longer applicable to older versions or configurations of a product. Software updates can also supersede other software updates if modifications have been made to expand language support. For example, a later revision of a product update for Microsoft Office might remove support for an older operating system, but add additional support for new languages in the initial software update release.

Operational Concerns:
When possible, deploy the superseding software update to client computers instead of the superseded software update. You can display a list of the software updates that supersede the software update on the Supersedence Information tab in the software update properties.

The Invalid Icon

The icon with the red X represents an invalid software update.

Description:
Invalid software updates are in an active deployment, but for some reason the content (software update files) is not available. The following are scenarios in which this state can occur:

You successfully deploy the software update, but the software update file is removed from the deployment package and is no longer available.

You create a software update deployment at a site and the deployment object is successfully replicated to a child site, but the deployment package has not successfully replicated to the child site.

Operational Concerns:
When the content is missing for a software update, clients are unable to install the software update until the content becomes available on a distribution point. You can redistribute the content to distribution points by using the Redistribute action. When content is missing for a software update in a deployment created at a parent site, the software update must be replicated or redistributed to the child site.

Folders & Filtering:
So now we understand a little more about what we are dealing with. Lets isolate all of the Expired and Superseded updates so they won't interfere with the deployments. In the Software Library expand Software Updates and Right Click on All Software Updates.Select Folder then Create Folder. Call the folder Superseded & Expired

Now we have a place to put the outdated updates lets go ahead and do that. In the upper right corner of the viewing pane you will see Add Criteria. Click on it to expand the selection window. Scroll down and Check Superseded then Click Add

This search is allmost used regularly so it is a good to save this search for easy reference later. Once you have your search results In the Navigation Baron the Search Tab Click Save Current Search As. Call it Superseded = Yes. You will then be able to refer back to this search quickly by clicking on Saved Searches and then Selecting Manage Searches for Current Node

So now we have our filter in place and we have run it so all we should see are the updates that have been superseded. We can confirm that by checking the icons for each update on the left.

In the Display Window select all displayed updates. Right Click on the updates and Select Move.

The Move Selected Items window will open, Select the Superseded & Expired folder and Click OK

This will move all the updates to the sub folder so we  won’t have to sift through them again.

Repeat these same steps for the the Expired items so all we are left with are active current updates.

Software Update Groups:
So now we understand the updates a little better and know how to remove inactive updates, the next thing we need to do is create a Software Update Group. This is a grouping of  updates which is required to be deployed.

Lets go back into All Software Updates and create a new filter. For the purposes of this segment we will be working with updates for Server 2008 R2. So in Add Criteria select Product. You will notice that the default search for Product is Active Directory Rights Management  Services Client 2.0 (its alphabetical).

Click on it and find Windows Server 2008 R2 and Click Search

What you should be left with are all of the current Windows Server 2008 R2 updates. In the viewing pane select all, Right Click and Select Create Software Update Group.

Give it a descriptive name like Windows Server 2008 R2. You can optionally give it a more detailed description. Click Create

Now we are ready to do the deployment. In the navigation window go to Software Update Groups. Find your newly created group for Server 2008 R2. Right Click on it and Select Deploy

Deploying Updates:
The Deploy Software Wizard will start and you can begin providing information for the deployment. The Software Update/Software Update Group should already be selected. As this is our first deployment we won’t have a Deployment Template available so you can skip that (don't worry we will make one shortly). Now from device collections click Browse and select  Server 2008 R2 group. Click Next

For Type of deployment you can choose between Available and Required. Since this is for updates we want this to be Required. If your network is configured for Wake-on-LAN you can check that box, otherwise skip it. For Detail level select Only Success and error messages. Click Next

For Time based on, you can set it either way but I generally prefer UTC. For Software available time you can choose As soon as possible or Specific time. If you use ASAP it content for the client will become available individually as soon as the Distribution Point has it to deploy if you set a specific time it will come as a group of updates. Installation deadline dictates the install behaviour. You can choose As soon as possible which means that as soon as the DP has distributed content the client will install (and reboot if necessary). If you use Specific time it will download update content but wait to install and reboot until the deadline. Click Next

User visual experience indicates what the end user will see in Software Center. Since these are Required updates (set previously) we don't really need to let the users know what is available as they won't have the authority to be selective anyway, so let us set Hide in Software Center and all notifications. Deadline behavior indicates what happens when the client hits the deadline. You want to check both boxes. Device restart behavior is pretty clear. If there is an update that requires the client to reboot, it will. You also want to check Commit changes at deadline.

On Configuration Manager alerts, this can be determined by your update policy so adjust it as required. If you have SCOM configured in your install you can automatically suppress alerts during the update run and send notifications for failed alerts. You should probably check both boxes. Click Next

You can determine what SCCM does with the actual updates in a slow site or boundary, whether to download or not. You can also dictate what the client does if content is not available from its primary server. It can either pull from a FSP or from other clients on the same subnet. If all else fails you can tell the client to pull directly from Microsoft. Click Next

As this is the first time we are deploying updates we will be required to create a Deployment package. This just determines where the updates are placed when you download them. Give the package a name and source location (this should be the WSUSContent folder created during the SUP install). Click Next

we can also determine what distribution points to send content to. Add the DP's as needed and Click Next

To reduce WAN traffic you can pull content straight from Microsoft as opposed to a site server. If you have a decent pipe between sites and boundaries this may not matter. Click Next

Choose the languages required by your environment. Click Next

On the summary page you have the option to save the update template as an answer file for later use. Click Save As Template.

Give it a good descriptive name and Click Save. This will give you the ability to skip steps next time you run updates. Click Next

SCCM will process the request and download the required updates. Depending on how many are in the group this could take a few hours to kick off but in the end you should have something like below.

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.