Last Updated on March 17, 2023 by rudyooms
In this new blog, I will be talking about a big Autopilot misunderstanding. I will try to explain and convince you why blaming Autopilot is not always the right thing to do when your Autopilot enrollment is a complete disaster
After enjoying the Windows Autopilot – Ask Me Anything! – YouTube…some time ago, I decided to write a unique blog on this misunderstanding. I will divide this blog into multiple parts
- The Tree of
- Why it is bad to blame Autopilot
- Did I change your mind?
1. The Tree of
First off, I noticed that a lot of people are always blaming Autopilot when their Autopilot Enrollment fails. You could ask yourself, why do we blame Autopilot? In my opinion, it’s bad to always blame Autopilot.
I guess I owe you some explanation on why it’s bad to blame Autopilot (in my opinion) when you experience issues when enrolling your devices with Autopilot.
When looking at this picture… I guess it tells you all right? Autopilot is only the tree that sticks out of the ground but it relies on way more mechanisms and moving parts…. to work…… or make you cry a bit when it fails you
ESP = Enrollment Status Page
PBR = Push Button Reset
CDN = Content Delivery Network
DO = Delivery Optimization
2. Why it is bad to blame Autopilot
Now we have seen the wonderful Tree of Autopilot, are you still going to blame the Autopilot product itself when you are experiencing issues when you are enrolling devices with Autopilot? If so please keep reading as I will show some examples of why you need to blame some other products or yourself instead!
I guess I don’t need to explain the Enrollment Status Page and how it is being used by Autopilot but then again.
Now we have read that nice blog, let’s dive into some reasons why ESP could haunt you
- If you are enrolling a device with Autopilot and you decided to mix up Win32Apps and MSI apps, your autopilot enrollment could fail
- If you configured 50 apps to be required during Autopilot, your deployment could easily fail you
- If you target the wrong devices or use dynamic groups
2.2 Human Failure
Okay, okay it’s not a Microsoft Product but it is an important part of when your Autopilot enrollment ends up in a failure or a success. Let me show you some nice human mistakes that could break your Autopilot Enrollment
- If you deploy bad PowerShell scripts, your device setup could fail you at the identifying Apps Phase Autopilot Hangs | Stuck on Identifying Apps | ESP (call4cloud.nl)
- If you deploy bad-packaged Win32 Apps, your Autopilot enrollment could fail you
- If you decide to test Autopilot enrollments with only 1 VPU assigned to your VM, the enrollment will kick you in the ass
I guess I can go on and on but …. let’s move on shall we?
I guess if you know me, you know I did write a lot about TPM issues and Attestation Issues during Autopilot Pre-Previsioning that were caused by your TPM, not by Autopilot 🙂
- If your device doesn’t have a TPM 2.0 your pre-pro will fail
- If your device has a vulnerable TPM firmware your Pre-pro will fail
- If your device hasn’t an up to date firmware, your pre-pro could fail
- If your Windows is not up to date your Pre-Pro will fail because there are a lot of Windows Updates released that will fix your TPM issues!
2.4 Microsoft Store
- If you are requiring the Company Portal Online version (or other online apps) as a required app during Autopilot, please make sure that your device is compliant when it reaches the account ESP phase
- I am not sure if this is a Microsoft Store issue or a Human Failure or an ESP issue … but if you decided to add the Quick Assist as a required app during enrollment you could end up with the 0x81036502 error
- Another issue you could have noticed is the 0x80073cfb error when you are using the Offline version of the Company Portal
2.5 Azure Ad
Do you recognize the OOBEAADB10 Error? If there are issues with Azure Ad, your Autopilot enrollment will definitely fail!
Guess what happens when there are CDN issues and you are requiring the Office 365 Apps as a required app. Yes! Correctly a lot of problems
Push-Button Reset (PBR)… I have done my fair job on this topic.
If you reset the device, there was a time that Windows was missing a lot of frameworks. If it misses those frameworks, you are pretty much done
Luckily the Windows.Old issue can’t be blamed on Autopilot… but still I need to mention it!
Where to begin with this part? I guess it’s pretty obvious that when there are issues with Intune, your device will time out on the enrollment. The same error I was showing you in the Azure Ad Part is also responsible for Intune enrollment Failures during Autopilot
This error is not nice, that’s for sure but you will also get this error even when you are not enrolling your device into Autopilot… So blaming Autopilot is maybe not the right thing to do?
Even when it’s not really a part of Autopilot it could still give you some headaches! Let me show you why. When Windows 11 was first released some old Windows 10 issue was brought back to life.
If you assigned the WUfB update ring to devices instead of users, you could run into an unwanted reboot that would mess up your pre-provisioning
As mentioned earlier in the TPM section, a successful attestation relies on some specific Windows Updates! Without them, you are lost
More information will be told in the next part!
2.11 Delivery Optimization (DO)
Of course, configuring Delivery Optimization to make sure the device that is enrolling with Autopilot downloads the contents from peers instead of downloading it directly from the Internet sources. But please beware that configuring DO to mode 99 or 100 could give you issues.
In this blog below, I am explaining why Bypass (mode 100) could give you issues when deploying Microsoft Store Apps
2.12 Hardware Suppliers
If Intel or AMD decides to change some stuff it could give you issues when enrolling a device with Windows Autopilot for pre-provisioned deployments. For example, when the 11th Intel gen CPU was released there were a lot of attestation issues
Let’s not forget about AMD!
Microsoft needed to rewrite the code to fetch the proper certificate (walk the certificate chain) to get the right AIK attestation URL. Do we blame Autopilot for this issue? I don’t!
SideCar, AKA the EMS agent AKA Intune Management Extension. If you installed the July preview update, you would have a nice 0x800705b4 error.
So do we blame Autopilot even when it’s the Sidecar agent that couldn’t be installed?
With the “New” store option in Intune, we can deploy Store Apps to our devices with the use of Winget
But this “new” store option also has its policy that could break stuff
Guess what happens when you try to install apps and something is preventing it?
3. Did I change your mind?
After you have read all of those examples above, do you still blame Autopilot itself when your Autopilot enrollment fails???
Of course, the easiest thing to do is to blame Autopilot itself but almost every time it’s something else. I know there are moments in time in which Autopilot is the guilty one but sometimes it isn’t.
As mentioned before, there are a lot of moving parts that could possibly break when enrolling your device with Autopilot into Azure Ad and Intune. Some of those parts could break and sometimes it is just because you broke it yourself 🙂