A subtle but pivotal change in the way older Windows 11 devices report their software version during mobile device management (MDM) enrollment could determine whether a device glides through provisioning or becomes permanently stuck at the out-of-box experience (OOBE) screen. Microsoft has confirmed, in support document KB5065083 published August 29, 2025, that for specific older builds, the enrollment request’s ApplicationVersion field will now increment by one relative to the actual build number—creating a one-bit signal that the device is “restore-capable.” IT administrators and MDM vendors who ignore this tweak risk escalating enrollment failures and help‑desk chaos.

The Change at a Glance

The enrollment request sent by a Windows device during OOBE traditionally carries two version numbers: BuildVersion and ApplicationVersion. Both were historically identical, pulled from the device’s Update Build Revision (UBR). After the installation of certain OOBE updates on older Windows 11 images, the behavior diverges: the BuildVersion remains unchanged, while the ApplicationVersion is incremented by a single unit. For example, a device running Windows build 26100.4770 would report BuildVersion 26100.4770 but ApplicationVersion 26100.4771. That one‑digit difference is the new “restore‑capable” marker.

Affected Windows Versions and Updates

The +1 logic applies only to devices that have received particular servicing updates:
- Windows 11 23H2: after installing the August 26, 2025 updates KB5064080 (monthly) or the OOBE package KB5065813.
- Windows 11 24H2: after installing the August 29, 2025 updates KB5064081 or OOBE KB5065848.

Older devices running these versions without the OOBE package remain unaffected; they will continue to report identical BuildVersion and ApplicationVersion values. The update is cumulative and designed to be slipstreamed into existing imaging and Autopilot provisioning pipelines.

Why the Signal Matters: The Restore CSP Conundrum

At the heart of this change is the Restore Configuration Service Provider (CSP). Microsoft has been rolling out an OOBE restore experience that lets users restore data from a previous device or backup during the initial setup. However, the code that enables this—the restore CSP—is delivered via a separate OOBE update package. Without a reliable way for MDM servers to know whether a freshly booted device actually contains that package, pushing restore policies blindly could break enrollment. If the CSP is absent and the MDM sends restore‑related commands, the device can hang or fail in OOBE, requiring manual reimaging or recovery.

Before KB5065083, there was no in‑band mechanism for MDM providers to detect restore‑capability. The ApplicationVersion bump solves this asymmetry: it is a lightweight, device‑reported signal that requires no additional protocol handshake. As soon as the enrollment request is parsed, the MDM server can decide whether to safely push the restore CSP.

Implications for MDM Providers and IT Admins

The practical risk is stark. An MDM product that always assumes the restore CSP is present—or, conversely, one that never sends it—will encounter two distinct failure modes:
- False positives: sending restore policies to a device that lacks the CSP causes policy application errors and OOBE stalls. Help‑desk tickets spike as devices sit at the “Just a moment…” screen indefinitely.
- False negatives: never sending the restore CSP deprives eligible users of the streamlined restore experience, undercutting the update’s value.

Microsoft’s own documentation warns that mismatched expectations are a real‑world cause of failed enrollments. The change is therefore a call to action for both MDM vendors and enterprise administrators.

Detection Logic for MDM Servers

The core detection is simple: compare the numeric value of ApplicationVersion with BuildVersion. If the former equals the latter plus one (incrementing only the last component), the device is restore‑capable. Pseudocode from the Windows‑forums discussion illustrates the safe approach:

build = parseVersion(enrollmentRequest.BuildVersion)   // e.g., 26100.4770
app   = parseVersion(enrollmentRequest.ApplicationVersion) // e.g., 26100.4771

if (app == incrementLastComponent(build, 1)) {
    // Device signals restore-capable; safe to send restore CSP
    sendRestoreCSP = true;
} else {
    // Fallback: do not send restore CSP unless the device is known good
    sendRestoreCSP = false;
}

Vendors should log both the raw string values and the parsed numeric components for audit trails. A telemetry flag such as EnrollmentDetectedRestoreCapable can be retained for 30–90 days to correlate with help‑desk tickets.

