Hyper V

The trust relationship between this workstation and the primary domain failed Hyper-V Server

The trust relationship between this workstation and the primary domain failed

When playing around with some Hyper-V servers that have been inactive for some time, we received an error:

Screenshot 2016 01 05 19 31 45

The cause of this is due to the fact that Active Directory is doing a lot more than simple user name and password storage. We found that a Hyper-V system that remains off for some time, then is turned on again can suffer this. The reason for this has to do with the way that some applications use the Active Directory. Take Exchange Server, for example. Exchange Server stores messages in a mailbox database residing on a mailbox server. However, this is the only significant data that is stored locally on Exchange Server. All of the Exchange Server configuration data is stored within the Active Directory. In fact, it is possible to completely rebuild a failed Exchange Server from scratch (aside from the mailbox database) simply by making use of the configuration data that is stored in the Active Directory.

The suggestion by some other blogs is to: simply reset the computer account. To do so, open the Active Directory Users and Computers console and select the Computers container. Right click on the computer that you are having trouble with. Select the Reset Account command from the shortcut menu, as shown in Figure 2. When you do, you will see a prompt asking you if you are sure that you want to reset the computer account.  Click Yes and the computer account will be reset.


This is perfectly safe to do, but is not likely to resolve the issue.

The Fix

1. Log into the server in question using the non domain admin account.

2. Open the Power Shell and run the command:

$credential = Get-Credential

(When prompted, you need to enter the domain administrator account and name.)

3. Then run the command: 

Reset-ComputerMachinePassword -Server ClosestDomainControllerNameHere

(Replacing the “ClosestDomainControllerNameHere” with your domain AD domain. domain.com for example.)

After running this you should be good to login.

Enabling Replication Failed The System Cannot Find the Path Specified Hyper-V

Enabling Replication Failed The System Cannot Find the Path Specified Hyper-V

While trying to replicate a Hyper-V server you receive the following error:

Enabling replication failed

Hyper-V failed to enable replication for virtual machine “Machine Name”: The system cannot find the path specified. (I0x80070003). (Virtual machine ID “ID Number”)

HyperV Replication Failed Path


The likely cause is that you have removed the path that was set under the replication server (or receiving servers) replication settings.

Under the Hyper-V Setting on the receiving or replication server, click on the “Replication Configuration Enabled as a Replication server”

Screenshot 2014 10 09 02 47 09

The Fix

Browse to the directory defined under “Specify the default location to store replica files” and ensure that the path is valid. 

The likely cause is that the folder defined here was removed and needs to be redefined. This can happen when you are cleaning shop.

Replciation Folder Selection Hyper-V



The trust relationship between this workstation and the primary domain failed Windows 2012 R2 Hyper-V snapshot

The trust relationship between this workstation and the primary domain failed Windows 2012 R2 Hyper-V

Screenshot 2014 08 02 23 22 38

After working with Hyper-V and Snap shots, you may find that a previously working domain member machine gets this error message. This is because the Domain Controller will automatically update passwords of Machine Accounts every 30 days, and a restored snapshot may not match the new pass.

The solution

  1. On the effected client machine open PowerShell
  2. Run the following command “Reset-ComputerMachinePassword” or specify the credentials switch if the account your running PowerShell with doesn’t have the correct AD perms for the CMDlet “Reset-ComputerMachinePassword –credential Domain\Adaccount” (You will be prompted for the domain password).
  3. After running this give the client machine a restart

After Reboot, the server will function correctly.

Converting a physical Windows Machine to a Hyper-V Virtual Machine P2V Problem

We recently wanted to move a physical windows 2003 server to a virtual server. This is known as P2V. The machine happened to be a Windows 2003 Server running exchange.
One of the reasons we wanted to move, was because the hardware was getting a little long in the tooth, and for various reasons, we did not wish to upgrade the version of exchange.
We were almost successful too, but as you will see, the nail in the coffin was a typical Microsoft issue. One that is just one more reason why our future avoids Microsoft wherever possible.

Convert P2V

To the physical machine, we installed a VM ware free tool known as VMware VCentre Converter. http://www.vmware.com/products/converter/
An easy to use free tool, that converts your physical machine into a virtual VM ware compatible single file. This file could be run on a VMware server. It is really easy to use and frankly like all VMware stuff… it just worked!
Cannot go without saying, that there is no Microsoft equivalent conversion tool.

Convert VM to Hyper V

To be able to use the VM single file, on a hyper V server, you need to convert it using the free tool from VM Tookkit http://vmtoolkit.com/blogs/announcements/archive/2006/11/20/vmdk-to-vhd-converter-available.aspx
This free little took, just runs agains the VMDK file and turns it into a VHD file.
Worked great thanks guys.

Mounting the VHD to Hyper V

Next and almost lastly, you just have to create a new HyperV virtual machine, and point it at your new VHD file that you have created and start the virtual machine.

