Virtualizing your Domain Controllers

I am asked all the time what the best practices are for domain controllers in a virtualized environment.  There are several that I will call out, but let’s begin with the simplest rule.

You should never have ONE domain controller.

This rule is not only true in virtualized environments, it is always true.  If you are too small to have a domain that is fine, but if you have a domain you should have two DCs.  If you run Windows Small Business Server that rule is just as true – join a second server to the domain and promote it.  YES IT DOES WORK, please don’t argue it again! Smile

You can absolutely virtualize your domain controllers.

I hear this question from people all of the time… and the reality is that there is nothing wrong with virtualizing your DCs.  If the main concern is the Time Synchronization issue, then there is a simple answer for that.  Your Active Directory domain resources will not be able to authenticate if the time is off by more than 300 seconds (5 minutes).  However that skew is from the domain, and not your wrist watch.  If your radio says it is 3:15pm and your domain says that it is 10:38am, the only thing that matters is that your network resources think that it is between 10:34 and 10:42. 

In simple terms, if one time resource is off it is bad… if ALL of your time resources are off, it’s not.  This theory may fall down with external resources – I have noticed that Twitter (or at least many Twitter clients) are sticklers for time, and if you are off then you will not be able to authenticate.  Lync can also be an issue, and I am sure there are dozens of other externally provided services that will cause issues.  However internally as long as your client and your server have the same wrong time, you’ll be fine.

So with that being said, my tendency is to select one domain controller and configure it to synchronize with an external time server.  I will then create a GPO in my domains to use that server as the authoritative time source for the entire network.  That prevents all manner of things from going wrong if you find the time is off.

Your Domain Controllers should be just that… and not much else!

Your DC should not be a file server, database server, media server, deployment server, update server… there are only three services that my domain controllers generally perform: Active Directory Domain Services, Domain Naming Service (DNS) server, and Distributed Host Configuration Protocol (DHCP) servers.  In my networks these three services go together nearly all of the time.  I don’t know of any good reason to put anything else on a domain controller, and every time someone says ‘Well what about…THIS?’ I disagree.

Of course, sometimes you don’t have a choice… Windows Small Business Server is a good example of that, but as you have likely heard me say before, SBS out of the box forces you to break a lot of rules that are simply not meant to be broken.  If you ever hear me discuss it I have said there are ways to make it more palatable… but that does not change the facts.  This is one reason I always tell my classes that it is easier for an enterprise administrator to adapt to small business IT than it is the reverse… the good habits of the enterprise admin will never hurt the SBS (although they may be considered overkill); some of the habits of small business IT Pros can, conversely, do serious damage to the enterprise IT environment.

Don’t P2V your domain controllers.

This rule is not as clear-cut as the others, but calls on some of them.  I do not believe in performing physical to virtual (P2V) migrations of domain controllers.  If an organization does have a physical domain controller that they would like to retire, I feel the following is a much safer and cleaner practice:

  1. Before you begin (as much as 10-14 days in advance) I will reconfigure the DHCP scope on the server in question to shorten the address length from whatever is currently in place (by default 8 days) to 1 hour.  This will prevent or at least minimize problems later on.
  2. When you are ready, create a new virtual machine and install the operating system.  Make sure you patch it to the most recent service pack, and apply all applicable critical and security patches.
  3. Join the new server to the domain, and promote it to domain controller.  Assuming you are on Windows Server 2008 R2 Service Pack 1 (which you should be by now!) you need to install the Active Directory Domain Services role, but the dcpromo.exe command will do that for you.
  4. After the server reboots, it will begin to synchronize with the Active Directory.  Remember, since AD is a distributed database, when you add a new server to the mix it will simply (over a period of time directly related to the size of your organization, factoring for network bandwidth issues) receive a complete copy of the AD that will be identical (upon completion) to the original server.  DNS will do the same thing, as long as you a) install the DNS role when you promote the server, and b) your DNS Zones are configured as Active Directory Integrated.
  5. Install and configure the DHCP Server role in the new domain controller.  If you have room to grow with your IP addresses I would recommend creating a completely different scope, but if you are tight then creating an overlapping scope will only cause very temporary headaches, most of which will be mitigated by doing this switchover during off-peak hours.  Remember to copy any reservations from the original server, especially when you have devices (such as printers) that require specific addresses.  Also, do not forget to verify that all of your Scope Options are properly configured.
  6. Stop the DHCP Server service on the original server (net stop “DHCP Server”).  Again, If your scopes are overlapping be sure to do this during off-peak hours.
  7. If the physical box held any of the Flexible Single Master Operations (FSMO) roles then you should transfer them to the new server, or to another domain controller in the organization.  If you forget to do this they can later be seized, but this is the easiest and least intrusive way of doing it.
  8. You can leave your source DC on for a week or two, but after a day or so I would usually power it down; don’t reformat it or throw it out just yet, but at this point you are ready to go!

One of the rules of P2V Migrations is GIGO: Garbage In, Garbage Out.  In other words, any legacy issues you may have had previously – whether it’s clutter, breaks, bugs, or whatnot – goes with you.  With the distributed database replication model of Active Directory you get to start fresh, with all of your data. 

