0xC004F074 and 0x8007232B: No KMS Host Could Be Found on Your Network

Fix it now

Windows finished the activation attempt without reaching a KMS host. Microsoft documents four things that cause it: no _vlmcs record in DNS, TCP 1688 blocked on the way, the Software Protection service stopped on the host, or a clock more than four hours out between client and host.

w32tm /resync
nslookup -type=srv _vlmcs._tcp
slmgr /dlv

1. Read the nslookup answer. A host name and port 1688 means DNS is doing its job and the fault is further along the path. “Non-existent domain” means the record is missing, or the client is searching a DNS domain that does not hold it.
2. If the record resolved, test the path before changing anything: Test-NetConnection kms.contoso.local -Port 1688 in PowerShell. TcpTestSucceeded : False means TCP 1688 is blocked between this client and the host.
3. If the record did not resolve, and only then, pin the host by hand with slmgr /skms kms.contoso.local:1688 and activate with slmgr /ato.
4. Confirm the result in the slmgr /dlv output: Licence Status reads Licensed, and the KMS machine name is the host you meant to reach.

Do not open with slmgr /skms. It switches DNS auto-discovery off on that client, so it hides a broken SRV record rather than fixing it and leaves you a machine that stops activating the day the host is renamed.

If that fixed it you can stop here. If not, the next section covers what the client does between DNS and port 1688, and which of the five documented causes you are looking at.

Why it happens

Volume-licensed Windows carries no key of its own. It ships with a GVLK, a generic volume licence key identical on every machine of that edition, and that key is an instruction rather than an entitlement: find a Key Management Service host on this network and borrow a 180-day activation from it. 0xC004F074 is the licensing service reporting that it followed the instruction and came back with nothing.

A client finds the host one of two ways. By default it asks DNS for a service record named _vlmcs._tcp in its own DNS domain; the host registers that record when the Software Protection service starts and re-registers it every 24 hours. If someone has pinned a host with slmgr /skms, the name sits in the registry instead and DNS is skipped entirely.

The companion codes name the layer that failed rather than the reason behind it. 0x8007232B, 0x80092328 and 0x8007251D are all DNS reporting that no such record exists. 0x8007232A is different in kind: the DNS server answered, and its answer was a failure, which points at the server rather than at the record. None of them says anything about your entitlement, and no key needs replacing.

Full reference

Commands worth knowing on both machines

slmgr /cdns turns publishing off. It is the opposite of what you want when clients cannot find the host, and it is a common misreading of the option list.

Reaching clients in other DNS domains

A KMS host publishes its record into its own domain only. In a multi-domain forest that leaves every other domain’s clients with nothing to find, which produces 0xC004F074 across whole sites while the host’s own domain activates without complaint. The supported fix is to list the extra domains on the host and let it publish into each of them.

Both values live under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform. Restart the Software Protection service after changing either one; that restart is what creates the records.

Creating the record by hand

Where dynamic update is not available, or the host has no rights to write into the zone, create the record yourself. On a Microsoft DNS server:

1. Open DNS Manager and expand Forward Lookup Zones.
2. Right-click the domain, and choose Other New Records.
3. Select Service Location (SRV), then Create Record.
4. Enter service _VLMCS, protocol _TCP, port number 1688, and the fully qualified name of the KMS host.
5. On a BIND 9.x server the equivalent record is _vlmcs._TCP, type SRV, priority 0, weight 0, port 1688, pointing at the host’s FQDN or A name.

When all five causes are ruled out

• Check the client’s Application log for Event ID 12288 and 12289. A 12288 with no matching 12289 means the request left and nothing came back, which puts the fault on the network or the host, not on the client.
• On the host, look in the Key Management Service log for Event ID 12290. It records each client that contacts the host, with the client’s CMID and the count at the time.
• Look for Event ID 12293 on the host. It reports that the host failed to publish its DNS records, which is the cause dressed as a symptom.
• Confirm the client is actually using a GVLK. slmgr /dlv should describe it as VOLUME_KMSCLIENT. A machine carrying a MAK or a retail key will never talk to a KMS host at all.
• If the host has been moved to a non-default port with slmgr /sprt, every client and the SRV record must carry that port too.

The clock this all runs on

That spread is why this is rarely an emergency on the day it appears. A machine that activated last week has months of margin, and a client that cannot reach the host keeps asking every two hours until someone fixes DNS. It becomes urgent only when a whole estate has been unable to renew for six months and the grace period expires on all of them within days of each other.

Every code this article covers

Confirm the fix worked

1. slmgr /dlv on the client reports Licence Status: Licensed.
2. The KMS machine name and port in that output are the host you intended, not a stale one.
3. The client’s Application log shows a 12289 following the 12288, with the activation flag set to 1.
4. On the host, the Key Management Service log records a 12290 for that client.
5. Reboot one client and confirm it stays activated without anyone touching it.

Questions people ask about this