Web Active Directory Blog

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.

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.

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.