Here is where it gets interesting

We managed to do all this, and turned on the virtual machine to one big problem. Microsoft Licensing.
Because the virtual instance detects new hardware, the Microsoft server drops into an unlicensed mode and wants to auto activate the license on the internet. Normally that would be fine, and you would just click on auto activate and wait 30 seconds before it auto activates.
Here is the problem. Because you have a new NIC network virtual instance, that has not been recognised by Windows, it will not allow you to connect to the internet until you install drivers. These drivers cannot be installed until you login. You cannot login until you activate….  and around and around we go on the Microsoft License ride!
There is no way around this, so the only option that is left to you is to contact Microsoft licensing via phone. So we called the licensing numbers listed in the Windows Server activation screen. These numbers were out of date and the phone calls failed. (Bummer that a multi billion $ company cannot redirect a phone number when it changes.)
So we researched the new phone numbers. Not actually that easy to find, and before long I was talking to a foreigner in a foreign country who could barely understand my Microsoft Licensing Query.
They were asking me for the activation code, so they could generate a new license key. After about 4 attempts of trying to understand the phonetic alphabet “B as in Bravo.. you say V as in Varo… No you idiod… BRAVO”. We found that the key generated by Microsoft failed, and wad never going to work.
Solution, is to bump up the chain, and submit a support ticket. Long and the short of it all was that while we had a fully licensed server that we have been running for years, that we could still access. With new hardware Microsoft were unable to generate a license key that would activate it manually. They advised that we should just auto activate!!!! WE COULD NOT EXPLAIN TO THE MONKEYS THAT THIS WAS NOT POSSIBLE. In order to get an internet connection we needed it to be active. Round and round we go… right!
They then advised that the only solution would be to install Windows server again. This was actually something we considered, as with a Virtual machine, there is nothing lost. Only problem was that to install the OS, you need the HyperV integration tools installed. To install them you need to login. To Login you need the license active… Round and round we go!


There was non. We were screwed by Windows 2003 licensing. MS could not help, and their stupid solution of “What you need to do here is reinstall” was no solution.
We failed!
But it’s not all bad. Before this, we had never really spent a lot of time with either VMware, or Linux servers. We have now! We love it, and more and more are enjoying everything that is non Microsoft. After years of accepting headache and heartache as a normal way of computing. We find that there is a better way…. stay away from Microsoft.

In fairness

This would not have been the case with a Windows 2008 server, as the license protection gives you a trial period to play. So the above process will work if you have a 2008 server. So we should not be too hard on MS, as they did improve one thing in the 5 years it took them to release 2008 server. The licensing does a trial mode.

In summary the process to follow is:

  1. Have a Windows 2008 server ready with Hyper-V – ours is a Dell PowerEdge 2970 with 16GB RAM, Dual quad-core AMD Opteron Processors, and a RAID 1/RAID 10 split for the OS/Storage. All the Hyper-V files run from the RAID 10 volume. This is good for about 12 guests.
  2. Install the VMWare convertor on the Hyper-V server. You don’t need to install the agent.
  3. Download the VMDK to VHD Convertor and unzip it to a local drive on the Hyper-V server (the desktop will do).
  4. Create a network share on the Hyper-V server that the target server can reach.
  5. Run the VMware converter against the target (it must be a Windows box, anything from NT4 upwards).
  6. Once complete (Our PE1750 with a 70GB disk took about 20 mins), point the VMDK to VHD converter at the new disk, and create a Hyper-V disk under your Hyper-V file location. Once complete, you can delete the VMDK file.
  7. Create a new Hyper-V virtual machine, using the new .VHD file as the boot disk. Don’t connect the machine to the physical network at this point.
  8. Boot the new Hyper-V machine, log in and let the hardware detection process run. Don’t insert the integration services disk yet. Reboot.
  9. Log in again and insert the integration services disk, and let it do its stuff. Reboot again.
  10. Log in a third time, and let the install complete. One more reboot!
  11. Log in now and have a look at the network settings. If you can’t see anything, you’ll need to shut down the guest and install a legacy adapter.
  12. Tidy up stuff that isn’t needed for a virtual machine – typically hardware management stuff.
  13. If all is good, shut down the old box, connect the network to your new virtual machine and fire it up!

Migrating Virtual Server 2005 VHD to Hyper V


There are a few little tips that I have learned the hard way this week while getting ready for a server data centre move.

When migrating from a Virtual Server 2005 to a Hyper V server, you must ensure that you uninstall the Virtual Machine add on tools for Virtual server first.

If you do not, you will find that the Hyper V tools will not install until the other package is removed. And that mouse control is not available until these tools are installed. We all know what a pain in the rear end it is to work a Windows server without a mouse.

It is much easier if you do it as the last thing before shitting down the VHD before moving it.