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:

Error Description Notes 801 InvalidZtdRequestBody. The request was malformed or it didn’t include a tenantId. You should never see this. If it happens, it’s probably indicative of a problem with the services. 802 InvalidZtdHardwareHash. The hardware hash provided is invalid. The hardware hash should be exactly 4,096 characters (4K) long. Make sure you use the value exactly as returned by the PowerShell script. 803 MissingZtdSerialNumberAndProductKey. The serial number and Windows Product ID values were null or invalid. You should never see this from Intune or Microsoft Store for Business, because you must use the hardware hash to register the device. (You should still specify the serial number so that you can easily find the device.) 806 ZtdDeviceAlreadyAssigned. The device is already registered to the specified tenant. This one is your fault: Don’t try to register the same device twice, it will fail. 807 ZtdDeviceIsNotRegistered. The device being deleted or configured does not exist in the service. This would typically only happen if Intune and the Windows Autopilot deployment service are out of sync (e.g. you removed a device from Microsoft Store for Business, and then tried to remove it via Intune before Intune had noticed it disappeared). 808 ZtdDeviceAssignedToOtherTenant. The device is already registered to a different tenant. Uh oh. We won’t tell you which tenant the device is registered to – hopefully you can figure it out yourself. If not, open a support case via the Intune Help and Support node. 809 ZtdProfileIsNotRegistered. The profile being assigned to the device does not exist. This is another “out of sync” issue (e.g. a Windows Autopilot profile was deleted via Microsoft Store for Business, but then Intune attempted to apply it to a device before it noticed that it had disappeared). 810 ZtdProfileAssignedToOtherTenant. The profile being assigned belongs to a different tenant. You should never see this – there’s no way to get Intune or Microsoft Store for Business to assign a Windows Autopilot profile from one tenant to a device in another tenant. 811 ZtdDeviceRegisteredByOtherTenant. The device being deleted exists in a different tenant. Another one you should never see – it would only happen if you are trying to delete a device that doesn’t exist in this tenant but does in a different one. (A device is assigned a unique ID when registered, so you’d need that unique ID to even try to do this.) 812 ZtdDeviceNotFound. The device being registered could not be found. This can’t happen via Intune or Microsoft Store for Business. It can only happen when registering a device using the Windows Product ID, the manufacturer, or the model. (More on this later.) 813 ZtdDeviceIsNotUnique. The MSA service could not uniquely identify the device given the hardware hash. This is highly unlikely – if you do see this, open a support case via the Intune Help and Support node. 640 StorageError. An error occurred while adding the device to the service or to Azure AD. This is generally a temporary error – try to import the device again to see if it happens again. (You might see an error 806 if the device was actually added. That’s OK.) If you see this with any sort of frequency, open a support case via the Intune Help and Support node.

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.