0xC004F050 in Office: the product key is invalid or for the wrong edition

Fix it now

Microsoft publishes 0xC004F050 as “the product key is invalid”, and names three checks: the key must be the right one for the product being activated, the characters must have been entered correctly, and an em dash pasted in place of a hyphen will fail. This is about the twenty-five characters and the build they are being offered to, not your network.

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

1. Read the installed product first: open Word, choose File, then Account, then About, and note the product name and version.
2. Read the licence name in the /dstatus output. It tells you which channel this installation expects, and a volume key offered to a retail build is refused here.
3. Retype the key into a plain text editor before you paste it, and check the separators. Microsoft names an em dash pasted in place of a hyphen as a cause of this code.
4. If it is refused again, the key and the installed product do not correspond. Deploy the build the key belongs to rather than looking for a command that forces it.

Firewall changes, proxy exclusions and DNS work have no effect here. The key is decoded locally and refused before an activation request is ever sent.

If activation completes you are done. If not, the next section explains what the licensing service checked and why the same key works elsewhere.

Why it happens

A product key is not a password checked against a list. It is a structured value that decodes to a product identifier describing the edition, the version and the channel it belongs to, and the licensing service can read that locally. If the identifier does not correspond to something the installed Office can be licensed as, the key is refused immediately and no activation request leaves the machine.

That local check explains two things people find baffling. It explains why the error appears instantly, with no pause for a network round trip, and it explains why every network remedy fails against it. It also explains the single most common shape of this problem in organisations: a key from a volume agreement being typed into a build downloaded from a consumer page.

Microsoft’s own guidance for this code is short and concrete. Make sure the key corresponds to the product being activated. Make sure the characters were entered correctly. And check for an em dash where a hyphen should be, which is what a word processor or a chat client silently does to a key someone pasted in. There is no published rule about which letters and digits appear in a key, so ignore any article that gives you a forbidden character list.

The four companion codes have no published descriptions at all. 0xC004F010, 0xC004F078, 0xC004C007 and 0xC004C010 come from the same area and are routinely glossed with meanings the vendor has never stated. Microsoft does publish 0xC004C001, “the activation server determined the specified product key is invalid”, which is the documented server-side refusal in this family and a useful thing to be able to tell apart from a local one.

Full reference

Which product ID belongs to which licence

Microsoft’s own line on that table is worth quoting to whoever built the deployment: if you use the wrong product ID, you cannot activate Office. The applications look identical once installed, which is why this goes unnoticed until a key is refused.

Volume installations already carry a key

By default, volume licensed versions of Office are installed with a Generic Volume License Key, and that key exists to make the installation find and activate against a KMS host or Active Directory rather than to be typed in by hand. Each edition has its own. If /dstatus shows a GVLK-based licence and you are trying to type a different volume key over it, check first whether the machine is meant to activate against infrastructure you already run.

Local refusal against server refusal

The distinction is practical. A local refusal is answered by changing the key or the build. A server refusal is answered by the channel the key came from, and no local change moves it. To read the vendor’s own text for any of these on the machine in front of you, run cscript ospp.vbs /ddescr: with the code.

Before you conclude the key is bad

1. Confirm the installed product name and version from File, Account, About, not from what you think was deployed.
2. Confirm the bitness, because the ospp.vbs path differs and running it from the wrong folder produces output about nothing.
3. Confirm the channel from the licence name in /dstatus.
4. Remove any leftover key with /unpkey: so you are testing one thing at a time.
5. Only then decide whether the problem is the key or the build.

When several Office versions are installed

Two Office generations on one machine each need their own licence and their own key, and they do not share. A key installed while both are present can bind to the one you did not mean, and the symptom is a key that reports as installed while the application you actually use stays unlicensed. Remove the versions you are not licensing, confirm with /dstatus that only the intended installation remains, then install the key.

Every code this article covers

Confirm the fix worked

1. cscript ospp.vbs /dstatus lists exactly one licence and reports it as licensed.
2. The licence name matches the edition shown in File, Account, About.
3. An Office application opens with no Unlicensed Product wording in the title bar.
4. The product ID used to deploy matches the licence you hold.
5. Reboot and re-check, since an activation that has not committed shows itself on the next start.

Questions people ask about this