Recipe2.8.Installing Exchange on a Domain Controller

Recipe 2.8. Installing Exchange on a Domain Controller

Problem

You want to install Exchange on a domain controller.

Solution

There aren't actually any technical barriers preventing you from doing this, although there are plenty of reasons why you may need to consider alternatives. The main technical issue is that when the server is rebooted or shut down, the Active Directory services stop before the Exchange services, which cause Exchange to pause while the DSAccess component waits for its AD queries to time out. This problem mainly arises when Exchange Server 2003 is installed on Windows Server 2003; the AD services on Windows 2000 don't shut down as quickly. Of course, you shouldn't be shutting down your servers that often. A more likely obstacle is that, depending on the size, configuration, and load on your server, you may find that performance of the combined services isn't as good as you'd like. For organizations with limited budgets and a small number of seats, Microsoft sells the Small Business Server (SBS) product line, which combines Exchange with the DC role and several others on a single server; however, most production Exchange installations keep the roles separate.

Installing Exchange 2000 or 2003 on a DC is a supported configuration, even though most Exchange professionals will rightly tell you this is not the optimal or even recommended way to deploy Exchange. Avoid installing Exchange/DC combinations on clusters, though; this is not supported by Microsoft.

Discussion

There is at least one instance where Microsoft deploys this configurationon a single-machine Small Business Server installationso there is obviously no underlying concern that makes a shared Exchange/DC configuration technically invalid. There are good reasons for avoiding this configuration, however:

You lose the benefits of high-memory performance optimizations. Both services like to have a lot of system resources available and both will tend to assume that they are the sole consumer of those resources. In particular, you should not use the /3GB Windows startup option even if you have over 1 GB of RAM, to avoid the likelihood of Exchange starving out AD.
You lose the benefits of security compartmentalization. If your Exchange administrators are not also Domain Admins, you will need to grant them the Interactive Logon privilege on the shared server. Since this server is a DCand since both Exchange and AD run as the LocalSystem accountadministrators can use their local access to elevate their privileges and gain access to AD.
You lose the benefits of redundancy. The Exchange components that interact with AD will not load balance or fail over to another global catalog server if something happens to the AD services. Admittedly, if you are in a single-server configuration to begin with, losing your single DC will cripple Exchange anyway, but this is a large concern if you were considering deploying multiple Exchange/AD combos.
You make disaster recovery much more difficult. Restoring an Exchange/AD combo from bare metal is unpleasant at best and can take far longer than the combined restore times and processes for separate servers.

If you still feel that the combination configuration is useful, there are a couple of caveats to keep in mind:

The combination server must also be a global catalog server. Since you lose the load balancing and failover capabilities, AD must be able to provide all the lookups that Exchange requires. This will have an impact on your replication traffic and bandwidth usage if you are deploying this combination to a branch office in a multi-domain organization.
As previously mentioned, shutdowns and restarts will introduce a 10-minute delay on Exchange Server 2003 servers. You can either lower the default service timeout (not recommended, as it may impact the stability of the rest of the system) or ensure that your administrators manually shutdown the Exchange services before shutting down the server.

The following batch script fragment shows the necessary commands to stop the Exchange services before shutting down:

net stop "Microsoft Exchange Management" /yes net stop "Microsoft Exchange Routing Engine" /yes net stop "Microsoft Exchange Information Store" /yes  net stop "Microsoft Exchange MTA Stacks" /yes net stop "Microsoft Exchange System Attendant" /yes

There are a handful of Exchange services that will be automatically stopped as these services are stopped; the transport protocol services will be stopped when the IIS services are stopped.