Best Practices for Installing Active Directory Domain Controllers in a Virtual Machine

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.

Why should you virtualize Active Directory Domain Controllers?

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.

Reduce security risks

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.

Lower costs with hardware standardization

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.

Creating a safe testing 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.

Do you need to keep at least one physical domain controller?

There are reasons to retain a physical domain controller and only you can make this decision for your environment.

• If you are running really old Windows Server versions like Windows Server 2012 or earlier, then retaining a physical domain controller is the least of your problems (please replace them with a more recent version!).
• If you only have a single domain controller, then virtualizing it might not be in your best interest. I would strongly recommend running at least two domain controllers, even in a small environment, but your circumstances might justify a single DC. The next section covers this in more detail.
• You have a hardware dongle that requires a physical server.
• You’re using 3^rd party software which specifically doesn’t support a virtualized domain controller.

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.

Flexibility, even if you are only deploying one domain controller

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:

• You can lower the risk of patching.
• You can have a powered-off copy of your single domain controller which will aid you in case of a disaster. Make sure to keep this copy on a different hypervisor and storage, ideally a different physical location (office or data center).
• You can share the physical computer’s resources among multiple virtual machines.
• If you need to replace your single domain controller with a new one, then you can get the new one ready, transfer the Flexible Single Master Operations (FSMO) roles and other clean-up tasks, and decommission the old domain controller after completing your testing.

Virtualization Technologies

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

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.

Hyper-V requirements

The Hyper-V role can be installed on Windows Server and Windows 10. This article will focus on the requirements for Windows Server, but Windows 10 has similar ones.

At a minimum, make sure the following is covered:

• A 64-bit processor with Second Level Address Translation (SLAT). To install the Hyper-V virtualization components such as Windows hypervisor, the processor must have SLAT. However, it’s not required to install Hyper-V management tools like Virtual Machine Connection (VMConnect), Hyper-V Manager, and the Hyper-V cmdlets for Windows PowerShell. See “How to check for Hyper-V requirements,” below, to find out if your processor has SLAT.
• VM Monitor Mode extensions
• Enough memory – plan for at least 4GB of RAM. More memory is better. You’ll need enough memory for the host and all virtual machines that you want to run at the same time.
• Virtualization support turned on in the BIOS or UEFI:
  • Hardware-assisted virtualization. This is available in processors that include a virtualization option – look for Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) technology.
  • Hardware-enforced Data Execution Prevention (DEP) must be available and enabled. For Intel systems, this is the XD bit (execute disable bit). For AMD systems, this is the NX bit (no execute bit).

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:

<code>Systeminfo.exe</code>

You’ll see the following output if your system can run the Hyper-V role:

Do you need Windows Server with the full GUI?

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).

If you need to locally configure or manage a Windows Server Core instance, then PowerShell and Server Configuration (SConfig) are going to be your two best friends.

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.

Third-party virtualization solutions

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.

Type 1 Hypervisors

• VMware ESXi/vSphere
• OpenStack
• KVM
• Red Hat Enterprise Virtualization (RHEV)
• Citrix Hypervisor

Type 2 Hypervisors

• VMware Workstation Pro
• VMware Workstation Player
• VirtualBox
• Parallels Desktop

Domain Controller Prerequisites

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.

Decide how many virtualized domain controllers you need

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.

Decide where to place your domain controllers

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.).

Implement system redundancy to avoid potential single points of failure 

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.

Domain controller installation and configuration

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.

Virtualization deployment practices to avoid

Before you start deploying virtualized domain controllers, there are a couple of important things that we don’t recommend doing.

Do not deploy a virtual domain controller’s database files on virtual IDE disks

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.

Do not implement differencing disk virtual hard disks (VHDs) on a virtual machine being configured as a DC

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.

Prevent potential update sequence number (USN) rollbacks

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.

Do not perform physical-to-virtual (P2V) conversions on domain controllers

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.

Security best practices

How to secure the host computer on which virtual domain controllers run

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.

Why using Windows Server Core is recommended

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:

• Reduced maintenance: Windows Server Core is pretty naked out of the box, you get to install what you need. To be fair, the Desktop Experience version doesn’t install most roles and features either, but it comes with the overhead of the GUI. Take a look at the patches to fully understand how much easier your patch management will become with Windows Server Core.
• Reduced attack surface: As above, fewer patches translate to a more secure system, even though no system is 100% secure, especially given our interconnectivity. Anyway, there’s much less to protect, many malware apps won’t run because they will need some of the GUI components.
• Reduced management: while this also applies to the GUI version, Windows Server Core almost forces you to become more efficient with the Command Line (CLI) and PowerShell to keep your servers in line. Windows Admin Center also helps.
• Lower hardware demands: Windows Server Core will save you some disk space and RAM consumption. Multiply this by the instances you run and it might make a significant difference to your budget.

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.

Why you may want to use read-only domain controllers (RODCs)

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.

Why you need to secure the VHD file of a virtual domain controller

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.

Why time synchronization is important

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.

Don’t checkpoint virtualized domain controllers

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.

Disable time synchronization for virtualized domain controllers

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.

Don’t place domain controllers in a saved state

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.

Why storage and network optimization are important

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.

Best practices for storing operating system, Active Directory, and VHD files

Operating system and Active Directory storage

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.

VHD files storage

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.

Synthetic vs. emulated Network Adapters

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.

How to modify DNS weight and priority to reduce load

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.

Why do you need regular system state backups?

Apart from compliance and regulatory requirements, it is simply a good practice to regularly backup your critical systems.

Backup and restore practices to avoid

• Do not take or use a Snapshot of a virtual domain controller: As mentioned earlier, snapshots or checkpoints aren’t a problem. Reverting to them is, so please be cautious.

• Do not copy or clone virtual hard disks (VHDs): Duplicate servers pose a huge risk when cloning a domain controller’s VHD. You should be well aware of the consequences (replication errors, sleepless nights…). You should only do it in a very controlled environment, and for good reason.

How to back up a virtualized domain controller

The backup process of your virtualized Active Directory domain controllers follows the same principles that apply to their physical counterparts.

Use Windows Server Backup with Active Directory Domain Services

Take a look at my previous article on Petri on how to use Windows Server Backup on your domain controllers.

What does Microsoft’s Site Recovery provide?

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.

How to restore your virtualized domain controller

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 you have the system state backup of a virtual domain controller

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 a system state data backup is not available

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.

Conclusion

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.

Related Article:

• How to fix the “An Active Directory Domain Controller Could Not Be Contacted” Error
• How to add a new domain controller to an existing domain