0x800F0906 and 0x800F081F: .NET Framework 3.5 Will Not Enable on Windows

Fix it now

Enabling .NET Framework 3.5 is not an ordinary feature install: the payload is not on disk after a normal Windows installation, so Windows has to fetch it. Microsoft publishes 0x800F0906 as the computer being unable to download the required files from Windows Update. Supply the files yourself and the feature enables in under a minute.

winver
Dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess
DISM /Online /Get-FeatureInfo /FeatureName:NetFx3

1. Run winver first and note the version and build. The source must match the version, edition family and language of the running system, and this is where most second attempts fail.
2. Mount the ISO, note its drive letter, and point /Source at the sources\sxs folder on it.
3. Check the sxs folder is readable by the account running DISM. If the source was copied from elsewhere it may have arrived without Read access, which produces 0x800F081F.
4. Confirm the result with the last command: the feature state should read Enabled.

The PowerShell equivalent is Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -LimitAccess -Source D:\sources\sxs, which takes the same source and the same restriction.

If the feature reports as enabled you are done. If it still fails, the next section explains which of the three codes you have and what each one is telling you.

Why it happens

Optional components such as .NET Framework 3.5 are delivered on demand. The manifests describing them are present on every installation but the payload is not, which keeps the installed footprint smaller. When you tick the box in Windows Features, Windows looks for the payload: first in any source you specified, then from Windows Update. If neither can supply it, the operation stops.

On a domain-joined machine, update traffic is usually pointed at an internal update server. Those servers distribute updates, not feature payload, so the request arrives somewhere that cannot answer it. Microsoft’s remedy is a policy setting written for exactly this case, and knowing its name saves an argument with whoever owns Group Policy: Specify settings for optional component installation and component repair.

The three codes are more specific than they are usually treated. 0x800F0906 is the computer being unable to download the required files from Windows Update. 0x800F0907 means an alternative source is missing or invalid AND that policy is set to Never attempt to download payload from Windows Update – so it names the setting that is blocking you. 0x800F081F means an alternative source was supplied but the location does not contain the required files, the user does not have Read access to it, or the files there are corrupted, incomplete or invalid.

That distinction is the whole article. 0x800F0907 is a policy problem and no amount of pointing at media fixes it if the source you gave is also wrong. 0x800F081F is a source problem and the READ ACCESS clause in Microsoft’s wording is the part people skip, because a copied sxs folder frequently arrives without it.

Full reference

What each code is published as

The policy, by its real name

The setting is Specify settings for optional component installation and component repair, under Computer Configuration, Administrative Templates, System. It offers the three things that matter here: an Alternate source file path, an option to contact Windows Update directly for repair content instead of Windows Server Update Services, and the Never attempt to download payload from Windows Update option that 0x800F0907 is reporting. Naming it precisely is worth doing, because a request to “let the machine reach Windows Update” is usually refused and a request to enable this specific setting for a specific group usually is not.

Enabling the feature from a source

winver

Dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -LimitAccess -Source D:\sources\sxs

DISM /Online /Get-FeatureInfo /FeatureName:NetFx3

/LimitAccess stops Windows contacting Windows Update at all, which is what you want when a source is supplied and when the machine is isolated. Leave it off if you want Windows Update used as a fallback. On Windows Server, the Add Roles and Features wizard offers an alternate source path on its confirmation page, pointing at the same sxs folder.

Why the source has to match

Where to look when it still fails

One more code is worth recognising here. 0x800F0922 is documented alongside these three and Microsoft attributes it to processing advanced installers and generic commands failing, with Read and Execute permissions on the sxs folder as the first thing to check. If that is what you have, the permissions on the source really are the answer rather than a guess.

Every code this article covers

Confirm the fix worked

1. Run DISM /Online /Get-FeatureInfo /FeatureName:NetFx3 and confirm the state is Enabled.
2. Open Windows Features and confirm the .NET Framework 3.5 entry is ticked.
3. Launch the application that required it and confirm it starts.
4. Reboot and confirm the feature is still reported as enabled.
5. If you changed a policy, run gpupdate /force on a second machine in the same scope and confirm the feature enables there without a local source.

Questions people ask about this