As some of you have noticed, the naming convention allowed for Windows Autopilot Hybrid Azure AD joined devices isn’t particularly flexible:  You can specify a prefix (e.g. “AD-“) and the rest of the computer name will be filled in with random characters and digits to pad the name to 15 characters.  So you end up with names like “AD-a8cDFefGZkyP.”  Eventually, we want to provide a more flexible naming mechanism, but until we can do that (it’s rather complicated, as the name is generated today by the ODJ Connector and it doesn’t know anything about the device itself) it is possible to automate the process of renaming the device after it has been joined to AD.

The trick with this process is that it needs to be done with connectivity to a domain controller, and in the context of a user that has rights not only to rename the local computer but also to rename the AD computer object.  While you could push out a script that has an embedded user ID and password, that wouldn’t be particularly secure.  As an alternative, you can allow the computer to rename itself in Active Directory.  That way, anything running as SYSTEM (e.g. an Intune app or scheduled task) would have the ability to rename the computer object in AD.  So how do you do that?  You delegate access to SELF.

Delegating Access to SELF

Here are the steps needed to delegate access to SELF.  First, open Active Directory Users and Computers as a domain admin and right click on the OU that the devices will be placed in.  I cheated and did this at the top level of the domain, but you can choose to do this on an individual OU as well.  Choose “Delegate Control…” from the context menu.

First you need to choose the account that you want to delegate to.  Click to “Add” and then specify SELF as the object name.

Once selected, you should see something like this:

Next, you need to choose what rights to delegate.  Choose “Create a custom task to delegate” from the choices.

Choose “Computer objects” from the list of object types.

Check “Read All Properties” and “Write All Properties” to enable renaming:

And finally, complete the wizard.

Customizing the app and script

You need to clone or download the sample from GitHub, which is located at https://github.com/mtniehaus/RenameComputer.  You should end up with a structure that looks something like this:

Inside that RenameComputer folder, you will find the RenameComputer.ps1 script.  That script should be updated to meet your needs, especially this line:

That’s tied back to my previous blog about having a Azure function that returns a sequential name.  In this case, I have it generating names like AD-00000451.  If you use the script without modifications, then you too will get sequentially-numbered devices that start with AD-, and that may not be what you want.

Once you are happy with that logic, you can then generate a new RenameComputer.intunewin package by running the “makeapp.cmd” batch file in the parent folder (as shown above).

Setting up the Rename Computer app

To set up the Rename Computer app, you need to add a new Win32 app, specifying the RenameComputer.intunewin package file:

Next, specify the basic properties for the app should be specified as appropriate:

Then specify the command line details:

The program properties specified above:

Install command:  powershell.exe -noprofile -executionpolicy bypass -file .\RenameComputer.ps1

Uninstall command:  cmd.exe /c del %ProgramData%\Microsoft\RenameComputer\RenameComputer.ps1.tag

Device restart behavior:  Determine behavior based on return codes

Next, specify the architectures needed (x86, x64) and minimum OS version.

And finally, you need a detection rule that looks for a particular file that the script will create:

Values specified:

Path:  %ProgramData%\Microsoft\RenameComputer

File or folder:  RenameComputer.ps1.tag

Detection method:  File or folder exists

Then you’re ready to assign the app to a group of devices – ideally a test group, so you can try this out in a controlled environment.

What does the script do?

There are several steps needed in the script to make sure that this is a reliable process.  For example, there is no guarantee that the device has connectivity to an Active Directory domain controller at the time the script first runs, and it may not even be a member of the domain yet.  So the script might not be able to do what is needed when it first runs.  In that case, the script will reschedule itself to run later via a scheduled task (still running in the system context so it will have rights to rename the computer object in AD).  When it finally succeeds, the device will need to be rebooted for the new name to take effect.

So the script needs to be fairly deliberate.  First, it needs to make sure the device is joined to a domain:

Next, it needs to see if there is connectivity to an AD domain controller:

If both of these are good, then the device can be renamed.  A new name is calculated and the rename is performed, which is simple:

The scheduled task can then be removed (it isn’t needed any more, if it exists), and the device can then be rebooted.  If the rename can be done during OOBE (meaning there is connectivity to an AD domain controller, then this is simple: set a 3010 return code and exit.  But if this doesn’t happen until later (e.g. after the user manually makes a VPN connection and signs in), then an explicit reboot needs to be triggered.  This will happen with a 10 minute delay.

In the case where we need to schedule a task to try again later, it will be created with triggers to run every day at 9am, as well as after each user sign in and after each reboot, until it finally finds connectivity and can complete the renaming process.

What’s the user experience?

If there is connectivity during the Autopilot device ESP process (and if you are using Always On VPN or another automatically-connecting VPN client, there might always be connectivity), then the user is unlikely to even notice:  There will be a coalesced reboot at the end of the device setup phase of ESP, and the computer will have its new name after that reboot, before they sign in.  Afterwards, you can confirm the device was renamed from the C:\ProgramData\Microsoft\RenameComputer\RenameComputer.log file (not to mention by just looking at the computer name):

If there isn’t connectivity, then it depends on when the scheduled task runs and can find a domain controller.  When that happens, they’ll see a popup letting them know the device is going to reboot:

If you check the C:\ProgramData\Microsoft\RenameComputer\RenameComputer.log file, you’ll see that it did the rename and initiated the reboot:

As always, let me know if you have any comments or suggestions, or if you find any issues.