Error code 0x800f0954 is a specific Windows Update execution failure that typically triggers when a system attempts to install optional features—most notably .NET Framework 3.5—but cannot communicate effectively with the update source. This error is not a sign of a hardware failure; rather, it indicates a configuration conflict within the Windows servicing stack, often related to how the machine handles Windows Server Update Services (WSUS) versus Microsoft’s public update servers.

The core of the problem lies in the way Windows 10 handles "Features on Demand" (FOD). When you trigger the installation of an older framework like .NET 3.5 (which includes .NET 2.0 and 3.0), the operating system looks for the necessary installation files. In many corporate or managed environments, the system is directed to look at a local WSUS server. If that local server has not been specifically configured to host or approve these optional feature packages, the installation fails, returning the 0x800f0954 status code.

Understanding the Relationship Between WSUS and Error 0x800f0954

In a standard home environment, Windows 10 fetches updates directly from Microsoft’s servers via the internet. However, in professional settings, IT administrators use WSUS to manage and distribute updates to save bandwidth and ensure stability. By default, when a computer is joined to a domain and configured for WSUS, it stops checking the public Windows Update for anything, including optional components.

When you attempt to enable .NET Framework 3.5 through the "Turn Windows features on or off" menu or via the command line, the system queries the local WSUS. If the WSUS server responds with "I do not have this package," the system does not automatically failover to the internet unless specific policies are in place. This "dead end" in the communication path results in the 0x800f0954 error. To fix this, you must either temporarily tell Windows to ignore the local server or provide the files manually.

Method 1: Bypassing WSUS via the Windows Registry

The most direct and frequently successful method to resolve error 0x800f0954 is to temporarily instruct the Windows Update agent to ignore the local WSUS server and go directly to the Microsoft Update cloud. This requires modifying the Windows Registry.

Step-by-Step Registry Modification

  1. Access the Registry Editor: Press Win + R on the keyboard, type regedit into the dialog box, and press Enter. If prompted by User Account Control (UAC), click Yes.
  2. Navigate to the Update Policy Key: In the left-hand navigation pane, drill down through the following folders: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU Note: If the WindowsUpdate or AU keys do not exist, you may need to create them, though their absence usually means the computer is not under a WSUS policy, and this error might have a different cause.
  3. Locate the UseWUServer Value: In the right-hand pane of the AU folder, look for a DWORD value named UseWUServer.
  4. Modify the Value: Double-click UseWUServer. In the "Value data" field, change the number from 1 to 0.
    • 1 means the system uses the local WSUS server.
    • 0 means the system uses the public Microsoft Update servers.
  5. Finalize and Restart Services: Close the Registry Editor. To apply the changes without a full reboot, you must restart the Windows Update service.
    • Open Command Prompt or PowerShell as an Administrator.
    • Type net stop wuauserv and press Enter.
    • Wait for the service to stop, then type net start wuauserv and press Enter.
  6. Retry Installation: Attempt to install .NET Framework 3.5 again via the Control Panel or the method you previously used. The error should no longer appear.

Important Note for Domain Users: After the installation is successful, it is highly recommended to change the UseWUServer value back to 1. Leaving it at 0 may cause your machine to bypass your organization's managed update cycle, potentially leading to security compliance issues.

Method 2: Using DISM with Windows Installation Media

In environments where internet access is restricted or if the Registry method fails, the Deployment Image Servicing and Management (DISM) tool provides a robust alternative. This method involves "sourcing" the files from a physical or virtual Windows 10 installation disc rather than downloading them.

Preparing the Source Files

To use this method, you need a Windows 10 ISO file or a USB installation drive that matches your current Windows version and architecture (e.g., 64-bit).

  1. Mount the ISO: If you have a Windows 10 ISO, right-click it and select Mount. This will assign it a temporary drive letter (for example, D:).
  2. Identify the sxs Folder: Open the mounted drive and navigate to the sources folder. Inside, you should see a folder named sxs. This folder contains the "Side-by-Side" assembly files required for .NET Framework 3.5.
  3. Run the DISM Command: Open PowerShell or Command Prompt with Administrative privileges. Use the following command syntax (replace D: with the drive letter of your mounted media): DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

