Automatically Rename Virtual Machine on Boot

I was recently reminded of a technique I developed and used a decade ago to automatically rename virtual machines when they booted for the first time. The requirement was to make the deployment of identical VMs to multiple classroom computers as efficient as possible at the technical college I worked at at the time. We were using VMware Player or VMware Workstation, depending on the needs of the class, to run VMs that were tailored to particular courses.

How It Used to Work

There was no central provisioning solution at the time. It was more of a proverbial “bubble gum & bailing twine” scenario. A VM was prepared based on course requirements, was sysprep’d, shut down and then 7zip’d into a compressed image. These were our master templates.

We wove a home grown collection of batch scripts and VBscripts together to copy the templates down from a file share to each classroom PC. The scripts created a consistent folder structure for storing the VMs, generated shortcuts on the desktop and start menu, and prepped the VMs for their unique hostname change.

How did it accomplish this? The hostname was derived from the local PC’s hostname plus the course the VM was tailored to. So if the underlying desktop had a hostname of “PC007” and the VM was intended for use with course “IT101” the derived VM hostname was going to be “PC007-IT101”.

There was a little bit more too it than that, of course, for example ensuring the target name stayed within NetBIOS naming restrictions. The derived hostname was then added as a value to the machine.id attribute in the VM’s VMX file.

machine.id = "PC007-IT101"

As part of the collection of scripts set to run upon first boot of the VM, a VBscript had been preemptively inserted in the VM image which would read machine.id and then rename the VM. It was able to read the value by calling a local executable that came with VMware Tools, VMwareService.exe.

"C:\Program Files\VMware\VMware Tools\VMwareService.exe" --cmd machine.id.get

Does it Still Work?

While it may not have the same value today as it did 10 years ago, what with the modern provisioning, desired state and automation systems available, I wanted to find out if this approach still worked. You know, as an academic exercise.

I chose an existing Windows 10 evaluation VM I had kicking around and manually modified the VMX file. So far, so good.

Firing up the VM, I searched the VMware Tools directory for the VMwareService.exe executable. Whoops. Looks like that file no longer exists in the modern VMware Tools.

Having a look at the executables available in the directory, I took a chance and tried running vmtoolsd.exe –cmd machine.id.get. Success! There was the machine.id value, as raw console output.

So how to take my 85+ line VBscript from yesteryear and come up with a PowerShell equivalent? Turns out it was easy. Some might say it was almost too easy.

$machineId = (& "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" --cmd machine.id.get | Out-String).Trim()
Rename-Computer -NewName $machineId

Run the two-line PowerShell script above with Administrator privileges and your VM will dutifully rename itself based on the machine.id.

What’s Old is New Again

So we’ve replaced an old, complex VBscript with two lines of PowerShell. That was satisfying. As mentioned, I do have an old VBscript that was used to modify the VMX file using a predetermined course identifier, but I’ll leave modernizing that as an exercise for you, dear reader.

I like to think that this example goes to show you how scripting and automation builds on itself. That lessons and approaches learned and refined years ago could still have relevance today. And indeed could also be renewed and reinvigorated with modern tools and approaches. Happy automating!

Featured image photo by focusedcapture