I’ve blogged about the *unfun* of the Windows Update Agent (WUA) before, answered many forums posts on the subject, and presented information on it at multiple venues including MMS and IT/Dev Connections. Until recently, I didn’t have a good solution though.
The simple diagram in this post sums up the dilemma. Basically, the WUA is meant to be an autonomous component that does things like install Windows updates, detect pending reboots, and nag the end-user about the first two things. None of these are these are desirable in an enterprise environment though where ConfigMgr exists and should instead be controlling these activities as it causes confusion and undesirable effects. The predominant and generally recommended solution for this is to disable the WUA via Group Policy (you can’t disable the service itself though because ConfigMgr uses the WUA to actually scan for compliance and install updates). [note color="#FFCC00"]Note that systems rebooting at 3AM when you aren’t expecting them to is almost always indicative of the WUA being enabled, detecting a pending reboot, and then restarting the system. This of course is generally bad joo-joos.[/note]
Now we get to the dilemma: the only (supported) way to update the WUA is for it to “self-update” from WSUS. But because it’s disabled, it can’t do this. And your stuck.
The relatively straight-forward solution though is to use a script that does the following:
- Enable the WUA via the registry (most Group Policy settings, including those for the WUA are just registry values).
- Restart the WUA’s service.
- Tell the WUA to update itself.
- Wait
- Restore the registry values for the WUA and restart it again.
Based on this model, I created a VBScript to do all of the above and also adds complete logging and version detection. Simply run this script using a “classic” package and program with the following command-line:
cscript.exe //nologo //B WUAUpdate.vbs