So, there you are, trying to beat your Minesweeper score, when the Active Directory administrator calls you wanting to know why he’s looking at computer objects named “WIN-1AWER48J54A” and the like. Hmm, looks like someone has been standing up virtual machines and joining them to the domain without renaming them. They probably forgot that the name in Hyper-V Manager isn’t just handed down to the guest operating system when it’s installed. We all know that “they” isn’t “you”, because we experienced Hyper-V administrators never make mistakes like that, do we? Of course, this isn’t the only scenario in which you’ve got one name for the virtual machine and a different one for the guest operating system and would like to make that go away. I’ve crafted a PowerShell script that will help you synchronize these.

How To Get It

How To Use It

Make sure that you unblock the file. Right-click the file in Windows Explorer and go to Properties. Click the “Unblock” button. You can also use the Unblock-File cmdlet.

The contents of the ZIP file, at least the .PS1 and .PSD1 file, need to find their way onto the Hyper-V host that contains the VMs to be changed.

The execution policy on that host needs to be RemoteSigned or Unrestricted (
Set-ExecutionPolicyRemoteSigned ).

Execute Sync-VMNames.ps1 in a PowerShell session on that host.

What It Does

The script is entirely menu-driven. It has three major functions.

You can synchronize from the guests to the hypervisor, which means that the names as they appear in Hyper-V Manager, Failover Cluster Manager, Get-VM, Get-ClusterGroup, Get-ClusterResource, etc., are all changed to match the guest’s computer name. Note that the cluster group is renamed to be exactly what the guest’s name is, but the resources are only changed if they contain the original name and only that portion of the name is changed. For example, if you have a cluster resource named “Virtual Machine sv-tango” and the related computer is named “sv-charleston”, the resource will be renamed to “Virtual Machine sv-charleston”. You can opt any VM out that you don’t want to change.

You can synchronize from the hypervisor to the guests, which means that the computer names will be changed to match what shows in Hyper-V Manager and Get-VM. Failover Cluster Manager and the resources are not considered. There are a huge number of restrictions on this:

The guest must be a Windows operating system.

The guest must be turned on.

The guest must be accessible from the management operating system over the network by an IPv4 address.

Hopefully these don’t spoil the fun. These restrictions are because I don’t know how to remotely change a non-Windows OS’s name in PowerShell and I’m not all that invested in learning and because a computer rename is a guest function. The management operating system can’t just command a guest to change it’s name.

The computer rename function will first attempt to use the credentials you logged onto the management operating system with. Since I figured this would probably get use on a lot of one-off VMs that aren’t domain-joined, it will ask you for credentials if the ones you’re signed in with don’t work. You have to get any other credentials right on the first try, though. Also, it won’t save any credentials. I’m pretty sure there’s a book out there somewhere that says, “Storing a lot of credentials for remote computers in an actively running PowerShell script is a bad idea”. If there’s not, there should be. Anyway, you’ll have to enter credentials for each and every target that won’t accept your current logged-on credentials. As with the synchronization from guests option, you are given the chance to opt out any virtual machines that you don’t want to change.

Warning: Renaming computers is not a trivial task. You can really wreck some server roles and applications by renaming the computers that they live on. Neither I nor Altaro are responsible for any havoc you wreak with this script. We are, of course, solely responsible for all the time you save with this script.

The third thing that this script will do is show you a summary of mismatched virtual machines on your host. It will also categorize those virtual machines that it can’t work with so you know why they don’t show up on the change screens.

The Fine Print

Normally, I test every script that I release very thoroughly, each and every line. In this case, I simply don’t have the resources to beat on this one as hard as I would like. Therefore, its initial release will be a 0.9b, as in, a beta. I’m comfortable with the portion that changes the virtual machine and cluster names, but the computer name portion could use some more vetting before stamping this with a 1.0. Consider yourself a lab rat recruit. Thanks! If it’s not working, please be as detailed as possible when you report errors. I will fix what I can, but I can’t read your mind.

I have worked in the information technology field since 1998. I have designed, deployed, and maintained server, desktop, network, and storage systems. I provided all levels of support for businesses ranging from single-user through enterprises with thousands of seats.
Along the way, I have achieved a number of Microsoft certifications and was a Microsoft Certified Trainer for four years.
In 2010, I deployed a Hyper-V Server 2008 R2 system and began writing about my experiences. Since then, I have been writing regular blogs and contributing what I can to the Hyper-V community through forum participation and free scripts.