Chris Mosby at myITforum.com

In a thread over in the forums we have been discussing the Software Update process among other things.  I copied a snippet of the book that Chris Urban and I have been working on, so I might as well blog about it here as well.  This is from the unedited first draft of  Chapter 14 Deploying Software Updates, so please be gentle

The Software Update Process in ConfigMgr

Software updates in ConfigMgr are composed of two main parts.  The metadata is the information about each software update that is stored in the site server database.  The other part is the software update file, which is what gets downloaded and run on the ConfigMgr client to install software updates. 

There are three main operational phases, after planning and configuration have been completed.

Synchronization

This is the process of retrieving the software updates metadata that meet the configured criteria from the upstream Windows Server Update Services (WSUS) 3.0 server or from Microsoft Update.  The WSUS Synchronization Manager component on the SUP works with the WSUS services to complete the synchronization process.  The highest site in the ConfigMgr hierarchy (the central site in most cases) with an active software update point synchronizes with Microsoft Update, either on a schedule you setup, or manually by using the Run Synchronization action on the Update Repository node in the ConfigMgr Console (We will go into more detail on how to do that later in the chapter.).  When a Sync cycle is started at the central site, the WSUS Synchronization Manager makes a request to the WSUS service to start a sync cycle. The software updates 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 synching 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.

Sidebar - Difference between scheduled and manual synchronization

Scheduled synchronizations will do a full sync, but using the Run Synchronization action will only do 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 only marked as expired during the scheduled synchronization.

End sidebar

When a sync is run on a schedule, all changes to the software updates metadata since the last scheduled sync are put into the site database.  This includes software updates metadata that is new, modified or removed. A manually run sync will be faster than a scheduled one, since it is only downloading delta changes.

When a software update sync finishes at the central site, 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, then send out a request to any child sites that are configured as a software update point. This continues on down the hierarchy until all child sites have been synchronized.

With an active Internet-based SUP, a sync request is sent to it right after the active software update point is finished with its syncing request. The process for both is the same except the upstream server of the Internet-based software update point is automatically configured to be the active 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 all over.  WSUS Synchronization Manager will create a status message 6703 in the case of a sync failure.

When an SMS 2003 site is upgraded, supported software updates are migrated into ConfigMgr database and marked as Expired.  Before ConfigMgr clients are able to scan for update compliance and before software update deployments can created, those updates must be put back into an active state by running a sync cycle.

SMS 2003 clients that are on a ConfigMgr site will use the Inventory Tool for Microsoft Update (ITMU) to scan for updates that are in the Microsoft Update catalog. This catalog must be synced for the SMS 2003 clients to be able to scan for the latest updates. By default, the ITMU tool will update the catalog every 7 days using the ITMU advertisement that is setup when it was installed on the SMS 2003 central site.

Compliance

When Software Update synchronization completes at each site, a site wide 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 randomly within the next two hours.  When the scan runs, a component of the Software Updates Client 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 and 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 Client 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 is when a new software update has the same fixes as a previous update, but may have fixed issues with the update and\or have added new fixes.  In SMS 2003 new software updates that supersede ones that had the same fixes, may be both marked as needed when only the new one was necessary.  In ConfigMgr software updates now uses the Windows Update Agent (WUA) and partially fixes this problem.  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 14.3 show details on the four states of compliance for Software Updates

Table 14.3

Deployment

That 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, 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 it hasn’t been downloaded already. When the wizard finishes, a 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 (DP) 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 and evaluation scan.  Updates that are still required on the client are then added to a class in WMI. Any updates that are mandatory deployments are downloaded as soon as possible from the DP 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.

Sidebar - Software Updates in ConfigMgr are always downloaded to the client

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

End sidebar

If the client can’t find the location of the DP through Location Services, the client will keep trying for up to five days before it stops.  If the client can’t connect to the DP 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 DP for up to four hours before it fails.

When an update deployment has a deadline that becomes available on a client, the Available Software Update icon will show up in the notification area that will tell a user that of the deadline that 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 three hours for deadlines more than 24 hours away, every hour for deadlines less than 24 hours away, and every 15 minutes for deadlines less than an hour away.

Just imagine the phone calls if you left things that way!  Luckily Microsoft has given you the option to turn that off with a site wide setting that lets you hide all software update deployments from users.  This setting doesn’t affect regular Software Distribution settings, but it will keep display notifications, notification area icons, and software update installation progress boxes from showing up at all. However, this will also make it where you can only send out mandatory software update deployments to your clients.  We would recommend doing that anyway, since users would more than likely delay deployments until they were mandatory in the first place.

Unless you hide your update deployments like is mentioned above, users will be able to open the Express/Advanced dialog box to start up the install of all mandatory software updates at once.  They will also be able to open the Available Software Updates dialog box, and then they can chose 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 update is still required; the local client cache will be checked to make sure that the update is still available, and then begin the install of the update.  When that is done another scan starts to make sure that the update is no longer required on the client and then a state message is sent to the management point saying that the update is now installed.