The 0x800705B4 error in our stars

In this blog, I am going to scuba dive a bit into the wonders of SyncML and how all devices ended up with sync errors and all new Autopilot enrollments ended up with a nice 0x800705B4 error.

1. Introduction

Last week, I decided to fetch my troubleshooting shovel from the shed to dig some holes because someone posted a question in the MMCP (not MMP-C… that’s something different), and he mentioned my blog.

Preparing your device for mobile management | 0x800705b4 (call4cloud.nl)

Unfortunately, the blog mentions the same error, but when I wrote it, it was because of an error with the latest update that got deployed and wrecked the OMADMCLIENT. But still, with my blog being mentioned, I needed to respond.

After reading the question and the full story behind it, I felt obligated to help him. Of course, he also put in a support ticket at Microsoft, but unfortunately, that got him nowhere. So that sounded like a challenge to me! Can I solve it in 24 hours without having access to their tenant?

When taking a closer look at the issue, he mentioned that they were experiencing a sync issue on their devices, and all new Autopilot enrollments ended up with the error 0x800705b4.

The error above mentions that something went wrong with the policy provider, and we got the famous timeout error.

2. Troubleshooting it “Rudy Style”

So, how am I going to troubleshoot such an issue? I am not working at that company so it’s going to be difficult to even take a look myself right? NOPE!! Wrong! The only thing he needed was my hash from a test device so I could start an Autopilot pre-provisioning!

I opened PowerShell, exported the hardware hash to a CSV, and he made sure to upload it to his tenant.

After reinstalling my device with the latest Windows 11 build, I started the Autopilot pre-provisioning, and as expected, it just hung there preparing your device for mobile management. Mission achieved!!

So, I started troubleshooting by using 1 of the same tools I always use, Fiddler. When looking at the Fiddler trace, I noticed that the first steps in the MDE enrollment were successful. My test device got the Intune Device Certificate and the corresponding enterprise scheduled task for the enrollment.(Which is obvious but… you need to make sure it was successful)

From there, the device would reach out to r.manage.microsoft.com to fetch the Intune policies and install the required Intune Management Extension. So I ensured I exported the Azure Ad and the Intune Certificate and attached them to Fiddler.

After watching for a couple of minutes, I noticed it retries to fetch the “policies” every couple of minutes but somehow fails to complete them.

When looking at the response, it showed me the whole message… nothing special and no other errors.

So, I decided to open the SyncML tool to see if it could tell me something more. When I looked at the SyncML message, I noticed that the last one also contained the CSP to install the Intune Management Extension.

The IME doesn’t get installed, so I must be getting close. Unfortunately, the SyncML tool only captures max64k, so I ended up with an incomplete message…. That’s unfortunate…

After giving up hope on the Syncml tool, I decided to take a look at the scheduled tasks that were delivered to the device. Those tasks should trigger the OMADMCLIENT and the deviceenroller.exe to start the initial sync of the device.

When taking a closer look at those tasks, I noticed that it didn’t run successfully and ended up with the error 0xc00cee2b. That’s a weird one?

To be sure it was indeed that same error I downloaded the simpleprogramdebugger and made sure I executed the same command that was listed in the scheduled task.

After executing the command and starting the debugging, the output wasn’t funny. As shown below, the same error 0xc00cee2b but without any additional details I really was hoping for.

Of course, when executing the task manually, this error is also going to be mentioned in the device-management event log but not as an error but just some piece of information (weird…)

So I can cross off Fiddler, Simpleprogramdebugger, and the event log, I guess it’s time to do some WPR tracing. I made sure I got my mdm.wpr file with all the proper tracing providers in it and started the trace. After executing the task and waiting for the error, I exported the ETL file and opened it in the WPR Tool

As shown below, again, the same error is being mentioned, but this time, we have some more information. The WPR trace contained all the functions the OMADMCLIENT goes through when fetching the policies for our device. In this error, I noticed that it breaks on processing the sync body

We can be sure that something went wrong while processing the sync body, but now we need to find that. What should we do now, as we only have the error 0xc00cee2b? I guess the first thing you must do is make sure you know what to look for.

As shown above, that corresponds with the “illegal XML character” message. Read it out loud… Illegal XML character!!! So, the Sync Body contains something invalid, but how are we going to spot it?

3. Fiddler and the WBXML message

So I decided to reopen Fiddler and started looking at the webview output of that Syncbody/WBXML message

It could be pretty hard to find the invalid character in it right? So I just copy-pasted the whole content to Notepad and saved it as an XML, nothing special. When this message arrives on the device, the OMADMCLIENT would extract the Syncbody, so why should not do the same, extract it from Fiddler and try to parse it?

Todo so I downloaded the WBXML parser and just opened the saved Notepad file in it.

As shown above, it instantly showed me that the file contained an invalid character. Okay… that certainly sounds like the error we got.

When taking a closer look at the specific line (21899) and looking it up in the doc. It mentioned the “DefaultAssociationConfiguration”. And yeah… that one looks pretty scrambled to me

But looking back at that number…. Mmmm, could it be It was staring me in the eyes, and I just didn’t notice it? I opened my WPR trace again and this time I took a closer look at the 4^th Field

As shown above, it mentions 21093… that’s indeed close to the 21899 I got from my own notepad. When comparing the stuff in the notepad file and the fiddler trace, I noticed that I somehow it was missing the first few characters.

How the hell could I overlook that field 4!! Field 4 mentions the invalid character!!

I guess I must be blind again…. lesson learned, that’s for sure!

4. The Simple paint flow

When looking at all of the above steps, it could be a bit too much to read, so I put in a simple paint flow. As always, you can press on it to get the BMP version to take a closer look at it!

5. Getting back to the OP

I left my device hanging on the enrollment error and I contacted the OP again. I asked him if somehow the policy to define the Default Associations Configuration was configured

Within a couple of minutes, I got a reply: Yes…. But we haven’t changed anything in that policy for months? After proving that I believed all the errors were because of that policy, he removed the policy assignment.

I trashed the autopilot settings in the Autopilot settings registry as shown below and retried the enrollment! So in this example, I just opened the AutopilotSettings Registry and started looking at the devicepreperation and devicesetup category. If one of them shows you an error/failed status, you need to trash the whole key and you could retry the enrollment

Within a minute or 2, it passed the “preparing your device for mobile management” and started installing the IME, Office, and all the other apps!

I asked the OP, to check the existing devices that were experiencing the sync issue. Take a wild guess what the outcome was! Those devices started syncing again and all new enrollments were successful!!

Conclusion:

I just can’t say it enough, knowing how stuff works and how to troubleshoot that same stuff will make you save the day in the future!