Information on the ConfigMgr 2007 client side process for Software Updates

I want to take a minute and walk through the process a System Center Configuration Manager 2007 client goes through when processing Software Updates but before we get into that I'd like to explain how to find information specific to a particular update in the client side log files.  When viewing the logs on the client you need to reference the GUID that is assigned to each update. To view this GUID for all your updates you can go into the console and anywhere that updates are displayed in a list, right click on the column header (where it has Bulletin ID, Article ID, etc…) and select View –> Add/Remove Columns. You then have to select “Unique Update ID” in the left list and then select “Add”. Now select “Move Up” until the Unique Update ID is the first one in the list on the right. Now if you look at the console, you will see the GUID as the first column in the window, then find your update and you now have the GUID for that update. You can see the updated console display here:

Once you know the GUID for the update in question you can then relate this to the log entries that Software Updates creates. Sometimes they give you both the GUID and the Title of the update:

1. Update (Missing): Security Update for Windows XP (KB961501) (0d841d92-dcfd-42d0-99cc-da46abbfb86c, 101)  WUAHandler                6/16/2009 7:35:32 AM

Sometimes they only give you the GUID:

Update 1 (0d841d92-dcfd-42d0-99cc-da46abbfb86c) finished installing (0x00000000), Reboot Required? Yes            WUAHandler                6/16/2009 7:37:32 AM

And sometimes they like to hide the GUID in the string. You can find the GUID in this log entry by viewing the string after the “SUM_” section:

Update (Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_19986d1f-0652-4816-8d54-0add7d1d444c) Progress: Status = ciStateSubmitted, PercentComplete = 0, DownloadSize = 0, Result = 0x0

So the GUID for this update in this example is: 19986d1f-0652-4816-8d54-0add7d1d444c.

Now on to the process itself.

The Scanning Process:

The SCCM 2007 clients receive their WSUS settings as a local policy on the clients, so if there are any Group Policies that overwrite the local policy it causes issues with our scanning process. We get an error in the wuahandler.log stating that our policy has been overwritten by a higher authority as you can see here:

Group policy settings were overwritten by a higher authority (Domain Controller)

The registry keys where we set this can be seen in this exported registry file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] 
"WUServer"=http://WSUSServer.corp.com:80 
"WUStatusServer"="http://WSUSServer.corp.com:80"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] 
"UseWUServer"=dword:00000001

These are the only keys that need to be set on the client, if they have any others then you need to check and make sure that they do not have any WSUS policies being applied from a previous WSUS implementation. When the client first looks for the existence of the keys it checks only for the “WindowsUpdate” key and not the values themselves. If the key is found, it will do a gpupdate to make sure that we have the latest policy is applied to the client. If for some reason the gpupdate will not complete on the client, we stop processing updates on the client.

When we get a scheduler event that tells us to kick off a scan cycle, or when we initiate the scan manually using the client UI we then query location services looking for our nearest SUP so that we can scan against it. You can see that log entry in the locationservices.log here:

Current AD site of machine is ADSiteName LocationServices 8/18/2009 8:22:05 PM 
Created and Sent Location Request '{5B457934-72DA-4070-A23A-7F5B05423206}' for package {72B140EF-F84E-4AE9-91E2-7F3863634AAB} LocationServices 8/18/2009 8:22:05 PM 
Calling back with the following WSUS locations LocationServices 8/18/2009 8:22:06 PM 
WSUS Path='http://WSUSServer.corp.com:80', Server='WSUSServer.corp.com', Version='696' LocationServices 8/18/2009 8:22:06 PM 
Calling back with locations for WSUS request {5B457934-72DA-4070-A23A-7F5B05423206} LocationServices 8/18/2009 8:22:06 PM

We then send up several state messages of type 501 up to the site server with the current scan state. We then create a state message of Topic Type 500 for each of the updates that are applicable to the machine. You can see the log entries for a manual scan here from the statemessage.log file:

State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:22:06 PM 
State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:22:06 PM 
State message with TopicType 500 and TopicId b94927af-f480-461b-8fe8-464636c33253 has been recorded StateMessage 8/18/2009 8:24:26 PM 
State message with TopicType 500 and TopicId f38d0fed-3fc3-411e-a028-2ecce50f2c07 has been recorded StateMessage 8/18/2009 8:24:26 PM 
State message with TopicType 500 and TopicId 95511f7c-4ffd-40e3-85d6-385abbe423db has been recorded StateMessage 8/18/2009 8:24:27 PM 
State message with TopicType 500 and TopicId ecb8b318-95c6-4f6d-aa45-b15557f70ce2 has been recorded StateMessage 8/18/2009 8:24:27 PM 
State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:24:27 PM

