Domain Controller virtualization solutions - Part 1

In this article we will show you the advantages and disadvantages of some common domain controller settings.

When it comes to building a virtual data center, there is probably no more controversial topic with the domain controller setup topic. Server virtualization has been around for a while and there have been some virtualization products, which is for many people to think that the basic principles for virtualizing network servers are probably well established. sure. All server virtualization has specific and concise instructions in most parts. That's why we don't just mention domain controller virtualization in our minds. However, there are many different philosophies about how to handle domain controllers in a virtualized environment. And there are actually many advantages and disadvantages associated with each of these different philosophies, so we decided to take this series to consider setting up domain controllers in a virtualized environment.

Now you might wonder why the topic of setting up domain controllers is such a controversial topic. We have heard of some people comparing complex domain controller setups like the question of 'previous ducks or eggs'. On the one hand, domain controllers will set up Active Directory structures that all other Windows servers follow, on the one hand, you need to create and configure virtual servers (usually Hyper-V or VMware servers). before doing everything virtualization. So you have to decide if your server needs to be a domain member. If you decide to turn your servers into a part of the domain, you must configure it to work in a certain way to make the network secure.

Separate the servers from the domain

One potential solution to the domain controller implementation problem is to separate the servers from the domain. In this domain model, the entire Active Directory forest will be virtualized, but the servers will reside in a workgroup outside the domain.

This domain controller model works quite well, especially in small organizations. In fact, when we decided to virtualize our production network, this is the domain controller implementation model that we choose to use. The basic reason behind our decision is that this model has allowed us to virtualize all our production servers. This makes it possible to move production servers from one server to another when needed.

Even so, this design work is not perfect. For us, the biggest problem we have encountered is also the result of using this model, which limits many options for network backups.

In our test network, we ran Hyper-V on all of our virtual hosts and used System Center Data Protection Manager 2007 (DPM 2007) as the backup solution. The problem is that DPM 2007 is quite dependent on Active Directory. That means that there is no option to join the DPM 2007 server into the domain. As a result, DPM 2007 has trouble backing up virtual machines, but we have no way to back up virtual hosts properly.

Another problem with separating virtual hosts from Active Directory is that almost all network management software extract information from Active Directory. Therefore, this type of design can limit your ability to manage virtual hosts by using other management software.

To give you an idea of ​​what we're saying, consider another aspect of network design. After we virtualized our production network, we decided to add a virtual host and use it to configure some testing machines. Although no testing machine is a member of the production domain, but the server is hosting test machines as a domain member.

As the network continued to grow, we decided to install System Center Virtual Machine Manager 2008 (SCVMM 2008) on the server hosting the test machines. You can see the screen captured from the SCVMM 2008 console in Figure A.

Domain Controller virtualization solutions - Part 1 Picture 1
Figure A: SCVMM 2008 cannot see other servers

Notice in the figure that the All Hosts section only lists one server, although there are many Hyper-V servers in the network. This behavior is a direct result of the fact that other servers are not domain members. SCVMM 2008 not only can't see other servers (or virtual machines reside in them) but you can't even install SCVMM 2008 on a non-domain server.

Create a separate domain

As you can see, ignoring virtual hosts from Active Directory works quite well for small networks, but this can lead to some management issues if the network grows and expands. There is another technique that allows us to solve most of those problems.

This technique involves setting up an Active Directory domain before deploying host servers. This domain exists only for the purpose of managing your virtual hosts. In this model, all of your production servers will be members of an entire Active Directory that are based on virtualized domain controllers.

This technique provides all the same advantages as separating servers from Active Directory, but allows you to take advantage of network management tools depending on the Active Directory database.

As is the case with all other domain controller implementation models that we will discuss, this model is not perfect. Make sure that you know, one of the main driving forces behind virtualization technology is to reduce hardware costs by making better use of server resources. This model does not accomplish that goal.

Having a separate domain for virtualized servers means that you will need at least one physical server to act as a domain controller. Of course, having a domain with only a single domain controller is a risky proposition, so in fact you will definitely spend two or more physical servers on service tasks as domain controllers.
Since the domain in question is created for virtual hosts only, it means that domain controllers for that domain will experience a very light load, which is impractical if your goal is to be good. more than your server hardware resources.

If you yourself want to use this domain model but are hard-pressed to justify the dedication of physical servers to perform tasks like domain controllers, then we recommend that you consider using the machines. The old owner you gave 'retired' before. As long as your old servers are still active and not obsolete, they will still be able to work as domain controllers for virtual hosts. It should be noted that, although you choose to reuse old server hardware, this model still requires you to purchase additional registrations required for the additional domain controllers you are deploying.

Conclude

So far, I have shown you two models that implement different domain controllers within a virtualized environment. However, there are many other implementation models that you can use, and we'll cover them in Part 2 of this series.