This method is also a great way of upgrading a DC from Windows Server 2003 to Server 2008 R2 – rather than do an in-place upgrade, you can simply do the side-by-side virtualization dance.  It won’t change your schema or upgrade your Domain (or Forest) Function Level, although if it is the first 2008 R2 domain controller in your domain you will have to run a couple of scripts to prepare the domain by running the following commands:

(On the server that holds the Schema Master FSMO role): adprep /forestprep

(On the server that holds the Infrastructure Operations Master FSMO role): adprep /domainprep /gpprep

That’s about it… as I mentioned, there may be exceptions if your DC is doing something that (according to my guidelines) it is not supposed to be doing, but then again this may be a great opportunity for you to step in line with best practices and separate other roles from the domain controller.

No go forth and virtualize your Active Directory Domain Controllers!

Advertisements

13 thoughts on “Virtualizing your Domain Controllers

  1. Pingback: SOA, Cloud and the network–part 1 « The Puchi Herald: A.I. Tech Update

  2. “This is one reason I always tell my classes that it is easier for an enterprise administrator to adapt to small business IT than it is the reverse… the good habits of the enterprise admin will never hurt the SBS (although they may be considered overkill); some of the habits of small business IT Pros can, conversely, do serious damage to the enterprise IT environment.”

    I would say the reverse is more true Mitch. An Enterprise ITPRO will typically treat an SBS install’s services as totally separate systems – not taking into account the integration that exists and is automatically managed by the Wizards that SBS contains, Thus breaking things the first time they make a change on SBS ‘for the better’.

    An SBS wise ITPRO will work with a wisened eye on an Enterprise install because they are aware of the integration they no longer have – vs. the Enterprise ITPRO we see coming into the SMB area who are not even aware of the integration in many cases.

  3. “You can absolutely virtualize your domain controllers.”

    I thought the greater issue with virtualized DC’s was the problem of restoring from a backup if required – compounded by the fact you now have more than one DC on the network?

  4. I’d like to consider an SBS server, which is also, as is the standard with SBS, the mail server and file server for a business. Now let’s say that business goes to the expense of deploying more hardware for a second domain controller. I completely agree that it does work. However, what is the gain? Once that SBS server goes down, there is no access to data, and the business is offline. What’s the value of being able to say the domain is online?

    • Hi Josh. While SBS is certainly a special case, I have seen many organizations that have multi-server SBS environments… the file server might be on a NAS device, and the mail server could be in the cloud.

      With that being said, the benefit to having multiple domain controllers in an SBS environment are several. If your SBS box goes down completely for a few hours the users would still be able to authenticate and work on anything that was not in the SBS box.

      My biggest reasoning behind having a second DC in the SBS environment would be around virtualization… makes it a bit easier 🙂

  5. I don’t entirely agree with the advice here. It does sound a little like the person who wrote it has done too much reading and not enough network infrastructure. More than one dc? Really? Are you serious talking of a business of 25 people, running on a tight budget, that they spend 1000 or so on a server just to replicate? And what if the AD database becomes corrupt, this could be months before you notice, replication would have taken place and now you have to rebuild anyway. So no, nice advice, but in the real world, in a small business, one DC with system state backed up will suffice. Only run DC on a server? Are you serious? On the whole domain controllers don’t actually do a lot, they authenticate, replicate, but once the log on/log off process has taken place they sit there, till the next replication. wow! what a waste of resources! contrary to belief dhcp and dns don’t require a lot. And what if you virtualise the other roles anyway? You still have it all running on one system, so whether it’s virtualised or not the effect is the same. Snapshots are great, but if the mainboard fails the system fails – virtual or not.

    I recently went in to rebuild a network than had one server running ad, dhcp, dns, file server etc for over 200 people. Not one person ever complained the network was slow – this server was running 4gb of ram! I simply added another server and shared resources. In this example I did replicate, and there’s the problem, I only have two servers both acting as dc’s, I have to put the other roles somewhere! – even if I have a san attached it will still run through the server.

    More than one server is great. Replication is great. Virtualisation is great. But budgets come first.

  6. Pingback: Best Practices About SMB IT | The World According to Mitch

  7. Hi Mitch

    Thanks for the reply 🙂

    I must confess my understanding of large scale networks are limited (I think the most users I’ve had is around 1000 on a network) so you are correct in seperating the two. To the best of my knowledge MS are flawed here, as they write plenty of material in blanket statement fashion detailing correct network infrastructure, yet I’m sure you agree a network for 100 people is designed a lot differently than a network for 10,000. Maybe MS should acknowledge this as well?

    I agree with you on the issues of a dc running as a file server as well. And I would never recommend any business network – however small – uses the 192.168 range.

    What you say about monitoring the network is indeed true but in my defence, often I am called in to set a network up and that’s it. Often someone will know someone who knows a little about IT and to save on cost they will use them for day to day IT maintenance to avoid paying into IT support from us. The only time we get a call is when something drastic has happened and often by then it’s too late (backup hasn’t been checked, error reporting hasn’t been checked etc). Should we really still maintain and check if we’re not being paid to do so?

    Often in my experience it’s the same, I get called in, told to set the network up which is followed by, “but we only have this much to spend”. What is one to do?

    I’d like to have your opinion on, say, setting up a network for 250 people, running two servers, including VPN. Usually we replicate, virtualise, and the file server is a SAN running behind a VLAN – I’m sure you can see though how security is still an issue in this setup.

    Thanks for your thoughts and time.

    Andrew

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s