Solutions for Virtualizing Domain Controllers (Part 7)

by [Published on 5 Jan. 2011 / Last Updated on 5 Jan. 2011]

This article concludes the series by talking about some considerations for virtualizing domain controllers on larger networks and the best practices that have been discussed throughout this series.

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

So far in this series, I have discussed the pros and cons of many different mixtures of physical and virtual domain controllers. In this article, I want to conclude this series by talking about some considerations for virtualizing domain controllers in multi domain environments.

When dealing with a multi domain, or even a multi forest network, the considerations for the placement of domain controllers are similar to that of much smaller networks. In fact, you can easily construct a multi domain network by building on the concepts that I have discussed earlier in this series.

When you virtualize the domain controllers on a multi domain network, the biggest thing that you have to remember is that some domain controllers are more important than others, and their location therefore requires a bit more consideration than you might give to a less important domain controller.

The first issue that you must consider is that of FSMO roles. There are both forest level and domain level FSMO roles. The first domain controller that is brought online in a new forest contains both forest and domain FSMO roles. As you create additional domains, the first domain controller created within each domain contains the FSMO roles for the domain.

Another consideration is that of global catalog servers. In a single domain network, you can make every domain controller a global catalog server. In larger networks however, you must have at least one global catalog server in each Active Directory site.

Finally, you must take your DNS server’s location into account. Since the Active Directory cannot function without a DNS server, you should configure at least two domain controllers to function as DNS servers and strategically locate those domain controllers on your network.

Active Directory Sites

One concept that seems to throw some administrators a curve ball in a virtualized environment is that of Active Directory sites. Sites are an Active Directory structure that is designed to help to reduce the volume of replication related traffic flowing across slow WAN links. Some administrators seem to not know what to do with the site structure in a virtualized environment.

As I’m sure you probably know, every Active Directory forest contains a default site. If you want to create additional sites, you must designate one domain controller in each site to act as a bridgehead for the site. Sites are joined together by creating a site links between bridgehead servers.

I have seen at least a couple of networks in which the administrator designed the site structure so that each host server essentially became a separate site, and all of the servers residing on a host server became a part of that site.

The idea behind this design is that high capacity host servers are often capable of hosting many different virtual machines simultaneously, but typically do not have enough physical NICs to dedicate a NIC to each individual virtual server. Treating each host server as a separate Active Directory site can help to minimize the amount of replication and authentication traffic flowing across the server’s physical network adapters.

Although I can see how using this approach to Active Directory site placement could be warranted in some situations, I believe that this approach is usually overkill. Unless you have a very large number of virtual servers residing on each host server and the server also has a shortage of physical NICs, you are usually going to be better off designing your site structure so that the site structure mimics your WAN topology, and does not take your host server topology into account.

So is there any harm in designing your site structure around your host servers? Not really. However, one of the advantages to server virtualization is that virtual machines are portable. If you end up having to move a virtual server from one host server to another, you may end up having to change the server’s site membership. More importantly though, each Active Directory site is usually linked to one or more subnets. You could create a separate subnet for each host server, but if you take that approach then moving a virtual server from one host server to another will require you to change its IP address to match the subnet of the new host. Depending on the server’s role, there can be consequences to changing a server’s IP address.

Some Final Thoughts

Throughout this article series, I have described a number of different strategies for virtualizing domain controllers. So which strategy should you use? Well, there really isn’t a one size fits all strategy. You have to do what is right for your own individual organization. Having said that, however, I do have some of my own best practices that I would like to share with you.

For starters, there is nothing wrong with virtualizing all of your domain controllers if that is what you want to do. If you do decide to virtualize all of your domain controllers, then I would recommend that you avoid joining your host servers to a domain. If you should ever have a massive power failure that brings down all of your servers, then you may find that you are unable to log on to your host servers after the power comes back on, because no domain controllers are available.

Another bit of advice that I want to give you is that you should think about reliability when deciding whether or not to virtualize your domain controllers. I recently heard someone say that you shouldn’t virtualize all of your domain controllers because you need something to fall back on if your virtualization software fails.

This statement makes it sound as though virtual servers are unreliable. In my opinion, if a technology is unreliable, then it has no business being used on a production network in the first place. Having said that, server virtualization technology has been around for many years now, and the major players offer mature virtualization platforms that are both stable and reliable.

In some cases, you may find that virtual servers are even more reliable than physical servers. For example, both Microsoft and VMware provide fault tolerant mechanisms for virtual servers. In Hyper-V for instance, you can create a failover cluster that will continue to run even if one of the cluster nodes fails. In contrast, you will not usually find this level of redundancy on a physical domain controller. As such, a virtual domain controller could conceivably be more reliable than a physical domain controller.

Although virtual domain controllers can be configured to be more reliable than a non-redundant physical domain controller, you do have to be smart about domain controller placement. For instance, you shouldn’t place all of your virtual domain controllers onto a single host server, because if that host fails then no domain controllers will remain online.

Just as you shouldn’t place all of your domain controllers onto a single host server, you should also avoid configuring your network in a way in which the failure of a single host server could cause a major outage. For instance, you wouldn’t want to locate all of your DNS servers or all of your global catalog servers on a single host server.

Conclusion

As you can see, there isn’t anything especially mystical about deciding whether or not to virtualize your domain controllers. Although it is perfectly acceptable to virtualize any or even all of your domain controllers, you do have to be smart about locating any virtual domain controllers.

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

Advertisement

Featured Links