1

I am running Windows 10 Pro x64 v. 1903. I edited my Group Policy for "Configure Automatic Updates" in the group policy editor, and now I want to set it back to "Not Configured". When I do this, it has no effect, and the group policy I previously "Enabled" for Automatic Updates is still in effect.

After re-setting my Automatic Updates policy in the group editor to "Enabled" and choosing option 2, in order to generate the following registry keys (which were missing after I reset my Automatic Updates group policy back to "Not Configured" after previously "Enabling" it):

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\AU

I tried deleting these keys, and rebooting. This also had no effect.

I have tried combinations of toggling my Automatic Updates group policy between "Enabled" and "Not Configured", deleting the above registry keys, running gpudpate /force /boot from the command-prompt, and rebooting (in various orders), but my Automatic Updates group policy still remains in effect.

After all my attempts to undo it, my group policy change to my Automatic Updates settings still seems to be in effect according to the red policy message on my Windows Update Screen telling me that "*Some settings are managed by your organization" and the "View configured update policies" screen that shows the group policy for Automatic Updates that I have tried to undo as still being in effect.

Can anyone on here give me any advice about what I can do to actually get rid of this group policy setting for Automatic Updates that I can't seem to undo?

Thanks in advance for any help with this problem.

  • Use this Microsoft Article to reset Automatic Updates and make sure Updates are ON. You cannot permanently turn off Windows Updates on an individual machine anyway. docs.microsoft.com/en-us/windows/deployment/update/… – John Jun 21 at 12:48
  • Thanks for the link John. I have come up with a workaround that addresses my problem more directly, but I am glad to have the link you provided in case I do need to reset my Automatic Updates from any undesirable states they may get into. – argannon Jun 21 at 21:37
0

OK, I have figured out a few things (somewhat by chance) and through further experimentation.

First, to be clear, when I say I want to undo/unapply my group policy setting, I mean that I want to be able to reset the state of this group policy back to its original "Not Configured" state and have this state be honored/applied properly such that this group policy is no longer in effect.

As far as I can tell, the problem I am having with undoing/unapplying my group policy setting that I previously applied to Automatic Updates is due to a boundary condition that Windows developers do not deal with very well.

The relevant boundary condition is the condition when we move from at least one group policy setting in a given section of the group policy editor being either "Enabled"/"Disabled" to a situation where all group policy settings in a given section of the group policy editor are reset to their original "Not Configured" state.

When such a boundary condition arises, Windows 10 fails to recognize/apply the "Not Configured" state of the last/most-recent group policy setting that has been returned to the "Not Configured" state, and instead, it retains the most recent "Enabled/Disabled" state of that setting as it was assigned before the state of that setting was reset to "Not Configured".

The real reason the "Not Configured" setting of my group policy for Automatic Updates is not being honored/applied revolves around the fact that this "Configure Automatic Updates" group policy setting was the only group policy setting that I had previously configured (as either "Enabled" or "Disabled) in the "Computer Configuration/Administrative Templates/Windows Components/Windows Update" section of my computer's group policy editor.

(FWIW, I followed the directions at the top of the primary answer for this post:

Stopping all automatic updates Windows 10

to originally "Enable" and set the group policy for the "Configure Automatic Updates" setting in the group policy editor on my computer. However, in Win 10 Pro x64 v. 1903, choice 2 is slightly different: it reads "Notify for download and auto install". And this choice seems to bring about slightly different behavior than choice 2 provided in previous versions of Windows 10. In v. 1903, Windows still automatically downloads and installs updates that it deems are too important to postpone, even when choice 2 is chosen by users configuring this group policy.)

To be clear, only after at least one setting in the "Computer Configuration/Administrative Templates/Windows Components/Windows Update" section of my computer's group policy editor was set to a state other than "Not Configured" (i.e., set to either "Enabled" or "Disabled") did the two registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\

get created in the registry. When all settings in the "Windows Update" section of the group policy editor are in their original "Not Configured" states, these above two registry keys do not exist.

Interestingly, after first "Enabling" only the "Configure Automatic Updates" setting and then resetting this only group policy setting in the "Windows Update" section that had a value other than "Not Configured" back to its original "Not Configured" setting, once again, all settings in the "Windows Update" section of my group policy editor were set to "Not Configured" and the above two registry keys once again disappeared from the registry.

The problem was that, even in this state, upon restart (and sometimes before) my "Configure Automatic Updates" group policy that was last in effect before I reset the state of this policy to "Not Configured", remained in effect.

Again, what seems to be happening here is that Windows 10 is not handling the boundary condition where a section in the group policy editor goes from having at least one setting's state set to "Enabled/Disabled" back to no settings' states being set to "Enabled/Disabled" and all settings' states once again being set to "Not Configured".

And again, when a user does toggle all settings in a given group policy component back to "Not Configured", after having previously "Enabled/Disabled" (at least) one of these settings, the previous state (either "Enabled/Disabled", and including any other options that were chosen as part of this policy specification) of this last-remaining group policy to be reset to "Not Configured", still remains in effect.

Here is the KLUGE WORKAROUND I have come up with to somewhat solve this problem.

Short and skinny: "Enable/Disable" (whichever you prefer) the setting "Do not include drivers with Windows Updates" in the "Computer Configuration/Administrative Templates/Windows Components/Windows Update" section of the group policy editor. (With the "Do not include drivers with Windows Updates" setting, the behavior of the "Disabled" state is equivalent to the behavior of the "Not Configured" state, so Disabling this state is the same as never having configured it at all. This is all-important.)

Once at least one setting in the "Computer Configuration/Administrative Templates/Windows Components/Windows Update" section of the group policy editor is set to something other than "Not Configured", the above two registry keys will once again be created in the registry.

And once these two WindowsUpdate registry keys actually exist in the registry, due to the fact that at least one sub-setting under this key has a state value in the group policy editor other than "Not Configured", all other settings in this "Computer Configuration/Administrative Templates/Windows Components/Windows Update" section of the group policy editor will have their respective states applied properly, including the "Configured Automatic Updates" setting whose state will now be properly applied as "Not Configured". (HOORAY!!! The original problem is now SOLVED!!!)

With this workaround, you will still see the "*Some settings are managed by your organization" message in red on your Windows Update screen and the "View configured update policies" screen will now alert you that the "Exclude drivers from Windows quality updates" group policy is in effect. ("Exclude drivers from Windows quality updates" is just the name of the policy. This same name is displayed whether you have "Enabled" or "Disabled" such exclusions.) However, there should now be no messages indicating that the "Configure Automatic Updates" group policy is still in effect.

In this state, your machine will now either behave in a way that excludes these driver updates (if the "Do not include drivers with Windows Updates" policy is Enabled) or that includes these driver updates (if the "Do not include drivers with Windows Updates" policy is Disabled).

And since the "Disabled" state for this group policy behaves in exactly the same way as the "Not Configured" state for this group policy, setting this policy to "Disabled" will be functionally equivalent to this group policy never-having-been-set and not-being-in-effect at all.

In such case, if this Disabled "Do not include drivers with Windows Updates" group policy is now the only "Windows Update" group policy you have in effect, the state of your "Configure Automatic Updates" group policy is now being properly honored/applied as "Not Configured" (original problem solved), and the rest of the group policies in the "Windows Update" section of the group policy editor are now acting in the same way they would act if no group policies were in effect at all for this section. Win, Win!!

This is the best I can do for a FIX. I am still unable to come up with a solution that actually takes all group policies out of effect once at least one group policy setting has previously been "Enabled/Disabled".

Hope this helps anyone in the future with a similar problem.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.