0xC004F015 and 0xC004F017: No Licence Installed for This Windows Edition

Fix it now

Microsoft documents 0xC004F015 as SL_E_PRODUCT_SKU_NOT_INSTALLED, meaning the licence is not installed. Two quite different things produce it: a key that belongs to a different edition from the one running, and, on a volume estate, a KMS host whose host key does not cover this client. Establish which before changing anything.

DISM /Online /Get-CurrentEdition
slmgr /dli
slmgr /dlv

1. Compare the edition DISM reports with the product the installed key claims to be. If they disagree, that is the whole answer.
2. If the machine is a volume client, read the KMS machine name from slmgr /dlv. A host that cannot serve this product produces this code with nothing wrong locally.
3. To keep the edition and change the key: slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX, then slmgr /ato.
4. To change the edition instead, check first what this installation can move to: DISM /Online /Get-TargetEditions.
5. On Windows client, entering a Pro key on a Home installation through Start, Settings, System, Activation performs the edition upgrade rather than failing.

On Windows Server the edition change is a DISM operation and needs /AcceptEula and /ProductKey. It is one-way, and some installed roles block it.

If the edition and the key now agree and the machine activates, you are done. If they already agreed, the next section covers the other half of this code.

Why it happens

Product keys are not generic. Each belongs to a key range tied to a specific edition and channel, and the licence store holds licence files describing what each edition requires. Installing a key records which product you claim to hold; the service then looks for a licence that matches both that claim and the edition actually running. When Home is installed and the key belongs to Enterprise, there is no pairing to make, and the service reports the licence as not installed rather than the key as wrong.

That wording is Microsoft’s own. The Software Licensing API documents 0xC004F015 as SL_E_PRODUCT_SKU_NOT_INSTALLED, “The license is not installed”, and it is returned by the offline activation functions among others. It is a statement about what is in the licence store, not a verdict on your key.

There is a second documented route to the same code and it has nothing to do with the local machine. Microsoft has a troubleshooting article in which Windows 10 Enterprise clients return 0xC004F015 against Windows Server 2012 R2 and 2008 R2 KMS hosts, with details naming 0xC004F042 and Event ID 12290 on the host. The cause there is the host key: the host was carrying a key that did not cover the client, and the fix was to install the correct host key on the host. Nothing on the clients was wrong.

0xC004F017 and 0xC004F00A appear alongside these and Microsoft publishes no meaning for either. 0xC004F004 and 0xC004F005 do appear in Microsoft’s activation help, but not where you would expect: they are grouped with the invalid product key, activation-servers-busy and failed-free-upgrade errors rather than with edition mismatches. If you are seeing one of those two, retry and check the key before you start moving editions around.

Full reference

Telling the mismatches apart

Editions, and how they actually change

Server edition conversion is one-way and some installed roles block it entirely. Take a backup, plan a maintenance window, and treat it as a change rather than as a troubleshooting step. slmgr /upk is worse: it removes the installed key and leaves the machine Unlicensed after restart until a valid key is installed and activated.

Why this clusters around imaging

A setup answer file with no key installs whatever the media defaults to, and the corporate key pushed afterwards belongs to a different edition. That is the single most common origin of this code in a managed estate, and it produces a batch of identical failures rather than one. The same trap catches servicing branches: a long-term servicing key will not activate a general availability build, and the reverse is equally true.

When you see this on more than a couple of machines, check the image before you check the machines. One wrong edition in a reference image reproduces itself perfectly across every deployment, and fixing them individually is a lot of work to arrive back where you started at the next rollout.

When everything matches and it still fails

1. Confirm the machine is genuinely on the key you think it is. slmgr /dli shows the last five characters, which is enough to tell two keys apart and is often not the key anyone expected.
2. If it is a volume client, go and look at the host. This is the half of the code that no amount of client-side work reaches.
3. Rebuild the licence files with slmgr /rilc and restart the Software Protection service.
4. Repair the component store with sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth if the scan reports repairs.
5. Check the clock. Activation fails on time skew with codes of its own, but a machine that is hours out will produce a confusing mixture of symptoms.

Before you conclude you need a different key

Compare what you are running against what the key was sold as, and do it from the two commands rather than from memory. A surprising share of these tickets end with the reader already owning the right key and having installed a different one, which costs nothing to correct. Where the two genuinely differ, you need a key for the edition you intend to run, and that is a purchase rather than a repair.

Every code this article covers

Confirm the fix worked

1. slmgr /dlv reports Licence Status: Licensed and the description names the edition and channel you expect.
2. DISM /Online /Get-CurrentEdition matches the key you installed.
3. Start, Settings, System, Activation offers no remediation link.
4. If the fix was on the KMS host, a second client of the same edition activates through discovery alone.
5. An older client that already worked still activates, confirming nothing regressed on the host.

Questions people ask about this