Windows Update Error 0x8024500C: When Update Is Blocked

Windows Update stops with 0x8024500C, the troubleshooter reports nothing wrong, and the same machine updated fine last month. The code has nothing to do with corruption or a bad download: a policy told the client not to go online, and the client obeyed. This guide covers what error 0x8024500C means, which settings raise it, and how to clear it on one PC or across a fleet without breaking the management you meant to keep.

What 0x8024500C Means

The code is missing from Microsoft's public error table, which is why the usual advice around it is so vague. It lives in the Windows SDK header file that defines every Windows Update result, wuerror.h, where it is named WU_E_REDIRECTOR_CONNECT_POLICY: "Connections to the redirector server are disallowed by managed policy."

The redirector is the first hop of every scan. Before the Windows Update client talks to any update server, it downloads a small file from Microsoft that tells it where the current endpoints are. Microsoft's Windows Update error reference files the neighbouring codes under "Redirector errors", the components that fetch and parse that file. 0x8024500C is the one that fires when policy forbids the fetch in the first place.

Two words in the message do the work: managed policy. The client had a working network and a working cache. It was told not to ask Microsoft for directions, so it stopped before the first step. That is also why the code shows up outside Windows Update. The Microsoft Store, Features on Demand such as RSAT and OpenSSH, and the Intune Company Portal installer all rely on the same redirector, and each reports the same number when the hop is blocked.

The Policy Behind It

The setting is called "Do not connect to any Windows Update Internet locations". It sits under Computer Configuration, Administrative Templates, Windows Components, Windows Update, and it writes DoNotConnectToWindowsUpdateInternetLocations = 1 to HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.

Microsoft's own description of it, in the Windows Update settings guide updated in February 2026, is the whole diagnosis. Even when a device gets its updates from an intranet server such as WSUS, it still periodically contacts the public Windows Update service to keep future connections working, for Microsoft Update, the Store and other services. Enabling the policy turns that off, and Microsoft says plainly that it "may cause connection to public services such as the Microsoft Store, Windows Update client policies, and Delivery Optimization to stop working."

The note underneath matters just as much: the policy only applies when the device is also pointed at an intranet update service. So the error needs two things at once, a WSUS or Configuration Manager pointer (WUServer plus UseWUServer = 1 under the AU subkey) and the ban on Internet locations. A WSUS pointer on its own is normal and harmless. The pair is what strands every public service.

That pair arrives from four directions, and the fix depends on which one. Group Policy is the classic route. An Intune profile writes the same values through the Update CSP. The Configuration Manager client sets the WSUS pointer itself, including on co-managed devices. And then there are the leftovers: an image captured from a managed reference machine, a laptop that left the domain, a "temporary" GPO from years ago. The policy is gone, the key is not, and nothing ever deletes it.

Where It Shows Up

The pattern is always the same: everything that comes from WSUS works, and anything that only Microsoft serves fails with 0x8024500C. Monthly cumulative updates approved in WSUS install. Adding an optional feature does not, because Features on Demand come from Microsoft unless you have staged them yourself. The top-voted answer on a Microsoft Q&A thread from 2024 is exactly that case: OpenSSH Server would not install on a WSUS-managed machine until the client was allowed to scan against Microsoft for a few minutes.

The Store is the second common face. "Try that again, something happened on our end" with 0x8024500C at the bottom means the Store could not reach its servers for the same reason. And because the Company Portal is a Store app, Intune rollouts on WSUS-managed fleets trip over it too. This r/Intune thread is a co-managed environment with updates flowing through Configuration Manager, where the Company Portal install kept failing with the code and the working answer was to install it through winget instead:

Winget is a fine workaround for one app. It does nothing for the next optional feature or the next Store update, so treat it as a way to unblock a user today, not as the fix.

Find the Policy Before You Touch Anything

The instinct with Windows Update errors is to reset the cache, rename SoftwareDistribution and run DISM. None of that applies here. The cache is fine and the component store is fine. The client is following an instruction, and the whole job is to find where the instruction comes from. Our guide to Windows Update policy explains the settings hierarchy; this section is the five-minute version.

Start with the registry, in an elevated PowerShell window:

