Renaming Autopilot-deployed devices

Over three years ago (yikes), I did a blog post that talked about renaming Hybrid AADJ devices after they have been deployed via Windows Autopilot. As I was revisiting that for an upcoming presentation, it occurred to me that such a thing doesn’t need to apply only to Hybrid AADJ; it can also be useful for AAD-joined devices.

So what’s wrong with the existing Windows Autopilot computer naming capabilities? Well, first the naming mechanisms that are supported are super-simple:

• For AADJ, you can specify a naming template that includes static text, the computer serial number, or a random set of digits (you specify the length). For example, you could specify “PC-%SERIAL%” or “A-%RAND:10%”. This template is evaluated client-side, and the resulting name is truncated to 15 characters (maximum NetBIOS-style computer name). (See the Accounts CSP documentation for the “details.”)
• For Hybrid AADJ, you can specify a computer naming prefix as part of the Domain Join object that you define in Intune. The rest of the computer name is generated by appending more randomly-generated characters and numbers to the specified prefix, always resulting in a 15-character name. (This setup is particularly annoying because the Intune developers assumed that names were case-sensitive, so they generate both upper and lower case random letters as part of the name.) This name is generated in the Intune connector, not on the client, so it doesn’t support the same %SERIAL% or %RAND% macros. (What would happen if Intune generated the same name twice? Granted, that’s not terribly likely, but the probability isn’t zero. If it does happen, the ODJ blob generation will fail and the entire Autopilot HAADJ process will fail with it. Want to try it? Specify a long prefix so the random part is fairly short. You’ll see it happen soon enough.)

It would have been nice for both of these to be the same (Intune could certainly provide the serial number to the Intune Connector so that it could use that to generate the name), but there is one challenge with Active Directory-joined machines (HAADJ): Computer names must be unique; duplicates aren’t allowed. And the Intune Connector won’t allow you to replace an existing computer object as that’s a potential security issue (the new computer would take over the identity of the old computer, and could break that old computer — really bad if that old computer was a domain controller or something like that).

In the case of AAD-joined machines, the computer name doesn’t really matter — there can even be duplicates, AAD doesn’t care.

In an ideal world, IT admins wouldn’t care what name was assigned to the machine; just let Windows pick a random name and be done with it. Sadly, existing IT processes usually get in the way of that simple idea. And there is an endless variety of naming “standards” used in organizations, so it would be impossible for Autopilot to ever make everyone happy.

But that takes us back to the renaming discussion: What if you just let Autopilot do its thing, using a prefix with a random suffix (e.g. “A-%RAND:13%” for AAD, “A-” as the prefix for HAADJ), and then rename the device later? How hard could that be? It depends:

• For an AAD-joined machine, you can just change the name and reboot. AAD and Intune will eventually sync the new name, but even before that happens everything will work fine.
• For a workgroup machine (which is nearly impossible to do with Autopilot), you can just change the name and reboot.
• For an AD-joined machine, you can change the name — but only if you (a) have connectivity to AD, and (b) have the rights to rename the existing computer object in AD (otherwise you get the “domain trust broken”-type errors when trying to sign in). If a VPN connection is needed to establish connectivity, how do you know when that’s in place? And how do you give a computer permissions to rename itself?

The first two bullets are easy: generate a new name, reboot. The last one is messier. That’s what the previous blog post covered. In this one, we can expand the script some to cover all three. See the RenameComputer repo on GitHub for the script, which you can customize for your desired naming convention.

So how do you set this up? Here are the steps:

1. If using Hybrid AADJ, you need to delegate access so that the computer itself (“SELF”) can rename the existing computer object in AD. That enables a script or scheduled task (really, anything running as LocalSystem on the device) to talk to AD (when connectivity is present) to do what is needed. See the “Delegating Access to SELF” section of the previous post for instructions on how to do this.
2. Clone or download the RenameComputer repo on GitHub. You can customize the script logic as needed for your specific naming requirements and then generate a new RenameComputer.intunewin package file using the “makeapp.cmd” batch file.
3. Add a new Win32 app to Intune using the generated .intunewin file. See the “Setting up the Rename Computer app” section of the previous post for instructions on how to do this.

So what logic is the script using to generate the computer name? The previous post used a sequential name generator (using an Azure function app to keep track of the last sequence number used) which you can certainly do, but this one takes a different approach:

So desktop computers will be named with a “D-” prefix, while “anything else” (we’ll assume laptop) will get an “L-” prefix. We’ll use up to 13 characters of the asset tag, and if that is blank or null, up to 13 characters of the serial number instead. Granted, that doesn’t solve the “name already exists in AD” problem, so if there is already a computer by that name in AD you will get an error.

In the case of an AD-joined device, there is additional logic that checks for connectivity to a domain controller. If this isn’t available, the script will schedule itself to re-run later via a scheduled task that runs periodically (e.g. every time the computer starts up, every time a user logs in, and at 9am every day) until it can see a DC. For AAD, that’s not necessary, so that logic doesn’t apply.

So what would it take to make this work in the “name already exists” case (e.g. you’ve reimaged or reset the device and want to reuse the same name)? You would either have to add a numeric suffix to the name (and shorten the name to allow for that, e.g. only use up to 11 or 12 characters of the asset tag), or you would have to add logic that removed or renamed the old computer object first. That’s particularly messy because of the rights required to do that — you certainly don’t want the computer account to be able to rename other computer accounts. That would likely require a setting up a web service that could be called (only when on the corporate network) to clean up the old name; once that is done, then the computer could rename itself.

In the (easy) AAD case, we can see the result after this completes:

In this case, since it was a Hyper-V VM, the asset tag is a GUID (longer than 13 characters), so we take the first 13 and append that to the D- prefix (since the VM identifies as a desktop computer).

Interestingly, the MDM service could send down a policy (for an AAD-joined device at least — it would break the domain trust on an HAADJ device) to set the computer name to an explicit value, again using the Accounts CSP. But I haven’t seen an MDM service that provides a mechanism to generate a (unique?) computer name service-side, so that’s not really pratical.

So will Microsoft ever improve the naming capabilities with Autopilot? For AADJ, perhaps — customers just need to ask for it (with conviction or lots and lots of devices). For HAADJ, not a chance.