Office 0x8007007B: the KMS host name is malformed or does not resolve

Fix it now

This code has two documented readings and they need different fixes. Microsoft lists it in the Windows activation error codes as “DNS name does not exist”, resolved by troubleshooting DNS; the underlying Win32 error 123 is “the filename, directory name, or volume label syntax is incorrect”. Clear the stored value, set it cleanly, then test resolution.

cd "C:\Program Files\Microsoft Office\root\Office16"
cscript ospp.vbs /remhst
cscript ospp.vbs /sethst:kms.contoso.local
cscript ospp.vbs /act
cscript ospp.vbs /dstatus

1. Host name only in /sethst:. The port goes in /setprt: as a separate call, and only if the host does not use 1688.
2. No space after the colon, no protocol prefix, no leading backslashes. slmgr accepts a host and port together; ospp.vbs does not.
3. If the syntax is clean and it still fails, test the name: nslookup kms.contoso.local, then nslookup -type=all _vlmcs._tcp to see whether the service record exists at all.
4. /remhst clears the stored host name and resets the port to the default 1688, which is the quickest way back to a known state.

Retype rather than paste. A name copied from a document can carry a non-breaking space or a typographic character that looks identical on screen.

If /dstatus shows the host and port you meant, and /act completes, you are done. If the name is clean and still refused, the next section covers the DNS half.

Why it happens

Two readings of this code are documented and both are real. Microsoft lists 0x8007007B in its Windows activation error codes with the description “DNS name does not exist” and the resolution “troubleshoot DNS-related issues”. Separately, the underlying Win32 error 123, ERROR_INVALID_NAME, is published as “the filename, directory name, or volume label syntax is incorrect”. A string that cannot be parsed and a name that does not exist arrive at the same code from opposite directions.

In practice the split is easy to make. If the code appears the instant you press Enter after /sethst:, you are in the syntax reading. If it appears later, during activation, with a stored name that looks correct, you are in the DNS reading and the fix is in the zone rather than in your typing.

The syntax half has one dominant cause. People arrive at ospp.vbs after years of slmgr, and slmgr /skms accepts a host and port together as one string. Office does not. In ospp.vbs the host name goes to /sethst: and the port goes to /setprt: as a separate call, and Microsoft documents them as two switches taking two values. Putting a colon inside the name field gives the licensing stack something that is not a name.

The two companion Win32 codes describe the same class of complaint from slightly different positions. 0x8007000D is error 13, ERROR_INVALID_DATA, “the data is invalid”, and 0x80070057 is error 87, ERROR_INVALID_PARAMETER, “the parameter is incorrect”. You see them when the string parses far enough to be handed on and still describes nothing usable. 0xC004F018 has no published description at all.

Full reference

Strings that will be rejected

The switches you actually need

/remhst does two things, and the second is easy to forget: it resets the port to 1688 as well as clearing the name. If your host listens on a non-standard port, you have to set it again afterwards.

Where the value is stored

Microsoft documents the KMS host name as KeyManagementServiceName and the port as KeyManagementServicePort, both REG_SZ values, and notes that these registry values can also be set using the ospp.vbs script. That is the right way round: the script is the supported interface and the registry is where it writes. Editing the values by hand is not necessary and a mistake there is harder to undo than a mistyped command.

Separating a name problem from a network problem

On testing with an IP address

Storing a literal address instead of a name is a reasonable diagnostic and a poor permanent configuration. If an address works where the name does not, you have proved the problem is name resolution, which is the useful part. Once proved, put the name back and fix the record, because an address stored on a client survives every future change to the host and fails silently the day it moves.

The undocumented code in this set

0xC004F018 has no published description on any Microsoft page. It appears alongside the others when a KMS configuration cannot be used, and any confident one-line meaning you find for it is unsourced. Run cscript ospp.vbs /ddescr:0xC004F018 on the machine and work from what Office itself says.

Every code this article covers

Confirm the fix worked

1. cscript ospp.vbs /dstatus shows the host name and port you intended.
2. nslookup <host name> resolves it from the client.
3. cscript ospp.vbs /act completes without an error.
4. The licence status reports as licensed with a remaining period.
5. Log off and back on, then re-check /dstatus to confirm nothing is overwriting the value.

Questions people ask about this