Windows Autopilot

What happens when you register a device with Windows Autopilot?

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:$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.

Categories: Windows Autopilot

16 replies »

  1. Hey Michael, first off appreciate you taking the time to share your knowledge of Autopilot across multiple platforms (blogs, Twitter, Reddit, etc.).

    In your last paragraph you use the word “typically” and right now we are a Hybrid Azure AD shop and see Autopilot devices with only one AAD object for Hybrid Azure AD joined. What is happening on the backend to cause this? Is there a way/reason to create the Azure AD/MDM object as we look to move to AAD joined?


    • (Somehow my last reply vanished, let me try again.) I didn’t discuss some of the possible complications, so the “typically” was just to note that it doesn’t always happen this way. Here’s the most common scenario where it doesn’t: You have an existing AD-joined device that isn’t registered with Autopilot. The device is synced via AADConnect into AAD and shows up as a “Hybrid Azure AD Joined” device. And you then register the device with Autopilot. That will cause the existing “Hybrid Azure AD Joined” device to be stamped with the ZTDID.


  2. Hey Michael nice one very informative…. Also any update on this ” error code 80070774″ Autopilot Hybrid Domain join failure….


  3. Great writeup, Michael! And … so true, i regret too!

    One of our AzureAD device objects is missing ztdid in the physicalIds attribute as you point out above.
    Without the ztdid information in the device object the ztdid claim cannot be added when an access token is created on OpenId connect authentication.
    But we badly need this claim in our backend application to identify the device where the request came from.
    For this reason i‘d like to go the fix-it way and add the ztdid (which i still have from the autopilot registration) to the physicalIds attribute using graph api.
    Could this work? i‘d suspect at least some permissions issue


  4. Hmmm, it,s the way i work.
    Once the import job is done, i use the state deviceRegistrationId sub-attribute to search for the yet disabled AzureAD devices object.
    I use something like$filter=physicalIds/any(c:c eq [ZTDID]:deviceRegistrationId)
    to query the device object


  5. Is there a way to upload the new hardware ID if the motherboard has to get replaced in a device without deleting it from Azure AD, Deleting the old HWID, Upload New HWID? When its deleted from Azure AD it removed all the programs, etc. Do you know if its possible to upload the new hwid if a device has to get its motherboard replaced?


    • You can upload a new hardware hash after the motherboard has been replaced. It will create new Autopilot and AAD device objects which can be placed in the same groups as the old device. Those new objects will only be used if the device is reset or reimaged.


  6. When I try to upload the new hardware hash after the motherboard replacement it fails with error 806 because it says the id already exists. I assume its seeing that service tag already in there, but I cant delete it without first deleting from Azure AD.


  7. Hey Michael, great description you provide here.
    We’re trying to test a registration of a surface laptop 2. Unfortunately we always end up with the error “ZtdDeviceNotFound”. Do you have a bit more explanation on what this means? I guess our test Device is a demo Device which was provided by Microsoft, can this be the reason why it fails? With the Hardware-Hash everything worked fine.


    • Solved it already. Our Device was already produced in 2017 and is too old for the Serial process. Note: in the device serial you can identify the manufacturing date. We had xxxxxxx742xx as serial which means it was produced in week 42 in 2017. But the manufacturing date must be greater than 804 to make it work.


      • Right. When you register a device (through Partner Center) without the full hardware hash, we have to look up the hardware hash; we only have data for devices manufactured after a certain point in time. (We typically suggest January 2018, although some OEM info is available before that.) If you try to register a device that isn’t in our “big database” of device info, it will fail with that ZtdDeviceNotFound error.