Software Updates–INTERNALS! (MMS 2011 session)–part III

In this final installment of this software updates series we will review the software update synchronization process.  There are a couple of variations of the sync process but, as you might expect, all involve a WSUS server – known as a software update point in ConfigMgr– at each primary (and in some cases secondary) site where software updates will be deployed.  The software update point at the central site (which is also a primary site) is the location where some of the variations in the sync process can be introduced because the central site is the location where all software updates are retrieved and initially placed into the ConfigMgr hierarchy.  That said, lets start at the central site.

We will start our discussion at the point where everything has been installed already.  If we then look under component configuration in the console we can review our settings for the software update point.  The setting we care about for this discussion are on the ‘sync settings’ tab.

The top settings that specify the synchronization source are the ones we care about.  At the central site only two of the three settings make sense – the first and the third. 

The first setting configures the software update point to retrieve the catalog of updates from the internet Microsoft Update servers. The third option configures the sync process to simply query the local WSUS server (which is also the software update point) for any new updates and synchronize from there. This third option allows ConfigMgr hierarchies that do not have access to the internet to still be able to do software updating but requires manual importing of the update catalog from a WSUS server that does have internet access. This manual export of the update catalog from an internet connected WSUS server and then manual import can be time consuming.  To do the import and export simply use the WSUSUTIL utility included with WSUS.

You might have a few questions on the sync process after reading the previous paragraph. I’ll try to address what I think you may be asking shortly.

If we take a look at the ‘sync settings’ tab on a child site we see that the options are all grey and the sync choice is set to option 2 – which simply means that the site will make use of the immediate upstream WSUS server (software update point) for it’s synchronization needs.

Now that we understand the sync settings lets dig into the sync process.  There are two ways to initiate a software update synchronization in ConfigMgr – on a schedule and manually.  To set a sync schedule for software updates you use the same component configuration page we just discussed – take a look at the ‘sync schedule’ tab.  Also note that the component configuration page for the central site is the only place where you can configure a sync schedule.  The reason is that the central site is the master site for the hierarchy – when it syncs it will notify the child sites that they should also sync – so an independent sync schedule at the child sites is not necessary. 

Another way to start synchronization is to navigate to the software updates node, choose Update Repository > Run Synchronization.  A warning will be displayed that this could take a while – select past the warning and the sync process will start.  Note that just like you cannot set a sync schedule at a child site you also cannot run a manual synchronization anywhere but at the central.

The sync process will start.  For our example we will trace the process that happens when ConfigMgr is configured to sync from Microsoft Updates.  The logs here are significantly truncated to focus on just the interesting parts.  As synchronization happens the log will reflect the process on an either a group of updates basis (first step) and then on an update by update basis (second step) – so there is a bunch of logging. 

All of the sync processing is recorded in the WSYNCMGR.LOG on the ConfigMgr server.  When configured to sync from Microsoft Updates the sync process is actually two steps.  The first step is to retrieve all new updates metadata and store it in the database of the WSUS server.  The second step of the process copies and transforms all of the update metadata from the WSUS database to the ConfigMgr database.  This might raise a question or two.  Why would two steps be required for the sync and why would the same metadata be duplicated between two databases?  Isn’t that a waste?  Good question.  Let me explain.  When the metadata is initially retrieved and stored in the WSUS database it is in the form WSUS expects and can use – but we still have to get the update data in a form ConfigMgr can use which is to convert this information to CI’s and SDM packages (see part II of this blog series for more info on CI’s/SDM’s).  You still may have a question as to why.  Remember that in ConfigMgr the WSUS server (software update point) is solely used for scanning.  There is no patch retrieval or patch distribution happening through WSUS.  All of the patch retrieval and distribution is done through ConfigMgr which allows the added benefits to updating that ConfigMgr brings compared to using stand-alone WSUS.  THAT is the reason we have to get the update data in a form that ConfigMgr can use through conversion. 

Lets take a look at the WSYNCMGR.LOG and see this in action.  The first and second line of the log shows that this is a manual sync request.  At line 5 we see that we are starting to synchronize the WSUS server – the name of that server happens to be SCCM – this is made more clear in line 6.  The first thing that we need to sync on line 7 is the categories – to see if any additional categories have been added at the Microsoft Updates server.  From there we start to synchronize the updates – we see there are 488 of them to pull down.  Note that we don’t sync all updates unless every update category is selected under component configuration.   We finally finish update sync from the Microsoft Updates Server and log a status message.

Step 2 of the sync process then starts.  Line 1 shows that the SMS database is now being synchronized with the WSUS server.  This is specifically called out on line 3.  We first make sure all update categories are copied over and then start to synchronize the updates themselves.  The update sync process has started in the last two lines of the log snip – for this sync we just have 167 updates to pull over so it shouldn’t take long.  Note that the updates are referenced by their unique update ID.  In some cases you will also see the update name and KB.

At the end of the synchronization we see in the log that the update process reports how long it took.  If this site were part of a hierarchy we would also see that the child sites are being requested to synchronize.  This server is a stand-alone so there is no need.

The following snip is from a primary site that has been requested to synchronize by it’s parent.  Note that there is no need to sync from Microsoft Updates so we just go immediately into the process of pulling updates down into the ConfigMgr database.  We also see at the end of the snip that the sync request is being sent down further to the secondary site - which is a child of the primary – to request it sync from the primary.

And to complete the picture the next snip is from a central site that is configured for option 3 in the sync settings – this option is the one for a ConfigMgr hierarchy that does not have internet access and will need the updates imported to WSUS manually.  In such a case there is no need for the WSUS server to try and sync from the internet so step 1 is omitted and we start straight away with step 2.

And that’s it!