0xC004F009 and 0xC004F021: KMS Activation Lapsed After 180 Days

Fix it now

Microsoft publishes 0xC004F009 as the Software Protection Service reporting that the grace period expired. On a KMS client that means the machine stopped renewing long enough for its activation to run out. Nothing has been revoked and your key is intact; the device simply has not spoken to a host in a very long time.

slmgr /xpr
slmgr /dlv
nslookup -type=srv _vlmcs._tcp
slmgr /ato

1. slmgr /xpr gives you the one-line answer on whether the machine is inside a licensed period. slmgr /dlv names the KMS host it last used, which is often the whole story.
2. If the service record does not resolve, the client has no host to renew against. Fix discovery, or pin the host to prove it: slmgr /skms kms.contoso.local:1688.
3. Check the clock before retrying: w32tm /resync. A badly skewed clock fails activation on its own and produces a different code.
4. Re-run slmgr /dlv and confirm Licence Status reads Licensed with a fresh period showing.

If you pinned a host only to prove where the fault was, run slmgr /ckms afterwards so the client goes back to discovery.

If the machine reactivates, you are done and it costs nothing. If it cannot reach a host at all, the next section covers why and what to do about devices that never will.

Why it happens

A KMS-activated machine does not hold a permanent licence. Microsoft documents KMS activations as valid for 180 days – the activation validity interval – with client computers attempting renewal every seven days by default, and each successful renewal starting the 180 days again. So a machine has to miss a long run of renewal attempts before anything visible happens. By the time you are reading this code, the device has been unable to reach a host for something close to half a year.

Microsoft’s published text for 0xC004F009 is that the grace period expired, and its listed resolution is to contact the Microsoft Licensing Activation Centers. That resolution is aimed at the general case rather than the KMS one; on a KMS client the practical answer is almost always to restore contact with a host, because the entitlement was never in question. 0xC004F021 travels with it and Microsoft publishes no meaning for it, as do 0xC004FC07 and 0x4004FC06.

What happens at expiry is designed to be survivable rather than damaging. Windows moves into a notification state: the machine keeps running, files and applications are untouched, domain membership and network access continue, and servers keep serving. That is why expired machines sit unnoticed for weeks, and why this is rarely the emergency it looks like on the day someone reports it.

The pattern to watch for is a cluster. One laptop expiring is a laptop. Twenty machines expiring in the same fortnight means they all last renewed around the same time, which points at a host that was decommissioned or a network change six months ago rather than at anything that happened this week.

Full reference

The intervals this all runs on

The spread is what makes this quiet. A machine that renewed last week has months of margin, and a client that cannot reach the host keeps trying on its own schedule the whole time. The failure only becomes visible when the margin is gone, which is why the first symptom is usually a user rather than a monitoring alert.

Commands worth having to hand

Catching this before it happens

• Report on slmgr /xpr output through your management tool. It is one line per machine and it turns a six-month silent failure into a weekly number.
• Watch the count on the host. A count that falls without machines being decommissioned means devices have stopped checking in, which is the same fault seen from the other end.
• Check the host’s own licence state on a schedule. Everything downstream depends on it and nothing warns you when it lapses.
• Treat any machine that is off-network for months as a candidate to move off KMS, rather than as a machine to reactivate by hand twice a year.

When the machine cannot come back

Some devices genuinely cannot meet a six-monthly cadence: equipment in a customer’s building, machines on isolated networks, laptops issued to people who never visit an office. For those, reactivating by hand is not a fix, it is a recurring ticket. A permanent activation is the honest answer, and a Multiple Activation Key is the supported way to get one.

Be selective about which machines move. A MAK activation spends a seat from a finite pool and rebuilding the machine spends another, so moving a whole estate off KMS to solve a problem affecting a dozen laptops trades one problem for a more expensive one. Where the devices are domain-joined and simply cannot reach a KMS host, Active Directory-Based Activation is worth checking first: it renews on domain contact and needs no host at all.

What expiry does not do

• It does not delete anything, block sign-in, or stop applications running.
• It does not consume or invalidate your key. The same generic volume licence key works the moment a host is reachable again.
• It does not affect domain membership, network access or file shares.
• It does not need a support call to Microsoft in the KMS case, whatever the published resolution for the code says in general terms.

Every code this article covers

Confirm the fix worked

1. slmgr /xpr reports the machine as activated rather than expired.
2. slmgr /dlv shows Licence Status: Licensed, and the KMS machine name is the host you expect.
3. The desktop watermark is gone and personalisation settings are available again.
4. slmgr /ckms has been run if you pinned a host to prove the diagnosis.
5. Come back after a week and re-run slmgr /dlv to confirm the renewal cycle is working, rather than the one manual activation having been a one-off.

Questions people ask about this