“Should I install my Exchange 2010 server onto a Domain Controller?”
“What issues will I see by installing Exchange onto my DC?”
“Is installing Exchange on a DC supported?”
“Is this DAG member supported on a DC?”
These are phrases that enterprise customers do not normally say. They are more in the realm of SMB customers, or consultants who are working with one of these smaller customers.
For clarity, Small Business Server is out of scope for this article.
Update 8-1-2014: Added TechNet Exchange 2013 link
Hopefully this is one of the first questions that is asked in the Exchange on a DC discussion. What’s the answer? Well it’s the consultant’s answer; “It Depends!”.
A regular Exchange 2010 install, while not recommended, is supported. This is covered on the Exchange 2010 System Requirements page in the Directory Server Architecture section. For reference the relevant passage is:
For security and performance reasons, we recommend that you install Exchange 2010 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2010. After Exchange 2010 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.
The same holds true for Exchange 2013 as stated in its System Requirements.
Additionally there is now a page on TechNet to specifically discuss this for Exchange 2013.
If Exchange 2010 is a DAG member, or will be a DAG member, then this is not supported. The official TechNet statement on this configuration is buried under the Add-DatabaseAvailabilityGroupServer cmdlet which will add the Mailbox server to the DAG.
To add a Mailbox server to a DAG, the Mailbox server must be running Windows Server 2008 Enterprise or Datacenter Edition or Windows Server 2008 R2 Enterprise or Datacenter Edition and it must not belong to any other DAG. The Mailbox server must be in the same Active Directory domain as all other Mailbox servers in the DAG. In addition, the Mailbox server must not be configured as an Active Directory directory server.
For Exchange 2013, this is again located with its version of the Add-DatabaseAvailabilityGroup cmdlet:
To add a Mailbox server to a DAG, the Mailbox server must be running the Windows Server 2008 R2 Enterprise or Datacenter operating system or Windows Server 2012 Standard or Datacenter operating system and it must not belong to any other DAG. The Mailbox server must be running the same versions of the Windows operating system and Microsoft Exchange, and be in the same Active Directory domain as all other Mailbox servers in the DAG. In addition, the Mailbox server must not be configured as an Active Directory domain controller or global catalog server.
Exchange may not block you from creating a DAG from a Mailbox server that is installed onto a DC, but that does NOT make it a supported solution. But what about the regular Mailbox server? Since that is a supported option, that makes it a good idea, right?
Well, I’m able to drive my car with my knees but that still does not make it a great idea!
Think about what is happening and what potentially has to happen if you collocate Exchange and AD.
Exchange 2010 SP2 introduced the Address Book Policy (ABP) feature. For this to work the Address Book traffic must go through the Exchange server so that CAS can strip out and control access to the directory information. If this is not done then the user sees everything. When Exchange is installed onto a GC, the Name Server Provider Interface (NSPI) endpoint is not owned by Exchange – rather it is the underlying OS. So guess what? ABPs will not work as the traffic is not filtered by Exchange.
This is not intended to be an exhaustive list of the issues caused by installing Exchange onto a DC.
In addition to the System Requirements page, please also make sure that you have the Supportability Matrix bookmarked as well! If you follow them wisely, then you will not do unsupported things like install PowerShell 3.0 onto an Exchange 2010 SP2 server.
Here are the links for your convenience:
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.