This blog will be about an old Autopilot feature called “Convert All targeted devices to Autopilot”. I dedicated a small blog to this wonderful feature to explain how existing devices are automatically registered for Autopilot.
1. Introduction
In one of my other blogs, I already mentioned some stuff about this wonderful feature to convert existing devices to Autopilot devices, but I decided to remove that part and dedicate a unique blog to it. Let’s proceed, shall we?
There are some precious moments in life when it could be hard to fetch the Autopilot 4k Hash yourself from the device. Luckily, Microsoft has got us covered! About four years ago, Microsoft introduced the feature to automatically “convert all targeted devices to Autopilot”
With this wonderful feature, you can ensure that your already Enrolled Entra ID Joined and Intune enrolled devices are automatically “converted” to Autopilot devices. This feature saves you some trouble fetching the 4k Hardware Hash yourself. Isn’t that nice?
The name “converted” may be the wrong choice, as people might think that the “old” device was removed after it was converted, but of course, that’s not the case!
As mentioned earlier, it works with existing Azure Ad Joined devices, but it’s good to know that it also works with existing Entra ID Registered devices enrolled in Intune. Let’s go forth and check out how it works with AADR devices
2. The Flow
Let’s start with the flow to make things a bit more clear, so please take a look at it before reading further!
As shown above, we have three major requirements! Let’s start with the first one: The device needs to be enrolled in Intune. If you have ensured your AADR is enrolled with Intune/MDM, Intune could fetch the 4k Hardware Hash by levering the ./devdetail/ext/devicehardwaredata CSP.
The second requirement that I am showing is that the device needs to be marked as corporate. As shown below, if the device ownership is configured as “Personal,” the “conversion” isn’t going to work! Personal devices and Autopilot are like #Intunebeer and Google Workspace. They don’t go well together!
Please change the Entra Registered device ownership to “Corporate” so that the Autopilot Deployment Service will accept it.
If (device.ownership -eq “Corporate”){
Write-host “It’s all fine!!!!, lets enroll that device into the Autopilot service”
}Else{
Write-host “You shall not pass!!! I am not accepting your personal PIEEEP”}
I guess it’s pretty obvious that you need to make sure that the Autopilot Profile with the “Convert All targeted devices to Autopilot” setting in it is assigned to the group the AADR device is a member of.
3. ./devdetail/ext/devicehardwaredata
In this part, I am going to tell you some additional funny details about the ./devdetail/ext/devicehardwaredata CSP. This CSP is responsible for fetching the Raw Blob 4k Hardware Hash from your wonderful Intune enrolled device.
I guess we all remember this one, right? As shown below, when fetching the 4k Hardware Hash ourselves we could also use PowerShell and call up on the same ID
(Get-CimInstance -CimSession (New-CimSession) -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter “InstanceID=’Ext’ AND ParentID=’./DevDetail'”).DeviceHardwareData
Another possibility to get some details about this 4k Hardware Hash on your Azure Ad Registered device is by opening the registry:
Software\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\node\ key and search for DeviceHardwareData
As shown above and below, by its looks, this registry key contains the Hardware Hash. When reassembling this value, we will end up with the reconstructed hardware Hash.
Besides looking at the registry, you could also look at what is going on with the use of the SyncML tool, you will notice that even when the device isn’t a Converted Autopilot device, Intune is asking the device to find and fetch the 4k Hardware Hash.
I was expecting to notice this CSP only when the device was being enrolled into the Autopilot Deployment Service, but I guess that’s not the case.
4. Takes Long
I guess, as we say in Dutch, it is Duurt lang!!. Sometimes, it really takes a long time before the existing Azure Ad Registered Corporate marked device has been enrolled into the Autopilot Deployment Service and has been assigned the proper Autopilot profile.
Microsoft tells us to “Allow 48 hours for the registration to be processed.” But most of the time, it will be processed within a couple of hours. Some time ago, I had one device that just refused to convert to an Autopilot device even when it was marked as a corporate device.
Of course, I could upload that hash myself, but that wouldn’t be fun, right?
So I decided to see if I could speed it up a bit. Before proceeding, I ensured the device was in the group targeted by the Autopilot profile.
I opened a nice cmd and put it in the Dsregcmd /leave command (or click on disconnect in the Access Work or School settings). After waiting a couple of minutes, I clicked on the connect button again
This time, it took about an hour before the device was converted to an Autopilot device. Of course, this isn’t the best practice, but I was curious if there was anyhow another option instead of waiting to “convert” the existing device to an Autopilot device.
5. What have we learned?
Looking back at the flow, let me explain a bit more about what I was trying to convey.
When enrolling a new device into the Autopilot Deployment Service, you will probably use the get-windows autopilot info PowerShell Module to upload the required hardware hash. By doing so you will be prompted to enter your Microsoft 365 account that is allowed to perform this action.
We don’t need to perform additional authentication to convert all targeted devices to Autopilot. Is that weird? No, of course not!
If you have read my previous blogs mentioning the Intune MDM device cert, you would probably know why, but then again, let me explain it again a bit more.
When your device is enrolled into MDM/Intune, trust is born between the device and Intune by using a nice certificate. With this trust relationship, the Intune service has direct access to the device to fetch the Hardware Hash by using the CSP (/devdetail/ext/devicehardwaredata) I mentioned earlier.
The wonderful Intune service also has direct access to the back end of the Autopilot Deployment service to create the “virtual Autopilot Device” with the DeviceHardwareData it fetched from the device. How else should it be possible for us to upload a CSV to create the Autopilot devices?
The last step will only be performed if your device is marked as corporate in Intune. Otherwise, you could wait until the end of day to have your AADR device converted to an Autopilot Device
Conclusion:
This “convert” option isn’t new, but looking at it and its flow was still fun. I guess I was a bit busy with my day-to-day job, so I didn’t have the time to perform a deep dive this week. Hopefully, you enjoyed it!
Hi,
Thanks for this article! I wonder if this works well for the hybrid-Azure AD join devices as well. All of our devices are Hybrid-Azure AD joined and co-managed. I tried assigning a HybridAzureAD join profile 5 days back and still the device is not reflecting under Assigned Devices. tried the AAD profile as well today morning with no luck. Really appreciate your response on this.
For us, working in a hybrid environment, once the Deployment Profile with convert is assigned to the sec group, the client is indeed added (in a matter of hours) to Windows Autopilot Devices. However, in nearly all cases no deployment profile is shown as assigned (even after weeks). This is very strange, as looking at the list SOME do get profiles assigned, but not many (8 out of around 250)… All of them are targeted by the same Deployment Profile which is used to convert them. So you end up with a situation in which the client is converted by a Deployment Profile which it says is not assigned to it…
This means that before resetting any device, we need to go back to the list of devices, find the one we are looking for and add a Group Tag. Then the profile is assigned. It works, but it’s not what we had in mind ;).
Thanks for this article! We used this method to register our hybrid joined intune enrolled devices in Autopilot.
This works fine, all clients are now in autopilot.
In autopilot we assigned a group tag, the idea was to add clients in dynamic groups based on this group tag.
Unfortunatly this seems not working. By the autopilot registration a new Entra ID object is created with the serial number as name.
When we lookup this device in Autopilot in Graph we see the autopilot object is linked to this new Entra ID object and not the already existing hybrid joined object. Also the managedDeviceId is “: “00000000-0000-0000-0000-000000000000” and not the ID of the actual intune device.
As this link is broken, the device is not part of any dynamic group based on the autopilot group tag.
Is there a method to re-link these objects?
I must admit the Autoconvert is good – also recently found the Ctrl-Shift-D allows you to export logs to a zip file which also contains the hardware hash – (who’d have known it) so rather than running the script etc you can get the hash without the machine going online was faster but the Autoconvert great for all the machines I got out there that already on in AAD.