This post is a continuation of my previous post: http://myitforum.com/cs2/blogs/jsandys/archive/2010/05/09/software-update-management-and-group-policy-for-configmgr-what-else.aspx.
So how do the rest of the settings in the Windows Updates Group Policy section affect Software Updates in ConfigMgr? The short answer is that they don’t. These settings effectively control how the Windows Update Agent automatically handles updates. With ConfigMgr, the Windows Update Agent (WUA) is still used as I discussed in the previous post. The key word in the statement is “automatically”; with ConfigMgr in the mix, the WUA doesn’t automatically do anything. It’s not that it can’t do work automatically, it’s that the WSUS server itself does not have any updates for it so it effectively does no work – recall once again that all updates are delivered via the software distribution mechanism in ConfigMgr and not WSUS. When ConfigMgr wants to do anything related to software updates, it directly controls the WUA to achieve the desired result: this includes update scans, re-evaluations, and installation. Thus, all of the other settings are essentially harmless or have no effect.
There are a couple of things to be aware of though. First, if you set the Configure Automatic Updates setting to Disabled, then the WUA will not automatically update itself from WSUS. WUA updates are periodically sent out by Microsoft and are picked up by WSUS. These are not listed as formal updates in WSUS and are automatically pushed out to all client systems set to update.
This may or may not be your desired outcome. In general, it is recommended to set this setting to Disabled and distribute an updated WUA using software distribution in ConfigMgr. If you allow WSUS to perform this task, you have no control over how WSUS pushes the WUA out. Clients will download the updated WUA using BITS, but essentially, every client that checks in will get it as soon as they check in. Depending on your network infrastructure and Software Update Point topology, this could be a bad thing. I have noticed one or two other updates that also do not need to be approved in WSUS but are still made available to clients so the users may also get prompted for these – just something to be aware of.
The other ramification of leaving this setting at Enabled is that the WUA will detect when a restart is pending and display an additional warning to the interactive user which could be very confusing. By default, if an update deployment suppresses restarts, ConfigMgr will display an alert to the user (shown below).
Note that leaving this policy at Not Configured in a GPO doesn’t change anything, it just leaves the actual setting as is whether it was set manually on the system or using another group policy. The ramifications above still apply.
On both Windows XP and Windows 7, at the WUA scheduled scan time (every 22 hours by default), the WUA will check if there any pending restarts. If there are, it will display its own notification (shown below) in addition to the ConfigMgr notification. The only difference I could see between XP and 7 is the ability in 7 to dismiss the notification set it to remind the user at a later time.
So, even though the WUA isn’t actually automatically installing updates, its still trying to help or actually getting in the way depending on how you look at it. And of course, users being users, this will undoubtedly generate at least a few help desk calls.
One thing to note is that setting the Configure Automatic Updates policy to Disabled does not disable the Windows Update service in Windows 7 or the Automatic Updates service in XP (these are the WUA service itself, just different names in the different versions of Windows). It merely disables automatic functionality of the WUA including scanning. The Automatic Updates service must be running for software updates in ConfigMgr to work properly. Using a group policy to set this service to automatic is recommended.
One major monkey-wrench in all of this is Forefront Client Security (FCS) 2007. FCS uses WSUS to push out its updates and definitions. Because definitions can get pushed out many times during a single day, using the software updates functionality in ConfigMgr would be cumbersome to say the least – it just wasn’t built with FCS in mind. Thus, you will have to enable the Configure Automatic Updates policy using a GPO. You should also set this policy to 4 – Auto download and schedule install. However, this will potentially result in the above behavior depending on the timing of the various events involved. Additionally, because definition updates should happen without any user intervention you should also set a handful of other Windows Update related policies according to FCS recommendations. As notes earlier though, these settings have no impact on the software updates functionality ConfigMgr though. (Complete guidance for configuring Software Updates in ConfigMgr for use with Forefront is available at http://technet.microsoft.com/en-us/library/dd185652.aspx.)
Group Policies are great and the Windows Update Group Policies have some great functionality; unfortunately, none of them actually do anything to Software Updates in ConfigMgr. Without FCS, the most you should set in relation to Windows Updates is the Configure Automatic Updates policy to Disabled and forcing the Automatic Updates service to Automatic. With FCS, as described above, this gets a little more complicated because you have to remember that WSUS is actually distributing updates for Forefront and thus the WUA has to be configured accordingly which may subject your users to the double restart notifications and the “uncontrolled” push of an updated WUA.
Thanks to John Marcum (http://myitforum.com/cs2/blogs/jmarcum) for supplying some supporting material.
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_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; 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:
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).