Working on the next doc for the SMB Kitchen project – this one detailing out what is supported where….
Did you know that Exchange isn’t exactly blocked from being installed on a Domain controller?
In large enterprises, domain controllers are single purpose servers that only serve one role. In Small business we do not always have the resources to plan our deployment such that the domain controller can be on its own server. There are certain server roles that are blocked from deployment or blocked from support when combined with a domain controller.
Exchange Server: While not recommended to be installed on a domain controller, it’s not officially blocked to install Exchange on a domain controller as long as the server is Windows 2012 standard. On Windows 2012 Server Essentials, Exchange is not supported to be installed on top of the Essentials server. As noted in Technet (Microsoft) when you go to install Exchange 2013 on a domain controller, you will get a warning:
“Microsoft Exchange Server 2013 Setup has detected that the computer you’re attempting to install Exchange 2013 on is an Active Directory domain controller. Installing Exchange 2013 on a domain controller isn’t recommended.”
The Technet documentation goes on to state the following statements in bold. The SMB implications of these statements is italicized.
If you install Exchange 2013 on a domain controller, be aware of the following issues:
• Configuring Exchange 2013 for Active Directory split permissions isn’t supported. This typically is not an issue in a small firm where the physical implementation of the network limits the permissions to just that physical implementation.
• The Exchange Trusted Subsystem universal security group (USG) is added to the Domain Admins group when Exchange is installed on a domain controller. When this occurs, all Exchange servers in the domain are granted domain administrator rights in that domain. In a small firm, typically there is only one Exchange server.
• Exchange Server and Active Directory are both resource-intensive applications. There are performance implications to be considered when both are running on the same computer. If you place Exchange on a domain controller, you need to properly size the physical server. It will need ample amounts of RAM, ample disk speeds and I/O. Any memory recommendations by Microsoft need to be increased for real world deployment.
• You must make sure that the domain controller Exchange 2013 is installed on is a global catalog server. In the case of a small firm, this is typically a non issue.
• Exchange services may not start correctly when the domain controller is also a global catalog server. This is a serious issue and one that has often plagued Small Business Server. For Small Business Server it was recommended to follow method 2 or 3 of http://support.microsoft.com/default.aspx?scid=kb;en-us;940845 (see http://blogs.technet.com/b/sbs/archive/2011/03/24/exchange-services-may-not-start-automatically-after-a-reboot.aspx for background)
• System shutdown will take considerably longer if Exchange services aren’t stopped before shutting down or restarting the server. SBS suffered from this and many folks scripted a shutdown of Exchange services in order to reboot faster (see http://msmvps.com/blogs/bradley/archive/2007/11/17/charlie-russel-on-shutdown.aspx )
• Demoting a domain controller to a member server isn’t supported. Typically in SMB demoting a domain controller isn’t often done. However, once you install Exchange on a domain controller you can never undo this process.
• Running Exchange 2013 on a clustered node that is also an Active Directory domain controller isn’t supported. If you plan any hyperV clusters, you cannot place it on a domain controller.
We recommend that you install Exchange 2013 on a member server.
Ultimately the issue is one of support. If you place Exchange on your domain controller, support can ultimately push back on supporting you in this configuration. Therefore for the SMB server of the future, it’s recommended that Exchange be on a member server.