Fix Windows Autopilot Hybrid Join Quality Updates Not Installing During OOBE

If your Windows Autopilot Microsoft Entra hybrid joined devices finish OOBE without taking the expected monthly quality update, or the deployment appears to stall while scanning for updates, the problem may be the Allow OOBE Updates setting in your Enrollment Status Page (ESP) profile.

Microsoft documents this on the Windows Autopilot known issues page as “Devices don’t get quality updates during Microsoft Entra hybrid joined deployments”. On affected builds, quality update scans offered during OOBE can time out during hybrid join provisioning. The result is confusing: the device can still enroll, but it misses the quality update you expected to land before the user gets the machine.

That makes this a real admin problem, not a cosmetic one. If your bench process assumes the device leaves provisioning fully patched, this issue breaks that assumption and leaves you with inconsistent build state across the same deployment batch.

Quick Fix checklist

Use this order before you keep retesting the same hybrid join profile:

1. Confirm the device is using Windows Autopilot Microsoft Entra hybrid join.
2. Check whether the Enrollment Status Page profile has Allow OOBE Updates enabled.
3. Verify the affected device has KB5041571 or later installed.
4. Review whether the quality update scan timed out during OOBE instead of fully failing enrollment.
5. Disable Allow OOBE Updates for the affected pilot group, or move the device to a profile where the setting is off.
6. Rerun provisioning on one pilot device.
7. After enrollment, trigger Windows Update normally and confirm the quality update installs outside OOBE.
8. Update your bench runbook so techs stop treating this as a random network or Intune sync issue.

If you skip step 2, you can spend hours chasing proxy, WSUS, or connector problems that are not the root cause.

Root cause

Microsoft’s Windows Autopilot known issues page says quality update scans offered during OOBE might time out during provisioning for Windows Autopilot Microsoft Entra hybrid joined deployments when Allow OOBE Updates is configured in the ESP profile.

Microsoft also says the issue affects devices with KB5041571 and later, and the issue is still under investigation.

The important detail is that this is not the same as a general Windows Update failure. The problem is the OOBE-time scan path during hybrid join provisioning. In practice, that means:

• Autopilot can still look healthy at a glance.
• The hybrid join flow can still advance far enough to fool the bench team.
• The quality update you expected to install during provisioning never lands.
• The failure only appears when you rely on Allow OOBE Updates in the ESP experience.

So the real fix is usually to stop forcing that update scan inside OOBE for affected hybrid join devices, then patch them immediately after enrollment using your normal update workflow.

Symptoms you will usually see

Affected environments often report one of these patterns:

• device provisioning takes longer than expected during OOBE
• quality updates never install during the Autopilot build
• two supposedly identical hybrid join test devices finish with different patch levels
• techs rerun the same device because it looks like a one-off timeout
• admins blame line-of-business apps, VPN prerequisites, or connector latency even though the problem follows the ESP setting

This is why the issue is easy to misclassify. There is no flashy error code in the title bar. The failure is in the behavior.

Logs and where to check

Check the Enrollment Status Page configuration

In the Intune admin center, review the ESP profile assigned to the affected device:

Devices > Enrollment > Enrollment Status Page

Verify whether Allow OOBE Updates is enabled in the profile used by the hybrid join deployment.

Review Autopilot deployment diagnostics

On the affected device, review:

Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

Use this to line up when OOBE provisioning slowed or when the device moved past the update scan without actually taking the expected quality update.

Review Windows Update logs after the device reaches the desktop

Once the device is past OOBE, review Windows Update operational events here:

Event Viewer > Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational

This helps you prove the device can still evaluate or install updates normally outside the OOBE path.

Review ESP troubleshooting guidance

Microsoft’s ESP troubleshooting guidance is still useful here because it helps you separate an ESP/OOBE behavior problem from a broader enrollment failure.

PowerShell and command-line checks

Confirm current update build state

Get-ComputerInfo | Select-Object WindowsVersion, OsBuildNumber, OsHardwareAbstractionLayer

Review recent Windows Update client events

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Export Autopilot diagnostics for a failed pilot device

Mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;Provisioning -cab C:\Autopilot\hybrid-oobe-updates-timeout.cab

Force a post-enrollment update scan

UsoClient StartScan

If your environment blocks UsoClient or you prefer policy-driven scans, use your standard Windows Update for Business or Windows Autopatch workflow instead. The key test is whether updates succeed after OOBE when the same device could not complete them during OOBE.

Repair workflow

Step 1: Confirm the device is actually in the affected scenario

Do not use this fix path for every Autopilot update complaint. Verify all three conditions first:

• the deployment is Microsoft Entra hybrid join
• Allow OOBE Updates is enabled in the ESP profile
• the missing update behavior happened during OOBE provisioning, not days later

If any of those are false, you are probably in a different Windows Update or Autopilot issue.

Step 2: Move one pilot device to an ESP profile without Allow OOBE Updates

This is the fastest proof step. Assign a pilot device or group to an ESP profile where Allow OOBE Updates is disabled.

If the next provisioning run completes normally and the device can then take the same quality update after enrollment, you have isolated the known issue instead of guessing.

Step 3: Stop expecting the quality update inside OOBE

For affected hybrid join devices, treat OOBE patching as unreliable until Microsoft closes the issue. Let Autopilot finish, then patch the device immediately after enrollment through your normal update ring or remediation workflow.

This is usually less risky than forcing repeated OOBE retries on bench devices.

Step 4: Validate the post-enrollment patch path

After the device reaches the desktop:

1. Sync the device with Intune.
2. Trigger a Windows Update scan.
3. Confirm the expected cumulative update is offered.
4. Install the update.
5. Reboot and verify the build number.

If that path works, your problem is not “Windows Update is broken.” Your problem is specifically the OOBE update scan in hybrid join provisioning.

Step 5: Update your deployment runbook

Bench teams need a short rule for this issue:

• do not keep resealing the same device because it missed the quality update during OOBE
• do not burn time on connector troubleshooting unless hybrid join itself is failing
• do not assume patch drift means Autopilot failed completely
• finish enrollment, then patch the device outside OOBE

That small process change prevents repeated false escalation.

Prevention

Use this prevention pattern while Microsoft continues investigating:

1. Avoid enabling Allow OOBE Updates for hybrid join rings where predictable bench timing matters more than in-OOBE patching.
2. Test new Windows cumulative updates on a small hybrid join pilot before rolling the same ESP behavior to all devices.
3. Keep a post-enrollment validation step that confirms the monthly quality update level.
4. Separate Autopilot success from device fully patched in your deployment checklist.
5. Document that KB5041571 and later are in the affected range until Microsoft publishes a resolution.

Why this matters operationally

This issue hits the worst part of a desktop engineering process: the handoff moment. A device can look done, but it is not at the patch level your team promised.

That creates downstream noise:

• extra restarts after first user sign-in
• confusion when compliance reports disagree with bench records
• wasted effort from techs retrying devices that were never going to patch correctly during OOBE
• inconsistent user experience across the same deployment wave

For many teams, the cleanest short-term answer is to remove Allow OOBE Updates from hybrid join scenarios where stability matters more than squeezing patching into provisioning.

Conclusion

When Windows Autopilot Microsoft Entra hybrid join devices do not install quality updates during OOBE, the fastest useful check is the Allow OOBE Updates setting in the Enrollment Status Page profile. Microsoft already documents that this update scan can time out during hybrid join provisioning on devices with KB5041571 and later.

The practical fix is to stop forcing the update during OOBE, let enrollment complete, and patch the device immediately after enrollment using your standard Windows update workflow. That gives you a repeatable process while Microsoft continues investigating the underlying issue.