You can find the reference to the Topic Types here: http://technet.microsoft.com/en-us/library/bb932203.aspx

You can also see the scan being kicked off by the windows update agent or WUA, in the windowsupdate.log file in the root of the windows directory. You know the scan is being kicked off by SCCM by seeing the ccmexec line in the log file as you can see here:

2009-08-18 08:41:57:000 1300 db0 Agent ** START ** Agent: Finding updates [CallerId = CcmExec]

The WMI entries related to scanning are below:

Root\ccm\softwareupdates\WUAHandler\CCM_UpdateSource (WSUS Server we scanned against) 
Root\ccm\softwareupdates\updatesstore\CCM_UpdateStatus (Compliance State for each patch)

The Evaluation Process:

Clients receive notification that they need patches through the following policy:

Root\ccm\policy\machine\actualconfig\CCM_UpdateCIAssignment

Each CI corresponds to a particular Deployment that is targeted at the client.

There are three ways that we can initiate an evaluation cycle:

1. Scheduler kicking it off due to an expired CI (Deployment) Deadline or we have met our recurring scheduled time frame

2. We receive a policy that has an assignment of patches that has an expired deadline, in other words there is a deployment targeted at the client and the deadline for the deployment is passed when we receive it

3. We manually kick it off through the Client UI

Once we meet one of these conditions we then kick off the Evaluation Cycle. First thing we do is kick off a scan so that we get the current scan data. We then check each of the assignment CIs that are in our policy. We call the CIAgent thread to tell us what patches are included in the assignment. We compare this list against all the ones that we have listed as applicable in WMI. We then call the SDMAgent to know what binaries are included in the patch package. We then call Patch Downloader who works with CAS (Content Access Service) to find out if the files for the particular package exist in the local cache. If not then we create a Content Transfer job and hand the request off to CTM (Content Transfer Manager). CTM then makes a location services request to find what DPs that are viewable to the client have that package residing on them. Once we get this list back CTM then passes the download processing off to the DTS (Data Transfer Service). DTS determines what transfer protocol it is going to use either BITS or SMB, depending on the list that is returned from the Location Services request. DTS periodically reports back to CAS with the download status of the package. Once complete it sends a completion notice to CAS. CAS then returns success to Patch Downloader who then calls the Updates Deployment Agent to start the installation process.

The Installation Process:

If the policy states that updates can only be deployed during maintenance windows then Updates Deployment checks with Service Window Manager to determine if there are any maintenance windows defined for this client. If not, it then calls WUA Handler and Execution Manager to kick off the installation. If the client does have maintenance windows defined then it will work with the scheduler to set a trigger for the start of the maintenance window. You should see an entry in the UpdatesDeployment log that looks like this:

No current service window available to run updates assignment with time required = 1800 UpdatesDeploymentAgent 8/3/2009 3:09:02 PM 
No service window available to run updates assignment UpdatesDeploymentAgent 8/3/2009 3:09:04 PM 
This assignment ({F65FFEE2-6869-43F3-B86A-B1D293FE0D1B}) will be retried once the service window is available. UpdatesDeploymentAgent 8/3/2009 3:09:04 PM 
EnumerateUpdates for action (UpdateActionInstall) - Total visible updates = 13 UpdatesDeploymentAgent 8/3/2009 3:21:20 PM 
CUpdateAssignmentsManager received a SERVICEWINDOWEVENT START Event UpdatesDeploymentAgent 8/3/2009 7:00:00 PM 
Attempting pending install assignment UpdatesDeploymentAgent 8/3/2009 7:00:00 PM 
Starting install for assignment ({F65FFEE2-6869-43F3-B86A-B1D293FE0D1B}) UpdatesDeploymentAgent 8/3/2009 7:00:00 PM

Once the maintenance window trigger launches the client will look at the first patch that it is to install and see what the max run time is set to. It then takes that value and adds 15 min to it to allow for a reboot of the machine. If there is at least this long available until the expiration of the maintenance window, it will then install the patch. It will do this same calculation for each and every patch. By default the max run time for patches is set at 20 min and can be changed by bringing up the properties to the update in the console. If there is not enough time left in the maintenance window, it will then stop the install and wait until the next maintenance window is available.