For MDM Vendors

  1. Implement the +1 detection as a configurable rule. Use the pseudocode above and ensure it gracefully handles edge cases (e.g., four‑part version numbers).
  2. Make restore CSP pushes idempotent. If the CSP execution fails, implement bounded retries with exponential backoff. Never block enrollment indefinitely; fall back to a safe, non‑restore path after X attempts.
  3. Add an admin‑facing indicator. Show a “restore‑capable” badge in the management console, along with the raw BuildVersion/ApplicationVersion values and the KB reference.
  4. Provide a simulation mode. Allow admins to inject synthetic enrollment payloads with and without the +1 signal to validate policy behavior before production rollout.

For Intune and Tenant Administrators

  1. Refresh OOBE images. Integrate the OOBE update packages (KB5065813 for 23H2, KB5065848 for 24H2) into your provisioning media. Devices that receive these packages will correctly signal restore‑capability, eliminating the ambiguity.
  2. Gate restore policies behind the signal. If your MDM console supports sequencing, only push restore CSP to devices that report the +1 marker.
  3. Pilot aggressively. Test the flow on 10–50 devices before broad deployment. Monitor event logs under DeviceManagement-Enterprise-Diagnostics-Provider and collect ESP logs via mdmdiagnosticstool at the first sign of OOBE hang.
  4. Check Conditional Access. Ensure that any CA policies applicable during enrollment do not block the endpoints required by the restore CSP; otherwise, the signal becomes moot.

Troubleshooting Enrollment Failures

When a device freezes in OOBE after an MDM push, start by opening a command prompt (Shift+F10) and running:
- mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment -cab c:\temp\mdmdiag.cab
- Collect ESP tracking logs from C:\Windows\Panther\UnattendGC\setupact.log
- Cross‑check the enrollment request payload from MDM telemetry to confirm whether the device sent the +1 ApplicationVersion and whether the server acted on it.

If the device is restore‑capable but the MDM did not send the CSP, verify that the OOBE update was applied. If it wasn’t, re‑image with the updated package. If the device is not restore‑capable but the MDM sent the CSP anyway, temporarily disable restore policies for that group and manually complete OOBE.

A Pragmatic Fix, But Not Without Risks

Microsoft’s choice to overload the ApplicationVersion field is a classic engineering trade‑off. Adding a new field or a separate protocol handshake would have required broader changes across MDM stacks and client code. The +1 convention reuses existing plumbing, making it backward‑compatible and cheap to implement. However, it also introduces a fragile dependency: any future servicing update that modifies version reporting could break the logic. Administrators should track release notes for the affected KBs and test each servicing update against their detection rule.

Security‑conscious organizations should note that the +1 signal alone is not a strong attestation. It merely indicates the presence of a software package; it does not verify integrity or authenticity. Pair the detection with device attestation, enrollment certificate validation, and continuous compliance checks before allowing restore‑related data flows.

Looking Ahead: Stability and Interoperability

Microsoft has not publicly committed to keeping the +1 convention permanent. It is best understood as a servicing‑window signal—active as long as there are devices in the fleet that need the OOBE package to become restore‑capable. Once all supported builds natively include the restore CSP, the signal may be retired. Until then, MDM vendors must ensure their logic remains aligned with the documentation.

Interoperability across third‑party MDM products is another open question. The forum discussion urges IT buyers to ask their vendors for a roadmap item that explicitly supports the +1 detection. Early adopters of the updated logic have reported reduced OOBE failures in pilot groups, but broad ecosystem adoption is still underway.

The Bottom Line

KB5065083 is not a routine documentation update; it is a canary in the enrollment coal mine. The +1 ApplicationVersion signal gives MDM servers a fighting chance to avoid a class of OOBE failures that have plagued Windows 11 deployments. IT administrators and MDM vendors who act on the guidance—implementing the detection rule, refreshing images, and piloting the restore flow—will protect their users from disruptive enrollment stalls. Those who ignore it risk a surge in help‑desk calls the next time a fleet of older devices hits the provisioning pipeline.