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:
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.
Categories: Windows Autopilot
Why is it so difficult to get the name from the AutoPilot profile? If this can be done on Azure AD join scenarios, why can’t that information be sent to the ODJ connector?
We’ll get that done eventually and will probably shift the name generation logic into the cloud entirely, but for now it requires multiple changes in various components of Intune, Autopilot, and the ODJ Connector to make that work, so it’s going to take some time before all of those can be completed.
Thanks for trying to provide a workaround for that.Now more than ever Autopilot has become a thing to watch for. Also looking for the public preview of offline domain join!
Thanks Michael! I always appreciate the way you explain the actions done in your scripts, it helps me learn about powershell in a very practical way. Very useful, great post.
We are currently using a domain-join profile to rename our Autopilot-Hybrid-AzureAD-join devices, and we are experiencing issues.
Basically, some devices disappears from our autopilot tag-based dynamic group when they are renamed by the AD-Join device policy: sometimes they are not members anymore after renaming, sometimes they are still members but with the old name.
The result is all our profiles are not deployed to the device anymore since all profiles are assigned to our tag-based dynamic group.
Any help for this?
PS: dynamic rule for our tag-based dynamic group is : (device.devicePhysicalIds -any _ -eq “[OrderID]:TESTHYBRID”)
Would it be possible for the rename script to pull the device name from the autopilot profile in Intune?
From the profile? No, that’s not sent to the client for Hybrid AADJ scenarios. Reading it from Intune would be tricky as you’d have to do that via the Graph API.
I was able to modify the script to suit our naming convention, using WMI to pull the Asset Tag number from Win32_SystemEnclosure and combining that with the desired prefix for the computer name. This works perfectly for a first time setup of a new computer, but once the computer has been reset, it’s going to hit an error the next time autopilot runs. Since the computer is joining the domain using an autogenerated name and then being renamed, it can’t use an existing computer account.
My first thought is that when we initiate a ‘fresh start’ or reset on a PC, we could also delete the computer account from AD, but I wonder if this wouldn’t have other consequences, especially once that delete syncs to AAD. Is deleting the computer account a safe way to handle this, or is there a better option?
LikeLiked by 2 people