code
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
  Select-Object WUServer, WUStatusServer, DoNotConnectToWindowsUpdateInternetLocations, DisableWindowsUpdateAccess
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' |
  Select-Object UseWUServer, NoAutoUpdate, AUOptions

Then read the values against what they mean. WUServer with UseWUServer = 1 says scans go to the named server. DoNotConnectToWindowsUpdateInternetLocations = 1 is the switch that raises this code. DisableWindowsUpdateAccess = 1 is a different block that produces 0x8024002F or 0x80240025 instead, so if that is all you find, you are on the wrong page. And if the policy key does not exist at all, policy is not your problem: look at the proxy or the firewall between the device and Microsoft.

Next, find the owner. gpresult /h report.html lists every applied GPO, and the Windows Update section of the report names the one that set the value. On an Intune-managed device, the Settings app under Accounts, Access work or school, shows the applied profiles, and MDM-written values show up with a policy store source of Mdm. If neither claims the key and the device was imaged from a managed reference machine, you have found a leftover.

Fix It Without Breaking Management

There are three exits, and the right one depends on who is supposed to manage the device.

If WSUS or Configuration Manager is meant to stay, keep the pointer and open only the public door. Set "Do not connect to any Windows Update Internet locations" to Not Configured in the GPO that carries it, run gpupdate /force, restart the Windows Update service and scan again. Scans still go to WSUS. The Store, optional features and Delivery Optimization can reach Microsoft again. If the only thing you need is optional features, there is a narrower switch: the "Specify settings for optional component installation and component repair" policy under Administrative Templates, System, which Microsoft's repair source guide documents, lets those downloads go to Windows Update while everything else stays on WSUS.

If you need one install right now and cannot wait for a policy change, use the temporary flip from the Q&A answer above: stop wuauserv, set UseWUServer to 0, install the feature, set it back to 1, start the service. The machine scans against Microsoft for those few minutes and nothing else changes. Policy refresh will overwrite the value anyway, which is also why leaving it at 0 is a bad idea: you would not know when it flipped back.

If the device is no longer managed, delete the leftover. This r/sysadmin thread from March 2025 is the textbook case: machines imaged by a Configuration Manager task sequence stopped updating overnight while Autopilot devices were fine, no GPO had changed, and the fix that worked was removing the DoNotConnectToWindowsUpdateInternetLocations value from the policy key.

After deleting a value, run gpupdate /force once more and read the key again. If the value comes back, something still manages the device, and that something is what you need to fix. The walkthrough below shows the registry and policy checks on a single PC:

None of the three exits needs a reboot, and none of them needs DISM. If you did run DISM RestoreHealth first, no harm done, but it was never going to change this code.

Fixing It Across a Fleet

One machine with 0x8024500C is a leftover key. A whole department with it on the same morning is a policy change, and someone made it. Before you touch endpoints, check the WSUS or Windows Update GPO history and any Intune update profile edited that week. The r/sysadmin case above took a week of guessing because nobody expected a setting that had not been touched to be the cause.

To see the spread, read the policy values across the affected devices instead of collecting screenshots:

code
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue |
  Select-Object @{n='Host';e={$env:COMPUTERNAME}}, WUServer, DoNotConnectToWindowsUpdateInternetLocations

Group the output by WUServer and by the block value and the picture is usually immediate: every failing device shares one server pointer and one GPO. OpenFrame can run a script like this across a client's devices and collect each device's output in one place. Our list of useful PowerShell commands has the remote-session variants if you are not using a management tool.

Then fix the source, not the symptoms. Unlink or edit the GPO, or change the Intune profile, and let policy refresh clear the key on its own. Scripting a registry delete across the fleet feels faster, and it lasts exactly until the next refresh writes the value back.

The Short Version

0x8024500C means a managed policy stopped Windows Update from asking Microsoft where its servers are. Look for DoNotConnectToWindowsUpdateInternetLocations = 1 alongside a WSUS pointer, find the GPO, MDM profile or leftover image key that wrote it, and fix that. Keep WSUS and open the public door, flip UseWUServer for a one-off install, or delete the key on a device nobody manages. If you then need a single update that WSUS never approved, our guide to the Microsoft Update Catalog covers installing it by hand.