Let’s assume that you are registering a new VM, or some existing device that you want to use for validating Windows Autopilot.  (New devices should be registered by the OEM, distributor, or reseller that you buy the device from – more on that later.)  In that scenario, you need to start off with the hardware hash and serial number of the device.  There are various ways to gather that, but assuming if it’s never been enrolled in Intune or ConfigMgr, then the simplest way is to run a PowerShell script to gather the needed.  Once you have that info, gathered into a CSV file, you can import that into Windows Autopilot via Intune or Microsoft Store for Business (although I strongly recommend using Intune).  That process for doing all of this is described in the Windows Autopilot documentation. 

But we want to focus on what happens during the back-end process, e.g. when Intune attempts to add the device to the Windows Autopilot deployment service.  There are a variety of checks performed, and if anything improper is found, an error is returned back to Intune and reported to the administrator.  Possible errors include:

A few quick notes on these items:

• Errors 806 and 810 should be the most common errors seen.
• You can cause more errors if you do things via both Intune and the Microsoft Store for Business.  Resist the urge.
• Pay close attention to the differences between error 806 (the device is already in your tenant) and error 810 (the device is already in a different tenant).
• Hardware hashes do change each time they are generated, as they contain date/timestamps, OS version info, and other info that can change.  That’s OK, as the matching algorithm will take that into account.  Only major changes to the hardware (e.g. a new motherboard) would cause an existing device to be detected as something new.
• If you try to delete a device and see timeouts or long delays, open a support case via the Intune Help and Support node.
• If you add or remove a Windows Autopilot device via Intune and you don’t see the device in the list, you can initiate a “Sync” from the Windows Autopilot devices node.  (Intune automatically syncs every 12 hours.)

Assuming the device was registered successfully, there are a couple of things that happen:

• The device is added to the Windows Autopilot deployment service.
• An Azure AD device object is created for the device, named using the serial number of the device.  If by chance there was an existing object for the device in Azure AD, that existing device will be used.  Either way, the device object will be “stamped” to indicate that it is associated with the Windows Autopilot device.

Here’s an example of a device that I just registered:

You can see the serial number (004524654257), manufacturer, and model on the first row, and you can see the name of the associated Azure AD device (named with the serial number) toward the bottom right).  If you click the Associated Azure AD device link (blue text), you can see the actual Azure AD device object:

As you can see, this Azure AD device object is disabled, indicating that the device has not yet joined.  But there are some more details that are useful to see that aren’t shown in the device management portal.  To see all of those, we need to use Graph Explorer to see the details.  Here are the results from this query:

https://graph.microsoft.com/v1.0/devices?$filter=displayName eq ‘004524654257’

So you can see the display name is currently the serial number of the device.  But there is also one other important value: the physicalIds value contains a [ZTDID] value that marks this device as a Windows Autopilot device – that same ID exists in the Windows Autopilot deployment service.  (Remember where else this value was used?  See this blog for more details on how to use this value in dynamic queries.  While you’re there, make sure you read about assigning profiles to the devices.)

Let’s dig in a little more:

• If you assign a Windows Autopilot user-driven Azure AD Join profile to this device and then deploy it, the existing Azure AD object will be enabled and an Intune device object will be created.
• If you assign a Windows Autopilot user-driven Hybrid Azure AD Join profile to this device and then deploy it, the existing Azure AD object will be enabled and an Intune device object will be created.  Later, after the device is joined to Active Directory, a second object will be synced from AD into Azure AD for the device.  If you are using Windows Autopilot white glove, the device is initially joined to Azure AD, and then later in the process removed from Azure AD and joined to Active Directory.
• If you assign a Windows Autopilot self-deploying profile to this device and then deploy it, the existing Azure AD object will be enabled and an Intune device object will be created.

Remember the state of these Azure AD device objects when they are initially created?  They are disabled.  Let’s say you’re a “clean freak” and you remove these Azure AD device objects.  What will happen?  It depends on the scenario:

• With Windows Autopilot user-driven deployments without using white glove, a new Azure AD device will be created, but it won’t be tagged with the ZTDID.
• With Windows Autopilot self-deploying mode deployments, they will fail because an associate Azure AD device cannot be found.  (This is a security mechanism to make sure that no “imposter” devices try to join Azure AD with no credentials.)  The failure will indicate a ZTDID mismatch.
• With Windows Autopilot white glove deployments, they will fail because an associated Azure AD device cannot be found.  (Behind the scenes, white glove deployments use the same self-deploying mode process, so they enforce the same security mechanisms.)

So, please don’t remove the Azure AD device object for a registered Windows Autopilot device.  You’ll regret it later.

Also, note that you will typically end up with two device objects in Azure AD for Hybrid Azure AD Join devices (one created when you register the device with Windows Autopilot, another synced from AD to Azure AD via AADConnect).  This is presently unavoidable (don’t delete either).  We are looking at ways to simplify this in the future.