Dev Blog

The case for virtual domain controllers

Posted by bills
September 23, 2011

I’ve been using Windows servers for a very long time. In all that time any article I’ve read on the subject of domain controllers has stressed the importance of having a machine dedicated to the role and, ideally, a backup. For a large enterprise this is probably good advice. For a small organization it’s overkill and having a physical machine means state backups and challenges is the hardware changes in the event of a failure. After a recent failure of a machine dedicated to the role of domain controller and, in a freak co-incident, it’s backup I’m now convinced a virtual domain controller is the way to go – at least for small organizations. For us, the CPU time spent managing updates to the OS vastly outweighs the time spent handling authentication and AD requests.

The VM benefit

The advantage of using a VM is that a virtual machine running Windows 2003 is only 5GB and can be backed up completely in just a few seconds. No state to backup and restore. No hardware problems. If there’s a problem with it or the host it can be restored pretty much straight away. It’s hard to see any downside. When the VM host starts it’s important the controller VM is given chance to boot first but that seem to be about it.

Triumph in adversity

I was forced to this realization because over the weekend both our primary and backup domain controllers failed. The primary has been running for years. So, too, has the backup. Both machines ran old AMD single core Sempron CPUs. I guess they were due to fail but both at exactly the same time (OK, within a couple of hours)? Immediately the disks of the primary domain controller were put into another machine but the OS (Windows 2003 R2) wouldn’t boot. The reason for mentioning the type of chip is that all our other machines use more modern multi-core chips and it turns out the OS is tied to the type of hardware. According to this Microsoft KB article a copy of Windows 2003 R2 installed on a single core processor will not boot when put into machine with more than one core because the hardware abstraction layer (HAL.DLL) and kernel (NTOSKRNL.DLL) are hardware specific. I tried coping over the hal and kernel I thought appropriate based on the article but nothing worked (copied by putting the boot disk into another PC). Presumably there are other change made during installation as well.

So potentially, that was it. And if both domain controllers were gone, so was a lot of information in Exchange.

But I remembered a couple of years ago I toyed with using a virtual machine as a backup domain controller. It worked fine but then I needed to the memory so had stopped using it. However it was a good copy of the domain. So I created a new virtual machine using the old hard disk file and it booted! It was pretty much down hill from there. There were four steps to completely fix the domain:

DNS was not setup correctly because this machine had not been the dns server. However the DNS settings were in the active directory so installing and enabling DNS brought DNS back to life. All that was left was to remove references to the now dead controllers.

With DNS restored dcdiag reported that the only issue was that the holder of the 5 roles could not be contacted so I used ntdsutil to remove the dead controllers from the domain following these instructions in a Microsoft knowledgebase article and to seize control of the domain master, rid master, infrastructure master following these instructions in a KB article called Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller.

The new domain controller could not be seen from outside the VM itself but this was because the virtual networking on the VM host was broken.

DHCP (which has also been on the primary domain controller) needed to be installed.