This question was a discussion about whether Active Directory is necessary to run Terminal Services. But a chain of answers and comments (mostly by me) brought up a related question around Domain Controllers.

It is clearly poor practice to have only one Domain Controller in an AD environment. It is also clearly best practice to have each domain controller on a separate (physical or virtual) single function server. However, not everyone can follow best practices all of the time.

Is it OK to use servers filling other roles as domain controllers?

What things should be considered in determining whether to "dual-purpose" a server?

Does the domain controller role change how Windows operates the file system or on the hardware?

Are there difference between versions of Windows Server?

  • Kara .. why did you add the "best practices" tag? I rather pointedly noted that this is about how not to follow best practices around domain controllers. Further, nabobs spouting "MS doesn't support" or "it isn't best practice" will contribute nothing and clutter what I am hoping will be good responses around solving a problem for small $.
    – tomjedrz
    Commented May 27, 2009 at 19:13
  • 3
    Actually I think Kara is kinda right to add best practices. Best practices is kind of a misnomer, it sort of means "issues on the good/bad practice axis", there is never going to be a bad practices tag! Commented May 27, 2009 at 19:18
  • I thought it was an appropriate AoD reference. :) Commented Jul 13, 2009 at 5:38

13 Answers 13


You can and it works. I have about 40 branch offices and - for political reasons - a management decision was made to give each a full server infrastructure. For financial reasons it was a single-server environment in each, so it's all DC/File/Exchange (this was in the Windows 2000 days).

