KB5065083: AppVersion +1 in Windows 11 MDM Enrollment

Title: What the Microsoft KB (KB5065083) means for MDM / Intune enrollment — why “ApplicationVersion +1” happens, the risk, and what admins & MDM vendors should do
Summary (one sentence)

• Microsoft confirmed that for certain older Windows 11 devices the enrollment request’s ApplicationVersion value will be incremented by 1 (relative to the BuildVersion pulled from Update Build Revision) so MDM servers can detect “restore-capable” devices; this behavior is documented in KB5065083 (published August 29, 2025). (support.microsoft.com)

Why you should care (quick overview)

• If you manage Windows 11 devices with an MDM (Intune or third‑party), this change affects how an enrollment request reports the OS version fields during OOBE. A mismatch between what the MDM expects (a restore CSP present) and what the device actually supports can cause policy failures and leave devices stuck in OOBE — which drives immediate help‑desk activity. The change is intentionally introduced to let MDM controllers detect older devices that have become “restore-capable” after installing the OOBE updates. (support.microsoft.com)

What Microsoft says (core facts from KB5065083)

• The enrollment request pulls two values from the device’s Update Build Revision (UBR): build version and application version. After the OOBE update is installed on certain older devices the build version remains the same while the application version increases by 1 (example: 26100.4770 → application version 26100.4771). (support.microsoft.com)
• The behavior applies to Windows 11 23H2 devices that have the August 26, 2025 updates (KB5064080 or OOBE KB5065813) and Windows 11 24H2 devices after the August 29, 2025 updates (KB5064081 or OOBE KB5065848). (support.microsoft.com)
• Why this was added: some older devices fail to apply the OOBE package that installs the restore CSP; MDM providers cannot otherwise detect whether the device contains the restore CSP, so the enrollment request now increments ApplicationVersion by 1 on devices that are restore-capable — MDMs should use that as the signal to send the restore CSP. (support.microsoft.com)

Technical deep dive — what’s changing, precisely

• The device’s UBR (Update Build Revision) exposes numeric components the platform uses to report build & application version values in enrollment requests. Prior to this change both values matched the UBR snapshot reported by the device. With the OOBE update path for older devices, Microsoft changes how ApplicationVersion is reported during enrollment: when the device is capable of showing the OOBE restore flow (i.e., contains the OOBE/restore package) the ApplicationVersion in the enrollment request is incremented by one relative to the BuildVersion read from the same UBR. The BuildVersion itself remains the canonical OS build number. (support.microsoft.com)
• Example (from Microsoft): a device running Windows version 26100.4770 will show:
• BuildVersion (enrollment request) = 26100.4770
• ApplicationVersion (enrollment request, after OOBE update logic) = 26100.4771
  This +1 ApplicationVersion is the restore-capable marker. (support.microsoft.com)

Operational implication (what breaks if you ignore it)

• If your MDM assumes the restore CSP is present and pushes restore policies to a device that does not actually include the restore CSP code, policy application can fail and the device can become stuck in OOBE. That leads to escalations and manual recoveries (reimage or out-of-band fixes). Microsoft explicitly calls out this mismatch as a real-world cause of failed enrollments. (support.microsoft.com)
• Conversely, if MDM servers are overly conservative and never send the restore CSP, eligible devices will not offer the restore experience during OOBE and users lose the improved restore UX the update enables.

How to detect this in your telemetry (recommendations for MDM vendors & admins)

• Inspect the enrollment request payload
• Pull the enrollment XML/JSON that your MDM receives during device enrollment. Identify the BuildVersion and ApplicationVersion fields that the device reports. If ApplicationVersion == BuildVersion + 1 (numeric increment of one on the last component), treat the device as “restore-capable” per Microsoft’s new signal. (support.microsoft.com)
• Example pseudocode (server-side detection)
• This is intentionally conservative: check numeric equality of the two reported version tokens rather than string-equality to tolerate formatting differences.
  

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

if (app == incrementLastComponent(build, 1)) {
// Device indicates restore-capable → safe to send restore CSP
sendRestoreCSP = true
} else {
// Don't send restore CSP blindly; use safe fallback path
sendRestoreCSP = false
}

- Use careful parsing (split on dots, increment last numeric portion) and log both raw strings and parsed numeric parts for troubleshooting.

• Telemetry flags & logs
• Add a telemetry event: EnrollmentDetectedRestoreCapable = true/false, with rawBuild, rawApp fields. This gives you an audit trail for devices where the MDM acted on the +1 signal (or didn’t). Keep these logs for 30–90 days to correlate help-desk tickets to enrollment behavior.

Recommended actions for MDM vendors (product guidance)

• Update detection logic: implement a defended detection rule that treats ApplicationVersion == BuildVersion + 1 as authoritative signal to send the restore CSP. Use the pseudocode above and make it configurable.
• Make restore CSP pushes idempotent & tolerant: if you send restore CSP and the device errors, handle the error gracefully — do not block enrollment indefinitely; schedule retries and fall back to safer flows. Consider an exponential backoff and a bounded retry count.
• Add explicit logging and admin UI: show a per-device “restore-capable” indicator in your console, with the raw enrollment values and the KB that introduced the change (KB5065083). This helps service desks triage quickly.
• Provide simulator/test harness: add a mode that simulates enrollment payloads with BuildVersion and ApplicationVersion differing so admins can validate policy behavior before mass rollout.

Recommended actions for Intune and tenant admins (what to do now)

