When autopiloting a device and receiving errors it always behaves like a flowchart or multiple prerequisites that need to be checked. I have tried to get a visual overview, what to do in which situation:
As you see, depending on your scenario and environment, you could have different points to focus on. I also want to give some explanation to some processes.
One thing in advance; Autopilot Azure AD is the best and easiest scenario. But when making the transition to the cloud, for most companies it is best to go hybrid first. See the deployment profile:
Hybrid Autopilot White Glove Process
First lets discuss the whole flow and whats exactly happening.
- registration of hardware hash to the tenant
- White Glove process gets started - TPM attestation
- device requests deployment profile from the tenant (containing tenant information, scenario and other relevant details)
- Intune is looking for an assigned Domain Join Profile (device configuration profile) preparing the Hybrid scenario and requests an Offline Domain Join
- the installed Intune Connector (ODJ Connector) is polling Intune every 3 min
- Intune Connector creates a computer object in the Active Directory representing that computer
- Intune Connector uploads a Offline Domain Join blob to Intune
- device applies this Offline Domain Join blob, performs ping check to domain controller and reboots then (skip connectivity check is possible with Win10 2004 or 1903/1909 with December update)
At this point the device is Active Directory (on-prem) joined with all configured settings from deployment profile. (name prefix, specified OU and domain)
Troubleshooting on the device
First I would always try to understand the exact problem on the device. Often an error code will help you to continue. The two I encountered where 0x801C03F3 and 0x80070002. The first one was my fault. I accidentally deleted the computer object in AzureAD>devices. To resolve this it is the best to reregister the device hash to Intune services. For the second error check "Troubleshooting in configuration".
First, if you have a new device, make sure it is registered to your tenant. Visit my post: Upload hardware hash to Intune, made easy
So, if the device has problems with enrolling to Intune, definitely control the backend configuration in Intune. See my blog post on how to get your Tenant ready for Intune Autopilot enrollment. And check any restrictions you have may set in your Tenant. Personally I have never run into any problems with it, but you never know.
Something I also suggest is taking a look to your MDM authority. This is really important, you have to set Intune as MDM in Azure AD and need to have that specific user in the group assigned over there.
If you still have problems in that step, it may also leads you to some hardware issues, like TPM version or other things that prevent an enrollment.
If the error codes don't help you, there are still some options to get more information. For example Michael Niehaus Script Get-AutopilotDiagnostics.
Install the Powershell script for a visual overview and more log information for the whole Autopilot process.
Microsoft also provides a built-in solution for collecting logs. Executable with:
Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\temp\autopilot.cab. To do an analysis of the logs I can also recommend Michael Niehaus reference.
Troubleshooting in configuration (hybrid)
In the hybrid join scenario, there are more components that are non-cloud such as the Intune connector and the Azure AD connector. The Intune connector is responsible for doing the offline join most known as ODJ blob. This blob will be requested from the Intune cloud for a new device and generated through the Intune connector, uploaded back to the Intune cloud and the device will download the blob and (hopefully) apply it. To troubleshoot these events, consider a look to the event viewer and events, generated from the Intune connector.
One more part is the connectivity check, which basically tries to communicate with the domain controller. This is usually the last step before rebooting and finishing the process. But imagine beeing offsite and have no connectivity with a domain controller, what is happening then? -Since some time, you can skip this step in the enrollment profile, which is also what I would do. This connectivity check is only useful, to guarantee that a user can later log on, after the enrollment, because the credentials will be checked against the domain controller, that obviously requires connection to the corporate network.
For best practice target the deployment profile to "All Devices". This will help against endless waiting for the ODJ Blob and Intune Connector won't ever receive anything. You can check this with event viewer on the server, therefore navigate to "Applications and Services logs>ODJ Connector Service"
Now create a filter to exclude events 30121 and 30150. (on the left "Filter Current Log")
Now search for events 30130 and 30140 this two represent a successful ODJ request from Intune service.
One more thing to mention is that after the Azure AD join Intune will convert the device into a Hybrid Azure AD object. This means if you just target the deployment profile to a group where the device is currently member of (in AAD state), after successful enrollment of HAAD it will not know which profile to take for redeployments. The AAD computer object is not anymore in that specified group. Sounds hard to understand but keep in mind that assignment to "All Devices" is the best.
Connectivity to a domain controller
This refers to point 8. where the device will attempt to ping a domain controller after applying the ODJ blob. This was initially thought to prevent unsuccessful user login attempts in the Win10 lockscreen, because credentials are checked against on-prem domain controller. Now with Windows version 2004 or 1903/1909 with December updates you can skip this connectivity check in the deployment profile so the device will reboot immediately. To this point a complete over-the-internet enrollment would be possible. (later on VPN would also make it possible)
Domain Join issues
I was struggling with this for a while. We have following environment: Windows Deployment Server (WDS) with AD integration to enroll our devices with Win10 2004. Then let Autopilot take over with White Glove. The problem was that WDS already joined the computer to the Active Directory and Autopilot would always fail with error 0x80070002. So make sure to check if the device obscurely joined AD already. If yes its likely that this happened into the default computers OU. To prevent WDS from doing this, you should set up WDS as a standalone server not integrated to the domain. Do this in this step:
when the installation is finished, configure it:
and enable the checkbox to disable Active Directory Joins triggered by WDS
In the end...
So what if all what I have written down here doesn't resolve your problem? Well then you will have to search the internet for people from the folks, that had the same issues. Reddit is a platform that is predestined to ask other people regarding Autopilot errors. Michael Niehaus blog is also a place to find high-level architectural advice or information. Of course you can also contact me for any questions :)
Nevertheless don't give up troubleshooting, no matter how hard it seems to be!