I do a lot of testing for clients and prospects with Azure, Intune, and Autopilot. Although I do the vast majority of my testing using Hyper-V VMs (I made a post about this here for quickly provisioning machines – Use Hyper-V and PowerShell to quickly spin up Windows test machines – SMBtotheCloud), sometimes there is a need to test or troubleshoot pre-provisioning or self-deploying Autopilot profiles. For that, I have a few spare physical machines since VMs are not compatible with those Autopilot deployment methods. Since those machines don’t get used frequently, and sometimes I forget to remove them as Autopilot devices from the client tenant, I try to use them only to discover they’re already Autopilot registered to a tenant. Determining the tenant for an Autopilot device using a regular user-driven autopilot profile is simple and can be determined here – Find the Tenant Where a Device is Autopilot Registered – SMBtotheCloud.
This is a little different if a device is assigned a self-deploying Autopilot profile. For starters, you have no idea which tenant it’s registered to, to begin with, so the login screen won’t provide any clues (maybe if there is a device naming convention it will), and you can’t log in to get to the registry. This leaves us with a few options.
- You could factory reset the device, and then as soon as the ESP kicks in, you can do a shift+F10 to get to an admin command prompt, then access the registry and see which tenant it’s connected to. However, you’ll need to use the Windows Startup options to reset the device and then babysit the reset process so you don’t miss the opportunity to get to the command line before it completes autopilot and ends up at the Windows logon screen. One other option is to pull the ethernet during the reset so the device never pulls the autopilot configuration after it comes back up. Then you can plug the ethernet back in and reboot the device. Still, you’re waiting for a full factory reset – not the most efficient use of our time since you’ll probably need to reset it a second time after determining the tenant where it’s registered and releasing it.
- We can use a boot drive, such as Hirens Boot CD, to load a lightweight version of Windows, load the registry hive, and determine the tenant. If you have a boot drive handy, this is a good option.
- We can use the Windows recovery startup menu. This is the most efficient way that I’ll be covering.
To begin, hold shift and restart the device. This will bring up the startup menu:
Select Troubleshoot and then Advanced Options:
Choose Command Prompt:
You’ll notice that the command prompt is not using C: as the default prompt. It will be using X: which is the Windows recovery environment. It has a minimal version of Windows loaded as a RAM disk. We want to type regedit into the command prompt to access the registry.
You’ll notice that there isn’t much in the registry. That’s because it’s pointed to the hives for the recovery environment. So, we need to load the hive from our C: windows installation. Select HKEY_LOCAL_MACHINE:
Then click File > Load Hive:
Navigate to C:\Windows\System32\Config\Software (this is the hive for HKLM). By default, explorer will be in the X: drive. Make sure you navigate to C:
You’ll be prompted to provide a Key Name and click OK. This is the name that will be used to access HKLM hive, which gets nested under the top-level HLKM::
We can see it under HLKM now:
Navigate to Microsoft > Provisioning > Diagnostics > Autopilot
Here we can see the Tenant Domain and the TenantID. Now we can go back to that client or tenant and remove our device from Autopilot so it can be used for testing in other organizations.