Windows Autopilot

Renaming Autopilot-deployed Hybrid Azure AD Join devices

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.

image

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

image

Once selected, you should see something like this:

image

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

image

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

image

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

image

And finally, complete the wizard.

image

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:

image

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

image

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:

image

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

image

Then specify the command line details:

image

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.

image

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

image

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:

image

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

image

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:

image

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.

image

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.

image

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):

image

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:

image

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

image

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

Categories: Windows Autopilot

5 replies »

  1. 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?

    Like

    • 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.

      Like

      • 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!

        Like

  2. 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.

    Like

  3. Hi,
    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”)

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s