0xC004F042: The KMS Host You Reached Cannot Activate This Product

Fix it now

Microsoft publishes this as the specified Key Management Service not being usable: the client reached a host, and that host cannot activate this software. The first thing to establish is which host answered, because in a mixed estate the client may have found an application-specific host rather than the one for Windows.

slmgr /dlv
slmgr /ckms
slmgr /skms kms.contoso.local:1688
slmgr /ato

1. Read the KMS machine name in the first slmgr /dlv output and write it down. That is the host that refused you.
2. If it is not the host you expected, the middle two commands are the whole fix: clear the discovered host, pin the right one, activate.
3. If it is the host you expected, go to that host and run slmgr /dlv there. Its description names the host key installed, which is what decides the products it can serve.
4. Once the client activates, run slmgr /ckms to return it to automatic discovery, and fix whatever sent it to the wrong host in the first place.

Microsoft’s own resolution for this code is /ckms, then /skms at the correct host, then /ato. Replacing the host key is the second answer, not the first.

If it activates against the right host, you are done. If the right host also refuses it, the next section explains what a host key covers.

Why it happens

A KMS host is not a general-purpose activation service. It serves the products its host key entitles it to serve, and nothing else. When a client asks for something outside that set, the host answers and declines, and the client reports 0xC004F042. Microsoft’s published text is that the specified Key Management Service cannot be used, and its documented cause is a client contacting a host that cannot activate the client software.

That framing matters because it puts two quite different situations under one code. The first is a client talking to the wrong host. Larger estates often run more than one: an application-specific host for Office and an operating-system host for Windows, or an old host nobody retired alongside a new one. DNS hands out whatever it holds, and a client that finds the Office host asking to activate Windows gets refused by a service that is working perfectly.

The second is a host whose key predates the product. Microsoft’s example is using a Windows Server 2016 host key to activate Windows Server 2022. A KMS host key carries an entitlement to a set of products, and a client outside that set is refused permanently, however many times the service is restarted. This is the case that costs money, and it is why the diagnosis order matters: the free fix and the paid one produce the same error.

0xC004F034 is worth telling apart from both. Microsoft publishes it as an invalid product key, or a key for a different version of Windows than the one installed, which is a client-side problem rather than a host one. 0xC004F062 and 0xC004E027 turn up in the same logs and Microsoft publishes no meaning for either.

Full reference

Commands that settle this in a few minutes

Microsoft’s resolution for this code on Azure virtual machines points the client at azkms.core.windows.net:1688. If the failing machine is an Azure VM, use that host rather than an on-premises one.

Estates that produce this code by design

Some environments generate 0xC004F042 as a matter of routine, and the pattern is worth recognising before you start changing keys.

• Two host generations running side by side, with both publishing a service record. Clients find whichever DNS hands them, so roughly half the estate works and half does not, and nobody can reproduce it reliably.
• An application host and an operating-system host in the same domain. Both are legitimate, both publish _vlmcs._tcp, and neither can serve the other’s products.
• A machine migrated from another organisation, still carrying a pinned host from its old network. Discovery never runs, so it fails from the first boot and never touches your infrastructure.
• An Azure virtual machine on an on-premises host name, or the reverse.

What a host key actually decides

The host key is the entitlement in machine-readable form. It is what tells the service which products it may activate, and nothing on the host or the client changes that. There is no registry value that widens it, no service restart that unlocks a newer product, and no client-side setting that talks a host into serving something it was not issued for.

So the practical question is only ever which key is on the host and what it covers. The description line in slmgr /dlv names the key; your licensing portal says what it entitles you to. Where those two answers and the products you are deploying do not line up, you have found the cause, and it is a licensing question rather than a technical one.

When the right host still refuses

1. Confirm the host is genuinely activated. slmgr /dlv on the host should read Licensed. An unactivated host produces 0xC004F041, not this code, but a host that lapsed can produce a confusing mixture.
2. Confirm the count. A host below the threshold refuses with 0xC004F038, which is a different article and a different fix.
3. Confirm the client is a volume client. slmgr /dli should not name a retail or MAK channel; a machine on either never uses a host at all.
4. Compare the clocks. Microsoft names a difference of more than four hours between client and host as a cause of activation failure.
5. Read the client’s Application log. Event ID 12288 records the attempt with the host and port used, and 12289 records what came back.

Keeping it from recurring

• Decide which host serves what, and make the DNS records reflect it rather than accumulating.
• Retire old hosts properly: remove the host key and delete the service record, rather than switching the machine off and leaving the record behind.
• Where an application host and an operating-system host coexist, document which is which somewhere the next person will find.
• Check the host key against the products you are deploying before a rollout, not after the first hundred machines fail.

Every code this article covers

Confirm the fix worked

1. slmgr /dlv on the client reports Licence Status: Licensed.
2. The KMS machine name in that output is the host you intended, not the one that refused you.
3. slmgr /ckms has been run if you pinned the host to prove the diagnosis, and the client still activates afterwards.
4. A second client of the same edition activates through discovery alone.
5. An older client that was already working still activates, which tells you nothing regressed on the host.

Questions people ask about this