none
Windows Server 2012 R2 Hosts Ignoring Windows Update GPO Settings

    Question

  • Architectural Overview

    I have a development environment that is comprised of five (5) physical machines. Three (3) of these machines (dacloud-vh01, dacloud-vh02, dacloud-vh03) are VMM (2012R2) host servers set up as a failover cluster. One (1) of these machines (dacloud-ss01) is configured as a NAS (iSCSI) server which is used as the required shared file system for the cluster. The last machine (dacloud-cs01)--included here just for completeness--is a utility server that handles a variety of services including being one (1) of the four (4) domain controllers for the environment. The first four (4) systems are in an AD OU called "DACLOUD Cluster Hosts".

    Methodology Background

    Since it feel like it is probably not the best of ideas for the filesystem upon which the majority of the virtual machines as well as the shared volumes used for a few SQL instances exist to suddenly disappear as a result of dacloud-ss01 being rebooted following an automated update, I have created a GPO policy specifically for the DACLOUD Cluster Hosts OU (called "Default DACLOUD Cluster Hosts") that modifies the Windows Update settings for the rest of the domain. The non-default settings for this OU specify that the server should check for updates but not download or install them, as I would like to install these updates myself, manually.

    What's Actually Happening

    As demonstrated by the below screenshot taken from a GP Results report within Group Policy Management, the non-default WU settings are being applied by the DACLOUD Cluster Hosts policy. Moreover, in the second screenshot taken from the Registry Editor on dacloud-ss01, we can see that the WU settings are being pushed into the registry as expected.

    That said, every Sunday morning @ 3AM, dacloud-ss01 checks for updates and, if found (let's face it, they're always found), installs the updates and, if required (let's face it, a reboot is always required), reboots the server. This, of course, causes pretty much the entire world to come crashing down in the environment as the filesystem that pretty much everything relies upon vanishes for about 3 minutes as the server reboots.

    I'm entirely stumped by this problem, so I would be grateful if someone could point me in the right direction before I lose (another) (critical) virtual machine or corrupt (another) (critical) database. Thank you.

    Tuesday, September 15, 2015 1:07 PM

All replies

  • I don't quite understand the scenario here, what do you mean the "non-default settings for this OU "?
     
    According to your screenshot, seems "Default DACLOUD Cluster Hosts" applies well on this OU. And WU settings is actually defined in the Default domain policy, what's your really questions here?
     
    "I have created a GPO policy specifically for the DACLOUD Cluster Hosts OU (called "Default DACLOUD Cluster Hosts") that modifies the Windows Update settings for the rest of the domain."
     
    --- since this GPO is linked for this specific OU, how come it can modify the settings for the rest of the domain?
     
    Wednesday, September 16, 2015 6:24 AM
  • Um... according to the screenshot the "Configure Automatic Updates" is set to "2" by the "Default DACLOUD Cluster Hosts" policy. This policy modifies the settings for the DACLOUD Cluster Hosts OU, not the entire domain...obviously, the Default Domain policy does that... The point here is that the GPOs are being applied as expected with the Cluster Hosts policies overriding those offered by the Domain policies. The problem here is that Windows Server 2012 R2 is entirely ignoring these settings and installing updates every Sunday morning @ 3AM and rebooting stuff willy-nilly.
    Wednesday, September 16, 2015 1:03 PM
  • Try to delete the registry keys under Policies to clear the GPO history, then run gpupdate /force to refresh the setings. After that checking again..

    Thursday, September 17, 2015 4:57 AM
  • Did as you suggested and the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key comes back exactly the same as shown in the screenshot in the original post.
    Thursday, September 17, 2015 9:23 PM
  • the non-default WU settings are being applied by the DACLOUD Cluster Hosts policy. Moreover, in the second screenshot taken from the Registry Editor on dacloud-ss01, we can see that the WU settings are being pushed into the registry as expected.

    what is non-default wu settings? do you have other wu setting configured in your default domain policy?
    Friday, September 18, 2015 9:45 AM
  • Yes. Default Domain policy sets the URL for the WU server and sets the AU policy to "4" for all other systems (as shown in the screenshot):

    However, you can see that on the dacloud-ss01 box, the "winning GPO" is the Default DACLOUD Cluster Host policy for that attribute. Additionally, by default if AU is configured using GPO, the servers should check every day for updates. In my case, the server's local maintenance seems to be overriding the GPO settings and doing the weekly check on Sunday @ 3AM.

    Friday, September 18, 2015 2:35 PM
  • Saturday, September 19, 2015 12:49 AM