Share via

WSUS GPO "4 - Auto download and schedule the install" not working

JRV 546 Reputation points
2023-04-25T19:59:54.2233333+00:00

One thing that's always Just Worked for me is Group Policy, so this is pretty surprising.

One WS2019 server has a Configure Automatic Updates Policy that's set to 4 - Auto download and schedule the install, set to every Tuesday at 2AM. The other WS2019 and WS2012 are scoped to a different Policy which has 4 - Auto download and schedule the install set to every Tuesday at 3AM.

User's image

Aside from the install time, all other WSUS settings are the same between the 2 groups of servers. The 2AM auto-install is working. The 3AM auto-install is not. It used to prior to April 2023 updates.

When I run GPMC Modeling against a 3AM server, it shows 3 - Auto download and notify for install (which is, in fact, what is happening...the updates are waiting for me to click Install in Windows Update).

The Winning GPO reported in GPMC Modelling is the correct GPO. I have verified it is set to 4 - Auto download and schedule the install. This is not a Group Policy inheritance or scoping problem; the intended GPO is applying; the setting is just not being processed correctly. User's image

On the problem servers, AUOptions in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU is set to 3. Should be 4. If I edit it to 4 and GPUPDATE /TARGET:COMPUTER, it reverts to 3. Likewise if I add the /FORCE parameter. User's image

There are 2 DCs, but according to GPMC Status for the Policy in question, both DCs are in sync.

I have deleted and re-created the GPO; no change.

I set the Policy to all the other values offered (2, 3, 5, 7) then back to 4. No change. Not only that, but AUOptions was reported as 3 by GPMC Modelling (rerunning the query each time) no matter what value the Policy was set to.

ADMX files are W10 v22H2. I examined the relevant section of the WindowsUpdate.admx file and it appears to be correct. User's image

Curiously, when I view the registry.pol for this policy file in SDM's Registry.pol Reader program, AUOptions is 4, as it should be. So the Policy is being written correctly to the registry.pol file. User's image

Yet it's reported in GPMC Modeling and written to the Policies key in the computers' Registries as 3. And it works as expected on the 2AM server, the workstations, and on all machines where it's supposed to auto-install at other sites. It's just this one group of servers at this 1 site where it's a problem. Weird, hunh. What do I do about this?

Windows
Windows
A family of Microsoft operating systems that run across personal computers, tablets, laptops, phones, internet of things devices, self-contained mixed reality headsets, large collaboration screens, and other devices.
4,826 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Limitless Technology 43,991 Reputation points
    2023-04-26T11:32:18.9366667+00:00

    Hello there, It seems you have correctly identified the cause for this behaviour and yes this might be due to GPO priority. GPOs are processed in the following order: The local GPO is applied. GPOs linked to sites are applied. GPOs linked to domains are applied. GPOs linked to organizational units are applied. By default, Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/group-policy-hierarchy You can try some Troubleshooting from here https://social.technet.microsoft.com/wiki/contents/articles/38043.group-policy-basic-troubleshooting-steps-for-beginners.aspx Hope this resolves your Query !! --If the reply is helpful, please Upvote and Accept it as an answer--