Limit of 1,000 Software Updates in a Deployment

Be sure to limit the number of software updates in your Software Updates Deployments. Configuration Manager 2012 supports up to 1,000 software updates per deployment. When using automatic deployment rules, be sure that the criteria you use will not return more than 1,000 software updates as a result.

Software Updates in Configuration Manager Are Always Downloaded to the Client

Software updates are always downloaded to the local client cache before they are run in Configuration Manager. You no longer have the option to have them run from a distribution point as you did in SMS 2003.

Deployment

The compliance assessment data is then used to determine which software updates are required on client computers. When you create a software update deployment with the Deploy Software Updates Wizard, as described later in this chapter, the software updates in the deployment are downloaded from the location specified on the Download Location page of the wizard to the configured package source, if they haven’t been downloaded already. When the wizard finishes,  deployment policy is added to the machine policy for the site. The updates are then copied from the package source to the shared folders on the distribution points set up in the package, where they will be available for clients.

When a client in the target collection of the deployment receives the machine policy, the software update client component starts an evaluation scan. Updates that are still required on the client are then added to a class in Windows Management Instrumentation (WMI). Any updates that are mandatory deployments are downloaded as soon as possible from the distribution point to the local cache on the client. The updates in the optional deployment category are not downloaded until they are manually started. If an optional deployment has a deadline that makes it mandatory, the client will download the update as soon as it registers the change in deployment status.

If the client can’t find the location of the distribution point through Location Services (via requests of the management point), it will keep trying to find a distribution point for up to 5 days before it stops. If the client can’t connect to the distribution point to which it has been referred as a source of the software updates in order to download the updates, it will try for up to 10 days before it stops trying. When you start updates manually, the client will try every hour for each distribution point for up to 4 hours before it fails.

When an update deployment has a deadline that becomes available for deployment on a client, the Available Software Update icon will show up in the notification area to tell a user that the deadline is coming up. By default, these display notifications will show up on a periodic basis until all mandatory updates have been installed. They will be displayed every 48 hours for deadlines more than 24 hours away, every 4 hours for deadlines less than 24 hours away, and every 15 minutes for deadlines less than an hour away.

Just imagine the phone calls you’d get if you left things that way! Fortunately, Microsoft has given you the option to turn these notifications off with the client agent settings that let you hide all software update deployments from users. This setting doesn’t affect regular Software Deployment settings, but it will keep display notifications, notification area icons, and software update installation progress boxes from appearing at all. However, this will also mean that you can send out only mandatory software update deployments to your clients. We recommend doing this anyway because users will more than likely delay deployments until they become mandatory.

Unless you hide your update deployments, users will be able to open the Express/Advanced dialog box to start up the installation of all mandatory software updates at once. They will also be able to open the Available Software Updates dialog box, where they can choose to install whatever is available.

When the deadline passes on a mandatory update, a scan will start on the client to make sure that the updates are still required; the local client cache will be checked to make sure the updates are still available, and then the updates will be started. When that is done, another scan will start to make sure that the updates are no longer required on the client. Finally, a state message is sent to the management point saying that the updates are now installed.

Compliance

When software update synchronization completes at each site, a sitewide machine policy is created that allows client computers to retrieve the location of the WSUS server and to start a scan for software update compliance. When a client receives that machine policy, a compliance assessment scan is scheduled to start at a random time within the next two hours. When the scan runs, a component of the client Software Updates Agent clears the previous scan history, sends a request to find the WSUS server that should be used for the scan, and then updates the local Group Policy with the WSUS server location.

The scan request is then passed to the Windows Update Agent (WUA). The WUA then connects to the WSUS server that it just got information about, downloads a list of the software updates that have been synced with the WSUS server, and scans the client computer for the updates in the list. A component of the Software Updates Agent then sees that the scan for compliance is finished and sends a state message for each software update that had a change in compliance state since the last scan. Those state messages are then sent to the client’s management point in bulk every five minutes. The management point will then forward the state messages to the site server, where they are inserted into the site server database.

Supersedence occurs when a new software update has the same fixes as a previous update but may have fixed issues with the update and/or added new fixes. In SMS 2003, when new software updates supersede ones that had the same fixes, they may both be marked as needed when only the new one is necessary. In Configuration Manager 2012 Software Updates, you can now configure the supersedence behavior; you can either choose to expire a superseded update or choose to expire the update after a configurable number of months at the software update point. When new software updates are released that supersede others, Microsoft Update is refreshed with that information. When client computers are scanned for compliance, the new updates produce a compliance state by the client, but the older updates do not. The only time this is not the case is when a service pack contains a required update. The WUA will then return a compliance state on both, which allows admins to deploy individual updates or service packs as needed. Table  shows details on the four states of compliance for Software Updates. 

