This article is not part of the Building Microsoft System Center Cloud series but we will need these DCs for our Hyper-V cluster that we are using in our Cloud series.

Now it is a good time to deploy VMs that will be our DCs. These VMs will not be highly-available (clustered) and the VMs will be located on the local disks. At the end of this article I will explain why I chose this configuration.

How admins built DCs in the past (Windows Server 2000 era)

I decided to do something crazy and I will show you how administrators built domain controllers in the past (Windows Server 2000 era). In the past admins had to separate NTDS (database), logs and SYSVOL on a different physical disks (RAID arrays). Disks were small and too slow. So to ensure good performance it was adequate to split transactions among multiple disks (RAID arrays).

DB admins use this approach every day to ensure good performance for their SQL Servers because smaller LUNs usually have better performance (especially if it is iSCSI).

Do we still need to separate NTDS, logs and SYSVOL? No, we do not. Loads of the SQL Server and Active Directory are different. AD and its usage have not significantly change over the years but power of computers has increased many times. Of course it is still a good practice to separate NTDS, logs and SYSVOL from a system disk but even when you have a lot of AD clients you do not have to use more than two disks (system and data).

Create Hyper-V virtual machine

• Create new VM.

New-VM -Name 'contdc0' -Generation 2 -MemoryStartupBytes 1GB -SwitchName Production -Path 'D:\Hyper-V' -NewVHDPath 'D:\Hyper-V\contdc0\Virtual Hard Disks\Disk0.vhdx' -NewVHDSizeBytes 50GB

• To show you how DCs were built in the past I will put NTDS, DB logs and SYSVOL on a separate disks.

Add-VMHardDiskDrive -VMName contdc0 -Path (New-VHD -Path 'D:\Hyper-V\contdc0\Virtual Hard Disks\Disk1.vhdx' -Dynamic -SizeBytes 50GB).Path

• Are we done? Not yet… There are other configuration settings and from this point it is easier to configure them in GUI.
• Memory: Dynamic
  • 
• Processors: We will share CPU cores between VMs and it is good to set more VCPUs for each VM.
  • 
• Automatic Start and Stop
  • For the most of servers (virtual machines) it is OK to save the VM state. But this setting is absolutely wrong for Domain Controllers. You should always work with DCs like those were physical machines.
  • It is a good practice that you power on the second DC later. So give it more time in Hyper-V configuration.
  • I found out that it is also a good practice to give some delay to every VM but usually you do not have to…
  • 
  • 
  • 

Notes

Delay for every VM

I found out that it is also a good practice to give some delay to every VM. Just a few seconds. I could see problems with initialization of the network storage that sometime took a longer and Hyper-V service initialized start of the VM before the storage was available. The result was that VM stuck in Off-Critical state. The resolution to get rid of this state is to restart the Hyper-V Virtual Machine Management service.

Restart-Service vmms -Force

Do not worry about this approach. It will affect Hyper-V Manager (the GUI) and vmconnect.exe but it will not turn off your VMs.

I also found that I need some delay before I start my laptop. Yes, my laptop is Hyper-V host and yes, I am using the BitLocker Drive Encryption. And this is the problem. It sometime takes longer before the data are accessible.

Saving or pausing Domain Controllers

Some time ago I did a several tests what would happen when you save a state for a longer period. I verified that when you left all DCs in saved state longer then TombStone lifetime you will totally corrupt the replication. The only solution how to repair domain services was to deploy a new DC, replicate data from the first DC that had all roles and kill the second DC. In testing environment it is fun but you really do not want to see something like that in the production environment.

If you have only one DC in you testing lab it is OK to save them. Btw. I am doing this for several years with Windows Server 2008 R2 and now with one Windows Server 2012 (R1) because I am using these VMs as testing machines to develop Windows PowerShell scripts that work with Active Directory.