This post is a continuation of my previous post: ConfigMgr Software Update Management and Group Policy.
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.