Automatically Rename Virtual Machine on Boot

Search for a command to run...

No comments yet. Be the first to comment.
The first full, official day of VMware Explore. I managed to attend a few sessions, as well as the traditional Welcome Reception and a couple after-hours events. In between I met folks both familiar and new. That's what a conference like this is abou...
![VMware Explore 2022: A New Dawn [Day 2]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277173084%2F27aa6c63-c1ff-4df5-8074-7bf666ef46fd.jpeg&w=3840&q=75)
Welcome to the VMware Explore US 2022 General Session live blog! General Session Only one general session this year, let's see what's up! Note: To view the live blog you need to read this post on https://teebeedee.org. If you read it some other way, ...
![VMware Explore 2022: General Session Live [Day 3]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277115028%2F62e1ebe4-7d09-46a8-8ac6-aca2c17e2487.jpeg&w=3840&q=75)
"See you next year San Francisco!" That's how my last post on this blog ended. It was August 2019. Simpler times. Needless to say I didn't see San Francisco in 2020. Or 2021. Two Gather(ings), Apart VMworld was held completely online those years. It ...
![VMware Explore 2022: The More Things Change [Day 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277227689%2Fe6cdc90f-c453-4673-afb3-9dba59700e47.jpeg&w=3840&q=75)
The bittersweet last day of VMworld. This year I'm doing something a little different and attending VMware's Future:NET. Future:NET is a sister conference to VMworld that focuses on networking. The day was broken down into sessions that alternated be...

Wednesday at VMworld. Full out sessions, last day of the Solutions Exchange. Let's check in. Swing and a Miss I had a breakout session booked early in the morning this morning. Early enough that I had to skip breakfast to get to it. No problem, I tho...

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