{last update 12/11/2018}
When creating a provisioning package to perform bulk enrollment, one of the first steps is to Set up device, which includes providing a naming convention for computer names.
This is what it looks like in WCD:
Draw your attention to %SERIAL% and %RAND%.
Using built-in environmental variables are great, if you’re creating new machine names in Azure, or you’re using autopilot to aid in the setup and AAD enrollment process. Assigning provisioning packages to groups, and then pairing those groups with the autopilot feature is quite an efficient way to perform remote setups.
BUT….the big but, what if you have existing machines, and you want the current computer name to be the computer name in Azure? Provisioning can’t help you with that. 🙁
What? Why not? According to Microsoft, you MUST use the conventions provided, i.e., %SERIAL% or %RAND% to generate computer names. Well, that’s not very friendly…or practical.
After digging around in the advanced areas of the Windows Configuration Designer, sure enough, there was no way to use the current computer name. Just for fun, I did try %COMPUTERNAME%, %PCNAME%, and %DEVICENAME%, just to see if there was perhaps some undocumented method; those did not work.
So, it got me thinking, how could I get around this? If you decide to rename the computer once the machine has been enrolled into Azure, guess what? The machine name doesn’t change in Azure! You have to reenroll. If you use the provisioning package method, you’re back at square one again—with the machine name using %SERIAL% or %RAND%. If you do a manual enrollment, using the Connect to work or school option, that works. But, let’s say you have hundreds, or even thousands of computers. That just isn’t a viable option. The last thing you need is for users being required to follow some step by step instructions, to complete some enrollment process. Microsoft, just no.
Soooo, let’s get to it. I figured out how to get around the forced naming convention.
The normal provisioning process works like this:
1 – Run provision package.
2 – Package adds some reg keys.
3 – Renames machine.
4 – Forces a reboot….all within a 60 second window.
5 – When the machine restarts and is back at the logon window, Sign in to: Your work or school account is now visible.
Workgroups
The trick is to get between steps 3 and 4, and rename the machine yourself, before it reboots. That’s right! Using some simple scripting techniques—batch, PowerShell, VBScript—whatever you like,
1 – Create a scripted package.
2 – Store current computer name in a variable.
3 – Run the provisioning package (you now have 60 seconds to work).
4 – Using the variable, rename computer back to original name.
The provisioning package will force the reboot, but….this time instead of %SERIAL% or %RAND% being used, it will apply the original computer name. BAM! Do note, this was tested on workgroup computers. If you want to do this for domain computers, make sure you launch the package with a domain user that has the appropriate rights to rename a domain computer (otherwise, you’ll blow up the domain computer account—not great).
Workgroup Solution
on error resume next
set wshShell = CreateObject("WScript.Shell")
strComputerName = wshShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colComputers = objWMIService.ExecQuery ("Select * from Win32_ComputerSystem")
'add provisioning package here
wshShell.Run "enroll.ppkg",0,false
WScript.Sleep 30000
For Each objComputer in colComputers
err = objComputer.Rename(strComputerName)
Next
WScript.Quit(0)
Domains
Now, something even more experimental, I also figured how to get around the domain machine name issue, where the domain computer account will have a disassociated trust after the above computer rename (if done without a domain user). This is the scenario: You want to deploy the PPKG under the security context of System Account from SCCM, or other desktop management software. But, if you do that, the AD computer account issue pops up, and Azure sometimes goes sideways, and just names the machine Azure-SERIAL anyways. Arrrg.
The solution: Rename the computer AND apply the registry keys that get altered by the PPKG during enrollment (before the reboot). How did I figure that out? I used procmon by SysInternals, of course.
See the steps below. These will take care of domain machines—installing a PPKG, under the security context of System Account (great for SCCM/LANDesk deployment).
Domain Solution
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
::Step 1 – Grab Current Device Name set PCName1=%computername% ::Step 2 – Install PPKG c:\windows\system32\provtool.exe enroll.ppkg /quiet ::Step 3 – Rename Machine WMIC ComputerSystem where Name="%computername%" call Rename Name="%PCName1%" ::Step 4 – Apply Reg Keys with Original Device Name reg add "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName" /v ComputerName /t REG_SZ /d "%PCName1%" /f reg add "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters" /v HostName /t REG_SZ /d "%PCName1%" /f reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters" /v "NV Hostname” /t REG_SZ /d "%PCName1%" /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\Nodes\1" /v ExpectedValue /t REG_SZ /d "%PCName1%" /f /reg:64 reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability” /v LastComputerName /t REG_SZ /d "%PCName1%" /f /reg:64 reg add "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DNSRegisteredAdapters\{FC5B1177-F053-4F20-A47F-063553C16BED}" /v Hostname /t REG_SZ /d "%PCName1%" |
* This does require appropriate timing; remember the 60 second window for the PPKG during enrollment.
* Tested with build 16299.785 and newer (older builds have issues with Intune)
Notes