Detailed Breakdown of the DISM Parameters

Understanding what this command does is crucial for troubleshooting:

  • /Online: Tells the tool to apply changes to the operating system currently running.
  • /Enable-Feature /FeatureName:NetFx3: Specifies that you want to activate the .NET Framework 3.5 feature.
  • /All: Ensures that all parent features of the specified feature are enabled as well.
  • /LimitAccess: This is the critical flag for error 0x800f0954. It prevents DISM from attempting to contact Windows Update on the internet or WSUS. It forces the tool to rely solely on the provided /Source.
  • /Source: Points the tool to the exact location of the installation files.

If the command finishes with "The operation completed successfully," your .NET Framework is installed, and the error is bypassed entirely by using local assets.

Method 3: Adjusting Local Group Policy for Feature Installation

If you prefer a more "official" administrative interface than the Registry Editor, the Local Group Policy Editor (GPEDIT) offers a way to configure how Windows handles optional component repair and installation.

  1. Launch Group Policy Editor: Press Win + R, type gpedit.msc, and hit Enter.
  2. Navigate to System Settings: Go to: Computer Configuration > Administrative Templates > System
  3. Locate the Policy: In the right-hand list, scroll down to find the entry: Specify settings for optional component installation and component repair
  4. Configure the Policy:
    • Set the policy to Enabled.
    • Look for the checkbox labeled "Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS)."
    • Check this box.
  5. Apply Changes: Click Apply and then OK.
  6. Force Policy Update: Open a command prompt and type gpupdate /force to ensure the system recognizes the change immediately.

This policy adjustment is essentially a more permanent and "clean" version of the Registry bypass. It allows the system to continue using WSUS for standard security patches while automatically switching to Microsoft’s public servers for "Features on Demand" like .NET 3.5 or RSAT (Remote Server Administration Tools).

Method 4: Clearing the CBS Logs to Remove Corrupted Data

In some instances, error 0x800f0954 persists because of corrupted logs generated by the Component-Based Servicing (CBS) stack. The DISM utility uses these logs to track the state of features, and if the log files contain erroneous entries, the installation might fail even if the connection to the update server is restored.

  1. Navigate to the Logs Folder: Open File Explorer and go to C:\Windows\Logs\CBS.
  2. Delete Log Files: You will see several files, typically named CBS.log and others with date stamps (e.g., CbsPersist_...log).
    • Note: You might need to stop the "Windows Modules Installer" service (TrustedInstaller) to delete these if they are currently in use.
  3. Execute Clean DISM: Once the logs are cleared, run a standard DISM cleanup command: dism.exe /online /Cleanup-Image /StartComponentCleanup
  4. Retry Feature Installation: After cleaning the component store, try the .NET installation again. Clearing the logs often removes the "memory" of the previous 0x800f0954 failure, allowing the process to start fresh.

Why .NET Framework 3.5 is the Primary Trigger for 0x800f0954

Many users wonder why .NET Framework 3.5 specifically causes this headache when .NET 4.8 or 5.0 install without issue. The reason is structural. .NET 3.5 is considered a "legacy" component in Windows 10. Unlike newer versions that are baked into the OS image, .NET 3.5 is kept as a "Payload" that is not pre-installed to save disk space and reduce the security attack surface.

Because it is a "Feature on Demand," it requires a fresh pull from an update source. Newer software often requires this specific version because .NET 3.5 includes libraries (2.0 and 3.0) that were built on a different architecture than the 4.x series. This makes it an essential component for backward compatibility, yet its "on-demand" nature makes it vulnerable to the WSUS misconfigurations that lead to error 0x800f0954.

Troubleshooting RSAT Errors (0x800f0954 and 0x8024002e)

While .NET 3.5 is the most common culprit, IT professionals frequently encounter 0x800f0954 when installing RSAT (Remote Server Administration Tools). In newer versions of Windows 10 (1809 and later), RSAT is no longer a separate installer package (MSU); it is integrated into the "Optional Features" section of the Settings app.

If you are trying to install RSAT via PowerShell using the Add-WindowsCapability command and receive this error, the Registry bypass (Method 1) is almost always the solution. A quick PowerShell script to automate this for RSAT looks like this: