This blog will be about the 0x800705b4 (Time-Out) error I got during the Autopilot “Preparing your device for mobile management” step. Please note that this is still a blog in progress, so I need to update it after getting a response back from Microsoft
1. Introduction
When looking at the New! Highlights of this wonderful KB5015858 We will notice that this update would also restore the functionality of Windows Autopilot deployment scenarios that are affected by the security mitigation for hardware reuse
If we didn’t remove that Intune Object we would be stuck with the 0x80180014 error
But that’s not all because even while the Microsoft Store Apps fix was not mentioned in the Highlights… some little bird told me it was fixed. If you are interested to know what I am talking about please read this blog first.
I made sure I installed a nice new shiny VM and made sure I installed the 2022-07 preview update KB5015858
2. The Issue
After updating my device with the 2022-07 preview update, I performed a remote wipe. After the remote wipe was done successfully I ended up at the login screen to start the Autopilot enrollment
After entering my username and password and, of course, approving and putting in the sms response for MFA Approving the MFA challenge, the device started enrolling into Azure Ad And Intune. After a few seconds, it completed the first step of “registering your device for mobile management” and started the “preparing your device for mobile management step”.
I waited and I waited…, but it still mentioned that it was “working on it.” After a lot of waiting, the famous time-out error 0x800705b4 popped up.
I was like, what the? I wanted to test if the Microsoft Store apps were working again after a wipe. I totally wasn’t expecting this error. This error almost looks like what the 2022-07 preview update was meant to fix! Of course, the same goes for Windows 11 when we have the installed 2022-07 preview update: KB5015882
Please Note: I also tested the same flow with the monthly 2022-07 update and that isn’t giving us this time-out issue !!! So it’s definitely due to the “Preview Update” version!
I also wrote some stuff about this error some time ago, but at this time, that error isN’T due to the lack of enough CPU power in my VM.
Autopilot and the 0x800705b4 error while Preparing the MDM (call4cloud.nl)
Please read this blog first as it also contains the flow the device goes through at the first ESP phase. I guess it could be useful ?
3. Troubleshooting part 1
Even though I wasn’t expecting this error, it looked like a fun error to troubleshoot. So let’s go! In the Certificate Zombies blog from last week, I showed you how to start troubleshooting device sync errors.
I decided to just use this PowerShell command to troubleshoot this error as well
wget https://aka.ms/intuneps1 -outfile IntuneODCStandAlone.ps1
powerShell -ExecutionPolicy Bypass -File .\IntuneODCStandAlone.ps1
Hopefully, it would show me some logs. After taking a better look at all the logs it produced my eye caught something
As shown above, I noticed some nice DeviceEnrollment and DeviceProvisioning Event Trace Logs inside the files/general folder. I opened the WPA Tool and opened the DiagnosticsLogCSP event trace log to begin with.
At first, I stumbled upon some weird behavior mentioning some node was not found and the corresponding error 0x86000002
Unfolding the Provider Name: Microsoft.Windows.EnterpriseDesktopAppManagement showed me some more information
That information led me further down the rabbit hole. As shown below it mentioned that it couldn’t find the SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\S-0-0-00-0000000000-0000000000-000000000-000\MSI\{{972db620-469f-489a-addb-d421dce15e48}} registry key
I guess we all know what this MSI 972db620-469f-489a-addb-d421dce15e48 translates to, right?
As shown above, that GUID corresponds to the Intune Windows Agent.msi AKA Intune Management Extension. Please note that this screenshot was taken from a working device! When taking a look at the broken device we will notice that the whole EnterpriseDesktopAppManagement key Is missing.
I guess we don’t need that :)? Luckily there is also a SideCar log file in the log files folder, so I decided also to take a look at that one
As shown above, the IME service was not installed! I decided to check if I could install it manually. I used the DownloadUrlList link from a still-working device and downloaded the MSI file. As shown below, it was installed successfully.
After the Intune Management Extension was installed, I retried the ESP, and it immediately completed the “Preparing your device for mobile management” step.
I hoped I was done troubleshooting! But unfortunately, now the device setup was hanging on identifying even while the Win32apps were installing in the background. So the missing Intune Windows Agent was not the root cause. Let’s find out what else we could do
4. Troubleshooting Part 2
After looking at the ETL files again, I noticed that the Windows Intune Agent wasn’t the only one that was giving me those stupid enrollment issues.
As shown above, all of the MSI files aren’t working! So we could skip the idea that our Autopilot enrollment was failing due to the Intune agent.
Do you know what process is responsible for downloading the Intune Windows Agent using a CSP? That’s right, the OMA DM Client (OMADMCLIENT.EXE).
The OMA-DM client can be used to enable an MDM server to initiate an MSI install (Windows Installer) on a device. I guess because all of our MSI’s are failing I guess we need to take a look at what’s happening with the omadmclient.exe
As always I downloaded Procmon and changed some filters to make sure I only got details about the omadmclient.exe
As shown above, it couldn’t find the tmp file it should have created to install the Intune Windows Agent. It looks like the OMADMCLIENT.exe just crashed. To be sure if there was an application error I opened the application event log (duh…)
As shown above, it shows us the 1000 application error mentioning the omadmclient.exe and the module ntdll.dll. I guess… it’s good old nirsoft to the rescue
AppCrashView – View application crashes (.wer files) in Windows 7/Vista (nirsoft.net)
After opening the App Crash View tool I immediately noticed that the omadmclient.exe stopped working a lot of times with the error code 0xc0000374 (a Heap has been Corrupted)
“Heap corruption occurs when a program damages the allocator’s view of the heap. The outcome can be relatively benign and cause a memory leak”
5. Troubleshooting part 3
Okay, it looks like Heap Corruption but I was still wondering if maybe the omadmclient.exe was updated after installing the 2022-07 preview update. Comparing this executable on a working 2022-07 device and the not working installed 2022-07 preview device led me to the conclusion that there was no difference…
But I was still not convinced, so I opened Procmon again to determine which Modules (DLL files) it loaded and which versions they were.
Please note: This test was performed on a failing Windows 11 device.
Just before the omadmclient.exe crashed and WerFault.exe was launched I noticed a “process create” occurring
When taking a better look at this process, I noticed some nice modules.
As shown above, these are the modules loaded with the 10.0.22000.832 version. I am not saying it is because of these DLL’s but for now… it’s good to know the Appxalluserstore.dll was also updated :)… Do you remember why I started to write this blog? Correct! to determine if the bug with the Store Apps was fixed. So I am pretty hopeful right now… But for now, I guess I need to stick with the “heap corruption”
I am not an application debugger, but what the heck, let’s fire up ProcDump and enable it to be a Just-In-Time debugger.
As shown above, with the -i -ma parameters I am making sure that it will dump out the process when it runs into heap corruptions/exceptions. After the debugger was enabled I again logged in to start the Autopilot enrollment and within a minute it started the dump!
Now we have our dump file, we could open it in the wonderfully WinDbg Preview tool. As shown below, it was mentioned the fact the dump file has an exception and we could run !analyze -v to start the analyze.
After pressing the nice button to start the analyze, it showed me again the same c00000374 error
So, something is definitely going wrong with the OMADMCLIENT.exe, but unfortunately, I guess it’s not my job to solve this issue this time. I emailed all my findings to Microsoft Support.
It very much looks like the 2022-07 preview update changed some stuff. Because of that, the omadmclient.exe crashes after the device is wiped and starts the autopilot enrollment again. So, for now, we are still stuck with this issue. Hopefully, the omadmclient crash will be fixed with the 2022-08 update!
Of course, it’s obvious when I have some more information about why the omadmclient.exe stopped working or when I have some feedback from Microsoft, I will update my blog!
6. Microsoft Ticket IT408981
After putting in a support ticket: 32209671, and sending some emails back and forth finally the Issue was acknowledged by Microsoft
This incident mentions the exact same behavior as I noticed, and the funny thing is… they also mention that the update contained a code defect that was causing the issue!
“Current status: We’ve reviewed the recent changes made to the service and determined that the July feature update (KB5015878 and KB5015882) contains a code defect that is causing the issue. We’ve developed a fix to address the code defect and we’re in the initial stages of deploying it to production. “
It’s obvious that I want to know more and whether I was on the right track looking at the changed files, etc. Hopefully, Microsoft will give me some more insight about what was causing it exactly!
Of course, I also made sure I tested if the same VM with the 2022-07 preview update was now working. I enabled the same VM again and watched the Autopilot process checking for (Zero Day Patches) update
After it was done checking for Updates, it arrived at the Azure Ad login screen. At the looks of it, the “fix” for the broking code WAS NOT delivered with ZDP but with something “new” and shiny called Autopilot Agility
But… wait … it isn’t available yet for Windows 11?. I guess Microsoft needs some changes to their Docs? But I guess “Autopilot Agility” is something for a different blog 🙂
After entering the credentials the “preparing your device for mobile management “step begins…. but this time it was completed within a minute or 2!
Conclusion
If you encounter a timeout while preparing your device for mobile management, it will probably be because the Intune management extension failed to install! Hopefully, this blog showed you how to start troubleshooting this issue!
Thank you very much for this article – we have been running into this issue since last week and were having a nightmare of a time diagnosing it. Really appreciate the write-up.
Thanx, if i have more info to share i will do so
This post gets a huge thanks from my colleague and I. We have spent the past 4 days trying to figure out why our Autopilot deployment has halted. I’m not going to go into all of the troubleshooting steps we took but I also came to the same conclusion as you. I have now uninstalled the offending KB prior to signing into the device to provision it and, it succeeds without a hitch. I couldn’t find anything on the web regarding this issue (despite my Google-fu being superb) and like you, also have an open ticket with Microsoft. It does, however, work fine with Windows 11….
Feel free to share stuff that ms told you , as at my side i am only hearing silence
MS’s answer was – for me to check TPM settings in the BIOS as the logs supposedly say it’s disabled (it isn’t and works as expected when the update is removed). They asked me to post my findings on the Intune forum, but to search the forum first in case there are any other posts relating to these two KB’s. There isn’t, I also haven’t posted yet. My ticket is now closed and we will continue to remove the update from any effected device, I feel it will now have a minimal impact for us, however the rest of the world is going to feel this pain for sometime, I hope your article reaches far and wide to save anyone else loosing many days of their lives from troubleshooting!!
So long as you remove the update KB5015858 or KB5015882 and reboot when prompted, PRIOR to signing in to the device, it will provision with no issues.
Mmm so ms closed the case and asked you to post the finding on the ms forum? Thats bad! I am passing this to the intune support as this isnt the way a ticket must be handled
Yesterday, at 16:57, the following service alert email arrived in my inbox –
Microsoft Intune service alert
Advisory information
Title: Users utilizing Autopilot with Enrollment Status Page may see intermittent timeouts when provisioning devices
ID: IT408981
Status
Service Restored
Restored Services
Microsoft Intune
Details
Title: Users utilizing Autopilot with Enrollment Status Page may see intermittent timeouts when provisioning devices
User Impact: Users utilizing Autopilot with Enrollment Status Page may have seen intermittent timeouts when provisioning devices.
More info: Affected users saw the error, “Something went wrong and we weren’t able to install the enrollment status policy provider. Error: 0x800705b4″.
While we were focused on remediation, users could have reset their devices and retried which may have allow them to successfully perform this function.
Impact was specific to Windows 10 and 11 devices that had the July feature update (KB5015878 and KB5015882).
Final status: We’ve confirmed that the fix has completed being safely implemented through our change management process, allowing users to provision devices via the Autopilot Enrollment Status Page without issue. While impact should be remediated, we encourage users who formerly faced the error to reset their devices to ensure that fix is registered. If devices aren’t enabled to reset, users can enable this setting via the Enrollment Status Page.
Scope of impact: Any user of a Windows 10 or 11 device that has the July feature update may have experienced intermittent impact when utilizing Autopilot with Enrollment Status Page to provision devices.
Start time: Thursday, July 21, 2022, at 5:00 PM UTC
End time: Thursday, August 4, 2022, at 2:27 PM UTC
Root cause: A recent update, KB5015878 and KB5015882, contained a code defect which resulted in impact.
Next steps:
– We’re exploring optimizations for our update validation methodology to better isolate potential code defects prior to deployment.
This is the final update for the event.
Hi Tjhanx! yes… Microsoft acknowledged this issue… just as I showed in the blog it self
I just went through the whole scenario, and rebuilt with latest W1123H2 just to make sure, cursed myself when I looked deeper into it and it was a Home licence, updated licence key after cursing the vendor and all working fine again now.
Hehehe yeah enrolling windows home isnt allowd and would defintely break the mdm enrollment 🙂
Rudy, Thanks for this blog.
Here’s my issue. The IME is no longer getting installed automatically during this phase. It errors out that it can’t be installed (Autopilot error and checking the sidecar). The work around is to install it manually, but what exactly is causing this? It should be “automatic” but that’s no longer the case.
If I install it manually, then it completes and moves on to the next time. Not sure what would cause this or how to fix. Hasn’t been an issue for a couple years lol.
ALmost sounds as if you have a corrupted intune policy that comes down when the device is enrolled inot intune. to install the ime, the csp needs to be send over to the device.. i guess that one fails to be delivered
https://call4cloud.nl/2023/06/the-0x800705b4-error-in-our-stars/