The number one reason for update installation failures from Microsoft is because your computers are running an out of date WUA (Windows Update Agent) or its not configured correctly. So how can this occur when we have Config Manager managing our updates and deploying them? Well its because WSUS handles the updating of the WUA agent and its components, not Config Manager. Incorrect Group Policy settings can also cause problems.
A client running the internal SelfUpdate process
There are a number of blogs out there discussing how to correctly implement WSUS, Config Manager and Group Policy, in fact Jason Sandys presented on this at MMS this year (2013). This gives a great overview of how to implement Software Updates ensuring that your WUA updates itself also.
When I upgraded to Config Manager 2012 I experienced quite a few clients that had out of date WUA’s. I was completely oblivious to this, however I identified the issue when decommissioning my old Config Manager 2007 instance. I could see in the IIS logs that I had computers still trying to contact my old WSUS server to do a WUA version check even though these computers had the new 2012 Config Manager agent running on them. This indicated that a number of computers had issues with their settings relating to how they were contacting the new WSUS server. I knew that my Group Policy settings, WSUS and Config Manager Software Updates implementation were correct as the vast majority of my clients were updating and communicating correctly.
So how do we put some checks in place so we can identify those computers with out of date WUA versions and re-mediate them? Well, I have done the following, maybe you will find the following information useful.
According to Microsoft you can use this SQL query:
however you can’t run this from within the Config Manager Console, you get an error about the view being unavailable.
A work around for this is to use the following query which I obtained from a Technet discussion (credit to Jason Sandy’s and those who responded on this page). Go to Monitoring tab within your Configuration Manager Console and create a new query with the following syntax:
select rsys.Name, wua.Version from SMS_R_System as rsys full join SMS_G_System_WINDOWSUPDATEAGENTVERSION as wua on wua.ResourceId = rsys.ResourceId
This will give you a view with results similar to the following:
When I initially ran this in my environment I then noticed a number of computers with out of date agents or no agent version at all even though they had the new 2012 client installed. This can mean that the Config Manager client has yet to run an inventory and upload the information, however in my case I could see that the inventory actions were running and had uploaded data. Subsequently I checked the WUAHandler.log on the problem computers and ran across two distinct issues.
Issue 1.
On some of the computers I could see that the WUAHAndler.log indicated that it was still pointed to the old WSUS server that no longer existed. I was seeing the following error in the WUAHandler.log
*******************************************************************************
Its a WSUS Update Source type ({63897A13-E330-463A-B09E-101151D25935}), adding it.
Enabling WUA Managed server policy to use server: :8530″>:8530″>http:// :8530
Waiting for 2 mins for Group Policy to notify of WUA policy change…
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server “>”>http:// and Policy ENABLED
Failed to Add Update Source for WUAgent of type (2) and id ({63897A13-E330-463A-B09E-101151D25935}). Error = 0x80040692.
*******************************************************************************
For these instances I browsed to the c:\Windows\System32\GroupPolicy\Machine folder on the computer and manually removed the Registry.pol file. This file was then re-created by doing a gpupdate /force on the computer. Following this action, the WSUS server reference in the WUAHandler.log was corrected and the computer then started to communicate with the new WSUS server. So it would seem that this file was corrupted and was not being replaced by my updated Group Policy.
Note: This can also be caused by incorrect Group Policy settings which override any local WSUS server policy that the Configuration Manager client attempts to set so bare this in mind when troubleshooting this error.
Issue 2.
On the remaining computers I was seeing a search related error in the WUAHandler.log, subsequently inspecting theWindowsUpdate.log indicated an issue with the client being able to contact the new WSUS server:
For these computers the problem lied with the machine proxy setting. This was shown when running netsh winhttp show proxy. This setting had been configured but then not removed as part of another internal process within our domain. To correct the communication problem I ran the following from an elevated command prompt then restarted the computer:
Allowing for inventory to be run on the re-mediated clients, the WUA version information then appeared in the SQL Query that I had configured in my environment. Checking the WindowsUpdate.log on those computers also indicated that the self update process was working.
I hope these two issues and their associated resolutions help you with your WUA version compliance when running Software Updates with Configuration Manager 2012!
