Hi kamal380​. An device has no way of knowing whether it is registered or not until it queries the Autopilot service and if it's not properly registered, the Autopilot service will simply tell it this. This will result in an event in the DeviceManagement-Enterprise-Diagnostic-Provider event log stating that the device is not Autopilot registered. This is truly the only local artifact of a device not being properly Autopilot registered and thus, there's nothing local to check or find on a device that is not properly registered with the Autopilot service.

Autopilot profile not downloading can be caused by multiple things though including not having proper connectivity to the Autopilot service which will also result in an event in the same event log stating this.

Beyond that, most troubleshooting will have to be on the service side for devices that do or cannot start the Autopilot provisioning process.

A lot more info on Autopilot troubleshooting is at Windows Autopilot troubleshooting FAQ | Microsoft Learn.

Thanks for your participation in today's AMA! The panelists covered this topic around 9:45 of the session. 

Thank you

Self-deploying mode (SDM) requires that the device is 1) Autopilot-registered and 2) an AP profile configuring SDM is targeted to the device (or a device group that the device is a member of). 

If those two prerequisites are correct, then you can check if the device pulled down the AP profile (after you've connected the device to ethernet and booted it to the first page in OOBE) by checking if you see a PolicyJsonCache registry value under the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache"; the value should be a JSON blob with your tenant's domain name in it.  If the value is not present with your domain in it, then that means the profile failed to be downloaded for some reason.  Some possible reasons:  1) You assigned the profile to the wrong device/group.  2) You already went through SDM on the device and need to press the Unblock button for it on the Autopilot Devices blade on the Intune portal (same blade where you registered devices into Autopilot).  (Some manufacturers are allowlisted to bypass this unblock for their devices, and so you don't have to press Unblock for their devices in between SDM or pre-provisioning device deployments.)

Hope this helps.

Thanks for your question! The panelists covered this topic around 6:17.

I saw that this was discussed when watching the recording (it was midnight my time when it was run).

In terms of applications that run only during Autopilot that has typically been the Autopilot Branding application Michael Niehaus publishes - which is somewhat a first run application for device/user customisation (e.g. HKCU settings). 

In terms of applications that run in Pre-Provisioning only, I've developed two applications (PowerShell scripts configured to run as applications) that install Windows Update and Driver Updates (minus firmware & network drivers) on devices. As these updates can take a long time to run if the OEM image is a few months or more old (we have customers who've had new devices sitting in a box for > 12 months), I don't want them running when a user is sitting in front of the device waiting. Hence the idea of running in Pre-Provisioning only. If those apps aren't installed because a device didn't use Pre-Provisioning, it's not a big deal. But there was certainly benefits for us to be able to run these if we did Pre-Provisioning.

Hope this makes sense.

You can directly install the Company Portal from the Microsoft directly suing the Microsoft Store app type in Intune. Is there a specific reason you can't use this?

Thanks for your feedback and question! The panelists covered this topic at 51:36 and encouraged you to go to aka.ms/CloudNativeEndpoints for more information. 

Agree! With the ui not showing the friendly name of the application currently installing knowing what App 1 of 10 is is useful to the user and IT for debug. The logs are disjointed and list guids instead of friendly names. Having a single all in one log like smstslog would be more useful for debug. We need control and reliability during deployment, having something that deploys the same each time is useful in this respect.

Most (if not all) TPM attestation issues are outside of our control as they are specific to the TPM hardware and/or the certificates that the TPM vendor issued to the TPM. Please continue working with support to help identify the source of the issue so that we can work with the various OEMs and TPM vendors.