Most of our software products run on Microsoft’s IIS web server. In our product installation guides, we specify in the system requirements to install our web applications on a member server instead of a domain controller. Recently, a prospect asked us why we recommend this since WebAD products connect to Active Directory. Is it really a best practice to use a Windows member server instead of a domain controller to run IIS web applications and other services like SQL Server or Exchange?
In short, it’s best to run web applications and other functional roles on a member server instead of a domain controller. Yes, Microsoft does have offerings like Windows Small Business Server (SBS) that combine seemingly myriad roles on a single server but these scenarios are really only intended for small businesses with simple needs. For many organizations, separating domain controller functions from member servers running other services allows you to maintain the health of your Active Directory environment without interference from oddities brought on through other services and applications. You can still combine roles on member servers to share hardware and software resources but there is no need to clutter your DC with unnecessary services that might interfere with AD operations.
The following snippet from an excellent discussion at ServerFault provides great insight.“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. Thirdly, 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!”
Another great comment from the same discussion provides more fodder to separating domain controller functions from other roles and services, although there are a few roles like DHCP and DNS that can work quite well on a domain controller.“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.”
With the advent of virtualization, the need to combine roles on domain controllers really goes away since the cost to spin up a new virtual machine instance is very cheap. Make it easy on yourself and keep your domain controllers pure while combining roles and services on member servers.