0x800F0950 and 0x800F0954: Features on Demand and language packs fail

Fix it now

The optional feature, RSAT tool or language pack could not get its payload. 0x800F0954 is the servicing stack saying the update servers it was told to use hold no optional content. Start by establishing which build you are on, because the correct answer changed with Windows 11 version 22H2.

winver
Get-WindowsCapability -Online -Name "<capability-name>"
DISM /Online /Get-Capabilities /Format:Table

1. On Windows 11 version 22H2 or later with a managed update server, the content should already be available from that server through on-premises UUP. Check the server is synchronising it before changing any policy.
2. On Windows 10 version 2004 through Windows 11 version 21H2, the usual cause is a policy conflict. Set Computer Configuration, Administrative Templates, System, Specify settings for optional component installation and component repair to Windows Update, and then either point feature and quality updates at Windows Update too, or stop specifying update sources by class at all.
3. Run gpupdate /force, then retry from Settings, System, Optional features, using View features.
4. Where the machine has no route out, install from media that matches its version: DISM /Online /Add-Capability /CapabilityName:<name> /Source:<path> /LimitAccess.
5. For .NET Framework 3.5 the payload is on ordinary installation media: Dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess.

Two options were removed from that policy in Windows 11 version 24H2, including the one that used to bypass a managed server. If you cannot find it, that is why, and on those builds you do not need it.

If the feature installs you can stop here. If not, the next section explains where the payload is supposed to come from and how the rules changed.

Why it happens

Features on Demand are packages Windows deliberately does not ship inside the image. RSAT, language and handwriting resources, .NET Framework 3.5 and a long list of smaller capabilities sit outside the component store until somebody asks for one, at which point servicing must fetch the payload before it can enable anything. Every code here is that fetch failing.

Microsoft documents where servicing looks, in order: the location given by /Source, then the locations set by Group Policy, then Windows Update for an online image unless access has been limited. When all three fail, Add-WindowsCapability fails silently and throws no exception, which is why the command often just stops rather than telling you anything.

The rule for managed machines has changed, and most guidance has not caught up. It used to be true that a managed update server could not serve this content, and a policy option existed to send optional content to Windows Update while patching stayed on the server. From Windows 11 version 22H2, on-premises Unified Update Platform updates made Features on Demand and language packs available from the update server again, so those clients do not need the policy. In version 24H2 the two options that configured it were removed.

On the builds in between, Windows 10 version 2004 through Windows 11 version 21H2, there is a specific documented conflict worth knowing. Clients cannot download this content when the optional component policy is set to Windows Update while the policy that specifies a source service for particular classes of update points feature or quality updates at the managed server. The two settings disagree, and optional content is what loses.

Full reference

Where servicing looks, in order

1. The location given by /Source, if one was given.
2. The locations configured by the optional component and component repair policy.
3. Windows Update, for an online image, unless /LimitAccess was specified.
4. Nothing. Add-WindowsCapability fails silently at this point and throws no exception.

That last step explains a great deal of the confusion around these codes. A command can appear to do nothing at all, and the absence of an error is not evidence that anything worked.

The policy, and what happened to it

The policy itself is at Computer Configuration, Administrative Templates, System, Specify settings for optional component installation and component repair, and it is delivered by Servicing.admx. Its settings are written under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing. When it is enabled you supply one or more fully qualified alternate source paths, separated by semicolons; a path may be a folder, or a WIM file written as wim:\\server\share\install.wim:3 with the image index on the end. Disabled or not configured means the files come from Windows Update where policy allows it.

UseWUServer is read only from HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. There is no AU subkey under the non-policy CurrentVersion\WindowsUpdate branch, so creating the value there writes something the update agent never reads. If you use the single-machine workaround of setting it to 0, installing the feature and setting it back to 1, use the policy path, export the key first, and put it back.

Commands for checking and installing capabilities

Which media carries what

The Features on Demand and Languages and Optional Features images are not on the public download page. Microsoft lists three channels for them: the Volume Licensing Service Center, which needs volume licensing access; the OEM Portal, which needs OEM access; and MSDN Download, which needs a subscription. That is the only part of this article where a commercial arrangement is genuinely the gate.

When it still fails

• Confirm the capability name exactly. They carry version suffixes and a near-miss produces a silent failure rather than a complaint.
• Check the account has read access to the source path and to the files inside it, not just to the share.
• Check whether the connection is metered, which suppresses optional downloads.
• Compare a working machine with a failing one. The difference is nearly always which organisational unit they sit in and therefore which update policy applies.
• Remember that configuring a Features on Demand installation source does not involve the managed update server at all. They are separate mechanisms and treating them as one is what produces most of the confusion here.

Every code this article covers

Confirm the fix worked

1. Get-WindowsCapability -Online -Name "<name>" reports the state as Installed.
2. Settings, System, Optional features lists the feature as installed rather than pending.
3. For a language resource, it can be selected as the display language.
4. An ordinary update scan still succeeds against the update server you intended, so nothing about patching was disturbed.

Questions people ask about this