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 () for supplying some supporting material.
Is this information still valid with SCCM 2012? Does the Windows Update service need to be set to automatic in windows 7 +? The default action is manual and the service is enabled on demand or at least that is my understanding.
Yes this is still valid. The WUA is still used and the service must be set to automatic or manual (whatever is default for the OS) — no changes there for ConfigMgr or Windows. The main point in the above info isn’t about changing anything with the service though, it’s about setting the WUA to disabled using a group policy which has nothing to do with the actual status of the service. The small section about setting the service to automatic can be ignored for Windows 7 and above though as manual is the default for the service and is sufficient.
Hi, Does automatic updates still need to be confined with System Center 2012 R2 and System Center Endpoint protection?
Not exactly sure what you’re asking here. If you’re asking about how to configure updates for SCEP in 2012, see http://technet.microsoft.com/en-us/library/jj822983.aspx. This is different from 2007 mainly because of the ability for ConfigMgr 2012 to auto-deploy updates using ADRs. Thus, it’s actually the ConfigMgr client agent controlling and initiating the updates via the WUA instead of the WUA having to do this autonomously and to answer what I think you’re asking, no, you don’t.
Jason, thanks for the informative article. A quick question. I’f I’m transitioning from WSUS to SCCM 2012 SUP, do you recommend removing all WSUS settings from domain group policy (or setting them to “not configured”) but changing the “Configure Automatic Updates” to disabled? My end goal: I’d like to guarantee the clients don’t auto install anything from MS, but make a nice transition to the updates I’ve approved in SCCM. Thanks!
It doesn’t really matter what you set them to because they really have no effect but I would change them to not configured just to avoid any confusion. And, yes I would absolutely set the Configure Automatic Updates to disabled before you do any transition to ensure your goal — there are many, many cases of systems going out to Microsoft and downloading updates during the transition because they did not do this.
Jason theres something missing here – maybe just cant see the SCCMForest from the SCCMTrees but your point above stating ” It doesn’t really matter what you set them to because they really have no effect ” i.e. domain GPOS for WSUS settings doesnt mesh with what we got hit with on our initial Transition from PURE WSUS patching of our servers with SCCM 2K12R2.
Our WSUS GPO’s were overwriting the SCCM clients settings rendering then incapable of getting updates from the SCCM server. We had to explicitly deny the servers we needed to allow them to use the SCCM server flavored WSUS via Delegation method.
Thats just one part, the real kicker question we are after a soution for after figuring that one above out is the following .
We deploy updates to a collection using the following combo: “As Soon As Possible – Reboot- Required” approach
Our compliancy comes back pretty high Then random days Later clients in the same collection start installing updates and rebooting.
Back to the GPO question – or are we barking up wrong tree to root cause this Latent installation and reboot behaviour?
We ended up removing the distribution points from SUGs and Packages that were created and deleting them
The whole thing has lost credibility until it gets sorted out
Proof of Concept never did this – only diff is the rats nest entanglement of GPO’s arent in POC as they are in Prod
Any direction on this would be highly appreciated as its looking pretty Eeeeeevil and I dont mean subnets LOL
Note the opening sentence: “So how do the *rest* of the settings in the Windows Updates Group Policy section affect Software Updates in ConfigMgr?” Remember that this post is a continuation of the a previous post discussing the settings that must match when using a group policy: only the Intranet location setting truly matters as discussed in that post. The *rest* of the settings are truly meaningless.
Thanks Jason, But I think the domain GPO essentially will MESS up sccm client. For a minute, I choose following Domain GPO’s (Configure Automatic Update)4 = Automatically download updates and install them on the schedule specified below
Specify the schedule using the options in the Group Policy Setting. If no schedule is specified, the default schedule for all installations will be everyday at 3:00 AM. If any of the updates require a restart to complete the installation, Windows will restart the computer automatically. (If a user is logged on to the computer when Windows is ready to restart, the user will be notified and given the option to delay the restart.)
If that settings is enabled you will see reboots happening at the 03:00 AM if no one is logged in to the server. If someone is logged on and you have configured the “No auto-restart for scheduled Automatic Updates installation” then AU won’t reboot the server which technically is going to happen at 03:00 AM. Note: This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the “Configure Automatic Updates” policy is disabled, this policy has no effect
So, if you don’t want unexpected reboots while using ConfigMgr It’s better that we leave the Configure Automatic Update to “NOT CONFIGURED”
Incorrect. Setting a GPO to not configured leaves the default values in place which is to install updates and reboot if necessary at 3AM. “Not configured” in GPOO terms means not enforced centrally, it doesn’t mean the setting is literally not configured. Thus, to prevent the reboot, you need to *disable* automatic updates exactly as I’ve described using a GPO.
Hi Jason, Noob here, at SCCM.. We have installed SCCM 2012 R2 in our Company.
We have many departments with an “IT” person over each department. (this is a headache) can’t seem to get anything done.. But that’s another story..
My question is about Windows Updates. But, First some History..
I have a test Server, in a test OU, under my departments OU in AD. Our ConfigMgr Client has been configured to point to the WSUS used by SCCM. I don’t have access at this time to see my “Client Settings” in CM. I don’t have any GPO settings for Windows Updates, but it is set to “Download But let Me Choose when to install.” So I assume this is set in the Client Setting as well??
I have successfully installed the ConfigMgr Client to my test Server from within Config Manager to my test Collection. I have also installed SCEP 4.5 and have updated it to 4.7 along with daily definition updates. This all works great.
Question: I don’t have anything configured for Software Updates as far as Windows Updates. But when I go to “Control Panel | Windows Update” on my Test Server I see many Updates waiting to be installed.
Why would this be? As I would except to see nothing, as updates come via ConfigMgr Client and a Software Package.
Steve
So I assume this is set in the Client Setting as well??
– No, as noted in the article, the only things set by ConfigMgr are the location of the update server as nothing else really matters to ConfigMgr. I do recommend that you create a group policy to disable automatic updates though.
I don’t have anything configured for Software Updates as far as Windows Updates. But when I go to “Control Panel | Windows Update” on my Test Server I see many Updates waiting to be installed.
– That means that the WSUS server being used by that server, presumably the one integrated into ConfigMgr, has updates approved in it. This is totally unsupported and is generally a bad thing to do. Thus, whoever is managing that WSUS needs to be consulted as to why they are doing this unsupported thing.
Hi Jason, thanks for the reply.. I guess the “Download and let me choose” must be set from an old GPo that had set it in the past, and just removing the GPo didn’t change it on my Test Server..
As far as the updates being approved on the SCCM’s WSUS.. I forgot to mention that we have an Up-stream WSUS that “feeds” our SCCM’s WSUS. If those Updates on the Upstream WSUS are approved, does the Approval flow to the Downstream Servers? Or is someone actually going in to the SCCM’s WSUS and Approving them?
Thanks for the help..
Steve
Could be on the Download and let me choose option. Running a GPResult may reveal where that came from — not sure if there’s any value in finding out though.
Yep, they’re most likely being approved on that upstream server which is replicated to the downstream server servicing as the top level WSUS instance/SUP in your hierarchy. This technically isn’t supported. It shouldn’t (to my knowledge) cause any real issue though except downloading the update binaries needlessly. Disabling automatic updates is definitely in order though to prevent the WUA from actually using those approvals in WSUS to install updates when you’re not expecting them to be installed and outside the control of ConfigMgr.
Jason, I work in a similar environment where we have our SCCM Server, which has a local WSUS instance integrated, pointed to a DISA Upstream WSUS server. To my knowledge, in a classified environment, with no internet access, there is no other way for SCCM to retrieve the update binary files without first approving the updates within the local WSUS, Unless I’m doing something wrong…..
You could also get the binaries from that upstream WSUS instance as well or perhaps another/separate WSUS instance. Ultimately, you are correct though in that some instance of WSUS somewhere should be downloading the updates by having them approved in that WSUS instance. You then must transfer the updates downloaded by that WSUS instance to your internal instance.
Since SCCM doesn’t rely too heavily on WSUS for update deployment, I’m hoping to accomplish the following. On my internet connect SUP, sync to the WSUS upstream server to pull down the metadata, and then tell SCCM to download the binary files from the Internet. Once the updates have fully downloaded, transfer the folder containing the binaries to the SUP with no Internet connection. Then during deployment from the closed network, provide a network location for the binary files. Thoughts?
Hey Jason,
Thanks for writting such a good, informative post. I’ve read both parts a couple of times, but I’m still confused on some bits. To save me repeating myself, would you mind looking at my post on Technet (https://social.technet.microsoft.com/Forums/en-US/1313056b-bc13-452f-8e31-534874b46f0f/sccm-client-pcs-failing-to-downloadinstall-windows-updates?forum=configmanagersecurity) and answering some of my queries. I think you’ve covered it all but I’m failing to understand it all together with GPO’s and SCCM interacting…
Appreciate your comments.
Answered your questions in that thread. Hope that helps.
Jason, greatly appreciate the article!
I’ve implemented a group policy to set Configure Automatic Updates to Disabled and pushed out Windows Updates through SCCM 2012. However, a handful of users thus far have gotten the prompt to reboot or postpone. I checked one of the clients resultant set of policies (rsop.msc) and it does return Configure Automatic Updates as Disabled. Any thought as to why end users are still receiving the reboot prompt? Thank you!
Hi Greg,
The first step is to confirm which reboot prompt that they are getting — WSUS or ConfigMgr. From there you can drill down as to why its showing.
Hi Jason,
I saw this and also the MMS conference you gave on updates. It is still valid that WUA updates only come through WUA and it wont update when this GP option is disabled or is it possible to get the WUA update through SCCM now? If those updates don’t come through SCCM still how is it possible to stay on top of when updates for this are released?
Many thanks for your continuing advice and help,
Andrew
Hi Andrew, No. Luckily, they’ve released the last few WUA updates as stand-alone installers also. It’s different for Win7 than it is for Win8, but that’s manageable: https://support.microsoft.com/en-us/kb/3065987, https://support.microsoft.com/en-us/kb/3065988. You can also still use the WUA Updater script I released a while back to force the update from WSUS though if you prefer this approach: http://blog.configmgrftw.com/scripts-ftw/
WUA client updates seem to be regularly released from Microsoft now and end up in Software Center on all my systems, so this does not seem to be an issue anymore when disabling “Configure Automatic Updates” in a GPO.
Yes, you are correct: Starting in July (or maybe June) of 2015, a new version of the WUA was released almost every month and these updates are available via a hotfix published in the WSUS catalog so this specific issue generally isn’t a concern anymore.
This is a great post! Thanks for taking the time to write it!
Thanks for this info, very helpful.
Thanks a lot for your great sharing. My question here is – Who comes my Servers 2012r2 are still reaching out to Microsoft for updates while I pushed them with sccm 2012r2 ? What do I have to configure or disable? Please help
There’s no way for anyone to know that without looking at the servers and performing some troubleshooting. How do you know that they are contacting Microsoft Updates for updates?
Hi, Jason when iam trying to push windows updates from sccm 2012 r2, iam unable to see any update in any of the client computer, but I can deploy the applications but not windows patches, in our company we have separate wsus server but we are not using that and we have a gpo for that wsus server and in the client machines windows updates have been automatically checked, can you help me on this, thanks.
Hi Ali,
Have you reviewed the wuahandler.log on the clients?
Some related reading here and it is just another method of setting co-existence between SCCM+GPO, still can be a trade off-depends on what you need.
However this has specific settings for a specific outcome.
https://cloudblogs.microsoft.com/enterprisemobility/2013/03/27/group-policy-preferences-and-software-updates-in-configuration-manager-service-pack-1/