Windows Update registry settings usually live under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, with AU handling Automatic Updates behavior. If a value sits under Policies, Group Policy, MDM, WSUS, or another management layer usually owns it, and that layer can write it back after a refresh. This guide helps you identify the control plane first, then edit the right place in Regedit.

Registry Editor basics

Registry Editor, or Regedit, is Windows’ built-in registry editing tool. Open it with Win+R, type regedit, and press Enter. The left pane shows keys in a tree. The right pane shows values inside the selected key.

For Windows Update work, the root hive matters because it tells you who owns the setting. HKEY_LOCAL_MACHINE points to machine-wide configuration, which is where policy and device-management settings usually live. A value can exist and still be ignored if another system writes over it later.

What you need before you edit

  • An account that can open Regedit and change the target key.
  • The exact value name you want to inspect, such as NoAutoUpdate.
  • Access to Settings, Group Policy, or an admin console if the device is managed.
  • A note of the full registry path before you change anything.

Which registry key controls Windows Update?

Which registry key controls Windows Update?
Windows Registry Editor shows a Windows Update policy key and value dialog

Start with HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. For Automatic Updates behavior, inspect the AU subkey under that branch. If the setting is policy-owned, this path is the place to verify it before you touch any other key. Group Policy commonly writes here and can overwrite local changes after the next refresh.

Open Regedit, paste the path into the address bar if your version shows one, and check whether the value already exists. If it is missing, policy may not be applied. If it is present but keeps changing back, another control plane is writing it again.

Decision table: common Windows Update registry locations

Registry location Control source Visible symptom Manual edits likely to revert? Next verification step
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Group Policy or another policy writer Settings match a corporate policy path Yes Check gpedit.msc or Group Policy results for Windows Update policies
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU Group Policy Automatic Updates policy NoAutoUpdate or related AU values keep returning Yes Review Computer Configuration > Administrative Templates > Windows Components > Windows Update
HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\Current\Device\Update Intune or other MDM policy on an Intune-only device Values appear under PolicyManager instead of Policies Yes Check device management status and the Intune update policy profile
WSUS-related policy values under the Policies branch WSUS, usually delivered by Group Policy Device points to an update server and ignores local choices Yes Check the WSUS GPO and the client’s reported update source
ConfigMgr client settings Microsoft Configuration Manager Update behavior follows client settings, not local edits Yes Review the ConfigMgr client’s Software Updates settings

Use Regedit to change the value only after you confirm which control plane owns it. If the device is unmanaged, a direct edit can work. If Group Policy, WSUS, ConfigMgr, or Intune owns the setting, change the policy there instead. Otherwise, the value can revert after the next refresh. Microsoft says Windows 11, version 26H2 is the next annual feature update, and eligible 25H2 and 24H2 devices can receive it through Settings > Windows Update (per Microsoft support).

  1. Open Win+R, type regedit, and press Enter.
  2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
  3. Check the AU subkey for Automatic Updates values such as NoAutoUpdate.
  4. Edit only the value that matches the behavior you want, then close Regedit.
  5. Refresh policy with gpupdate /force if the device uses Group Policy.
  6. Reopen Regedit and confirm the value stayed put after refresh.

A common first-timer mistake is editing a value in the Policies branch and then checking only Settings, not the policy source. Suppose NoAutoUpdate is set to 1 under AU, but the device is domain-managed. The value may look correct for a moment, then Group Policy may write it back on the next refresh.

Why do my registry edits keep reverting?

Why do my registry edits keep reverting?
Windows Registry Editor with highlighted menu steps and red arrows

Registry edits keep reverting when another control plane owns the setting. Group Policy is the most common cause. MDM on Intune-only devices can also reapply values under PolicyManager. ConfigMgr client settings and related policy can control update behavior instead of local registry edits. The fix is to change the owner, not to keep rewriting the local value.

What to check first

  1. Open gpedit.msc or check Resultant Set of Policy if the device is domain-managed.
  2. Look for Windows Update policies under Computer Configuration > Administrative Templates > Windows Components > Windows Update.
  3. Check whether the device is enrolled in Intune and using HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\Current\Device\Update.
  4. Review ConfigMgr client settings if the machine is managed by Microsoft Configuration Manager.

Say your laptop is joined to a workplace domain and a value under WindowsUpdate\AU resets within minutes. That timing points to policy refresh, not a broken registry hive. Changing the GPO is the next move.

Should you edit Windows Update keys directly or use Group Policy?

Use Group Policy, Intune, WSUS, or ConfigMgr when one of those systems is managing the device. Edit Regedit directly only when the PC is local, unmanaged, and you need a quick change that no policy will overwrite. If you skip this check, the setting may change back after the next refresh cycle. Manual edits may revert when a policy is applied (per Microsoft support).

For home PCs, direct editing can be reasonable if you know the exact value and path. For enterprise devices, changing the policy layer is the safer move. On Intune-only devices, check the PolicyManager branch instead of forcing values under Policies\Microsoft\Windows\WindowsUpdate.

What should you check if Windows Update registry settings are not taking effect?

What should you check if Windows Update registry settings are not taking effect?
Windows Update settings page with update options and a highlighted toggle

If the value is present but Windows Update ignores it, the wrong control plane is usually winning. Check whether Group Policy, WSUS, ConfigMgr, or Intune is still active. Also confirm that the value lives in the branch the device actually uses. A correct-looking key in the wrong branch will not control update behavior.

Escalation order

  1. Verify the exact registry path and value name.
  2. Check policy source with gpedit.msc or the device management console.
  3. Confirm whether the device is using Policies\Microsoft\Windows\WindowsUpdate or PolicyManager\Current\Device\Update.
  4. Refresh policy, then recheck the value after the refresh.

If that still does not change behavior, inspect Windows Update logs and the management console before making more registry edits. That tells you whether the value is being ignored or replaced.

Common mistakes

  • Editing the wrong branch and expecting the setting to stick.
  • Assuming a registry value is local when Group Policy owns it.
  • Changing AU values without checking whether the device is managed by Intune.
  • Using cache resets as a fix for policy reapplication. That does not stop a policy from writing the value again.

For a WSUS-managed PC, the update path often comes from Group Policy, not from manual registry work. For a ConfigMgr-managed endpoint, client settings can decide the behavior, and Group Policy can still win if both are present. For Intune-only devices, the PolicyManager branch is the clue.

Keep reading

Frequently asked questions

How do I check which source Windows Update is using in the registry?

Look at the full path first. If the value sits under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate or \AU, Group Policy or another policy writer is likely in charge. If it appears under HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\Current\Device\Update, the device is usually getting the setting from MDM such as Intune.

Why do my Windows Update registry settings keep reverting?

A policy refresh is usually writing the value back. Check Computer Configuration > Administrative Templates > Windows Components > Windows Update, then review whether WSUS, ConfigMgr, or Intune is also managing the device. Manual edits under the policy branch often lose to the next refresh cycle.

Which registry key controls Windows Update policies?

Use HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate first, then open the AU subkey for Automatic Updates behavior. If the device is Intune-only, also check HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\Current\Device\Update because that branch may control the same setting.

Should I edit Windows Update registry keys directly or use Group Policy?

Use Group Policy when the device is domain-managed or WSUS-controlled. Edit Regedit directly only on an unmanaged PC where no policy layer will overwrite the value. After any change, run gpupdate /force and confirm the value still appears in the same key.

How do WSUS and Intune store Windows Update settings differently?

WSUS settings usually arrive through Group Policy and land in the traditional Policies branch. Intune-only devices may write update settings under HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\Current\Device\Update. That difference matters because the same visible setting can come from a different owner.