Powershell – Automatically Create virtual Networking in Hyper-V

I’ve rebuilt my test lab a number of times and have gotten sick of setting up my NICs and VLANs, etc over and over in Hyper-V.  This Powershell script will build a virtual switch for each network device on your host system, binding physical adapters and needed, and then adds each VM to each switch.  Easy peasy!

Function Build-Networks{
$NetworkAdapters = Get-NetAdapter
Get-NetAdapter | % {New-VMSwitch -Name ($_.Name + " External Connection") -NetAdapterInterfaceDescription $_.InterfaceDescription}


Get-VM | % {$vm=$_.Name; Get-VMSwitch | % {Add-VMNetworkAdapter -ComputerName $vm -SwitchName $_.Name}} # add one nic per switch
Get-VM | Get-VMNetworkAdapter | ? SwitchName -eq $null | Remove-VMNetworkAdapter # remove null nic


Hyper-V, fixing moved VHD files

Here is a scenario for you: some lowly admin thinks he will free up space by moving a VHD file, or perhaps you add more storage to your home test lab, and move your VHD files to the new drive.  If you tried this operation while the VM is running, the file copy will fail.

If you try this on saved or shut down VMs, you can definitely move the virtual hard drive (.vhdx file) which will cause the VM associated with it to rather predictably fail when powered on, as seen below.

Failed to restore with error The System cannot find the file specified.
Attachment .vhdx not found. The System cannot find the file specified.
The hard disk image file does not exist.

Lets verify by going to the path specified.

Sure enough, there is no VHD file at the path listed.

Now, lets determine where the VHD file went off to.  Lets use Powershell to track down the VM’s ID.

Here we are searching for VMs that match the name specified, and then selecting the VM id and the VM Configuration File storage Path (E:\) in the screenshot above.

Using this excellent blog post by Ben Armstrong I determined that the VM configuration files are stored in the Virtual Machines folder on the path specified in the Powershell output (you can also check this using the Hyper-V console)

Sure enough, we see a Virtual Machines folder in the path specified.

Earlier, we saw that the VM ID was 6D68E…, lets open the configuration file associated with it.




Search for the VHD path we gathered from the earlier error message.  You should find this under the <controller#> <drive#> tags in the XML.  Replace the incorrect path with the correct path.  Be sure to omit any single or double quotes.



Now save the file, and try to restart the VM again with Hyper-V or Powershell.

If all went well, you should now see the VM started successfully!

I hope this helps you!

How to reset the local admin password of a Hyper-V VM

Do you ever get that sinking feeling, when you’ve forgotten the root password to your test lab?  Again?

I hate it too!  So I decided to figure out a way around it, using an work around.

Reboot your VM with your Windows OS or Server install disc.  Any version will work.


Hit Shift+F10 for a command prompt.


Next, browse to your windows\system32 directory.  We’re going to make a copy of utilman.exe and replace the original binary with a copy of CMD.exe.  This will allow us to use an ages-old trick to launch a command prompt as the System account from the logon screen.


Once completed, restart the system.


At this point, clicking the Accessibility Icon in the bottom-left hand corner, or hitting left-shift 5 times will call the UtilMan.exe, which we earlier replaced with cmd.exe. This means you now have access to a system authority level account without needing to logon!  You can have a lot of fun with this.  More on that later.


We are now just a few short steps away from a localadmin account.

The quickest way to do this is to create an account:

net user /add localadmin Dr0wssap!

Now give the account privilege.

net localgroup administrators localadmin /add


Now simply logon with these credentials.


To save on keystrokes, you can use .\ notation to log on to the local system.


And you’re in!

From here, you can use other means to reset your domain accounts to gain access to your lab again.

As I mentioned earlier, the ability to launch a privileged command prompt at the logon screen allows for some curious behavior.  For instance, if you call Explorer.exe, very interesting things happen.  Not as much fun on Windows Server 2012 or Windows 8.  On Server 2008 or Windows 7, you can have the Start Bar and desktop display over top of the logon screen!

Here is an example of a similar situation, launching Explorer while a Task Sequence is running.


This is also a potent security risk.  It is a reminder of why we always maintain physical control of our servers and encrypt our VM Virtual Hard Drives.  With the new ease of cloning Domain Controllers as VMs, someone might potentially attempt this on a domain controller.  If they are able to log on as the Local System or local Admin account to a DC, there is opportunity for mischief.

I hope this post will be helpful to others.