Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 3 – Virtual DCs and AD File Placement
In the first part of this series on Active Directory considerations in Azure Virtual Machines and Virtual Networks we took a look at Hybrid IT and how Hybrid IT can solve some important problems in your datacenter. In the second part of the series we took an overview of key Azure Virtual Machines and Virtual Networks concepts and capabilities. In this installment, part 3, we’ll examine whether it is safe to host domain controllers in a virtualized environment and where you should put the Active Directory related database and supporting files.
If you haven’t read the first two parts of the series, check these out:
- Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 1 – Hybrid IT
- Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 2 – Azure Virtual Machines and Virtual Networks Basics
Let’s start the discussion today with safety concerns regarding virtualizing domain controllers.
How safe is it to Virtualize Domain Controllers?
If you’ve been in the virtualization space for a while, you probably know that there are issues with virtualizing domain controllers. Many of us have virtualized domain controllers in the past only to feel the pain of something going wrong and either cratering our domains or creating a lot of problems we wish we had avoided.
For example, we know that backing up and restoring domain controllers can roll back the state of the domain controller and lead to issues related to inconsistencies in the Active Directory database. When it comes to virtualization, restoring snapshots would have the same effect as a restoring from backup – the previous state would be restored and lead to Active Directory database inconsistencies. The same effects are seen when you use more advanced technologies to restore a domain controller, such as using SAN snapshots and restoring those, or creating a disk mirror and then breaking the mirror and using the version on one side of the mirror at a later time.
The issue here is USN bubbles. USN bubbles can create a number of issues, including:
- Lingering objects in the Active Directory database
- Inconsistent passwords
- Inconsistent attribute values
- Schema mismatch if the Schema Master is rolled back
- Potential for duplicated security principles
For these reasons and more, you want to make sure that you avoid USN bubbles.
Note:
For more information on USN bubbles, check out How the Active Directory Replication Model Works.
Virtualization makes it all too easy to create a USN bubble scenario and therefore the general recommendation has been that you should not virtualize domain controllers. However, with the introduction of Windows Server 2012, it is now fully supported to virtualize domain controllers. This is accomplished by a new feature included in the hypervisor which is called the VM Generation ID. When a domain controller is virtualized on a supported virtualization platform, it will wait until replication takes place to be told what to do. If the virtualized DC is one that was restored from a snapshot, it will wait to be told what the correct state is.
Note:
For more information on VM Generation IDs, please see Introduction to Active Directory Domain Services Virtualization.
It’s important to note that VM Generation IDs need to be supported by both the hypervisor and the guest operating system. Windows Server 2012 Hyper-V and the Windows Server 2012 operating system acting as a guest supports VM Generation IDs. VMware also supports VM Generation ID when running Windows Server 2012 domain controller guests. At this time, Azure Virtual Machines and Virtual Networks does not support VM Generation ID, although that may be a function of the current customer preview offering. Make sure to check for updated guidance on Azure support for VM Generation ID support after the service becomes generally available.
When creating a domain controller in Azure Virtual Machines and Virtual Networks, make sure that you either create them new and place them in a Virtual Network, or use one that you created on premises and move it to an Azure Virtual network. You don’t want to sysprep domain controllers, mostly because it won’t work – sysprep will tell you that it won’t sysprep the domain controller because it detects when that’s being done.
Instead, move the VHD file to Azure storage and then create a new virtual machine using that VHD file. If your on premises domain controller is running on physical hardware, then do a physical to virtual conversion and move the resultant .vhd file to Azure storage and create the new virtual machine from that file. You also have the option to create a new domain controller in Azure Virtual Machines and Virtual Networks and enable inbound replication to the domain controller. In this case, all the replication traffic is inbound, so it won’t cost you any money for traffic costs for the initial inbound replication, but it will cost you in the future for outbound replication. More on that later in this series.
Where Should I Place Active Directory Related Files?
Azure supports two disk types where you can store information for virtual machines:
- Operating System Disks (OS Disks) – used to store the operating system files
- Data Disks – used to store any other kind of data
There is also a “temporary disk”, but you should never store data on a temporary disk because the information on the temporary disk is not persistent. It is primarily used for the page file to speed up the boot process.
The difference between a data disk and an OS disk relates to their caching policies. The default caching policy for an OS disk is read/write. The way this works is that when read/write activity takes place, it will first be performed on a caching disk. After a period of time, it will be written to permanent blob storage. The reason for this is that for the OS disk, which contains (hopefully) only the core operating system support files, the reads and writes will be small. This makes local caching a more efficient mechanism than making the writes directly to permanent storage. Also something else to be aware of is that the OS Disk size limit at this time is 127 GB, but again, this may change in the future.
The default caching policy for Data Disks is “none”, which means no caching. Data is written directly to permanent storage. Unlike OS Disks, which are currently limited to 127 GB, Data Disks currently support 1 TB. If you need more storage for a disk, you can span up to 16 disks for up to 16 TB, which is available as part of the current Extra Large virtual machine’s disk offering. Note that this is the current maximum disk size and that this might change in the future.
With all this in mind, think about where you would want to place the DIT/Sysvol location. Would it be where caching could lead to a failure to write, or would it be where Active Directory related information is immediately written to disk? If you said the latter, you’d be correct.
The main reasons for this is that write-behind disk caching invalidates some core assumptions made by Active Directory:
- Domain controllers assert forced unit access (FUA) and expect the I/O infrastructure to honor that assumption
- FUA is intended to ensure that sensitive writes make it to permanent media (not temporary cache locations)
- Active Directory seeks to prevent (or at least reduce the chances) of encountering a USN bubble situation
For more information related to Active Directory and FUA, please see Things to consider when you host Active Directory domain controllers in virtual hosting environments.
Summary
In this article we took a look at issues related to the safety of putting a domain controller in a virtual environment and where you should put the Active Directory related files. The conclusion is that improvements in Windows Server 2012 and Hyper-V in Windows Server 2012 make it possible to host domain controllers safely in a virtualized environment. And while these improvements are not currently available in Azure, it is hoped that they will someday be ported to the service and that you should keep a lookout on support documentation to see if this is implemented. When it comes to placement of Active Directory related database and supporting files, the conclusion was to put them on a Data Disk, so that information is immediately written to permanent media. The next installment of this series will cover issues around optimizing your deployment for traffic and traffic related costs. See you then! –Tom.
HTH,
Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder
