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.

http://blogs.technet.com/b/wsus/archive/2013/10/08/enabling-a-more-predictable-windows-update-experience-for-windows-8-and-windows-server-2012-kb-2885694.aspx

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.