0x80248015 and 0x8024002E: an expired service registration or a policy block

Fix it now

Neither code says your Windows is out of support. 0x80248015 is the update datastore reporting that a service registration has expired, and 0x8024002E is the client being refused the public service because policy says it must use a managed one. Both are usually repaired on the client.

net stop wuauserv
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f
net start wuauserv
wuauclt.exe /resetauthorization /detectnow

1. Wait a few minutes after the last command, then scan again. The client re-registers itself and takes a new identity from whichever service it is pointed at.
2. If the scan still fails, look at HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and its AU subkey. That is the branch the agent reads, and a WUServer value there is what makes 0x8024002E appear when the machine reaches for the public service.
3. Rename the download cache: stop wuauserv and bits, rename %WinDir%\SoftwareDistribution to SoftwareDistribution.old, then start both services.
4. Confirm the licence state separately with slmgr /dlv, so you are not attributing a scan failure to an activation problem or the reverse.

Delete only the client-identity values named above. Removing the whole WindowsUpdate key takes the client’s service list with it.

If updates are flowing again you can stop here. If not, the next section explains what each code is really reporting and which of them is a policy decision rather than a fault.

Why it happens

Both codes come from the Windows Update agent, and both are widely misread as verdicts on the product’s support status. They are not. 0x80248015 is WU_E_DS_SERVICEEXPIRED: an operation did not complete because the registration of the service has expired. The word service there means a service the client is registered against in its own datastore, not the Windows product. 0x8024002E is WU_E_WU_DISABLED: access to an unmanaged server is not allowed.

Read the second one carefully, because it is not an error in the usual sense. It is the client being told no. Something has declared this machine managed, so when it tries to scan the public Windows Update service it is refused. That is policy working as designed, and the fix is to decide which service the machine should be using rather than to repair anything.

The first one is a genuine fault, and it is nearly always a stale client identity. Every client holds a registration in %WinDir%\SoftwareDistribution\DataStore, keyed to values under the client-state branch of the registry. Clone a machine, restore it from an image, or move it between update servers and two machines can end up claiming the same identity, or a machine can hold a registration the server has long since forgotten.

Full reference

Which registry branch does what

UseWUServer is read only from the policy branch. Creating it under the client-state key does nothing at all, which is a popular workaround that quietly fails and leaves people believing they have redirected a client.

Reading 0xC1900213 correctly

0xC1900213 is MOSETUP_E_NO_OFFER_FOUND: there was no offer found that matches the required criteria. That is a statement about the offer, not about the device. A machine can fail to be offered a build because of a safeguard hold, because the servicing channel it is on has nothing newer, or because the managed service it is pointed at has not approved anything for it. None of those is a verdict on the hardware, and all three are worth checking before anybody concludes the machine is finished.

The commands worth having to hand

When the machine genuinely is out of servicing

At that point no client-side repair helps, and it is worth being clear about why: the service has nothing to offer a build it no longer produces updates for. There are two supported ways forward. Upgrade the machine to a supported build, which is free where the hardware and the existing entitlement allow it. Or take an Extended Security Updates entitlement, which is a licence you install and activate on the machine so that security updates continue to be offered for a defined period.

Check the hardware before assuming the upgrade route is closed. Machines are written off as incapable far more often than they deserve to be, and an upgrade that works costs nothing beyond the time to run it.

Every code this article covers

Confirm the fix worked

1. A scan completes and either offers updates or reports the machine as up to date, with no error code.
2. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate holds a fresh SusClientId rather than the one you deleted.
3. On a managed client, the machine appears in the update server’s console with a recent check-in time.
4. slmgr /dlv reports the licence as Licensed, confirming activation was never the issue.

Questions people ask about this