Autopilot - Device deadlock between two tenants

After wiping a Windows10 Autopilot device from Microsoft Endpoint Manager, we got welcomed to the correct tenant by name and logo. When signing in with a current licensed user, we got the message saying "That username looks like it belongs to another organization. try signing in again or start over with a different account". Time to troubleshoot!

The background for the wipe was to repurpose the device for a new user. 

Windows Autopilot is managed and maintained by Microsoft in a backend database that associates hashes with customer tenants. This time I got a schizophrenic device dealing with two tenants.

The problem

The error message looked like this on Windows 10 and Windows 11 after trying to upgrade.

In order to search the problem I hit <shift>+<F10> to open CMD. By running the hostname command, I noticed the assigned computer name from Autopilot was wrong. The wmic bios get serialnumber command gave me the serial number to check in autopilot devices in MEM. A check told me that the device was present in the Tenant it was supposed to be. I did a check in regedit under the path HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot and found some foreign values pointing me in the direction of an old tenant which this user/device previously was a part of. The company was earlier on migrated completely to the new tenant as part of a larger merge of companies.

The old tenant was still present, but the serial number was not found in Autopilot devices on that tenant. The Autopilot device list was empty. A check of devices in Azure AD did however list the device as an autopilot device!

Device serial not found in Windows Autopilot devices on old tenant

Device serial not found in Windows MEM devices on old tenant

Device serial not found as Autopilot devices in Azure AD Devices on old tenant!

As a next thing to test, I deleted the serial number from Windows Autopilot devices on the new tenant where the device was expected to be. A new hardware hash was captured from the device and uploaded to the this new tenant. This gave the error code "808  –  ZtdDeviceAssignedToOtherTenant"!

The solution

On the old tenant I did log inn to Microsoft Store for Business, selected Manage and Devices. This showed three devices including the troublesome one - got you! Since this should be a desolated tenant, all these devices was selected and removed.

A new import of the CSV file containing the hardware hash was now successful, and the correct deployment profile got assigned

I did initiate a new factory reset from the CMD prompt on the device with the command systemreset --factoryreset. After the device was reset and rebooted, the Autopilot onboarding routine went as expected!

The device is finally onboarding with Autopilot

What if...

If the device record didn't exist in Microsoft Store for Business or Intune, the next step would have been to require assistance from Microsoft Support to remove the device record. In that case, I might have needed the device CSV file, proof of ownership (typically a bill of sale in its original format including the serial number with the company name appearing in the document) and a diagnostic log from the device collected with the command Mdmdiagnosticstool.exe -area Autopilot -cab c:\out.cab. The support should in case have been initiated as described in Get support in Microsoft Endpoint Manager admin center - Microsoft Intune found on Microsoft Docs.

Summarize the cause

After summing up the experience, the question left for me is how this could have happened?

• The device was actually listed as an autopilot device in the new tenant.
• The device did actually welcome me with the name and logos from the new tenant.

I guess the problem must originate from the time of migration from old to new tenant and the facts that 

• the new tenant do allow personally owned devices to be onboarded
• the deployment profile is assigned to a dynamic group collecting all Windows 10 devices
• the deployment profile has the check set for converting all targeted devices to Autopilot
• the user was administrator on the device in the old tenant

My theory is that the user managed to unregister the device from the old tenant since he was local admin. Further on the user managed to manually join the device to the new tenant since this tenant allowed personally owned devices to be onboarded. In the new tenant, the device got caught by the group containing all Windows 10 devices and was converted to an Autopilot device. This may have formed a breeding ground for the special situation leading to this Autopilot deadlock where the user was welcomed with the name and logo from the new tenant, while the device settings was received from the old tenant returning the "808  –  ZtdDeviceAssignedToOtherTenant" error message upon signing in.

Please leave a comment if you have similar experiences to draw on, or other conclusions to share.