I published a new script on the PowerShell Gallery called AutopilotDeviceSync.  This grabs a list of all your Windows Autopilot devices, Azure AD devices (including Hybrid Azure AD Join devices synced from your on-premises Active Directory), and Intune devices.  If you weren’t aware that every device existed in three or more places, let me explain that first.

As I had discussed in previous blogs, when you register a device with Windows Autopilot, a new Azure AD device object gets created at the same time, named using the serial number of the device.  There is no Intune device object yet, because the device hasn’t yet enrolled in Intune.  Autopilot/Intune tracks the relationship between the Autopilot device object and the related Azure AD and Intune device objects, so you end up with something like this:

The pink box (left) is the Autopilot device, the yellow box (right) is the Azure AD device object.  The arrow to nowhere points to the Intune device object, which doesn’t exist yet.  Let’s say you then do a user-driven Azure AD join deployment.  Now you’ll see the Intune object (green box, upper right) created:

Also notice that the Intune and Azure AD device objects are now renamed to reflect the current device name.  Pretty simple.

But if we do a user-driven Hybrid Azure AD Join, things get much more interesting.  The device starts off the same (no Intune device), but after it enrolls in Intune and joins Active Directory, you’ll see something like this:

(If you watch really closely, you might see the Intune device name start off as DESKTOP-blah, as the device initially joins with a Windows-generated name, before switching to the name in the ODJ blob.)  Still, that’s not too bad.  But within 30 minutes (with AAD Connect, faster with ADFS), you’ll see a change:

A second device object is created in Azure AD, representing the Active Directory device (labeled a “ServerAD” device, meaning Active Directory).  And when that shows up, Intune switches all of its targeting to that new device, but the Autopilot device is still linked to the Azure AD device (which you should never delete, as you can’t get it back without removing the device from Autopilot and re-importing it – we’ll block those deletes in the future).  Now, Intune is going to use the Hybrid Azure AD Join (“ServerAD”) device for all policy targeting, so now what is important is the group membership for that device.

So what happens if you re-deploy that same Hybrid Azure AD device?  You get a new name, a new object in Active Directory, and eventually a new object in Azure AD that represents that AD device (“ServerAD”):

Notice that the old Hybrid Azure AD device (which still exists in AD too) is pretty much orphaned and useless at that point.  And the names of the devices don’t necessarily match either, since the new AD device has a different name.

Alright, that’s the background – if you’ve done enough Hybrid Azure AD Join deployments, you’re probably already familiar with that.  If you’re not aware, well, consider yourself lucky, because it matters a lot for policy targeting – especially the “Domain Join” profile that tells Intune what domain that device should join.  (If you’ve ever heard me say “target your Domain Join profile to “All devices” that’s why: you can’t go wrong with that, there will always be a “Domain Join” profile available for Intune to use.)

So where does the script come in?  Remember what I said when I started:  The script will grab all the Autopilot, Azure AD, and Intune devices.  It will then check the links between all the objects, flagging issues such as:

• Orphaned Hybrid Azure AD Join devices in Azure AD that can be cleaned up from Active Directory.
• Device name mismatches, where the Azure AD device name doesn’t match the Intune device name.  (Intune picks up its device name from the device itself, so it naturally settles on the “right” name.)  Typically, this would be from the Hybrid Azure AD Join scenario.
• GroupTag (a.k.a. OrderID) and PurchaseOrderID values that aren’t in sync between the various Azure AD device objects.
• Azure AD device objects that have been improperly deleted (e.g. the Autopilot device points to an Azure AD device object that no longer exists.)

Here are the steps to use the script:

• Start PowerShell.  (Do this on a domain-joined server while logged in with an appropriate AD account that has rights to remove device and has the ActiveDirectory PowerShell module on it if you try out the “if you’re brave” items below).
• Make sure the following PowerShell modules are installed (one-time operation):
  • Install-Module AzureAD
  • Install-Module WindowsAutopilotIntune
• Install the script:
  • Install-Script AutopilotDeviceSync
• Then run the script:
  • AutopilotDeviceSync.ps1

If you are brave, you can add the “-FixNames” switch to get it to rename the AAD device objects to match the Intune devices.  And if you’re really brave, you could try the “-CleanDevices” switch to get rid of any duplicate AD devices (which should then replicate the deletions to AAD).  I don’t suggest doing that in production – I’ve tested it a few times in my lab environments to clean out orphaned AD devices and fix AAD device names, but that doesn’t constitute “full validation” – use at your own risk.

Also, because this script grabs a copy of every device in Autopilot, Azure AD and Intune, it may not like large tenants.  And it will generate a lot of console output, which you can catch in a transcript (without color) if you like.