However, management of it is a nightmare, and my preferred rule is "a DC is a DC and nothing else goes on it". These are your most important servers, and if your AD goes funny you will have a horrible time getting it back right. If you can, give yourself the best chance of avoiding this by having dedicated DC roles. If you can't, beg, scream, whimper, bribe, threaten, prophesy, or whatever it takes to put yourself in a position where you can.

  • Can you elaborate a bit on the "management is a nightmare" statement?
    – tomjedrz
    Commented May 29, 2009 at 15:09
  • 2
    Aside from having 40 remote servers with no IT staff on-site, splitting out your server roles to separate boxes does put you in a very nice position where you can do maintenance on one box without affecting the others. Also, putting weird and flaky third party software (I'm talking printer drivers here) on a DC doesn't chime well with my sensibilities. Thrdly, you want your DC event logs to be squeaky clean, you don't want a minor heart attack any time you get a security or system warning from one of those! Commented May 29, 2009 at 21:31
  • what does it mean for AD to "go funny"? Commented Oct 10, 2021 at 22:28

Multi-Role Domain controllers are pretty common. Although, most roles they perform are network infrastructure roles. Good examples are File Servers, DHCP and DNS. They are poor choices for things like Terminal servers (Users do not have rights to log into a Domain Controller and giving them said rights grants requires Domain Admins), Web Application Servers, Line of Business App Servers, Firewall/Proxy/ISA servers, etc

In my environments, I prefer to have all internal DNS Servers running on Domain Controllers as well as my DHCP services. This seems to be a good mix of roles on the DCs to reduce cost and make the best use of the hardware possible.

  • 1
    I can see no problem whatever with DCs doing DHCP and DNS. And if you don't have high load file and print is also fine. SBS is a DC and does pretty everything (except Terminal Services, which is a bad idea on every level). Commented May 27, 2009 at 19:21
  • Is it OK to use servers filling other roles as domain controllers?

"You can even cut a tin can with it, but you wouldn't want to!" - Mr. Popeil, lyrics Weird Al Yankovic

I guess the question is: do you want to? Sure, you can turn your domain controller into a file and print server, or a SQL Server box, or any number of other functions. But there's a downside to this, a price to pay in the form of degraded functionality on that box. If you have very few users (say under 25-50), or you are squeezed by budget constraints and you need to make this an "all in one" box, you could get away with doing so. But there are performance issues, security issues, and even the potential for incompatibilities between services. Doing "all in one" boxes is a function of evil budgets set forth by keepers-of-the-pursestrings that don't understand the price they'll pay.

If you can afford it, put the domain controller on a separate box. Heck, if at all possible, get a cheap yet server-grade box, probably a department-level box, and put your DC services on that; then get a twin of that box, and put DC services on that as well. This is the model that Windows would like you have, and you really, really, should have at least two domain controllers for each domain.

Buy the beefer boxes for those services that are used most - databases, email, file & print, etc. These are the "everyday" boxes that users see regularly; the domain controllers are best left rubber-stamping user credentials across the domain.

  • What things should be considered in determining whether to "dual-purpose" a server?

Can you get away with degraded levels of performace? Will there be an incompatibility between the service you're installing, and any other services that may run? Will it interfere with AD authentication?

  • Does the domain controller role change how Windows operates the file system or on the hardware?

No. But it will increase its workload. And if you integrate other non-windows functions (say, using a PAM stack to authenticate a linux box via Kerberos as part of an IMAP service) then expect that workload to increase.

  • Are there difference between versions of Windows Server?

Each release increases the number of features, although it's safe to say that you want at least Windows 2000 if not better. Most folks are on Windows 2003 (and cousins), which includes enhancements to file services, volume shadow copy, etc. 2008 provides even more enhancements.


Microsoft Small Business Server is AD + Exchange + File server + router/VPN Server + Sharepoint + SQL Server.. and more all rolled into a single server. So i wouldn't say its 'best practice' to have every function on a different server. For small operations it doesnt make sense to run everything in different hardware.


Yes, they can, but from a security perspective, the usual answer is no. The reason is a simple one: the more that's running on a domain controller, the greater the surface area which can be exploited to take the box. Take the box and you've got the domain. Typically it's not unusual to see DNS running with Active Directory integrated zones. However, anything else, I would say no unless you're a small shop and simply can't afford to break out the services.


It looks like it boils down to Security and Performance. I don't think performance is much of an issue on small networks, AD uses a miniscule amount of the cheapest server you could put together right now.

At that point, you can just weigh security vs. cost - which is what all security questions boil down to in a small network...


I think all of the answers can be summed up by Small Business Server.

Sure, MS was able to throw nearly EVERYTHING (AD, Exchange, SQL, etc) onto a single box. But it runs like crap and is only useful in very limited situations.


In short, can you do it? Yes. Should you do it? I don't recommend it, but it can work if you are in a bind.

From a performance standpoint, it depends on the load of the two services. On a smaller network, a DC could also double as a DNS or DHCP server without issue. On a larger network, it's asking for trouble.

I would highly recomend that you do not put more than one "primary" server on the same physical box. IE, if this is your master DC, using it as a secondary DNS server or backup DHCP server would be acceptable. Reason being, you don't want a failure on one box to take out to take out two services.

I would highly discourage anyone from running more demanding services, such as a web server (IIS or Apache, etc) or Databases of any sort.

If you do decide to run more than one type of service on the same physical box, I would highly recomend getting as "beefy" of a box as possible, and using it as a host for Virtualized servers. This way, all your services are still somewhat independant of each other on the OS level.


I would generally run DNS and DHCP on Domain Controller(s), and have at least two DCs. Personally, I have a virtual DC running on two of my virtual hosts (running VMware ESXi, three virtual hosts total) and one physical as well. All DCs are DNS servers, and two of them are DHCP servers (serving half of the range each). Virtualization makes it easy (and depending on how you pay for Windows licensing, affordable) to have task-specific VMs, and I much prefer splitting things out as rebooting one server won't affect others.

However, I'm running SBS 2003 at another (smaller) office and it functions well on a beefy server, although the reboot scheduling issue is sometimes annoying. SBS is physical, but I have a second server running VMware ESXi that has a Windows VM which is also a DC so I have a seconary (second DC is allowed with SBS as long as SBS holds FSMO roles). I hate having one DC, it would make recovery more difficult and any downtime longer!

I would try and add only something like print and/or file serving to a DC if possible, in addition to DNS and DHCP. Others would have to be weighed carefully...and if possible, stick even a desktop/low end server in as a secondary DC/DNS only box if you must mix on the primary hardware. Even non-redundant hardware is likely to be up if your primary is down and vice versa (whether it's for a reboot or a crash).


There is nothing that inherently denies a domain controller from functioning in other capacities.

If you have an existing AD infrastructure and you only have one domain controller, I'd say that any drawbacks of promoting another server would be outweighed by the advantages of getting another DC.

Remember that after you run dcpromo, you'll have to reboot, so any services provided by the newly promoted machine will be interrupted. Also, if you have any domain controller security policies, they will apply to that server.

  • Anything that a User must log into (he mentioned Terminal Services) cannot be on a DC unless all users are members of Domain Admins. Commented May 27, 2009 at 17:57
  • This isn't exactly true. There is server level software (MS Team Foundation Server, for example) that flat won't install onto a domain controller.
    – NotMe
    Commented May 27, 2009 at 20:57
  • Can't the domain controller security policy be changed to permit this? (not that I'm suggesting it's a good idea, but the parent seems to be aware that this isn't the best idea) Commented May 28, 2009 at 11:44

You COULD but why would you want to? Theoretically you can have the whole shebang of services on same box (Small Business Server). Just because you CAN do something, however, doesn't necessarily mean you should. The Domain controller holds the AD database so if you want to risk bogging that down with printing (and god forbid) file sharing then that's a risk you'll have to assess yourself. If you want to play it safe stand up a Linux server for free and use that as a network file share or print server and try to keep your Domain Server boxes as just that.

  • How about an absolute inability to spend money, for reasons that should be crystal clear at this time in our history.
    – tomjedrz
    Commented May 27, 2009 at 19:15
  • 1
    When will people learn that software is an investment to improve productivity. Not buying software to save on licensing cost, but meaning you have to do 10x more work is crazy. Unless your happy to work for free Commented May 28, 2009 at 9:36
  • @Nick - why would having a File Server also act as a Domain Controller cause tons of extra work? Just curious ... we're very tight on money (<50 employees) and considering just throwing both on the same box to save the $700.
    – Beep beep
    Commented Jun 18, 2009 at 5:33

(don't take me too seriously, but you know I have a point)

Sure, just install VMware, and on it Debian and you have a great multi-purpose server. That is, if the load on the host is small enough.

  • You do have a point, an interesting one in fact. A DC could perhaps be in a VM on a Terminal Server or Web Server, or the other way around.
    – tomjedrz
    Commented May 27, 2009 at 19:35
  • That's me... but I think: Install Debian, on it install VmWare and on it the "servers". Use full backups on the host/debian, and when needed just move the "server" to a new host. Cloud computing at it's best.
    – elcuco
    Commented May 27, 2009 at 19:52

If I had the choice of having just one Domain Controller, or running another DC say on an SQL box, then I would take that option.

In fact, I'd probably rather run a Virtual Server than actually turning any other working server into a domain controller - even if it was just running on a workstation.

My personal opinion is that for stability you need a minimum of three domain controllers which allows you to split the operation master roles, and you should always have at least two global catalogues - but taking into account that the infrastucture master shouldn't be a GC.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .