I have already written a blog post about this topic here. But it was dedicated more to the technical side of troubleshooting Autopilot errors during the enrollment. Now I want to give you some ideas and an insight on how I troubleshoot Autopilot errors.
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.
First, if you have a new device, make sure it is registered to your tenant. Maybe you have your vendor doing this for you, but it is also possible to do it manually with a script from Michael Niehaus. If the device is not new, ensure that old records are deleted. (also if using Windows Deployment Services (WDS), don't join the device before starting with Autopilot)
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.
When you use White Glove to pre-provision, also assign a user to the device. (this is also under device enrollment). I noticed that when I was setting it up without a user, the device was not working properly.
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.
Please refer to the troubleshooting part, if you still have problems.
When you are going for Azure AD joined and still experiencing issues, you will have to analyze logs with MDMDiagnosticsTool.exe or Get-Autopilotdiagnostics.
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!