Your Tech Business | Technologies for a more efficient and productive business

Run Microsoft Exchange On A Domain Controller

server-web-mail-technologyYes you can install Exchange on a domain controller (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 and your cloud-based phone system 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 totaling 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 with your phone system – 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 separated.

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.

· · ·

Comments are closed.