0x8007007B and 0x800706BA: Wrong KMS Host Name or Port 1688 Blocked

Fix it now

These are two different failures on the same path. Microsoft publishes 0x8007007B as “DNS name does not exist”, so the host name you gave the client does not resolve. 0x800706BA is “The RPC server is unavailable”: the name resolved and nothing answered on TCP 1688.

slmgr /dlv
nslookup kms.contoso.local
nslookup -type=srv _vlmcs._tcp

1. Read the KMS machine name in the slmgr /dlv output first. It is often not the host you think the client is using.
2. If the plain nslookup on that name fails, you have the 0x8007007B case. Fix the record in DNS, or point the client at a name that does resolve with slmgr /skms kms.contoso.local:1688.
3. If the name resolves, test the port: Test-NetConnection kms.contoso.local -Port 1688 in PowerShell. TcpTestSucceeded : False is the 0x800706BA case.
4. On the host, open the port with Set-NetFirewallRule -Name SPPSVC-In-TCP -Profile Domain,Private -Enabled True in an elevated PowerShell session.
5. Retry with slmgr /ato, then confirm with slmgr /dlv that Licence Status reads Licensed.

slmgr /skms switches DNS auto-discovery off on that client. Use it to prove where the fault is, then run slmgr /ckms to hand the client back to discovery once DNS is fixed.

If the client activates you can stop here. If not, the next section explains what each of the two codes is actually reporting and which layer it comes from.

Why it happens

A volume-licensed client has to find a Key Management Service host before it can do anything. By default it asks DNS for a service record called _vlmcs._tcp in its own DNS domain, and connects to whatever that record names on TCP 1688. If someone has pinned a host with slmgr /skms, that name is read from the registry instead and DNS discovery is skipped. Both of these codes come from that sequence, and they come from different points in it.

Microsoft’s activation error list publishes 0x8007007B as “DNS name does not exist”, with a resolution that sends you to the KMS and DNS troubleshooting procedure. That is worth stating plainly, because the same value is Windows error 123 in other contexts, where it means a name is syntactically invalid. In an activation failure it is the resolver reporting that the name it was given does not exist. Correcting a typo does fix it, but only because the corrected name is one DNS can answer for.

0x800706BA is a different layer. Microsoft publishes it as “The RPC server is unavailable”, and gives three things to check: a firewall exception for KMS on TCP 1688, DNS SRV records that point at a valid host, and general network connectivity. KMS runs over anonymous RPC on that port, so a client that has resolved the name and cannot open the socket reports the RPC server as missing rather than the host.

0xC004F056 turns up in the same conversations. Microsoft publishes no meaning for it, so treat it as one more sign the client did not complete an exchange with a host, and diagnose it with the same two tests rather than by the digits.

Full reference

What each command in this article is for

The firewall rule is SPPSVC-In-TCP. Microsoft’s own article on creating a KMS host enables it with Set-NetFirewallRule -Name SPPSVC-In-TCP -Profile Domain,Private -Enabled True, which is more reliable than hunting for a display name that varies between Windows versions.

Reading the path in order rather than guessing

Each step below either succeeds or names the layer that is broken. Working through them takes about two minutes and is faster than changing settings and retrying.

Clients that live in another DNS domain

A KMS host publishes its service record into its own DNS domain. In a multi-domain forest, or where a machine’s primary DNS suffix does not match the domain holding the record, discovery finds nothing and the client reports a DNS failure. There are two supported answers and they suit different situations.

• On the client, slmgr /skms-domain <FQDN> sets the DNS domain to search for the service record. Discovery still happens; it just happens somewhere else. Microsoft documents this for disjoint namespaces, and it is overridden if a specific host is also set with slmgr /skms.
• On the host, the multi-string value DnsDomainPublishList under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform lists extra DNS domain suffixes, and the host publishes its record into each. Restart the Software Protection service afterwards; the restart is what writes the records.
• DisableDnsPublishing in the same key controls whether the host registers at all. 0 or absent means it registers every 24 hours; 1 means it never does.

Neither code is about your entitlement

Nothing here says anything about your product key. No key is exhausted, blocked, expired or wrong, and no licence needs buying to clear either code. Both are faults in your own network: one in a name that does not resolve, one in a port that does not answer. If you are seeing 0xC004C003, 0xC004C020 or one of the 0xC004F0-range refusals instead, you are looking at a different class of problem and this article will not help.

When the port opens and activation still fails

• Compare the clocks. Microsoft names a difference of more than four hours between client and KMS host as a cause of activation failure, and nothing in these two codes points at it.
• Check the client’s Application log for Event ID 12288 and 12289. A 12288 with no 12289 after it means the request left and nothing came back.
• On the host, look in the Key Management Service log for Event ID 12290, which records each client that reaches it.
• Confirm the client is actually a KMS client. slmgr /dlv should describe it as a volume client. A machine carrying a MAK or a retail key never talks to a host at all.
• Confirm the host has met its count. A host below the threshold answers the connection and then refuses, which looks nothing like either of these codes but is often the next thing you hit.

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.
3. Test-NetConnection <host> -Port 1688 returns TcpTestSucceeded True from the client’s own subnet.
4. slmgr /ckms has been run if you pinned a host only to prove where the fault was, and the client still activates afterwards.
5. A second client on the same subnet activates without being pinned, which is what proves discovery works rather than one machine.

Questions people ask about this