Exchange Server 2007 and Domain Controllers - A Summary
Over three years ago, I wrote my most popular (in terms of number of times it has been read) blog post ever: "Exchange Server 2003 and Domain Controllers - A Summary." Since it was written in January of 2005, Exchange Server 2003 service pack 2 has been released, Windows Server 2003 service pack 2 has been released, Exchange Server 2007 RTM'ed, and Exchange Server 2007 service pack 1 has been released.
Recently, I also blogged about a key point missed in that original article; the fact that Local\Administrators on a member server is a far different animal than Builtin\Administrators on a domain controller (this leads to the fact that you can't restrict permissions for an Exchange Server Admin when Exchange is installed on a DC). That was in this post.
The basic recommendation and supportability statement has not changed: Microsoft does not support the execution of DCPROMO on a server after Exchange Server has been installed. This includes either the demotion of a domain controller to a member server OR the promotion of a member server to a domain controller.
Also, while running Exchange Server on a domain controller is supported by Microsoft, it is not recommended.
From a technical perspective, Exchange Server is "nothing more" than a large application that uses lots of the capabilities of Windows Server. It uses IIS, ESE, NTFS, ACLs, Active Directory, ASP.NET, the .NET Framework, etc. etc. However, unlike many applications that use only a small part of the capabilities available from a given technology, Exchange Server uses some of the technologies to the utmost - ESE, for example, was initially developed for the use of Exchange Server.
What this tends to mean is that changes in the underlying operating system can have a large impact on how Exchange Server works.
Take, for example, the fact that a domain controller has no local account database. None. So, when IIS is installed on a domain controller, the IIS user that is created for application pools is a domain user, instead of a local user. Any application that "knows" what the IIS user is will have issues with a change from a member server to a domain controller, and vice versa.
Note also that different security policies are applied to domain controllers vs. member servers. This affects the rights available to any service or process running on the subject server. It also affects the rights assigned to the various built-in accounts attached to that server. Any single domain controller has identical rights (via the Domain Controller Security Policy) as every other domain controller in a domain. However, a member server is subject to both Local Security Policy and to the Domain Security Policy. Not to mention that different Group Policies may be attached to the Domain Controllers OU versus the Computers container.
Therefore, from a security perspective, it begins to become obvious that making a change from member server to domain controller is a very significant change and it should be no surprise that this change can significantly effect some applications. It actually becomes surprising that more applications are not effected by this change.
Except in fairly rare cases, making all DCs into GCs (domain controllers into group catalog servers) is a good idea. The exceptions tend to revolve around bandwidth-constrained environments where there are large numbers of domains and high-churn (that is, lots of changes).
In fact, if you install Exchange Server on a domain controller, that DC must be a GC. Installing Exchange Server on a DC removes any redundancy from Active Directory for that particular Exchange server. Exchange will always refer to the server on which it is installed for LDAP and GC queries.
This also means that any Exchange Server installed on a Windows Server 2008 DC cannot use the Windows Server 2008 functionality that allows Active Directory to be stopped and restarted on that server. If Active Directory is stopped on that server, Exchange Server will stop working.
When you make a DC into a GC, it does not immediately become available for use by Exchange Server. The GC replication process has to complete before the DC will begin advertising itself for use as a GC. If you are needing to create a new GC and then eliminate an old GC, you will need to monitor the event log in order to know when the new GC is ready.
On a similar note, when you remove the GC attribute from an existing GC, it will not stop being a GC until the next reboot. This needs to be taken into account during your planning.
Exchange Server makes heavy use of Active Directory, and in medium-to-large environments, Microsoft makes specific recommendations about the number of GCs that should be available (see KB 875427). In general, you need to have a dedicated GC processor core for each four Exchange processor cores (assuming the cores are of a similar architecture and speed).
Prior to Exchange Server 2003 service pack 2, when installed on Windows Server service pack 1 (or earlier), there were long delays associated with restarting a DC where Exchange Server were installed. If you are in that case, please update to more recent version (Service pack) of both Exchange Server and Windows Server. This problem occurs because of dependencies between Exchange and Active Directory - a needed Active Directory service would terminate prior to Exchange being done with it, causing Exchange Server to appear to "hang" until it timed out.
If you install Exchange Server on a domain controller, the Exchange Server Administrator must be a member of Builtin\Administrators or of Domain Admins. Since both have privileges over every server in the domain, you have no restriction of responsibilities.
Both Active Directory and Exchange Server are memory and processor intensive applications. In 32-bit installations, it is commonly recommended to use the /3GB switch for Exchange Server, but this is NEVER recommended for a DC. On a DC, using that switch can cause Active Directory to be starved for memory.
Similarly, in a 64-bit installation, both Exchange Server and Active Directory will attempt to consume all available memory (as will SQL Server, should it happen to be installed). This can lead to memory-to-disk thrashing without careful tuning.
Finally, if you do choose to install Exchange Server on a domain controller, you should verify and test your backup and recovery plan thoroughly. Placing both Exchange Server and Active Directory on a single computer significant complicates the recovery process should a significant failure occur. Significantly.
If you want to review the Microsoft guidance on this topic, enter the following query into Google: "running exchange server on a domain controller site:*.microsoft.com".
Until next time...
As always, thanks for reading. If you have topics that you would like to see covered, please e-mail me or leave a message for me in the forums.