Once the installation is completed we then pass off to the Update Store process who kicks off another scan so that we can update WMI with the latest state and then it creates the state messages that are sent up to the server with the updated installation compliance. There are five compliance states that a patch can be in on a client:

1. Installed 
2. Needed 
3. Not Needed 
4. Soft Reboot (Reboot requested but we can still install other patches) 
5. Hard Reboot (Reboot requested, we cannot install anything else until this is completed, not even other MSI installs)

On the Site server there is one more state and that is “unknown”. This state means that the server downloaded new metadata about a patch but that the client in question has not scanned for the patch and reported back to the site server with its compliance state.

You can see the entries in the logs for the installation status in the wuahandler.log like this:

1. Update (Missing): Security Update for Windows XP (KB961501) (0d841d92-dcfd-42d0-99cc-da46abbfb86c, 101)  WUAHandler                6/16/2009 7:35:32 AM  
2. Update (Missing): Cumulative Security Update for Internet Explorer 7 for Windows XP (KB969897) (38942b2d-e662-490b-8a67-d69bb73d28e3, 101)          WUAHandler        6/16/2009 7:35:32 AM 
3. Update (Missing): Security Update for the 2007 Microsoft Office System (KB969679) (57adacc9-c673-40b7-a946-6671ab71ad23, 101)                WUAHandler        6/16/2009 7:35:32 AM  
4. Update (Missing): Security Update for Windows XP (KB970238) (723b4632-b686-45b3-8aa5-6e638e598657, 101)               WUAHandler                6/16/2009 7:35:32 AM

You can then see the completion status and if the patch requires a reboot later in the wuahandler.log file:

Update 1 (0d841d92-dcfd-42d0-99cc-da46abbfb86c) finished installing (0x00000000), Reboot Required? Yes            WUAHandler                6/16/2009 7:37:32 AM 
Update 2 (38942b2d-e662-490b-8a67-d69bb73d28e3) finished installing (0x00000000), Reboot Required? Yes        WUAHandler                6/16/2009 7:37:55 AM  
Update 3 (57adacc9-c673-40b7-a946-6671ab71ad23) finished installing (0x00000000), Reboot Required? No           WUAHandler                6/16/2009 7:38:24 AM  
Update 4 (723b4632-b686-45b3-8aa5-6e638e598657) finished installing (0x00000000), Reboot Required? Yes        WUAHandler                6/16/2009 7:38:28 AM

We then send up the state message for the one that did not require a reboot as you can see here in the statemessage.log file:

State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_57adacc9-c673-40b7-a946-6671ab71ad23 has been recorded StateMessage       6/16/2009 7:40:45 AM

We then can see after the reboot the entries in wuahandler.log where it finished the install:

Update (0d841d92-dcfd-42d0-99cc-da46abbfb86c) has finished the post reboot operation. HResult: 0x00000000.   WUAHandler                6/16/2009 7:44:44 AM\ 
Update (38942b2d-e662-490b-8a67-d69bb73d28e3) has finished the post reboot operation. HResult: 0x00000000.                WUAHandler                6/16/2009 7:44:44 AM 
Update (723b4632-b686-45b3-8aa5-6e638e598657) has finished the post reboot operation. HResult: 0x00000000.                WUAHandler                6/16/2009 7:44:44 AM

We then see in the statemessage.log file where we send up the state message for the patches that did require a reboot:

State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_0d841d92-dcfd-42d0-99cc-da46abbfb86c has been recorded   StateMessage       6/16/2009 7:46:58 AM 
State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_38942b2d-e662-490b-8a67-d69bb73d28e3 has been recorded StateMessage       6/16/2009 7:46:58 AM 
State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_bbf29408-fe2d-4adb-b9da-af6245b16e42 has been recorded  StateMessage       6/16/2009 7:46:58 AM

Additional Information:

If your Update Store in WMI on the client gets out of sync with what the server shows installed then you can run a script to resend a full compliance state using this link:

 http://gallery.technet.microsoft.com/ScriptCenter/en-us/db05902e-dfa3-4401-87d6-1a93aea85642


Group Policy Which needs to be configured  
Always Ensure that the following three policies mentioned are not be configured from domain level. The SCCM client will apply the policy whenever it is required.

a. Allow signed content from intranet Microsoft update service location.

b. Specify intranet Microsoft update service location

c. Automatic Updates Configuration
 
 See Tech net article for more details – http://go.microsoft.com/fwlink/?LinkId=94680.