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
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?
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
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.
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.