Best Practices for Enabling .NET Framework 3.5 with Intune: Scripts, Packaging, and Deployment Tips

Enabling .NET Framework Across Your Intune-Managed Devices

Many enterprise and line-of-business applications still depend on .NET Framework 3.5, while Windows 10 and 11 include .NET 4.x by default. Intune admins must choose the right method to enable .NET 3.5 reliably at scale. Below, you’ll find in-depth insights into the most common approaches, pros and cons of each, and best-practice guidance for cloud-only, hybrid, and internet-connected environments.

---

Why .NET 3.5 Matters

Even though modern Windows versions ship with .NET 4.x, older apps often require .NET 3.5. If you skip this step, users may see application errors, installation failures, or degraded functionality. Enabling .NET 3.5 during provisioning or post-deployment ensures legacy apps run smoothly without help-desk tickets.

---

1. Win32 App Deployment with SxS Source Files

Overview: Package the .NET 3.5 installation files (the “sxs” folder from a Windows ISO or WSUS share) together with a script that runs DISM to enable the feature.

How It Works:

1. Extract the \sources\sxs folder from a Windows install ISO.
2. Create a PowerShell or batch script: powershellDISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:%~dp0\sxs
3. Wrap the script and source files as a Win32 app in Intune.
4. Assign to device groups.

Pros:

• Works offline—no dependency on Windows Update.
• Reliable retry logic built into Intune’s Win32 deployment.
• You control the exact .NET version and language packs.

Cons:

• Requires packaging several hundred megabytes of source files.
• Increases your Intune storage usage and network load during delivery.

---

2. Intune PowerShell Script

Overview: Deploy a lightweight PowerShell script that calls the built-in Enable-WindowsOptionalFeature cmdlet, relying on Windows Update (or local sources) for the payload.

How It Works:

1. In Intune, create a PowerShell script profile with: powershellEnable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -NoRestart
2. Assign it to your target device group.
3. Optionally, add a detection script to confirm feature installation.

Pros:

• Simple and quick to push—no large content package.
• Ideal for environments with reliable internet access.
• Minimal Intune storage usage.

Cons:

• Fails if devices can’t reach Windows Update or if local source files are missing.
• No built-in retry logic beyond Intune’s script retry count.
• You may need additional logic to handle language packs or feature-on-demand dependencies.

---

3. Feature-on-Demand (FoD) via Windows Update CSP

Overview: Use the Windows Update client or an Intune configuration policy (CSP) to enable FOD features like .NET 3.5 directly from Microsoft’s update servers.

How It Works:

1. Create a Device Configuration profile in Intune using the OMA-URI: text./Vendor/MSFT/Update/FeatureManagement/EnableNetFx3
2. Configure it to fetch the feature from Windows Update.

Pros:

• Native OS mechanism—no packaging required.
• Automatically downloads the correct payload for the OS build.
• Supported in scenarios where Group Policy or CSP is preferred.

Cons:

• Requires internet connectivity and Windows Update access.
• Less granular control compared to a self-hosted source.
• May take longer if the update service is slow or throttled.

---

4. Co-Management with Configuration Manager and Intune

Overview: In hybrid environments, use Configuration Manager (ConfigMgr) to distribute .NET 3.5 as an application or feature package, while Intune handles compliance and reporting.

How It Works:

1. In ConfigMgr, create a package or application that runs the DISM or FoD install.
2. Enable co-management for workloads such as “Windows Updates” or “Windows 10 compliance.”
3. Use Intune compliance policies to verify .NET 3.5 presence.

Pros:

• Leverages existing ConfigMgr infrastructure for content distribution.
• Works in air-gapped or highly restricted networks.
• Offers rich reporting and deployment flexibility.

Cons:

• Requires a ConfigMgr deployment—adds complexity if you’re cloud-only.
• Dual-tool management may confuse smaller IT teams.

---

Best-Practice Recommendations

• Cloud-Only, Internet-Connected Devices:
  Use the PowerShell script for speed and minimal packaging. Include a detection script to verify installation and retry if needed.
• Cloud-Only, Restricted Networks:
  Package .NET 3.5 as a Win32 app with SxS source files. This ensures no dependency on Windows Update and full offline capability.
• Hybrid Environments with ConfigMgr:
  Distribute via ConfigMgr and use Intune for compliance checks. This offloads bandwidth while preserving Intune’s modern management.
• All Scenarios:
  Test your chosen method in an Autopilot provisioning profile. .NET installations can extend provisioning time; ensure it stays within your SLA.
• Naming and Detection:
  Whichever method you choose, include a clear detection script. For Win32 apps, use Get-WindowsOptionalFeature -Online -FeatureName NetFx3. For PowerShell, check the feature state before and after execution.

---

By aligning your deployment method with your network topology and management tools, you’ll ensure .NET 3.5 is enabled quickly, reliably, and without surprises—keeping legacy applications running smoothly across your entire fleet.