Active Directory (AD) is a foundational part of the Windows Server system, and any changes to it must address three broad sets of requirements. The first requirement set is for the entire Windows Server ecosystem that depends upon it for authentication and access control. Whether it’s Exchange Server, System Center, Hyper-V, SQL Server, or many other products inside and outside Microsoft, thousands of enterprise software solutions depend on AD.
The second set of requirements is for AD service owners—the systems administrators who actually manage the AD distributed application across its span of domain controllers (DCs). Though AD has made great strides in manageability since its early days, it still remains a complicated beast (perhaps a hydra with its many heads). How can this critical but confusing piece of infrastructure be made easier to work with in an IT environment that’s far more complicated than when the directory service was first designed?
The third, of course, is for the literally millions of users around the world who work with AD directly or indirectly for access control to various resources in their domain. How will the aging users/groups model of access control evolve to meet the complex security and compliance requirements we live with today, and grow for tomorrow’s certainly expanding needs? As Microsoft’s Nathan Muggli said, “Designing changes to Active Directory is like ordering pizza for a million people; everyone wants something different.”
For Windows Server 8, the AD team didn’t alter the product dramatically. There’s no SQL Server-based directory service database, nor can a DC host more than one domain partition (why would you need to anymore, when you can create another virtual DC?). Instead, the team focused on three major goals that address all of its stakeholders to varying degrees. First, AD needs to have virtualization that just works. Second, AD must be simple to deploy. Finally, AD must also be simple to manage.
AD Virtualization Now Just Works
Ensuring that virtualizing AD just works should be a great relief to many systems administrators, because even though the rules for a safely virtualized AD aren’t that difficult, the responsibility for it is spread across several teams. This means that keeping AD safe in a virtual world isn’t just a technical problem; it’s a people or organizational problem. And the consequences for screwing it up can be severe, as illustrated in the Microsoft article “USN and USN Rollback.”
What causes problems for AD before Windows Server 8 in a virtualized environment is that the AD distributed application isn’t aware of any virtualization-specific actions taken underneath it at the host level. Specifically, you can confuse AD and potentially induce an unhealthy condition known as USN rollback if you restore a DC VM from a snapshot or image backup. Why? Because a distributed application such as AD has more off-server dependencies than a single-instance application. When a DC has been restored from an image backup, it magically appears as though it’s from an earlier time—but in an incomplete manner because neither its partners nor the restored DC itself recognizes it.
In contrast, Windows Server 8’s “virtualization safe” AD technology ensures that a virtual domain controller (VDC) is able to detect when snapshots are applied or a VDC has been copied. Detection of these changes is built on what’s known as a VM generation ID (gen ID) to detect changes and protect AD, or take corrective measures. This requires changes to Hyper-V, and Microsoft is working with other virtualization vendors to make sure they include this technology in the latest version of their hypervisors as well. It’s in their interest to do so, because until then Microsoft has a competitive advantage in its own Hyper-V.
AD Domain Controller Cloning
The team’s second goal of making AD simple to deploy was made possible by the gen ID technology. Because of it, it’s easy to safely clone virtual Windows Server 8 DCs. From the administrator’s viewpoint, the process is pretty simple: You copy/paste/rename the source virtual DC’s .VHD disk file to create a second copy on disk. Relocate it to the destination folder you desire. Use Hyper-V Manager or Virtual Machine Manager to create a new VM, and associate the copied VHD with the new VM. Then, just start it up. There’s more that happens under the covers, of course; I’ll be describing more about this VDC cloning process in a future article.