Ultimate guide to define device names in Windows Autopilot Hybrid Join Scenario

When working with Windows Autopilot and implementing Hybrid join you will face different issues. One common challenge is to implement a naming convention for your devices, because Autopilot only allows to change the name based on:

• Azure AD Join:
  • Fixed string
  • Serial Number
  • Random Number
• Azure AD Hybrid Join
  • Prefix (Fixed String)

This is in most of the companies an issue because other systems have used specific naming conventions on the devices to group them based on locations or device type like Desktop or Notebook.

With the modern enrollment scenarios this is no longer that easily possible. Especially in a Hybrid Join scenario, where the device gets a new name on each enrollment this leads to a lot of unused old computer objects in your Active Directory.
We always try to move customers to just leverage the built-in solutions, but at some point, you would like to have at minimum on each enrollment the same device name for a device, which is not possible with Azure AD Hybrid Join at the moment. Therefore, I created a solution to have much more flexibility in a Hybrid Join Environment.

Azure AD Hybrid Join really required?

First, you should ask the question if you really require an Azure AD Hybrid Join or if an Azure AD Join is not enough in your environment. The biggest drawback is that with an Azure AD Join you cannot use old but good working GPO’s. Intune is working on the replacement, but the troubleshooting is much more complex, not all settings are available and the management of them is not that simple like with the on-premise GPO editor. So, this can be a good point to stay on Azure AD Hybrid Joined devices, but the Authentication to on-premise resources, which is most often referred to is not a valid point. Also, with Azure AD Joined device and no trust to the on-premise Active Directory your users can still authenticate to fileservers and print servers (Kerberos/NTLM) without entering the password. More details in the following blog.

Renaming devices in Azure AD Join scenario

There are lot of good blogs which are highlighting the steps to rename a device with a PowerShell Script on the devices. Therefore, I will not explain this process in detail, but you will find them for example on the following pages:

• PowerShell:
  • https://secureinfra.blog/2018/12/06/intune-device-management-renaming-windows-10-devices/
• MDM OMA-URI (Account CSP):
  • https://www.petervanderwoude.nl/post/rename-a-device-via-windows-10-mdm/
  • https://triplesixseven.com/renaming-windows-devices-in-intune/

Renaming devices in an Azure AD Hybrid Joined scenario

If you try the MDM OMA-URI version from above, it will end in a device which lost the trust to the domain and therefore the users are no longer able to sign-in again. So, this functionality should not be used at all. I started trying out, if it works when we rename the device manually on the device in a ConfigMgr Co-Managed environment and it worked like a charm and updated the name in all systems (AD, Azure AD, Intune and also ConfigMgr). Now how can we invoke this remotely on all machines in a reliable way. The renaming can only be successful when a device is connected to the company network. Because PowerShell Scripts in Intune are only executed once and in case of an error only retried a few times, I only saw two possible options to build a reliable solution:

• ConfigMgr Configuration Item
• Intune PowerShell Script Extended by Scheduled Task to retry renaming infinite times.

Because I have a co-managed environment, I decided to use a Configuration Item. The renaming will happen in the local system context; therefore, we have to set the permissions in Active Directory accordingly. You have to provide write permissions on Computer Objects to the “_Self” principal where the Objects resides. In my environment I granted “Write all properties” to all “descendent computer objects”:

Next you have to create the Configuration item. For your convenience you can just download it from my GitHub repository and Import it:

After importing it, you should configure your target computer name. At the moment it’s using “KUR-” as a prefix and attaches the serial number of the device.

#Target Computername
$Serial = Get-WmiObject Win32_bios | Select-Object -ExpandProperty SerialNumber
$TargetComputername = "KUR-$Serial"

Here you have all the possibilities, just think about requesting a predefined name from a webservice. For example, you could provide the device name as Order ID in Windows Autopilot. Therefore, the vendor can use the value to print it on a sticker and you can retrieve it easily from Windows Autopilot and set it here. Or detect if it’s a notebook or a desktop and include an abbreviation of it in the name. If you created a cool solution, please share it.

My solution checks also for the maximum NetBIOS hostname length (15) and shortens it if required. The actual renaming happens later in the script:

$ComputerName = $env:COMPUTERNAME
Write-Log "Current ComputerName '$env:COMPUTERNAME'"
Write-Log "Target ComputerName: '$TargetComputername'"
 
if ($TargetComputername.Length -ge 15) {
   Write-Log "Target ComputerName is longer ($($TargetComputername.Length)) than the allowed length of 15. It will be shorted."
   $TargetComputername = $TargetComputername.substring(0, 15)
   Write-Log "New Target ComputerName: '$TargetComputername' "
}
 
if ($ComputerName -eq $TargetComputername) {
   Write-Log "Computer Name matched! Compliant."
   return "Compliant"
} else {
   Write-Log "Computer Name doesn't match! Non Compliant"
   Rename-Computer $TargetComputername
   Write-Log "Change Computer Name from $($env:COMPUTERNAME) to $TargetComputername"
   Write-Log "Reboot required."
   return "NonCompliant"
}

Then you can assign the Configuration Item to a Baseline and deploy it to your devices, and they start renaming according to your defined names. Important, the actual renaming happens after the device reboots.

But keep in mind you need to have a cleanup job, because if the computer object already exists with a specific name, then the rename process will fail. Read more about this issue and how to solve it in my blog about the Intune Connector for Active Directory Extender.

What’s next

Now, what can we need more in an Azure AD Hybrid joined environment?

• Move the computer to a specific OU, based on things like hardware type or based on user’s location.
• Add computer accounts to a specific active directory group to assign share permissions or grant auto enrollment on specific certificate template.
• Cleanup old computer objects. With every join a new computer object is created and also Intune keeps records of the old device.

Read more about how to solve these challenges in my blog about the Intune Connector for Active Directory Extender.

• About
• Latest Posts

Follow me

Thomas Kurth

Principal Security Consultant | MVP at baseVISION AG

I’m a consultant, trainer and architect for modern workplace and enterprise mobility projects with Microsoft Technologies in the past ten years. I love to push and design the modern workplace based on Microsoft 365 for my customers which is the only answer for the current security threats, agile world and the fast-changing business requirements of my customers. Important for me is to simplify and automate the operational processes, because there are the highest costs.

Follow me

Latest posts by Thomas Kurth (see all)

• Microsoft Sentinel ASIM Parser demystified - March 31, 2024
• Enhancing Network Security Insights with IDS/IPS of Ubiquiti Dream Machine Pro and Microsoft Sentinel - March 10, 2024
• Ubiquiti Dream Machine Pro Logs to Microsoft Sentinel - February 6, 2024