ConfigMgr Software Update Management and Group Policy

There is definitely a lot of confusion about how Group Policies interact with, control, and affect Software Update Management (SUM) on ConfigMgr clients. At the outset of this post (or series of posts), I don’t even know exactly what’s going to happen with some of the different settings and combinations that I’m going to try and then document.

The Windows Update Agent

The Windows Update Agent (WUA) is the key Windows component that handles both update scanning and update application to a system — this is the same whether the system uses Microsoft Updates from the web, WSUS, or ConfigMgr for updates. Because ConfigMgr actually uses WSUS, these two methods have a few things in common, specifically, the actual delivery of the update catalog to the clients. In both cases, this comes straight from WSUS and thus the use of the same group policy setting(s). Additionally, there are other settings in group policy that effect how the WUA agent behaves which I intend to explore.

Domain Group Policies vs. Local Group Policies.

As their names imply, domain group polices originate from the domain and local group policies originate on the local system. A common misconception is that local group policies are simply local registry edits in one of the above policy keys. This is not true; although you may get the desired result, this is not a true local group policy. To edit a local group policy, you must open the local group policy editor: gpedit.msc. Also note that domain group policies overwrite settings defined in a local group policy without prejudice on a setting by setting basis. Thus, only settings actually configured in the domain group policy will trump those defined in the local group policy; settings defined in a local group policy and not in the domain group policy will be left unaffected.

Why is the local vs. domain distinction important? Because ConfigMgr uses local group policies to configure the Windows Update settings on all managed clients. The clear implication here is that if you have any Windows Update settings in a domain group policy, they will overwrite those that ConfigMgr sets. The settings in the screenshot below were configured by the ConfigMgr agent in my lab environment and viewed using gpedit.msc.

So what happens if we do have a domain group policy and how can we troubleshoot this? It depends on which settings are applied in the domain group policy.

Setting the Server

The first setting to test is the actual update server. First, I’ll set it to the same value that ConfigMgr sets it to.

First a gpupdate /force and then initiate a Software Update Scan Cycle from the ConfigMgr agent Control Panel applet and check wuahandler.log on the client.

So far so good. Next, let’s set the domain group policy to point to another server and see what happens.

Another gpupdate /force, initiate a Software Update Scan Cycle again, and finally check wuahandler.log.

Egregious FAIL!

Notice what the log file says here: “Group policy settings were overwritten by a higher authority”. From this it is apparent that ConfigMgr checks to make sure that the WSUS settings do match up with those that it expects, namely the server location, and if they don’t it “gracefully” stops processing.

One of the first things I tried way back when at a customer site was to trick the process by overwriting the values directly in the registry. As many folks know, all of the group policies contained in the Administrative Templates section ultimately just set registry values (see What Is Administrative Templates Extension? for more information). The Windows Updates settings are in this section and thus update specific registry values located in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate; note that the WUA will not automatically notice that you’ve updated the values manually so you must restart the Automatic Updates service to make them effective.

So what are the results? As you may (or may not) expect, everything worked. Of course, as soon as group policy decides to refresh, you’re back at square one.

One thing I learned in testing and verifying the above was that if the Windows Update server is set to a name that either does not resolve or is not a valid WSUS server, Windows Update is not a happy camper and neither is the ConfigMgr agent. It took multiple stops and starts of the Automatic Updates service and the SMS Agent Host once a valid update server is set for everything to work as expected again. It seems that if Windows Update has any kind of error connecting to the configured update server, the ConfigMgr agent refuses to do anything as far as software updates go — the wuahandler.log will show an initial error message but then will not show anything else until the problem is corrected, which as I just mentioned, took restarting both services. If I was patient, I think things might sort themselves out eventually, but restarting the services expedited the process.

XP: Keep Your Computer Up To Date

Another thing I noticed on my XP test client is that if there are no policies applied, either local or domain, and Windows Update has not been manually configured, then the “Keep your computer up to date” notification icon is displayed along with the associated balloon message. This is the default state of all Windows XP systems in my experience.

As soon as a Windows Update policy is applied though, including the ConfigMgr local group policy for Windows Updates, the icon and balloon are removed. This can be seen in the WindowsUpdate.log.

Windows 7: Action Center

The (nearly) equivalent behavior in Windows 7 is handled by the Action Center as seen below. However, getting rid of this message is not the same as in XP. The Action Center is a completely separate component from Windows Update and thus its messages are not generated by the WUA itself. To get rid of this message, you must set the “Configure Automatic Updates” setting; the local group policy set by ConfigMgr for Windows Updates is not sufficient. By default (in my testing at least), this setting is already set on the component at install time to “Auto download and schedule the install” and so you don’t actually need to do anything. If for some reason it’s not set though, just use a group policy to set it (local or domain).

If you set the “Configure Automatic Updates” setting to anything other than the default “Auto download and schedule the install” including disabling it, the Action Center will show the following message:

The Action Center itself is way beyond the scope of this blog, but I did dig up a few links for reference:

• How To Manage Action Center in Windows 7
• Group Policy Settings for Action Center
• Engineering Windows 7 : Action Center
• Disabling a specific Action Center message via script or registry key

This blog post is long enough now so I’ll continue in another post tomorrow (hopefully). Next up is looking at the other “Configure Automatic Updates” settings and how they affect Software Updates in ConfigMgr as well as actually stopping the WUA service (i think we can all guess what happens when we do that).