Running Exchange on a Domain Controller
First of all... Yes you can install Exchange on a DC. If you somehow
found your way here from a google search while halfway through an
installation and need an answer right now, then your answer is "It
isn't ideal but yes you can".
If you were hoping for something a little more in-depth then read on…
First of all, the most obvious comment: this is indeed a Microsoft
supported scenario, and in fact something they do themselves if you
purchase the Small Business Server product and go with the defaults.
There are countless people out there right now using Exchange installed
on a Domain Controller who will never be aware of this discussion never
mind how many websites it has been covered on.
Small Business Server has a couple of important considerations however, that make it an 'edge case' for server setups.
- SBS is a compromise product. I don't mean that in any kind of
derogatory manner, but simply to say that the whole basic premise of
the product is that it is providing a broad range of services to a
limited amount of users.
- Exchange on SBS is essentially the standard edition of Exchange,
with all the limits that implies, which has an effect of rate-limiting
the amount of growth and resources it can do.
- Microsoft's deployment tools for SBS are written with all this in mind.
Installing Exchange onto a DC can be seen as a cost cutting exercise,
because it obviously reduces the amount of servers you need to buy.
Again, very true and correct. However, there are some considerations
that you should consider when totalling up the overall cost of this
choice.
Installing Exchange onto a DC introduces a number of problems, that are
not apparent on a server that is lightly loaded, but which can choke a
server that is heavily loaded; therefore a reasonable decision taken in
the early days of a network implementation can come back to bite you
later.
Both Exchange and Active Directory are based on resource hungry
databases, and are serving users in time critical functions. Both
systems can use large amounts of RAM; disk capacity and bandwidth; and
processor time. If these processes have to compete for those resources
then poor performance is your most likely outcome, and when it effects
the CEO's login times and email client behaviour, saving a bit of money
might not seem as important as it used to.
You can of course attempt to over-specify your server to take this into account. The problems with this are two-fold.
- I assume you hope your business will grow - so now you've got to
specify head room for growth in AD size, growth in Exchange size, AND
extra free room for them to share resources.
- The reasons for sharing a server we mentioned earlier were pretty
much based on the cost of buying two servers. Remind me again how
buying one big server for £8000 to share the two jobs is cheaper than
buying two £2,500 servers to keep the jobs seperated.
Another problem is security (you knew I'd get to that, right?)
If you want to use Exchange as a OWA or OMA web-mail server, then
you've not only got to expose an Exchange server to the Internet, but
now you've also got to expose a Domain Controller. Yes of course you
can firewall it all off, but this simple cheap solution is suddenly
getting less simple, and unless your time is worth nothing, that means
it isn't that cheap either.
Any outages that effect one service will have an impact on the other...
want to patch Exchange and need to reboot? Ooops, now nobody can
authenticate to anything because the DC is offline too. Want to patch
your DC? I hope nobody was working on an important and lengthy email
because they just lost it when you rebooted your DC.
Problems with applications that work with one service can affect the
stability of the other service. For example, a faulty Exchange virus
scanner would now also be in a position to upset basic network
operations.
Just to drive a final nail in the coffin - lets look at operational concerns.
Sharing a server means that more services are suddenly interacting with
each other. Now all of a sudden you've got servers that take forever to
reboot.
If you ever have to do a disaster recovery of your Domain controller
then guess what - your Exchange recovery skills better be up to scratch
too! Hate recovering Exchange servers after a disaster? Well guess what
- now you need to recovery a domain controller too - at the same time!
The issue here is not that the recovery is impossible, but rather the
cost of recovering one of these critical and sensitive services is
compounded by having to also recover the other one at the same time.
Any DC that runs Exchange needs to be a Global Catalogue server.
Exchange server functions that would normally fail over to using
different domain controllers if their preferred DC is not
available will not work as expected.
So obviously, I'm pretty much against the idea. In a small business
scenario with only one or two servers, it is acceptable if your choices
are either to do this or go without Exchange entirely, but as an
overall solution, it simply doesn't scale.
[This post is one I managed to recover from the old blog system]