Introduction
My client's request was for me to create an Intune Autopilot build. Although the client did already provision and manage devices using MECM and a task sequence - their goal was to move away from this and in fact any on premise Active Directory dependencies. Thus my task was to:
1) Configure Autopilot policies in Intune to install the required Apps and enable Hello for Business.
2) Configure the build with an Azure Active Directory only joined device rather than a hybrid Azure/On premise Active Directory joined device.
3) Use the Enrolment Status Page so that users could only access the OS after a selection of minimal applications had been installed.
3) Validate the above on a Hyper-V virtual machine.
And I did create the required configuration policies and I did import the VM's hardware hash into Intune. When building a VM machine from a Windows 10 21h2 ISO file, and after entering my account credentials in the AutoPilot sign in window, it wasn't long before the ESP page appeared. It would then stick on the Device Preparation Stage for sixty minutes (the configured ESP time out setting) before crashing with an 0x800705b4 error.
.jpg)
The Fix
An internet Google search pointed to various possibilities. One of them suggested my VM needed 4 GB RAM and 4 Virtual CPUs configured on the VM. My VM's configuration had 8 GB ram and it did have 4 Virtual CPUs - so this tip didn't address my issue.
I did deselect the Enable Dynamic Memory option but the error still appeared.
The breakthrough came while reading this ESP troubleshooting article:
https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-enrollment/understand-troubleshoot-esp
Under the section titled The Device subkey the illustration showed the Sidecar key under HKLM\software\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\PolicyProviders\
When I pressed Shift and Fn and F10 to bring up the command prompt on my VM, at the error message, and when I ran regedit I could see that I did not have the SideCar key. The SideCar provider is another name for the Intune Management Extension provider, which is required to install win32 applications. I did have the ConfigMgr key and then the penny dropped. This Intune implementation was in in co-management mode with MECM and a previous pilot had been testing Autopilot with on premise Active Directory Join enabled setup. A policy under Devices\Windows\Windows enrollment\\Co-management settings was in conflict with our Autopilot requirements. Thus the Intune Management Extension provider was not getting installed - but this was required since this was an Azure Only Autopilot deployment.
When I applied the following options in the co-management settings policy - the Autopilot ESP page was able to progress to the next stage and the provisioning was a success.
The Override co-management policy and use intune for all workloads option was set to Yes. The Automatically install Configuration Manager agent option was set to No. I also renamed the policy to Turn Off Co Mgmt, as can be seen.
I hope you enjoyed reading this article and I hope it helped you with your ESP issue.
