Unable to Enable .NET Framework 3.5 on Enterprise Windows Devices

Jiya Raha 100 Reputation points
2026-11-02T08:31:31.86+00:00

Hello everyone

We are experiencing an issue in our Microsoft Windows environment where .NET Framework 3.5 cannot be enabled on multiple enterprise workstations. The installation either fails during the process or does not complete successfully, preventing applications that depend on .NET Framework 3.5 from running as expected.

We are trying to determine whether the issue is related to missing installation source files, Windows Server Update Services (WSUS) restrictions, Group Policy settings, or Windows Component-Based Servicing (CBS) errors. We would also like to understand if there are any dependency or configuration issues within the Windows servicing stack that could be blocking the installation.

Thank you in advance

Windows for business | Windows 365 Business
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Chance Maurice Niyonzima 825 Reputation points Independent Advisor
    2026-11-02T09:29:44.49+00:00

    Hello Jiya,

    Thank you for posting your question on the Microsoft Windows Forum!

    The most important finding is that .NET Framework 3.5 is a Feature on Demand (FoD). In enterprise environments, installation failures are usually caused by source availability, WSUS/GPO restrictions, or Windows servicing stack issues, rather than a problem with .NET Framework itself.

    What the evidence typically points to

    Before making changes to WSUS or Group Policy, I would first identify the exact installation error code, because the error often reveals the root cause immediately.

    Common error code includes:

    User's image

    Highest-value next step

    Please review the installation logs and identify the exact failure code.

    Check:

    C:\Windows\Logs\CBS\CBS.log

    and:

    Event Viewer
→ Applications and Services Logs
→ Microsoft
→ Windows
→ Servicing

    The goal is to determine whether the failure is:

    Source-related
WSUS-related
Group Policy-related
Component Store-related

    Enterprise environments using WSUS

    One of the most common enterprise scenarios is:

    Devices use WSUS

.NET Framework 3.5 requests Feature on Demand content

WSUS cannot provide the payload

Installation fails

    In that case, verify the Group Policy setting:

    Computer Configuration
→ Administrative Templates
→ System
→ Specify settings for optional component installation and component repair

    If appropriate for your environment, allow Windows to obtain repair content directly from Windows Update or provide an alternate source path.

    Recommended enterprise deployment approach

    The most reliable deployment approach is:

    Use Windows installation media that matches the OS version.
Provide a valid \sources\sxs source path.
Configure the optional component repair policy.
Run gpupdate /force.
Enable .NET Framework 3.5.

    You can also test installation manually using:

    DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:X:\sources\sxs /LimitAccess

    where:

    X:

    represents the mounted ISO or installation media.

    Microsoft References

    One clarification

    Could you share:

    • The exact installation error code
    • Whether the affected devices are configured to use WSUS
    • Whether the issue affects all enterprise devices or only a subset

    These details will help determine whether the root cause is a source-file issue, Group Policy restriction, WSUS configuration, or a Windows servicing-stack problem.

    I hope this answer has brought you useful information. If so, please click on "Accept Answer" and consider upvoting it. Doing so helps other community members identify useful solutions to similar issues.

    Was this answer helpful?

  2. AI answer

    2026-11-02T08:32:03.9433333+00:00

    On enterprise Windows devices, .NET Framework 3.5 installation commonly fails for exactly the reasons listed: missing feature payload files, WSUS or Group Policy restrictions, or servicing-related source resolution failures.

    Key causes by error pattern:

    1. 0x800F0906
    • Windows could not download the required source files.
    • This commonly occurs when the device cannot reach Windows Update.
    1. 0x800F081F
    • The source files could not be found.
    • This indicates the .NET 3.5 payload is missing and no valid alternate source was provided.
    1. 0x800F0907
    • Group Policy or network policy is preventing Windows from downloading the files.
    • This is specifically associated with policy settings that block Internet-based repair content.

    Why this happens in enterprise environments:

    • In Windows 10 and Windows Server 2012 R2, .NET Framework 3.5 is a Feature on Demand.
    • The metadata is present, but the binaries are not included locally.
    • When the feature is enabled, Windows attempts to retrieve the missing files from Windows Update unless an alternate source is configured.
    • If devices are configured to use WSUS, or policy blocks direct Windows Update access, installation can fail.

    Practical resolution paths:

    1. Use installation media as the source
    • Create or obtain Windows installation media that matches the installed Windows version.
    • Mount the ISO.
    • Configure Group Policy Specify settings for optional component installation and component repair.
    • Set Alternate source file path to the mounted ISO sources\sxs folder.
    • Run: 
        gpupdate /force
    • Then enable .NET Framework 3.5 again.
    1. Allow direct Windows Update access for repair content when WSUS is in use
    • In the same Group Policy setting, enable the option to contact Windows Update directly for repair content instead of WSUS.
    • This requires Internet and Windows Update access.
    • Normal servicing can still continue through WSUS.
    1. Configure a local source path for enterprise deployment
    • A local source can be staged from installation media by copying \sources\sxs to a folder such as C:\dotnet35.
    • The servicing policy can then point to that local source path.
    • A WIM file can also be used as the source, with the required image index.
    1. Check servicing prerequisites if setup is blocked
    • Ensure the installation is being run with administrative privileges.
    • Restart the device if a previous installation is pending.
    • If setup reports component store corruption, servicing repair may be required before .NET 3.5 can be enabled.

    What to verify in the environment:

    • Whether affected devices are configured to use WSUS.
    • Whether Group Policy blocks optional component repair from Windows Update.
    • Whether the alternate source path is configured and points to a valid sources\sxs location.
    • Whether the source matches the installed Windows version.
    • Whether CBS or DISM logs show CBS_E_DOWNLOAD_FAILURE, CBS_E_SOURCE_MISSING, or CBS_E_GROUPPOLICY_DISALLOWED.

    For enterprise rollout, the most reliable approach is:

    • provide a matching Windows source,
    • configure the optional component repair policy,
    • point to sources\sxs,
    • run gpupdate /force,
    • then enable the feature.

    If the environment must stay on WSUS only, a local or shared source path for sources\sxs is the supported approach.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.