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?
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.
"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.
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?
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.
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.
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.
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.