State	Description
Required	The software update is applicable to the client, which means any of the  following conditions could be true: ◆ The update has not been deployed to the client. ◆ The update has been installed, but the state of the update hasn’t been updated in the database yet. ◆ The update has been installed, but the client requires a reboot before it finishes. ◆ The update has been deployed but is not yet installed.
Not Required	The update isn’t applicable on the client.
Installed	The update is applicable on the client, and it has already been installed.
Unknown	This state usually means that the software update has been synced to the site server, but the client hasn’t been scanned for compliance for that  update.

 

Synchronization

Synchronization is the process of retrieving the metadata for software updates that meet the configured criteria; it can be retrieved from either the upstream Windows Server Update Services (WSUS) 3.0 SP2 server or Microsoft Update. The WSUS Synchronization Manager component on the software update point works with WSUS to complete the synchronization process.

The highest site (Central Administration Site) in the Configuration Manager hierarchy that has a software update point synchronizes with, for instance, Microsoft Update; this is done either on a schedule you set up or manually by using the Synchronize Software Updates action on the All Software Updates node in the Configuration Manager console. (We go into more detail on how to do that later in the chapter.) When a sync cycle is started at the CAS, the WSUS Synchronization Manager makes a request to the WSUS service to start a sync cycle. The software update’s metadata is then synchronized from Microsoft Update, and any changes are inserted into the WSUS database.

When WSUS finishes its sync cycle, WSUS Synchronization Manager starts syncing with the WSUS database and inserts any changes into the site server database. When that process is finished, the WSUS Synchronization Manager component (SMS_WSUS_SYNC_MANAGER) creates a status message with an ID of 6702.

When a software update sync finishes at the CAS, a sync request is sent out to all of its child sites. When a child site gets that request, it will first sync itself from its parent site and then send out a request to any child sites that are configured as software update points. This continues on down the hierarchy until all child sites have been synchronized. With an Internet-based software update point (which is also used in Network Access Protection scenarios), a sync request is sent to it right after the software update point that synchronizes with the synchronization source is finished with its syncing request. 

The process for both is the same except that the upstream server of the Internet-based software update point is automatically configured to be the first software update point for the site, and the site server database is not updated when the Internet-based software update point finishes its sync cycle. If the synchronization fails, there is a retry interval of 60 minutes. The WSUS Synchronization Manager component will schedule the sync to run again 60 minutes after the process fails and start over. WSUS Synchronization Manager will create a status message with an ID of 6703 in the case of a sync failure.

Difference between Scheduled and Manual Synchronization

A scheduled synchronization does a full sync, but the Run Synchronization action does only a delta sync. Updates are marked as expired if they are superseded by another software update or marked as expired in the update catalog. They are marked as expired only during the scheduled synchronization.

When a sync is run on a schedule, all changes to the software update metadata since the last scheduled sync are put into the site database. This includes metadata that is new (products, languages, and so on), modified, or removed. A manually run sync will be faster than a scheduled one because it downloads only delta changes to what already exists in the database.

The Software Update Process in Configuration Manager

As you’ll see throughout the hands-on portions of this chapter, the biggest parts of the software update process are planning and configuration. After you’ve completed those, Configuration Manager itself performs three main operational phases: synchronization, scanning for compliance, and deployment.

• Synchronization
• Compliance
• Deployment

Automatic Deployment of Patch Tuesday Software Updates

The Automatic Deployment Rules feature allows you to automate the deployment of software updates. You can use it to automatically deploy the Patch Tuesday software updates for test purposes or prepare the deployment in production. Depending on your requirements, you can configure an automatic deployment rule for Windows 8 or 8.1 Patch Tuesday updates by creating an automatic deployment rule with the following steps:

1. Create a new software update group each time the rule runs. This way you are able to group the update groups per Patch Tuesday cycle, and you will limit the size of the software update deployment.
2. Select Enable The Deployment after this rule has run.
3. Select a collection with your test systems where you want to automatically test the Patch Tuesday patches.
4. Supply the following search criteria for the rule:
     ◆ Product: Windows 8 ORWindows 8.1
     ◆ Date Released Or Revised: Last 1 Day
     ◆ Update Classification: Security Updates

 

5. Before going further, preview the number of updates that will be initially discovered. This way you can test your criteria before going into production and, for instance, accidently automatically deploying hundreds of updates.
6. Evaluation Schedule: Be sure the evaluation runs after the Software Update Synchronization Schedule on the second Tuesday of every month.
7. Deployment Schedule: Enable the availability of the deployment for four hours after the deployment is created so that you are sure that the deployment has been distributed throughout your Configuration Manager hierarchy. Configure whether you want the deadline for the deployment.
 

After you configure the rest of the automatic deployment rule, the rule will create a software update
deployment every second Tuesday of the month.