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:
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.
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.)
The trust relationship between this workstation and the primary domain failed Windows 2012 R2 Hyper-V
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.
On the effected client machine open PowerShell
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).
After running this give the client machine a restart
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.
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.
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.
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.
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:
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.
Install the VMWare convertor on the Hyper-V server. You don’t need to install the agent.
Download the VMDK to VHD Convertor and unzip it to a local drive on the Hyper-V server (the desktop will do).
Create a network share on the Hyper-V server that the target server can reach.
Run the VMware converter against the target (it must be a Windows box, anything from NT4 upwards).
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.
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.
Boot the new Hyper-V machine, log in and let the hardware detection process run. Don’t insert the integration services disk yet. Reboot.
Log in again and insert the integration services disk, and let it do its stuff. Reboot again.
Log in a third time, and let the install complete. One more reboot!
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.
Tidy up stuff that isn’t needed for a virtual machine – typically hardware management stuff.
If all is good, shut down the old box, connect the network to your new virtual machine and fire it up!
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.