Home > GPO, Windows2012, Windows2012R2, WSUS > HOWTO: Dealing with Windows 2012 and 2012 R2 Windows Update Behavior and the 3 Day Delay

HOWTO: Dealing with Windows 2012 and 2012 R2 Windows Update Behavior and the 3 Day Delay

So let’s assume for the moment, that you’re a guy trying to work on some pretty detailed WSUS update deployments for a mixed OS network. This network will included some Windows 2012 and Windows 2012 R2 servers. You configure your WSUS server to auto deploy updates at some time – let’s say Sunday at 3:00AM. Then you check on Monday and realize that some of the servers still have a > 24 hour uptime, so updates must not have installed. You get busy, forget about it thinking the updates failed, and go about your day.

Then Wednesday morning you identify that some of the servers restarted at 3AM. Which is odd, because you didn’t do any maintenance. So something must be broken, now we need to investigate.


Hello, Microsoft KB2885694. It seems in this KB, they’ve released an update to allow 2012/2012R2/8/8.1 to have a more controlled update experience. Gone are the “we’re restarting in 15 minutes” that is non-cancellable. Now what you can do is create a schedule maintenance window, and allow things to happen IN that window. So you’ll install updates and wait for that window to reboot. That might be when you deploy other software as well. Or do weekly reboots. Or just stop monitoring the system to send alarms. Either way, it’s a quasi-good thing. Unless you’re EXPECTING it to do what it has done in Windows 2003/2003R2/2008/2008R2.  If you’re not in an environment that does a lot of patches, or doesn’t do them regularly, and have only recently added 2012/2012R2 systems, this may catch you off guard. 

The body of the text on this is:

KB 2885694 introduces two main changes that define how Windows Update on Windows 8 and Windows Server 2012 computers can be configured using group policy. All policies mentioned are located at this path:

Computer Configuration / Administrative Templates / Windows Components / Windows Update

When enabled with a value of 4…

The Configure Automatic Updates group policy works identically to the Windows 7 / Windows Server 2008 R2 and earlier behavior.

On Windows 8 and Windows Server 2012 without KB 2885694 installed, that policy could configure the main automatic updating setting, but configuring the scheduled install day and time had no effect. After installing KB 2885694, the policy will enable you to configure machines to:

  • Install updates during automatic maintenance, the default behavior, or
  • Install updates at the scheduled day and time defined in the policy

A new group policy called Always automatically restart at the scheduled time enables restarts soon after updates are installed, instead of 3 days later

Also, in the link for http://support.microsoft.com/kb/2885694 is the following important nugget:

However, the scheduled day and time in this policy setting has no effect. The computer still installs downloaded updates during automatic maintenance, which defaults to 2:00 AM. Additionally, the computer no longer restarts 15 minutes after installing updates. To help avoid unintended data loss, a restart timer instead begins 3 days after updates are installed, and only when you are actively using the computer and are able to see and react to the restart timer.

Let’s talk about that last bit “only when you are actively using the computer”. This means the timer MAY NOT START, until an interactive login happens. So no one logs in until Tuesday afternoon at 2PM. All well and good. But THEY don’t know about this process, and they ignore the message. Guess what happens on Friday at 2PM? That *IS* 3 days later after all…

That would be good to know. So you have a few options:

1) Install the update(s) and get understanding of the options, making it more “Windows 2008R2” ish.

2) Deal with the new method, and create some process that automatically restarts during maintenance

3) Create a process that will watch for a “RebootPending” status and when found, reboot. Obviously this has some danger to it, if you try to do this anytime. But if you do it just say “Sunday from 3:00-5:00AM” you’d probably be fine. Until you tried to do mass updates on say a Quarterly Outage on a Friday night at 8:00PM and couldn’t figure out why 30% of your servers aren’t updating.

