Installing Active Directory domain controllers in a virtual machine (VM) can be useful if you want to separate them from the physical network, giving you more flexibility and additional protection for your Active Directory infrastructure. In this guide, we’re going to detail the best practices for installing Active Directory domain controllers (DCs) in a virtual machine.
Contrary to what you might have read over the past couple of years, on-premises Active Directory (AD) domain controllers are still widely used. Almost every project I have been working on, even the ones that are supposedly Greenfield, either included Active Directory in the design or required it to be added during the deployment phase because the requirements changed.
These domain controllers need to be hosted somewhere, and for many organizations, virtualizing them has become the default option.
As an engineer working in the nineties, I remember my days of trying to hunt down a rogue or missing server in a server room multiple times larger than my home. Having less hardware will give you a better oversight of your gear, even though you still need to document and label every single piece of kit.
A virtualized environment can make it easier to keep track of your servers and services. All of them should be clearly visible in Hyper-V Manager or alternative management tools.
In case of an intrusion or attack, rollbacks are also easier since you should already have the capacity to host the recovered and clean virtual machines.
Notice the occasional “should” in my articles. Leveraging virtualization technologies can look easy, but that isn’t always the case. You still need to plan properly, revise as you deploy, review, and repeat. This doesn’t ever stop, and it shouldn’t.
The fact that we can host multiple virtual machines on a physical computer allows for those physical computers to be optimized, both in terms of cost and availability. Even two hypervisors will enable you to increase your availability to a level that might be sufficient for your environment.
If you have been one of the many IT pros who had to deploy patches to production environments without the ability to test them beforehand, then you will greatly appreciate the ability to clone your active domain controllers, isolate the clones, patch the living hell out of them, and subsequently test and re-test until you are fully satisfied. Then, you can repeat these steps with your production domain controllers.
There are reasons to retain a physical domain controller and only you can make this decision for your environment.
If you find yourself in any of the above categories, then you should at the very least consider reviewing your organization’s IT infrastructure so you can be aware of the inherent risks inherent to your IT structure.
If you only operate a single production domain controller, then virtualizing it can still benefit you. Some of them are covered in more detail in the previous section:
While there are many virtualization technologies on the market, this article will mainly focus on Microsoft Hyper-V, its requirements, and what to consider regarding the need for a GUI or not.
Hyper-V is Microsoft’s hardware virtualization product. It lets you create and run a virtualized version of an operating system, called a virtual machine.
Each virtual machine acts like a complete computer, running an operating system and programs. When you need more computing resources, virtual machines give you more flexibility, help you save time and money, and are a more efficient way to use hardware than just running one operating system on physical hardware.
Hyper-V runs each virtual machine in its own isolated space, which means you can run more than one virtual machine on the same hardware at the same time. You might want to do this to avoid problems such as a crash affecting other workloads or to give different people, groups, or services access to different systems.
At a minimum, make sure the following is covered:
As a general rule, decide what your workload is going to be before going to the next step. I always separate production from everything else (dev, test, UAT, training, etc.).
If your workload is going to include production, then make sure you follow the official system requirements for Hyper-V on Windows Server. Also, consider procuring yourself certified hardware and a support contract to eliminate another possible headache down the road because nobody wants sleepless nights over incompatible gear.
If you already have hardware in place, then you can easily check its compatibility by running the following command and scrolling down to the Hyper-V Requirements section:
You’ll see the following output if your system can run the Hyper-V role:
If your main goal is to use your server as a hypervisor then you should not need to install Windows Server with Desktop Experience. Windows Server Core comes with a smaller footprint (less RAM and CPU overhead as well as a saving in required disk space), fewer security updates (because there isn’t as much to patch), and a significantly reduced attack surface (see the Security Best Practices section below).
This is especially helpful during the initial deployment and troubleshooting. Remote configuration and management are easily and securely done via Windows Admin Center, Server Manager, and other tools. Please see Microsoft’s Manage a Server Core server support page for further information.
There is a great choice in alternative virtualization solutions on the market. Typically, they are divided into bare metal (type 1) and hosted (type 2) hypervisors, and both categories have their advantages and disadvantages. Type 1 runs directly on the hardware, whereas type 2 runs on top of an operating system like Windows or Linux.
Remember: You need to choose a solution that’s good, fast, cheap. Pick at least two of them. Then get your ideal plan on a piece of paper and revise it until you feel ready to commit to it.
Virtualized domain controllers have the same limitations as physical ones, so make sure that you cover Microsoft’s recommendations on capacity planning and be aware of the limits. An essential question that you will need to answer before promoting the first server to a domain controller is how many domains you will need to operate within your forests and if a single forest is sufficient (usually it is, but it will depend on your unique requirements).
If the answer to this question is one domain, then your environment might only require only one or two domain controllers (see below for redundancy). If you need multiple domains, then you will need at least one domain controller per domain.
As above, this will depend on your environment: For a small single-office location, all your domain controllers might be placed in a small comms room or half-rack in the corner. If your workforce is distributed across multiple locations, then at the very least the larger ones might need their local domain controllers.
Also, you need to consider placing dedicated domain controllers in sites with slow or unreliable connectivity, or places where potential regulatory issues can cause Internet connectivity to be halted (China, Russia, etc.).
For a production environment, even a small one, the absolute minimum should be two domain controllers, ideally in different locations. Even placing domain controllers on opposite ends in an office is better than having them on top of each other.
The same applies to the underlying host: You shouldn’t keep all your domain controllers on a single hypervisor because if you lose this one, then your whole domain will go down.
Installing and configuring Active Directory and deploying additional virtualized domain controllers isn’t significantly different from running them on bare metal. Please see our previous guides: How to Install Active Directory in Windows Server 2019 (Server Manager) and How to add Windows Server 2022 as a domain controller for detailed information.
Before you start deploying virtualized domain controllers, there are a couple of important things that we don’t recommend doing.
While this is not a problem when deploying Active Directory on recent Windows Server versions, this used to be a big deal during the Windows Server 2008-2012 era. Microsoft recommended against the use of virtual IDE disks to prevent a loss of consistency with IDE-attached virtual hard disks when a Hyper-V host server experiences an unplanned restart. The company issued a hotfix to rectify this issue.
Microsoft still recommends placing your Active Directory database (NTDS.DIT), logs, and SYSVOL on a virtual SCSI disk. Please see Microsoft’s Virtualization deployment practices to avoid support page for more details, and I strongly recommend that you follow their guidance.
You should avoid implementing differencing disk virtual hard disks (VHDs) on a virtual machine that you are configuring as a domain controller. This makes it too easy to revert to a previous version, and it also decreases performance.
To help prevent a potential update sequence number (USN) rollback situation, do not use copies of a VHD file that represents an already deployed domain controller to deploy additional domain controllers. For more information about USN rollback, please see Microsoft’s USN and USN rollback support page.
Adding a new domain controller or replacing an existing one, especially within a domain, is easy. You can even keep the server name and IP address.
You can either move the services like DNS, DHCP, and FSMO roles to an already existing domain controller, or create a temporary domain controller that will hold these services and roles while you decommission the original DC and replace it with a new one that will get the name and IP address of its predecessor. It sounds a bit convoluted, but it works.
Should you really need to run a P2V conversion, then please make sure that you take your domain controller offline. You don’t want to poison your Active Directory with a duplicate domain controller instance since dealing with replication errors and a possible tombstone situation isn’t how you will want to spend your night or weekend.
Please see Microsoft’s Determine the tombstone lifetime for the forest support page to determine your tombstone lifetime (TSL). Your specific TSL will depend on your first-ever installed domain controller, unless you have manually changed it. The different Windows Server versions default value varies from 60 to 180 days, and Microsoft recommends that you set it to 180.
First of all, remember that your Hyper-V servers are just additional Windows servers. They’re actually very special ones that host many, if not all of your business-critical systems.
As a result, there’s no reason for these Hyper-V servers to not be managed by your Active Directory, Group Policy Objects (GPOs) for identity, access, as well as patch management, etc. There’s nothing stopping you from treating your hypervisors as standalone servers either, just be aware of the trade-offs for both categories.
Let’s get the obvious out of the way: Windows Server Core should be your default choice unless you have a good reason to use the full GUI (Windows Server with Desktop Experience) version of Windows Server. One such reason is application incompatibility, but that doesn’t apply to running a domain controller on Server Core.
Server Core has many advantages:
Take a look at Petri’s Configure (promote) Windows Server 2022 as a domain controller with PowerShell article to see how little is involved in creating a new forest or adding an additional domain controller to your existing domain. Moreover, we recommend checking out our detailed guide on how to install Hyper-V on Windows Server Core.
Read-only domain controllers (RODCs) mainly find use in your branch offices. Typically, your head office and larger locations would have full (writeable) domain controllers, and your smaller offices and locations would get RODCs.
Another argument for read-only domain controllers is locations with lower physical and IT security: Your branch offices and smaller sites will not necessarily have the same level of protection as your head office or larger locations do.
Since read-only domain controllers store only a part of your Active Directory database (it will cache whatever requests it gets from that location’s user base), this leaves your full Active Directory database protected from a potential attack, especially if a bad actor was to gain physical access to your RODC.
A VHD/VHDX file is essentially the equivalent of your computer’s hard disk. While gaining ownership of this “virtual hard disk” doesn’t necessarily give a bad actor access to its content, it certainly gets them closer to their nefarious goals.
You need to make sure that you have adequate storage protection in place. If you store your VHDs locally on your hypervisors, then ensure that the underlying storage is encrypted.
The same applies to remote storage like SANs and NAS devices: Each vendor will have their individual recommendations and options, so make sure you familiarize yourself with them. And don’t forget to look at protecting the connection between your hypervisor and your storage.
Modern hypervisors have the ability to synchronize their time with their hosted virtual machines. The hypervisor becomes the time source for all its hosted virtual machines.
Some hypervisors like Hyper-V enable time synchronization by default but others don’t, so make sure you familiarize yourself with how your hypervisor of choice handles time synchronization.
Most of this section can lead to replication errors and dealing with them is never any fun. I remember spending a fair few nights and weekends on-site trying to recover an Active Directory, and you will never get that time back.
If your environment has only one domain controller, then feel free to use checkpoints on your single DC. In all other situations where you have multiple domain controllers, I strongly suggest you don’t use checkpoints.
The primary problem isn’t the creation of the checkpoint, but what can happen if you revert one of your domain controllers: Because your other DCs might not be aware of this change, this can easily lead to a corrupted Active Directory database. I will add this link about USN and USN Rollback a second time because it is critical to a healthy Active Directory.
Microsoft has addressed this issue and made improvements in the more recent versions of Windows Server, but there’s no guarantee that you will not get to spend a night or whole weekend recovering your Active Directory. There’s more on backups later in this article.
In Hyper-V Manager, navigate to the settings of your virtualized domain controller and select Management – Integration Services. Untick the Time synchronization box to ensure that this domain controller doesn’t receive time from the hypervisor and the Active Directory time master server (typically the domain controller holding the PDC Emulator role).
You can also take a look at this excellent Microsoft TechNet article on Active Directory time synchronization.
Placing domain controllers in a saved state isn’t a problem per se, but it can become one if you keep them in a saved state longer than your tombstone lifetime setting. Consider shutting down a domain controller that you need to take out of production, even if this happens to be a temporary change. This only works if you have an adequate amount of domain controllers in your environment, so make sure that you plan according to your needs and budget.
As so very often, your ideal choices will depend on your environment. In a small Active Directory with a few dozen users, your lightweight domain controller’s disks and network connectivity won’t have that great of an impact. In a large enterprise with hundreds of thousands of users spread across the globe and dozens of domain controllers and RODCs, it suddenly becomes extremely important.
Your capacity planning steps will include mapping out your users’ behavior (e.g., do you have 25,000 users logging on between 08:00 and 09:00 every workday), their location (which might require internal or external networking connectivity to be upgraded), firewalls to be replaced, and downtime windows, which might leave you with a single point of failure at an important location.
I recommend you to spend as much as you can justify, keep your estimated growth in mind and consider adding another 25% on top, just in case.
It’s recommended to store the Active Directory database file (Ntds.dit), log files, and SYSVOL files on a separate virtual disk from the operating system files. Create a second VHD attached to a virtual SCSI controller and store the database, logs, and SYSVOL on the virtual machine’s virtual SCSI disk.
Virtual SCSI disks provide increased performance compared to virtual IDE disks, and they support Forced Unit Access (FUA). FUA ensures that the operating system writes and reads data directly from the media bypassing any and all caching mechanisms.
For maximum performance, do not store VHD files on a disk that is used frequently by other services or applications, such as the system disk on which the host Windows operating system is installed. Store each VHD file on a separate partition from the host operating system and any other VHD files. The ideal configuration is to store each VHD file on a separate physical drive.
Hyper-V supports synthetic and emulated network adapters in virtual machines, but the synthetic devices offer significantly better performance and reduced CPU overhead. Each of these adapters is connected to a virtual network switch, which can be connected to a physical network adapter if external network connectivity is needed.
Follow the recommendations in this section to optimize the network performance of guest operating systems running in a Hyper-V virtual environment.
All new domain controllers have the same default weight (100) and priority (0). For most environments, this doesn’t need to be modified. You might have a few domain controllers that can handle more authentication requests than others or you might want to designate a group of DCs to handle requests from specific applications.
Be careful with these changes, your DNS servers might return only a few or even a single domain controller to your clients if you misconfigure the weight or priority. Take a look at Microsoft’s Reducing the workload on the PDC emulator master support page for further information.
Apart from compliance and regulatory requirements, it is simply a good practice to regularly backup your critical systems.
The backup process of your virtualized Active Directory domain controllers follows the same principles that apply to their physical counterparts.
Take a look at my previous article on Petri on how to use Windows Server Backup on your domain controllers.
Microsoft’s Azure Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Azure Site Recovery replicates workloads running on physical and virtual machines from a primary site to a secondary location. When an outage occurs at your primary site, you fail over to a secondary location and access apps from there. After the primary location is running again, you can fail back to it.
This will depend on your backup approach: As a general rule, keep track of your Active Directory database history and make sure you don’t overwrite good information with an outdated backup. Documentation is your friend, always remember that!
If a valid system state backup exists for the domain controller virtual machine, you can safely restore the backup by following the restore procedure prescribed by the backup tool that you used to back up the VHD file.
Take a look at Microsoft’s Restoring the system state backup of a virtual domain controller support page for further information and a step-by-step guide.
If you do not have a system state data backup that predates the virtual machine failure, you can use a previous VHD file to restore a domain controller that is running on a virtual machine. If you can, make a copy of the VHD, so that if you encounter an issue during the procedure or miss a step, you can try again with the copied VHD.
Take a look at Microsoft’s Restoring a virtual domain controller when an appropriate system state data backup is not available support page for further information and a step-by-step guide.
IT security is hard and never-ending, but I hope you’ll be able to make good use of these best practices for installing Active Directory Domain Controllers in a virtual machine. The heavy lifting still needs to be done by you and your team of colleagues, customers, and suppliers, but in the end, it is unavoidable.