• Patch OOBE / images where possible
• Ensure your provisioning images or devices have the listed OOBE updates (the KBs Microsoft called out). Devices that receive the OOBE packages will report the +1 ApplicationVersion when applicable; refreshing images reduces unexpected behavior. (support.microsoft.com)
• Don’t push restore CSP blindly to all enrollments
• If your MDM console lets you sequence policies, gate restore CSP pushes behind the ApplicationVersion detection; only push to devices that report the +1 marker.
• Use Enrollment Status Page (ESP) & mdmdiagnosticstool
• When troubleshooting stuck OOBE/ESP issues, collect ESP logs and MDM diagnostic CABs (mdmdiagnosticstool) as per Microsoft guidance — those logs show ESP tracking and policy application errors and are essential when you escalate to Microsoft. See Microsoft’s ESP troubleshooting guidance for the exact commands and log locations. (learn.microsoft.com)
• Pilot the logic
• Do a small pilot (10–50 devices) with the updated detection & policy flow before a broad rollout. Monitor for OOBE failures, error codes in DeviceManagement-Enterprise- Diagnostics Provider logs, and help-desk tickets.

Why Microsoft chose this approach (short analysis)

• There is asymmetry: MDM servers can push CSPs but historically had no reliable, pre-flight way to know whether a freshly booted device contains the restore CSP code (which is delivered via an OOBE update on older images). To avoid blind pushes that break enrollment, Microsoft added an explicit signal (ApplicationVersion increment) in the enrollment request so MDMs can make an informed decision. That’s a pragmatic fix: it’s a device‑to‑server lightweight signal that avoids adding a new protocol call or changing the enrollment handshake. (support.microsoft.com)

Failure modes to watch (and how to recover)

• Symptom: Device stuck in OOBE after MDM pushed restore CSP → Cause: device lacked restore CSP but MDM assumed presence.
• Recovery: Start with collecting the OOBE/ESP logs (Shift+F10 in OOBE and run mdmdiagnosticstool as documented). If possible, manually complete the OOBE or reimage with refreshed image that includes the OOBE package. (learn.microsoft.com, support.microsoft.com)
• Symptom: Enrollment shows BuildVersion and ApplicationVersion identical (no +1) on a device you expect to be restore-capable.
• Causes to check: device didn’t get OOBE update, image is stale, or the device failed to install OOBE package. Refresh image or apply the OOBE KB as needed. (support.microsoft.com)

Design & security considerations (for larger fleets)

• Don’t overtrust the +1 signal alone as a security decision point — pair it with additional checks:
• Device attestation, enrollment certificate state, and conditional access checks (avoid sending restore flows when conditional access policies would block the required endpoints).
• Provide admin override: allow an operator to enable/disable restore pushes per device if emergency recovery is needed.
• Audit & compliance: record which devices accepted restore CSP and which had failures — this matters for change control and for post‑incident review.

Where to find the authoritative docs (quick references)

• The Microsoft Support article (KB5065083) describing the ApplicationVersion +1 behavior and the affected KBs. (support.microsoft.com)
• Configuration Service Provider (CSP) documentation — explains what CSPs are and how MDMs use them (useful background when you plan to send restore CSP). (learn.microsoft.com)
• Troubleshooting Enrollment Status Page (ESP) — how to collect logs and use mdmdiagnosticstool and other troubleshooting commands. (learn.microsoft.com)

Practical checklist (copyable for change control)

• For MDM vendors:
• [ ] Implement ApplicationVersion == BuildVersion + 1 detection rule.
• [ ] Make restore CSP pushes idempotent and error-tolerant; implement bounded retries.
• [ ] Add telemetry and admin UI indicators for “restore-capable” detection.
• [ ] Pilot on small groups and collect ESP logs for failures.
• For IT admins / tenants:
• [ ] Confirm which devices in your fleet are Windows 11 23H2 / 24H2 and whether the August 26/29 2025 OOBE/Windows updates are applied. (support.microsoft.com)
• [ ] Update provisioning images used in Autopilot / imaging pipelines to include the OOBE packages where possible.
• [ ] If you use Conditional Access, verify restore endpoints aren’t blocked during enrollment.
• [ ] Conduct a small pilot and collect mdmdiagnosticstool output if you see OOBE/ESP failures. (learn.microsoft.com)

Questions this raises (open items to monitor)

• Will the +1 convention remain stable across future servicing (Microsoft can change signals in servicing updates)? Track Microsoft release notes and the KB lifecycle for the OOBE updates referenced in KB5065083. (support.microsoft.com)
• MDM vendor interoperability: confirm third‑party MDMs adopt the detection logic; if you depend on a third‑party MDM, request a roadmap or patch that explicitly supports the +1 detection.

Bottom line / TL;DR

• Microsoft added a small but important signal in the enrollment request: the ApplicationVersion is incremented by 1 on older devices that have the OOBE/restore package present. MDM providers should use that signal to decide whether to send the restore CSP; tenant admins should patch images and pilot the updated flows to avoid enrollment failures. The authoritative details and the KB number are KB5065083 (published August 29, 2025). (support.microsoft.com)

If you want, I can:

• Produce a short script you can drop into your MDM server (C# / PowerShell / Node) that parses BuildVersion/ApplicationVersion and outputs “restore-capable” or not.
• Draft an Ops playbook you can paste into your change request (pilot, rollout, rollback) around this change.
• Walk through how to collect mdmdiagnosticstool output from a device stuck in OOBE and what specific log lines to look for.

Which of those would be most useful right now?

---

Source: Microsoft Support Enrolling an older device causes the application version in the enrollment request to increment by 1 - Microsoft Support