0x800F081E and 0xC1900204: the update does not apply to this edition

Fix it now

Something about this machine does not match what the package or the upgrade expects: the edition, the language, the architecture, or the migration path between the edition you have and the one on the media. Establish what the machine actually is before you change anything.

winver
dism /online /get-currentedition
slmgr /dlv

1. Compare the edition, version, build and architecture you just read against the media you are installing from. One of them will not match.
2. For an upgrade blocked by 0xC1900204, the migration path itself is the problem. Microsoft’s own example is Enterprise to Home, which setup will not perform.
3. If you are entitled to a different edition, change it in place rather than reinstalling: open the activation settings with ms-settings:activation, or run changepk.exe /ProductKey <key>.
4. From a script or a session with no desktop, the equivalent is cscript.exe c:\windows\system32\slmgr.vbs /ipk <key> followed by a restart.
5. Where the change of edition is not a supported in-place path, a clean install from media of the target edition is the only route.

Changing edition changes your licensing position. Do not install a key you are not entitled to use in order to make an error message disappear.

If the package installs or the upgrade proceeds you can stop here. If not, the next section separates the codes that are about edition from the ones that are not.

Why it happens

Windows packages are not universal. A cumulative update, a language pack or a feature payload is built for a specific edition family, a specific architecture and often a specific language, and component-based servicing checks all of that before it will open the package. Setup runs a parallel set of checks for an upgrade: it works out which image on the media applies to this machine and whether the path from the current edition to that one is a supported migration.

The codes here come from both of those systems, and they do not all mean the same thing. 0xC1900204 is MOSETUP_E_COMPAT_MIGCHOICE_BLOCK, the migration choice selected is not available, with Enterprise to Home given as Microsoft’s example. 0xC1900215 is MOSETUP_E_NO_MATCHING_INSTALL_IMAGE, setup could not find an install image for this system. 0xC1900205 is MOSETUP_E_COMPAT_MIGCHOICE_CANCEL, the user chose to cancel because the system does not pass the requirements for the desired migration choice.

Two of them are not edition statements at all. 0x80070663 is Win32 1635, ERROR_PATCH_PACKAGE_OPEN_FAILED: this update package could not be opened. That is a Windows Installer failure and it points at the file, its location or the installer state, not at your edition. And 0x800F081E has no published meaning anywhere in Microsoft’s documentation. It appears when servicing refuses a package before installing it, which is a description of where it happens rather than of what it means.

Full reference

Establishing what the machine is

Changing edition without reinstalling

Where a supported path exists, an edition change is a licensing operation rather than a reinstall. Entering a key for the target edition reconfigures the installation in place, keeping applications and files, and it takes a restart rather than an afternoon.

All three do the same job. If the path is not supported, none of them will help, and a clean install of the target edition is the answer. That is the point at which the entitlement matters, because a clean install of a different edition needs a licence covering that edition.

Codes that are documented and codes that are not

It is worth being straight about 0x800F081E. Microsoft publishes no meaning for it. Explanations circulate that give it a precise sense, usually one that fits whatever the article is arguing, and none of them is sourced. What can be said is where it appears: servicing refusing a package during applicability checking, before installation begins. That tells you to compare package and machine, which is what the causes above do.

Language packs and features are a special case

• A language pack for a version does not install on another version. The version has to match, not merely the edition.
• Optional features and language resources are payloads Windows fetches rather than ships, so an applicability refusal may really be a source problem in disguise.
• On a managed client, servicing may be pointed at a source with no optional content, which produces a different set of codes worth ruling in or out separately.
• Where the machine cannot reach a source at all, an explicit /Source and /LimitAccess proves whether the payload is the problem.

Before you decide a licence is the answer

• Confirm the installed edition rather than trusting what the machine was ordered as. Machines are re-imaged, and the sticker rarely follows.
• Check whether the media you have carries the edition you need. Multi-edition media is common and the right index may already be there.
• Check dism /online /get-targeteditions, which lists the editions this installation can be moved to in place.
• Only then price the change, because the licence is the fix for exactly one of the causes above and not for the others.

Every code this article covers

Confirm the fix worked

1. dism /online /get-currentedition reports the edition you intended to end up on.
2. slmgr /dlv reports the licence as Licensed with a description matching that edition.
3. The package or upgrade that produced the code now completes.
4. winver reports the version and build you were targeting.

Questions people ask about this