Jim Guckin

I got a call yesterday from my old job, it was the software specialist who was having problems with the VMWare 3.51 server which I installed a couple of months before I left.  Though by the time I was able to get a break and call them back, but it got me thinking about my first VMWare environment I built.  I made a blunder that first virtualization…well 2 actually, but one of them hopefully I can help you to avoid.
One of the first servers I got on the VMware enviroment was one of our domain controllers.  The domain controller we had was outdated and many time unable to hold up to the task of being a domain controller.  So with the VMware environment, I hoped to sort that out.  I virtualized the server and for the first day things seemed to be going OK.  Yet, I noticed over the next couple of days, the time on the server moving ahead.  This was a problem, because all of our workstations used this server for their time.  Then some of the other servers starting acting up because of the time discrepancy.  It was an easy fix, that I want to impart to you, so you don’t make my rookie mistake.First, inside the infrastructure client option, ensure that the option “Time synchronization between the virtual machine and the host operating system” is unchecked.Secondly, I our domain controller was not set to use an external time source (like time.microsoft.com). The procedure is simple and can be found in detail on Microsoft’s Knowledgebase article 816042, but in essence, it comes down to setting the following registry values under

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\:

• Parameters\Type = “NTP”
• Parameters\NtpServer = “time.windows.com,0x1”
• Config\AnnounceFlags = “5”
• TimeProviders\NtpServer\Enabled = “1”
• TimeProviders\NtpClient\SpecialPollInterval = “60”

Finally, you need to restart the W32Time service at the domain controller using net stop W32Time followed by net start W32Time, or you can just restart the server like I did.  Though if you are going to restart the server, remember if it’s the only domain controller in the domain, you wont be able to log on or authenticate during the downtime.  Luckily we had a physical domain controller to handle the load while I was rebooting.
Now it’s always a best practice to have two domain controllers to a domain, for fault tolerance, but in this case, I decided to keep a physical domain controller and a virtual domain controller.  Our enviroment only had on Dell Equilogic SAN, which stores the VMware files, so incase that went down I wanted a physical one in it’s place.  Though if you have a more robust network, you could put two virtual ones in, as long as they don’t reside on the same hardware.
So hopefully I’ve given you the domain controller virtualization tip, so you’re not driven as mad as I was when you do it.  I know Microsoft kind of discourages you from making a domain controller virtual (SEE KB888794), yet I’ve seen it work flawlessly and give you a Hight Availability (HA) with your domain controller and even seen it work well for Disaster Recovery(DR).