It was a rough week for Intune. First, BitLocker policies suddenly stopped applying without any good reason. The event logs indicated that the BitLocker policy was applied, but the disk still had the default XTS AES 128 encryption. Then, suddenly, Windows Autopilot enrollments began stalling in Device setup, with nothing but “Identifying.”
Two issues, one week, same Windows image, same assignments, same policies. Something had changed.
Reproducing the Autopilot Identifying failure
The BitLocker issue was already on our radar. Policies looked fine in the logs, but encryption never applied. We broke down that BitLocker issue in detail here: BitLocker policies not getting applied in Intune – 65000. What we didn’t know yet was why. Then came the second problem: Autopilot ESP froze at the Identifying step.
At first, our own lab devices enrolled fine. But someone shared a set of MDM diagnostic logs from a failing device. Based on the RegistryDump reg file, we recreated their exact policy set
Yes, I know, who does that? But after recreating the exact same policy set, suddenly our Windows Autopilot enrollment broke down:
- BitLocker still failed to apply (error 65000) and defaulted to XTS AES 128.
- Windows Autopilot ESP got stuck on Identifying, indefinitely.
This wasn’t a slow Intune sync. The MDM client (OMADMCLIENT) was crashing during enrollment!
Chasing the OMADMClient Crash that caused the Autopilot Identifying issue
The application event log confirmed it. Windows Error Reporting was full of entries for omadmclient.exe crashing with:
- Faulting module: policymanager.dll
- Version: 10.0.26100.5058
If omadmclient dies while PolicyManager.dll is being queried, one thing is for sure: your Autopilot enrollment will be stuck on Identifying forever.
Finding the “Autopilot identifying” trigger
We stripped down all the policies we created based on the MDM registry keys, one by one, and re-ran Autopilot each time.
The breakthrough: the crash disappeared when Application Guard was excluded.
Re-assigning the application guard policy made the ESP collapse again. With Application Guard combined with certain Edge CSPs (isolated browsing, SmartScreen, download restrictions), the crash was 100% reproducible. So the trigger was Application Guard + Edge policies. The root cause was deeper: the PolicyManager build itself.
When did this begin?
At first, it looked like the failures started around the Intune 2508 release. The build shipped a new app control and updated ring behavior, but neither of these changes would explain why PolicyManager and omadmclient.exe suddenly broke, causing Windows Autopilot to get stuck on identifying. It smelled more like a Windows-side update.
Then we found it: KB5065848. An OOBE dynamic update pushed at the end of August, tied to Windows Backup for Organizations.
That KB5065848 package delivered a refreshed policymanager.dll (10.0.26100.5058). And that was the build we kept seeing in the crash logs.
But how was that update getting installed? Well, that’s where Autopilot zero-day patching comes into play. Let’s zoom in on how that ZDP process works in detail!
How ZDP installs updates
To understand exactly how Zero Day Patches (ZDP) are deployed during the Out-of-the-Box Experience, we need to examine the msoobeplugin.dll. That DLL shows the exact ZDP flow.
- OobeZdpManager::StartUpdate spins up a CZDPTask.
- CZDPTask::_BeginAsyncSearch runs a WU query with:
- IsInstalled = 0 AND DeploymentAction = ‘Installation’ AND CategoryIDs contains ‘<ZeroDayPriority GUID>’
Only updates tagged as Zero-Day Priority are returned.
- _FilterUpdates enforces the metered rule: only High priority (DownloadPriority = 3) updates survive if the device is on a metered network.
- _Download calls IUpdateDownloader → payloads land in C:\Windows\SoftwareDistribution\Download\<GUID>.
- _Install hands them to IUpdateInstaller, committing them into WinSxS.
From there on, we started to examine the WindowsUpdate.log and ReportingEvents.log to find out if they contained some more information about the ZDP patches!
Spotting the ZDP run
While digging through the Windows Update logs, we noticed exactly that:
- WindowsUpdate.log showed ClientApplicationID = OOBE ZDP with KB5050575, KB5065847, and KB5065848 listed for download.
- ReportingEvents.log confirmed detection, download, and install.
That explained why policymanager.dll 10.0.26100.5058 suddenly appeared and why omadmclient.exe began to crash. And then something strange happened.
The very next day, a new Autopilot enrollment (with an application guard policy assigned) told a different story. OOBE ZDP still installed KB5050575 and KB5065847 but KB5065848 was gone. The device went through Autopilot without a single omadmclient crash. Checking manually confirmed it:
No results. The package was missing. Microsoft had quietly pulled the ZDP patch back. That one change explained why the issue started suddenly, and why it disappeared just as suddenly.
Microsoft’s Official Announcement
A few hours later, Microsoft published an advisory mentioning that some users couldn’t access their Microsoft 365 apps or resources. The advisory pointed at KB5065848 as the common thread, and sure enough, it noted both BitLocker not applying and the device stuck on Identifying during Autopilot ESP.
That lined up perfectly with what we were seeing: pulling the ZDP package fixed both.
But the other half of their announcement, the missing MS 365 apps inside Company Portal, is still unresolved. That problem wasn’t caused by KB5065848 and wasn’t fixed by pulling the ZDP package. Microsoft bundled three separate issues together, but only two of them were tied to the ZDP OOBE update.
And a funny thing? The Windows Backup for Organizations restore functionality that KB5065848 was supposed to deliver quietly disappeared along with it. With it, the restore option during the OOBE is now gone again it seems?
As nothing happened (until you manually install the August build before enrollment)
They closed the advisory with the usual “Next steps: we’re performing an in-depth root cause analysis …” Well… let me do that with a joke I stole from Niehaus: “Root cause analysis: Europeans were our testers.”
Why KB5065848 broke it
We were still able to grab the KB and crack it open. Inside, it wasn’t just a “Windows Backup for Organizations” feature update. The package also refreshed core MDM components.
Among the files:
- policymanager.dll (version 10.0.26100.5058)
- windowsbackupandrestorecsp.dll a brand-new CSP for Backup and Restore
That combination explained everything. With the new PolicyManager in place, assigning Application Guard + Edge policies caused omadmclient.exe to crash on startup.
- BitLocker silently fell back to defaults because its CSP never applied.
- ESP sat forever on Identifying because PolicyManager never responded.
Two separate failures, traced back to one DLL refresh inside a single ZDP package: KB5065848.
Conclusion
BitLocker policies silently failing and Autopilot hanging on Identifying looked like two different problems. In reality, they were symptoms of the same cause: KB5065848, a ZDP package that refreshed core MDM components during OOBE.
With KB5065848, in play, Application Guard and Edge policies tipped omadmclient.exe over the edge. BitLocker reverted to its default settings, and ESP was stuck on identifying.
The logs told the story: OOBE ZDP pulled KB5065848, installed it, and the problems started. Microsoft pulled it back, and the problems stopped. Simple as that.
What makes this more than “just another bad update” is the way it hit: during OOBE, silently, before a device ever reached Autopilot. And while BitLocker and ESP are back on track now, the promised Windows Backup for Organizations restore functionality vanished with the patch.
In the end, we didn’t just trace a bug; we got a reminder. ZDP is powerful. It can change core system behavior during enrollment. And when something goes wrong there, your Autopilot enrollment can fail badly!