How to Best Retire Physical Domain Controllers
It’s impossible to virtualize everything, but one particular chain has historically chafed at the system administrator’s ankle: the need for physical domain controllers (DC) under Microsoft Active Directory Domain Services (ADDS).
Every Active Directory domain has one or more DCs to provide the various services that end users, servers and solutions rely upon. Without them, the day-to-day operations of most businesses would grind to a halt.
Traditionally, sysadmins have kept at least one DC physical, protecting it from the potential vagaries of virtualization, but that’s no longer necessary. With Windows Server 2012, Microsoft finally made it possible to confidently run an ADDS environment with all virtualized DCs. There are two things a sysadmin should consider before retiring physical DCs for good.
Time Synchronization
Because system time is often used as an arbitration method within a domain, it is important to keep all physical and virtual systems marching to the same clock by avoiding circular dependencies within time sources — especially since Kerberos authentication requires a default maximum time drift of five minutes.
Incorporate a reliable, external time source (such as pool.ntp.org) as a clock. Point the virtualized DC with the primary domain controller emulator (PDCe) role to the external clock, then do the same for hypervisors, to avoid dependencies between the physical hypervisors and the virtualized DCs.
In instances of unplanned outages, hypervisors can synchronize immediately with the external clock. The virtual environment also can remediate any time drift properly as soon as the PDCe is back online.
VM-Generation ID Support
Knowing that virtualization administrators have the ability to snapshot, clone or copy a virtualized DC keeps many sysadmins awake at night. Such unsupported operations can wreak havoc within ADDS — scary things such as update sequence number rollbacks that could, in a worst-case scenario, become résumé-generating events.
To address the issue, Microsoft added the concept of the virtual machine generation identifier (VM-Generation ID) to Windows Server 2012. This allows a virtualized DC to use a software-defined data center to track many common activities.
Choose a hypervisor that will work with the virtualized DC to ensure that VM-Generation ID runs accurately. That includes Hyper-V Server 2012 or later, and vSphere 5.0 Update 2 or later, but the list will likely grow. Remember, just because something seems to work doesn’t mean it’s supported. It’s best to err on the side of caution and choose a compatible hypervisor.
