Solutions for Virtualizing Domain Controllers (Part 2)

If you would like to read the other parts in this article series please go to:

• Solutions for Virtualizing Domain Controllers (Part 1)
• Solutions for Virtualizing Domain Controllers (Part 3)
• Solutions for Virtualizing Domain Controllers (Part 4)
• Solutions for Virtualizing Domain Controllers (Part 5)
• Solutions for Virtualizing Domain Controllers (Part 6)
• Solutions for Virtualizing Domain Controllers (Part 7)

Introduction

Toward the end of my previous article in this series, I began discussing the possibility of creating an entirely separate Active Directory forest that can be used to manage your virtualization hosts. The advantage of using this technique is that it enables you to virtualize all of your production domain controllers, while still being able to use Active Directory dependent management tools.

Obviously though, there are some disadvantages to placing your virtualization hosts into a dedicated forest. As I alluded to in the previous article, one of the primary disadvantages is the infrastructure requirement. In other words, the dedicated forest will require its own domain controllers, its own DNS server, and it may also require other types of infrastructure servers such as patch management, antivirus management, or backup servers.

Another major disadvantage to creating a dedicated forest for your virtualization hosts is the fact that there is a disconnection between the virtualization forest and your production forest. Depending upon how your network is configured, this disconnect may prevent Active Directory information from being shared between the two forests. This can be especially problematic if you are using an Active Directory dependent backup solution and want to backup servers from both forests.

Even if the Active Directory isolation caused by using multiple forests isn’t an issue for you, the infrastructure requirements involved in creating an entirely separate forest for your virtualization hosts may have you wondering if taking this approach is worth the effort. Unfortunately, none of the strategies for virtualizing and organizations domain controllers are perfect. There are however some things that you can do to make this approach a bit more appealing.

One approach that you can take is to configure two physical servers to act as domain controllers for your production domain. You can then configure one of the two physical domain controllers to act as an Active Directory integrated DNS server.

Once you have completed this configuration, you can join your host servers to your production domain without having to worry about getting into the chicken or the egg paradox. You can safely virtualize all of your domain controllers, except for the two that you just set up. Of course this assumes that the forest in question only contains a single domain. Later in this series I will address multi domain virtualization models, but for right now I want to keep things simple by limiting my discussion to a single domain forest.

The rationale behind using this approach is that it protects you against host server failures (at least to some degree). Let us pretend for example that the two physical domain controllers do not exist, and that you have virtualized all of your other domain controllers. Depending upon how those domain controllers are hosted, you could potentially end up in a situation in which the failure of a host server causes your virtualized domain controllers to become inaccessible, therefore preventing anyone from logging into the network. Having two separate physical domain controllers ensures that users will still be able to log onto the network, even if the entire virtualization infrastructure were to fail.

Of course simply creating a couple of physical domain controllers alone is not quite enough. As you will recall, I mentioned that one of these two servers should be configured to act as a DNS server. So far we haven’t configured any of the other machines on our network to use it though. My advice is to treat this server as a secondary DNS server. That way, the hosts on your network can still make use of your primary DNS server. In the event that either your primary DNS server, or the hosts that it resides on fails, the physical DNS server can resolve DNS queries for your network until the situation is corrected.

Another issue that you will have to consider if you follow this approach is that of Flexible Single Master Operations roles. Windows 2000 Server and above make use of a multi master replication model, in which updates to the Active Directory database can be written to any available domain controller. Even so, some domain controllers are considered to be more important than others. Domain controllers that have been assigned flexible single master operation roles are responsible for maintaining the Active Directory’s integrity. For example, the domain controller that is holding the Schema Master role is responsible for maintaining the Active Directory schema. All schema changes must be written to this domain controller.

I don’t want to turn this article into an in-depth discussion on the various Flexible Single Master Operations roles and their functions, because there are already a number of articles on the site that discuss these roles in detail. I do however need to talk about flexible single master operations role placement within a virtualized environment.

As you may already know, there are two basic types of flexible single master operations roles; domain level roles and forest level roles. When you create an Active Directory forest, the first domain controller that you set up is automatically assigned all of the forest level roles, and all of the domain level roles for the domain that you are created. If you create additional domains within the forest, then the first domain controller in each domain is assigned the domain level roles for that domain.

With that in mind, let’s go back to our virtualization model in which two physical domain controllers are created, and all of the previously existing domain controllers are virtualized. Let’s also continue to assume that this model is being applied to a forest that only contains a single domain.

Since all of the previously existing domain controllers have been virtualized, it means that all of the flexible single master operation roles are being hosted on a virtual domain controller. Since the Active Directory cannot function for long without access to the domain controller to which these roles have been assigned, it is important to consider whether or not virtualizing this domain controller is a good idea.

In my opinion, there is no harm in virtualizing the domain controller that holds the flexible single master operations roles. Yes, the host server could potentially fail, bringing the domain controller down with it, but physical servers are also capable of failing.

The reason why I believe that it is safe to virtualize the domain controller containing the Flexible Single Master Operations roles is because the failure of this domain controller is not catastrophic (assuming that there are other domain controllers on the network).  As long as some domain controllers and a DNS server remain on your network, the Active Directory will continue to function normally for a while.

If the failure is such that recovering the domain controller is deemed to be impossible, then you can seize the flexible single master operations roles from the failed domain controller, and appoint the roles to a functional domain controller. It is this ability that leads me to believe that it is safe to virtualize domain controllers, even if they contain flexible single master operations roles.

Conclusion

In this article, I have discussed some of the merits of using physical servers to act as domain controllers, and I have talked about the safety of virtualizing domain controllers which have been assigned flexible single master operations roles. In Part 3 of this series, I will continue to refine this domain controller placement model, and talk about global catalog server placement.