Troubleshooting Windows Update for Business (WUfB) Deployments in Microsoft Intune

Patching workstations in Intune uses Windows Update for Business (WUfB), a modern cloud-based solution that enables administrators to manage Windows Updates without the need for traditional on-premises infrastructure such as WSUS or SCCM. However, despite its benefits, WUfB deployments can be challenging to troubleshoot when devices do not behave as expected. The processes are different, logging is different, so it can be expected that troubleshooting issues will be a little different as well. This article outlines a structured approach for identifying and resolving issues related to WUfB deployments, when managed through Microsoft Intune.

Understanding the WUfB Architecture

Before diving into troubleshooting, it’s important to understand how WUfB operates within an Intune-managed environment:

Policy Delivery: Intune delivers configuration profiles and update rings to endpoints.
Registry Application: These policies are written to specific registry keys to be consumed by the Windows Update client.
Update Source Detection: The system determines whether to use Microsoft Update or a local WSUS based on policies.
Readiness Assessment: The device must meet certain criteria to install feature updates, governed by readiness policies and compatibility checks.

Core Troubleshooting Areas

When updates fail to apply as expected, the root cause often lies within one or more of the following areas:

Incorrect or missing WUfB settings
Conflicting Group Policies or registry settings
Device readiness or compatibility issues
Misconfigured update source
Failure to reach Microsoft Update endpoints

Verifying Applied WUfB Policies via the Registry

To determine which WUfB settings have been applied on a device managed by Intune, examine the following registry location:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\providers\<GUID>\default\Device\Update

This registry path contains the effective values for update settings deployed via Intune. The GUID isn’t the same, so you will need to scroll through the list of GUIDs under the providers key and locate the key that contains Device/Update. Once there, specific keys to check include:

BranchReadinessLevel: Determines the servicing channel (e.g., Semi-Annual, General Availability)
DeferFeatureUpdatesPeriodInDays: Sets the number of days to defer feature updates
PauseFeatureUpdatesStartTime: Indicates if feature updates are paused
UpdateServiceUrlAlternate: Identifies an alternate update source if defined

Actions:

Confirm that these values reflect the intended Intune configuration profile.
If they are missing or incorrect, review the Intune Update Ring assignment and ensure the device is targeted.

Detecting Readiness Failures

Devices that are not eligible for an update due to compatibility issues will defer the update process silently. To investigate readiness failures, check the following registry path:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\CompatMarkers\NI24H2

Here, the presence of specific values indicates whether the device meets the prerequisites for installing the 24H2 update.

Common Issues:

Missing drivers or incompatible hardware
Application incompatibility
Blocked updates due to safeguard holds

Actions:

Verify the presence and status of RedReason, Resolved, or similar values.
Cross-reference the RedReason with Windows release health documentation for known issues.

Identifying Conflicting Policies (WSUS Configuration)

Even in cloud-native environments, legacy policies—especially those defining WSUS servers—can interfere with WUfB.

Check for WSUS-related policies here:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

Key Value:

WUServer: If this value is set, the device is still pointing to a WSUS server for update management, overriding WUfB.

Actions:

If WUServer is defined, identify the source:
- Group Policy (via gpresult /h report.html)
- Configuration Profiles with custom OMA-URI
Remove or override this setting using a remediation script or Intune policy

Best Practice:

Use Policy CSP settings in Intune to explicitly disable UseWUServer, ensuring WUfB takes precedence:

<pre><code><SyncML>
  <CmdID>1</CmdID>
  <Add>
    <Target>
      <LocURI>./Device/Vendor/MSFT/Policy/Config/Update/AllowUpdateService</LocURI>
    </Target>
    <Data>true</Data>
  </Add>
</SyncML>

Verifying Connectivity to Microsoft Update

For devices managed by WUfB, access to Microsoft Update endpoints is essential. Network configurations, firewalls, or proxies may block required services.

Required Endpoints:

*.windowsupdate.microsoft.com
*.update.microsoft.com
*.delivery.mp.microsoft.com
*.do.dsp.mp.microsoft.com

Actions:

Run Test-NetConnection or use a proxy log to ensure traffic is permitted
Confirm that TLS 1.2 is enabled
Validate connectivity using the Windows Update Troubleshooter or wuauclt /detectnow

Reviewing Windows Update Logs

With Windows 10/11, update logs are not stored as flat text files. Instead, they are generated dynamically from event tracing logs.

Steps to Generate Logs:

Get-WindowsUpdateLog -LogPath C:\WULogs\WindowsUpdate.log

What to Look For:

Policy detection errors
Connection failures
Service registration problems

Using Intune’s Update Reports

Intune provides update compliance and deployment reporting for enrolled devices:

Navigate to:

Endpoint Manager Admin Center > Devices > Monitor > Windows Update (Preview)

Here, you can:

See which updates are pending, installed, or failed
Determine update deferral status
Monitor installation deadlines and reboot compliance

Additional Diagnostic Tools

Windows Update Troubleshooter:

Accessible via Settings > Update & Security > Troubleshoot or from Control Panel.

Update Compliance Workbook:

Use Log Analytics and Update Compliance to monitor:

Deployment progress
Safeguard holds
Update eligibility state

Common Pitfalls to Avoid

Overlapping Group Policy and Intune Policies
- GPO settings may win due to higher precedence when not using MDM-enrollment only devices
Misconfigured CSP Policies
- Syntax or case sensitivity errors can cause policies to silently fail
Missing licensing
- WUfB feature deployment requires Windows 10/11 Enterprise/Education SKUs
Update Ring Conflicts
- Multiple update rings with overlapping scopes can cause conflicting behaviors