Boswell's Q&A

Everything But the Kitchen Sink

Auditors think this admin should turn DCs into file and application servers. Is this a good idea?

• By Bill Boswell
• 12/21/2004

Bill: I am a senior level IT exec at a small startup company. We recently went through an audit. When the auditor delivered the final report, I was criticized for the number of servers we had. They recommended that we take our two Windows Server 2003 domain controllers (which are also AD-integrated DNS servers along with doing DHCP and IAS) and turn them into file servers and application servers, as well.

This sounds like a terrible idea. What are your thoughts?
—Chris

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Chris: I agree with you. In my opinion, the auditors are in error. They looked at the Domain Controllers sitting in a rack and saw "servers" when they should have seen "appliances." For example, if you had a software-based firewall such as CheckPoint or ISA, I'm sure they wouldn't have expected it to also function as a file-and-print or application server. I'd argue that Domain Controllers should also fall into this category.

The primary reason for separating DC functions from other services is security. By keeping users off the Domain Controllers, you minimize the risk of viruses and malware getting access to the directory service or playing havoc with the domain by getting root on a DC. Also, you avoid the risk of inadvertent privilege elevation causing accidental deletions or other problems. And by keeping Domain Controllers isolated in their own Organizational Unit, you avoid potential security breaches caused by inappropriately configured Group Policies.

This "protection by separation" isn't 100 percent effective, of course. Worms can get access to DCs via unpatched services. But because pristine Domain Controllers are pretty much carbon copies of each other (except for their FSMO roles), you can patch and restart them quickly in the event of a rapidly spreading outbreak. This might not be true if they host complex applications.

From an operational perspective, there's a logistical advantage to keeping additional services off the Domain Controllers. You don't need to worry about the impact on logons if a new printer has a poorly written driver that sends CPU utilization to 100 percents or bug-checks the server. Also, backups are much simpler to perform on a pristine Domain Controller because a System State backup captures just about everything you'd need to recover in the event of a loss of the DC.

If the hardware is sized appropriately in relation to the number of users, then the cost of a Domain Controller "appliance" is minimal. If the Domain Controllers in your organization have excess capacity, perhaps you can mollify the auditors by purchasing basic 1U boxes with a couple of mirrored SATA drives for use as DCs and repurpose the existing hardware.

Before I get a flood of e-mail from VARs, I know that Small Business Server violates this separation of duties, but SBS is intended for very small companies where cost is the single greatest factor in determining which technologies get deployed.

Readers, how do you feel about this subject? Should DCs be "appliances" or should they pull their weight just like any other Windows server. My e-mail address is [email protected].

On a personal note, the MCPMag.com staff and I are going to take a two-week break. "Boswell's Q&A" will return the first week of 2005 with more solutions to your IT problems. I really appreciate the great feedback that I've gotten from all of you over the past year. Every day I learn something new from a reader of this column. I'm grateful for that.

Peering ahead into 2005, it looks as if the fun never stops for Windows admins. Although Microsoft has extended the for-fee support of NT 4.0 and Exchange 5.5, they are only delaying the inevitable. If you haven't started putting together your migration plans, now is the time to start. Windows Server 2003 SP1 is coming soon, with some security settings that are bound to cause controversy but will also help protect servers during and after initial setup. Windows Server 2003 R2 will be out in October with lots of new features. Also, the next version of Exchange will start beta testing in 2005. The feature set hasn't been announced, but it looks as if it will include the initial release of Microsoft Shell (MSH, code-named "Monad"), which will change forever the way you think about command line administration of a Windows server.

And far out there in the distance, you can hear the jostling of Longhorns.

But all that can wait for a while. Now it's time to relax. Have a great holiday, if management hasn't decided to schedule all the server outages over Christmas and New Year's.