0x8024500C and 0x8024402A: update policy is pointing clients nowhere

Fix it now

These are policy codes rather than client faults. Microsoft publishes 0x8024500C against the ‘Do not connect to any Windows Update Internet locations’ policy, and 0x8024402A, 0x80244011 and 0x8024001A all say a value the client needed was never set. Read the policy that is actually applied before you change anything on the machine.

gpresult /h C:\gpreport.html /f
gpupdate /force

1. Open C:\gpreport.html and find the Windows Update settings under Computer Configuration. That tells you which object is applying them, which is the part you cannot get from the registry.
2. In Registry Editor, read HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and its AU subkey. Microsoft documents WUServer and WUStatusServer as REG_SZ on the parent key, and UseWUServer as REG_DWORD on AU.
3. UseWUServer set to 1 with no usable WUServer is the whole answer for 0x80244011 and 0x8024402A: the client has been told to use an intranet server it was never given.
4. Fix it in the Group Policy object, not the registry: Computer Configuration, Administrative Templates, Windows Components, Windows Update. Set ‘Specify Intranet Microsoft update service location’ to the full URL including port, or turn the policy off entirely if the machine should scan Microsoft’s service.
5. If 0x8024500C is what you have, look for ‘Do not connect to any Windows Update Internet locations’ in the same node and switch it off unless a WSUS server is genuinely serving these clients.
6. Reapply with gpupdate /force, restart the Windows Update service and scan again.

Clearing the values in the registry on a managed machine buys you one scan. Group Policy writes them back at the next refresh, so the object is the only durable place to fix this.

If the scan completes, you are done. If it does not, the next section explains what the client is doing with these values and which of the six codes is telling you what.

Why it happens

The Windows Update client has two possible sources: Microsoft’s service, or an intranet service you nominate. Which one it uses is decided entirely by policy values under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Group Policy writes them, an MDM writes them, a script can write them, and none of the three tells the client anything about whether the arrangement makes sense. All six codes on this page are the client reporting that the arrangement does not.

Three of them are simply missing values. 0x8024402A is WU_E_PT_CONFIG_PROP_MISSING, a configuration property value was missing. 0x80244011 is WU_E_PT_SUS_SERVER_NOT_SET, and it is the specific one: the WUServer policy value is missing in the registry. 0x8024001A is WU_E_POLICY_NOT_SET, a policy value was not set. Read together they describe a half-written policy – something enabled the intranet path without completing it.

The other three are refusals rather than omissions. 0x80240025 is WU_E_USER_ACCESS_DISABLED, Group Policy settings prevented access to Windows Update, which is a deliberate block someone configured. 0x8024500C is what Microsoft attributes to the ‘Do not connect to any Windows Update Internet locations’ policy. 0x80240020 is WU_E_NO_INTERACTIVE_USER, which is not a policy fault at all: the operation did not finish because nobody is signed in, and Microsoft’s mitigation is to sign in and let the device restart.

Full reference

The values the client actually reads

All of these live under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. The non-policy branch under CurrentVersion holds client state such as SusClientId – it is not where these values belong, and a value written there is read by nothing.

Which policy sets what

Every setting on this page lives under Computer Configuration, Administrative Templates, Windows Components, Windows Update. The ones that produce these codes are ‘Specify Intranet Microsoft update service location’, ‘Configure Automatic Updates’, ‘Do not connect to any Windows Update Internet locations’, ‘Remove access to use all Windows Update features’ and ‘Enable client-side targeting’.

Editions that can host these policies

Microsoft publishes the editions that Windows Update client policies are available on: Pro, including Pro for Workstations; Education; and Enterprise, including Enterprise LTSC, IoT Enterprise and IoT Enterprise LTSC. Home is not on that list. That is the practical reason a Home machine cannot be pointed at WSUS – not that the registry rejects the values, but that nothing supported reads them.

When the policy looks right and the codes persist

• Check the URL includes the scheme and the port. http://wsus.example.local:8530 behaves; wsus.example.local does not.
• Check whether more than one object sets Windows Update values. The report names the winning object, and it is often not the one you were editing.
• Check the machine’s MDM enrolment. On a co-managed device, an MDM policy and a Group Policy object can both be writing here.
• Confirm the service is running and set to start, because a policy fix on a stopped service changes nothing visible.
• Look at the client log with Get-WindowsUpdateLog. WindowsUpdate.log is written to C:\Windows\Logs\WindowsUpdate and the cmdlet produces a static, readable copy of it.

Every code this article covers

Confirm the fix worked

1. The policy branch now holds either a complete intranet server configuration or nothing at all, with no half-set pair left behind.
2. A fresh gpresult /h report shows only the object you intend applying Windows Update settings.
3. A scan from Settings, Windows Update completes and lists or installs updates.
4. The same result holds after a restart and a policy refresh, rather than only until the next gpupdate.
5. On a WSUS deployment, the client appears in the WSUS console with a recent last-contact time.

Questions people ask about this