Andres Rodriguez - Fotolia

Get started Bring yourself up to speed with our introductory content.

Exchange 2016 architecture recommendations

All companies must include three areas in their Exchange Server 2016 design blueprint -- servers and storage, availability groups and namespaces.

The public beta of Microsoft Exchange Server 2016 is scheduled for release this summer, with the release to manufacturing...

planned for later this year. Is your architecture ready for Microsoft's latest email platform? The Exchange team outlined preferred architecture guidelines for Exchange Server 2016 deployments at Microsoft Ignite. Here's a rundown of what you need to know to design an Exchange 2016 environment.

Server and storage design. Microsoft stresses the importance of deploying Exchange on commodity hardware to reduce deployment costs and keep the server resilient. The ideal server candidate to run Exchange 2016 has dual-socket mid-range processors with a maximum of 24 cores and up to 196 GB of memory. Depending on an organization's size, the server specifications can be much lower.

Even though the Exchange team's recommendation has always been to run multirole servers in Exchange 2010 and Exchange 2013, some IT admins separated the roles in their deployments because they didn't understand the roles' architecture or why the deployment should be resilient. In Exchange 2016, Microsoft ensured all deployments follow that recommendation by combining all client access proxy components, core server protocols and mailbox functionalities into a single role. Exchange 2016 features only one mailbox role, aside from the optional Edge Transport role.

Now all Exchange 2016 deployments will have a collection of Mailbox 2016 servers to handle client connectivity and mailbox data. The preferred storage for Exchange 2016 architecture is just a bunch of disks (JBOD) with at least three copies of all mailbox databases. Storage includes a large number of high-capacity 7,200-rpm serial-attached SCSI disks with a battery-backed cache controller. The company chose this cache controller because of performance issues found in dogfood deployments. To make the best use of the high-capacity disks, configure multiple databases on a single volume, along with logs and content index, and then configure a hot spare for auto reseed.

Reformat all Exchange data volumes, including databases, logs and content index, with a Resilient File System. This is why Windows Server 2012 R2 and Windows Server 2016 are the only operating systems that Exchange 2016 supports. BitLocker can encrypt the data volumes to protect the data in the disks when configured in the JBOD model.

Database availability group design. Not much has changed with database availability group (DAG) limits in Exchange 2016. Like previous versions of Exchange, an Exchange 2016 DAG can have a maximum of 16 mailbox servers with 100 databases -- active and passive -- per server. DAGs can span across multiple Active Directory sites; it's generally recommended to not stretch AD sites across data centers. Using multiple AD sites creates resiliency in the transport layer.

To prevent data loss in a loss failover, Exchange keeps a copy of a message on a transport server that's in a different AD site than the source. If the AD site is stretched across data centers, Exchange won't be able to differentiate the server's location and may end up placing the message on a transport server in the same data center, creating a single point of failure.

The Exchange team wants a symmetrical DAG model spread across AD sites with the same number of servers and database copies in each data center. This means the DAG will have an even number of members and will use a file share witness (FSW), which should be placed on a third data center that can connect to both data centers. This ensures that there is an automatic data center failover. If you don't have a third data center, companies can also place FSW in Azure.

Exchange 2016 DAGs will be deployed without an administrative access point, removing the need for a network name and IP address resources. There's no need to have different network adapters to serve Messaging Application Program Interface and replication network. It's best to use a single network interface card without teaming; Exchange is already in control of any failure type, thereby activating another copy of the database.

Distribute active database copies across all servers in both data centers. Microsoft requires four database copies: two in each data center, one of which will be configured as a lagged copy (for seven days) with automatic play down enabled. This assumes that Exchange's native protection will be used instead of traditional backups. This is a good design for enterprises hosting large mailboxes, such as Office 365.

Namespace design. For a site-resilient data center pair, the Exchange team recommends a single namespace per protocol across both data centers for Exchange 2016 architecture. For example, you can have for HTTP and for the Autodiscover service. You can use the same HTTP namespace for other protocols, such as Simple Mail Transfer Protocol, point-of-presence or Internet Message Access Protocol, or you can have separate namespaces if necessary. There should be a load balancer pair in each data center and a single virtual IP address (VIP) per data center.

Single namespace with Layer 7 and no session affinity is the preferred load-balanced method in Exchange 2016. This method gives a health check in each protocol and doesn't need to use session affinity at the same time.

Round-robin domain name system (DNS) is the easiest method to get traffic to the Exchange VIP. Another option is to use geographical DNS, also known as geo-DNS, which routes the traffic to the "local" data center based on an end user's location. Advanced options such as Global Traffic Managers (GTM) can provide further resiliency in the load balancing layer. GTM appliances can check the load balancer pair's status in each data center and route traffic accordingly if one pair of load balancers or a site is down.

About the author:
Rajith Enchiparambil is a UC Architect who works on large Exchange and Office 365 projects for clients in the U.K. He specializes in Exchange, Office 365, Active Directory and a bit of Lync. He has been working in the IT industry for the last 13 years and has worked extensively with Microsoft Exchange since version 5.5. Enchiparambil has worked for consultant services such as HP, Siemens, AtoS, CapGemini and Computacenter. He regularly writes about Office 365 and Exchange in his personal blog,

Next Steps

Important Exchange 2016 changes

Admins take a peek at Exchange 2016

Experts react to Exchange 2016 features

Tips for an Exchange 2016 move

Dig Deeper on Exchange Server setup and troubleshooting