Office 0xC004F027: the licence is tampered after a KMS crack or activator

Fix it now

Office is refusing licence data that did not come from Microsoft’s licensing service. Microsoft publishes no description for 0xC004F027, so read the vendor’s own text on the machine with /ddescr before acting. The repair is to remove every installed key, clear any pinned KMS host, and activate with a key you can account for.

cd "C:\Program Files\Microsoft Office\root\Office16"
cscript ospp.vbs /ddescr:0xC004F027
cscript ospp.vbs /dstatus
cscript ospp.vbs /unpkey:XXXXX
cscript ospp.vbs /remhst
cscript ospp.vbs /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
cscript ospp.vbs /act

1. Note the last five characters of every key /dstatus reports, and run /unpkey: once for each. There is often more than one.
2. /remhst removes the KMS host name and resets the port to 1688. If an activator pinned a loopback address as a host, that is what clears it.
3. Before you install a genuine key, deal with whatever wrote the data. Removing licence state on a machine that still runs an activator at logon buys you a few days.
4. Take a restore point or a snapshot first if this is a machine you cannot rebuild.

Reinstalling Office on its own does not clear this. The licensing store sits outside the Office program files and survives an ordinary uninstall.

If /dstatus reports a licensed status that survives a reboot, you are done. If it reverts, something is putting the state back and the next section covers it.

Why it happens

Volume editions of Office do not keep their entitlement in the program files. They keep it in a protected licensing store made of signed licence files and a token store, both maintained by the Software Protection Platform. The service re-reads that store and checks what it finds, and this code is what comes back when the check does not pass.

Microsoft publishes no description for 0xC004F027, and none for 0xC004F023, 0xC004F01D, 0xC004F006, 0xC004F02A or 0xC004D319 either. That is worth knowing before you accept a confident one-line meaning from anywhere. What you can do is ask the machine: cscript ospp.vbs /ddescr:0xC004F027 prints the text Office itself holds for the code, and that is the only description with the vendor behind it.

In the field, the overwhelming majority of these are installations where a third-party activator, KMS emulator or loader has written into the licensing store. That is an observation about where the code turns up rather than a published cause, and it matters because it changes what the repair has to include. If you clear the store and leave the thing that wrote it, the state comes back.

It also explains why the error survives the fixes people try first. Reinstalling Office replaces the program files and leaves the licensing store where it is. An Office repair does the same. Until the state is cleared and a legitimate key installed, every attempt hits the same refusal.

Full reference

Telling the variants apart

The switches this repair uses

Take a restore point or a virtual machine snapshot before rebuilding licensing state, and be prepared to reactivate Windows as well as Office. Both sit on the same Software Protection Platform, and a machine that ran an activator has usually had both touched.

Treating the machine, not just the licence

An activator is not a licensing shortcut with a licensing-shaped risk. It runs with high privilege, it disables or patches parts of the licensing stack, and it commonly arrives bundled with other payloads. A machine that has run one needs a full antivirus scan and, in a business, a decision about whether it can be trusted at all rather than just relicensed. Your documents are not touched by any of this; the question is what else was.

If this is a managed estate

1. Find out how widely it has spread. One machine is an incident; twenty is a process problem, usually a shared image or a build document that nobody owns.
2. Check whether a volume agreement already covers these devices. If it does, the fix costs nothing but the clean-up and an activation against your own host.
3. Rebuild the reference image from Microsoft media, deploy with the product ID that matches your licence, and run OSPPREARM.EXE before Sysprep so the deployed machines get unique Office client machine IDs.
4. Remove local administrator rights where an activator was run by a user. That is what actually stops the next one.

The six codes and what is knowable about them

0xC004F027, 0xC004F023, 0xC004F01D, 0xC004F006, 0xC004F02A and 0xC004D319 have no published descriptions. The 0xC004D prefix on the last one belongs to a different part of the platform from the 0xC004F codes, which is a hint about where it comes from and not a meaning. Run /ddescr: against each one you actually see, write down what the machine says, and work from that rather than from a table someone assembled without a source.

Every code this article covers

Confirm the fix worked

1. cscript ospp.vbs /dstatus reports a licensed status with the channel you expect.
2. The KMS host name line is empty or names your own host, not a loopback address.
3. An Office application opens with no Unlicensed Product wording in the title bar.
4. Reboot, wait, and re-run /dstatus to confirm the state holds rather than reverting.
5. A full antivirus scan completes with nothing outstanding in quarantine that you have chosen to ignore.

Questions people ask about this