Fix Windows 11 25H2 Not Installing from Intune Because of a Safeguard Hold

If Intune says the device is in scope but Windows 11 25H2 never installs, check for a safeguard hold before you start rebuilding policies or blaming enrollment.

Microsoft’s own Intune guidance is blunt: feature update policies do not downgrade devices, and devices won’t install a feature update if the targeted Windows version is blocked by a safeguard hold. Microsoft also says safeguard holds are applied when known issues exist and are removed once the issue is resolved.

That means the rollout can look healthy in Intune while the endpoint silently refuses the offer.

Quick Fix Checklist

• Confirm the policy targets Windows 11, version 25H2.
• Confirm the policy is assigned to the correct device group.
• Confirm the device is actually eligible for the target version.
• Check whether Microsoft has placed Windows 11 25H2 under a safeguard hold.
• Confirm the device is not already on a newer build, because feature update policies do not downgrade.
• Check whether old TargetReleaseVersion policy values are pinning the device elsewhere.
• Verify wlidsvc is running.
• Verify telemetry is not disabled below Microsoft’s minimum requirement.
• Confirm Windows Update can reach Microsoft update endpoints.
• Re-scan after the hold is cleared or after you remove the conflicting legacy policy.

Why this happens

1. Microsoft blocked the version, not Intune

Feature update policies in Intune only specify which Windows version the device is allowed to install. Microsoft says the policy stays in effect until you change or remove it, but the device will not install the target version if a safeguard hold is active.

So the common failure pattern is:

• policy assignment is correct
• device is targeted correctly
• Windows Update never offers 25H2
• no useful error appears in the Intune portal

That is usually a hold, not a broken policy.

2. The device is already outside the policy’s scope

Microsoft notes that feature update policies don’t downgrade devices. If the endpoint is already on a newer Windows version, the policy doesn’t apply and the device stays where it is.

This matters in mixed rings where older devices are being upgraded while pilot devices may already be ahead of the target.

3. A legacy Windows Update policy is pinning the device

A feature update policy can be correct and still lose to older controls such as:

• TargetReleaseVersion
• TargetReleaseVersionInfo
• ProductVersion
• WUServer
• WuStatusServer

If those values still point to another release path or WSUS, the device can ignore the Intune feature update rollout.

4. The device can’t report or scan cleanly

Microsoft’s feature update guidance requires:

• Intune management
• Microsoft Entra joined or Microsoft Entra hybrid joined devices
• telemetry at the required level
• wlidsvc running

When telemetry is too restricted or wlidsvc is stopped, the rollout and reporting path gets messy fast.

Root Cause

The most common root cause is a Microsoft safeguard hold on the targeted Windows release.

Secondary causes are usually one of these:

• the device is not eligible for the target release
• the device is already on a newer version
• old Windows Update policy is overriding Intune
• Windows Update scan or reporting prerequisites are broken

Logs / Where to Check

In Intune

Check these views first:

• Devices > Windows > Windows updates > Feature updates
• the specific Windows 11 25H2 deployment
• Assignments
• device status and rollout stage
• Windows Update for Business reporting, if enabled

Look for a pattern where the device is assigned but never leaves the offered or pending state.

On the endpoint

Check these logs:

$logs = @(
  'Microsoft-Windows-WindowsUpdateClient/Operational',
  'Microsoft-Windows-UpdateOrchestrator/Operational',
  'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
)

foreach ($log in $logs) {
  Write-Host "`n=== $log ==="
  Get-WinEvent -LogName $log -MaxEvents 200 |
    Where-Object {
      $_.LevelDisplayName -in @('Error','Warning') -or
      $_.Message -match '25H2|feature update|safeguard|offer|target release|Windows Update'
    } |
    Select-Object -First 25 TimeCreated, Id, LevelDisplayName, Message
}

Also inspect local policy state:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue |
  Select-Object TargetReleaseVersion, TargetReleaseVersionInfo, ProductVersion, WUServer, WuStatusServer

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection' -ErrorAction SilentlyContinue |
  Select-Object AllowTelemetry, MaxTelemetryAllowed

Get-Service wlidsvc | Select-Object Name, Status, StartType

If TargetReleaseVersionInfo is still set, the machine may be pinned to an older release and never accept the 25H2 offer.

PowerShell Triage Commands

Use these to separate a hold from a real device problem:

Write-Host '=== OS version ==='
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Write-Host '=== Windows Update policy ==='
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue |
  Format-List

Write-Host '=== Telemetry policy ==='
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection' -ErrorAction SilentlyContinue |
  Format-List

Write-Host '=== Update service ==='
Get-Service wlidsvc | Format-List Name, Status, StartType

If you need to force a fresh scan after fixing a conflicting policy, use:

UsoClient StartScan

How to tell a safeguard hold from a bad deployment

It is probably a safeguard hold when:

• the policy assignment is correct
• the device is otherwise healthy
• 25H2 never appears for multiple checks
• other devices in the same ring behave differently
• Microsoft release health or release notes mention a known issue for the release

It is probably a deployment problem when:

• the device is not in the assigned group
• the device is on the wrong Windows edition or build family
• telemetry is blocked
• wlidsvc is stopped
• legacy update policy is forcing another release target
• the device is already on a newer build

Remediation workflow

1. Confirm the device is truly targeted by the Intune feature update policy.
2. Remove or neutralize old Windows Update GPO or registry settings if they conflict.
3. Confirm wlidsvc and telemetry prerequisites are in place.
4. Verify the device can talk to Microsoft update services.
5. Check Microsoft release health and the Windows message center for 25H2-related holds.
6. Wait for the hold to clear, then run another scan.

Do not keep reassigning the same policy every few minutes. If Microsoft is holding the release, repeated policy churn will not force the upgrade through.

Prevention

• Keep feature update rings and feature update policies separate in your rollout design.
• Remove legacy TargetReleaseVersion settings before moving to Intune feature update policies.
• Maintain a small pilot ring that mirrors production hardware.
• Watch Microsoft release health before widening the rollout.
• Keep telemetry and Windows Update service prerequisites documented in your baseline.
• Treat a release hold as an upstream condition until Microsoft clears it.

Bottom line

If Windows 11 25H2 is assigned in Intune but never installs, check for a safeguard hold first. Microsoft documents that safeguard holds stop targeted feature updates until the known issue is resolved. In practice, that is often the fastest way to separate a real deployment mistake from an upstream Windows block.