So for now, my suggestion would be to move towards the Windows 2008R2 method. Likely, you need to do that anyways, as you have a mixed OS fleet to support, so accept the lowest common method. Note though, that’s not as simple as you’d think So – how do you DO that? The same link (http://support.microsoft.com/kb/2885694) indicates how – but you have to read it carefully:

An update is available that lets you control how the Automatic Updates client applies updates in Windows 8 and Windows Server 2012. After you install this update, the "Configure Automatic Updates" policy setting will work again as it used to in previous Windows operating systems. Instead of installing updates during the daily maintenance cycle, Windows updates will be installed at the time and day that are scheduled in the "Configure automatic updates" policy setting.  
This update also introduces the following Group Policy setting that you can configure to force the computer to automatically restart sooner in order to finish installing important updates:

Computer Configuration\Administrative Templates\Windows Components\Windows Update\Always automatically restart at the scheduled time

Update information

To obtain this update, install update rollup 2883201. For more information about how to obtain this update rollup package, click the following article number to view the article in the Microsoft Knowledge Base:

2883201 Windows RT, Windows 8, and Windows Server 2012 update rollup: October 2013

What’s that you say? Your WSUS server is 2008 R2? And your domain/forest is 2008 R2? And you edit your GPO’s from a DC or the WSUS server? Guess what – you’re never going to see the 2012/2012R2 based GPO settings to enable them!

So what you need to do:

· Start modifying GPO’s on the HIGHEST level OS you have. A generally good practice

· Apply update 2883201 to that system

· Modify the GPO

· Apply update 2883201 to ALL your 2012/2012R2 based servers. (What you thought it would be as simple as updating the GPO editing machine? They won’t know what to DO with the updated GPO until they get the update that says that they should use that information to do it the Windows 7/2008R2 way….)

So there’s a fun little catch-22. In order to get control over your updates on your Windows 2012/2012 R2 systems via WSUS/GPO, you need to deploy an update that you’re having issues deploying, to tell it how to deploy updates.

On the plus side, looking at WSUS reports in this environment:


It looks like all the systems have it. So now we just need to go edit the GPO’s on a 2012 R2 system.

So let’s look at how this appears different:

2008R2 based Group Policy Editor:


2012R2 based Group Policy Editor:


2012R2 based Group Policy Editor:


Well that doesn’t make any sense, no new settings. But why?


“Administrative Templates: Policy Definitions (ADMX files) retrieved from the central store”. That means the ADMX files are being loaded from AD, and NOT from this machine. If you haven’t PUT the updated ADMX files on the Central Store… then it’s not going to work.


Policy Definitions (ADMX files) from 2010 likely isn’t going to help us much in 2014… If you go ahead and get: http://www.microsoft.com/en-US/download/details.aspx?id=41193 for the Windows 8.x/2012 ADMX templates, you can update the central store. Note that sometimes some of the ADMX files remove options that used to exist, so consider this when you’re blindly copying in ADMX files that might overwrite others. Unpack the files to a location – on a Windows 7 system this will go to C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions. Then you want to take the WindowsUpdate.ADMX file and copy it to \sysvol\\Policies\PolicyDefinitions\">\\<domain>\sysvol\<domainname>\Policies\PolicyDefinitions\ Do the same for the ADML (language) file, but put it in \sysvol\\Policies\PolicyDefinitions\en-US">\\<domain>\sysvol\<domainname>\Policies\PolicyDefinitions\en-US. Close and re-open the Group Policy you were editing, and go back to the Windows Update node:


Look who decided to come to the party. Also note there is now an option for completely blocking the “Check for updates directly from Microsoft Update”. This isn’t relevant to our topic, but worth calling it out as an additional update. Set this to ENABLED and set a time (Default and minimum is 15 minutes), and save your Group Policy.

Now, if you’re looking to identify if this is working, you’ll want to look at the C:\WINDOWS\WINDOWSUPDATE.LOG on your Windows 2012 servers:


Here you can see we have a server that has installed updates, and is setting the timer for a few days from today (2014-03-20). That’s no good. So let’s do a GPUpdate /force on the system, and a WUAUCLT /UpdateNow and see what it says. If you’re using something like my WSUS_FORCE.BAT to push the updates and restart when the registry key indicates there is a restart pending, you’ll see:


Here you can see right before that, at 1:40:21AM, that Windows Update indicated a restart was required. The reboot in question only took about 15 seconds to complete. This allowed the post restart updates to install and finish. We now show no required updates on the VM.


This matches with what WSUS indicates as well for FSRVCLOTEST6.

So the key takeaways here:

· When introducing a new OS to your environment, such as Windows 2012 or 2012R2, make sure your GPO’s are updated to allow for it.

· Even if they are, be aware that updates can change the behavior of previously known systems.

· Only ever update/modify/edit GPO’s with the MOST RECENT OS in your environment, using the MOST RECENT ADMX files.

· Before blindly copying over the entirety of the ADMX/ADML files, test and confirm you’re not modifying any required settings. Remember you might be support Windows 2003 or 2000 still or Windows XP on the client side.

· Be careful selecting any new features from the latest GPO’s and ensure you check for backwards compatibility. Most GPO settings will tell you the minimum/oldest OS that is supported for that setting.

· Using the above modifications, you can not only be certain that Windows 2012/2012R2 systems will reboot during scheduled/automated maintenance, but also during situations where you are brute force pushing out something like a WSUS_FORCE.BAT which will look for new updates and install them immediately.

  1. Kevin
    September 11, 2014 at 10:37 AM

    Thanks – your guide cured my Microsoft insanity induced headache! Much appreciated.

  2. December 17, 2014 at 8:48 AM

    Supposedly 2012R2 already includes this patch, but we’re seeing the pre-patch behavior where the 2012R2 servers will not reboot when they are supposed to. Any thoughts? Thanks.

    • December 17, 2014 at 8:50 AM

      I had to install it to make it work the way i described. YMMV but if you are having the same luck, try patching a pilot system and confirming?

      • December 17, 2014 at 9:02 AM

        How did you get it to install? The 2883201 rollup is not applicable on 2012R2. (Just tested it)

  3. December 17, 2014 at 10:02 AM

    Took a look back through my notes – it does appear to be included in 2012R2. You’ve modified the associated GPO settings so that this option is able to be used? The update itself only installs the bits, the action is controlled via GPO.

  4. December 22, 2014 at 8:20 AM

    Thanks. We’ve been looking into this more and realized the problem is actually some of our 12R2 servers are getting stuck rebooting; not hanging per se as the server is up and otherwise operational. This is giving the appearance that automatic updates is not rebooting when it seems to be trying to do so and failing. Thanks again.

  5. Max
    February 18, 2016 at 11:50 AM

    My environment is 2012R2 only. No WSUS, updates come from Microsoft. 2 GPO settings:
    Configure Automatic Updates > Enabled > Option 4 > Mon 3AM.
    Always automatically restart at the scheduled time > Enabled > 15 min.
    My servers install updates per schedule at 3AM and the last Update Event (22) says that restart is pending to finish up and it will happen in 15 min. But it NEVER happens.
    The KB2883201 won’t install since it is not applicable.

    • February 18, 2016 at 2:07 PM

      Have you updated you GPO ADMX files to provide the new GPO options required to change the behaviour back to classic settings?

      • Max
        February 19, 2016 at 1:31 PM

        Hi, thanks for the reply. I haven’t followed your solution because I am not sure it applies to my situation. My problem is that the servers do not restart at all rather than a 3 day delay. I checked the logs and they show 50+ days uptime, when the counter is set to restart in 15 min after the updates are installed. I just wanted to ask if you thought your solution fixed this behavior as well?

      • Max
        February 19, 2016 at 2:10 PM

        Answering your above question – I didn’t have to because the update is included in Server 2012R2 and I can confirm that I see all the settings you mentioned plus one extra: Turn off the upgrade to the latest version of Windows through Windows Update”. I don’t have a central store but the templates are present on all DC’s (which by the way do not restart either).
        Could you please elaborate on your batch script that takes care of the reboot? I thought “Always automatically restart at scheduled time” GPO should take care of it?

  6. February 18, 2016 at 2:24 PM

    Frankly I don’t think this works properly no matter what you do. I’ve never been able to reproduce the pre Win 8 behavior on any 8.x or newer OS, desktop or server. We ended up using WUInstall, which is a command line utility that controls patching (via WSUS) and allows you to force reboots, etc. It has cleaned up our patch environment significantly.

  7. Shuki
    March 10, 2016 at 12:58 AM

    Microsoft published a new update to solve this problem – https://support.microsoft.com/en-us/kb/3138615

    • March 10, 2016 at 7:55 AM

      Hrm. Will have to test that. I note a specific lack of 8.0 and 2012 non-R2 listed. Granted they’ll argue that 8.1 is just a service pack for 8.0 so why haven’t companies gone there (I’ve seen it ;() but 2012 non-R2 needs this as well. Which means one may still need to resort to some work around to make it work.

      We’ll have to give it some testing!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: