Introduction
When we think of some of the limitations causing issues when it comes to manoeuvring around structuring our Autopilot process, one of them will always seem to stem around the naming conventions.
Today, we will bring more light into a workaround for how this can be achieved.
Accommodating Name Conventions in General
We have configuration profiles such as domain join where we can specify a prefix up to 15 characters. But I can’t imagine too many folks utilizing this without having conflicts with their NetBIOS names. But it can be a great way to start if using a short enough prefix to have a randomized part for the rest.
The real part of name conventions derive from the Autopilot Profile where we can assign a name template which can use variables such as the serial number and the %RAND% variable to customize a random mix of characters. However, the drawback for this is normally around the fact that you cannot assign naming templates when your profile is specific to Hybrid Devices. And unfortunately, in a lot of real case scenarios this can normally be the biggest hurdle.
Can we use the name field in the autopilot right pane
Yes and no. See you could populate a name there, but again in hybrid cases this name will get ignored on the on-premise domain. Not only that, but after the autopilot has been deployed you can potentially face an issue where the device cannot log onto the domain due to the changes not being synced between AAD and On-Premise and have trust issues where logon is not possible. If you were to utilize a local account as part of your autopilot profile or make the user an administrator via the autopilot settings you could correct that. But when pushing this through a good amount of devices this can cause a huge administrative effort to be corrected.
Workaround for renaming convention
The solution I find for this is having a Win32 application which can be used to rename the devices via a PowerShell Script.
But since we want to address this during the time a device is built, what we want to do is make this a mandatory application within its Enrollment status page. That way, once its complete the naming convention is at company standard and ready to go.
PowerShell Naming Convention Template
In Figure 1.1 we have a template of how the logic would work for device naming standards which can be anything of course but the example just shows the structure on how this would actually look.
This structure uses logon credentials which specifically have enough permissions to join devices to the domain. You can of course use more stricter credential objects if you’re not wanting to use a plain text version like the example shown above.
The next part of the script is where we define the naming convention that we will use. Now as stated before when using a hybrid autopilot profile the naming templates option is not available to you, but even if it was available, there may be just some standards which Intune may currently not have a variable.
So in our example we will combine the model name of the device separated with a “-” and following with a serial number.
The last line will go ahead and rename that device with the new device name specific to that endpoint.
Detection Methods
There are two detection methods for this. And when you see the explanations on scenarios you will totally understand why there is 🙂
Ideal Method
The ideal method is to have a detection script which can make sure that the current device name remains in line with the naming convention. Here in Figure 1.2 we have a script which contains the same logic for the naming convention mentioned before and where compare this with the current name of the endpoint and the desired new name. As long as they match, there will be no issues.
Cautious Method
Now here is an explanation for the cautious method. With the one shown above, if we have devices which are enrolled in Intune already, which have different names and are NOT an autopilot device, we essentially have a Win32 application which will simply rename that device ASAP. That may not necessarily be a bad thing but it’s not something you want to just happen without your control or consent in most cases.
You could make a case of creating a filter to explicitly exclude devices with an enrollmentprofile assigned to it which used autopilot. But to be on the safe side, its worth it to not layer the workflow you have.
Overall you’ll want to get every device following the correct naming convention first before you use the Ideal Method.
For this one, we could utilize a detection method that picked up something like a text file to state its compliant. To avoid trying to find a common text file every machine would have we could create one like “RenameDevice.txt”
PowerShell Script for Rename Device.txt
The first part is to create a PowerShell script in Intune which can create this file for us. A line like below
New-Item -Path C:\Windows\Temp -Name RenameDevice.txt -ItemType File
Here I would then deploy the script to all of the devices which currently are not Autopilot devices.
Change Application Detection Method
Next, we want to go into the Win32 application for the detection method and change the conditions for this to fit what we are trying to achieve.
So in Figure 1.4 we see how the detection method is configured here
This will check the same location which we create the txt file for, and this should prevent any issues from having a rename device job going out forcefully.
Summary
Overall its an interesting strategy for renaming devices to the naming convention you want. But you can see how there are a lot of moving parts especially when you may want to prevent certain deployments from happening, especially a rename device job 🙂
The detection method could be used for other applications as well if there are applications you may not want to hit a device straight away.
