Export (0) Print
Expand All

Mailbox servers

[This topic is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders. If you have feedback, we'd love to hear it! Email us at ExchangeHelpFeedback@microsoft.com.]  

Applies to: Exchange Server 2016

In Exchange 2016, there are only two server roles, Mailbox and Edge Transport. With this design, any Exchange 2016 Mailbox server can accept and process requests from any client for servers within that Active Directory site. You don't need to worry about how many servers you'll need to handle connections from clients or other servers anymore. Connections will go to any server that's available to accept the connection.

The Exchange 2016 Mailbox server includes all of the services that were previously in the Exchange 2013 Mailbox and Client Access server roles:

  • Mailbox services Client access protocols, transport services, mailbox databases, and Unified Messaging services.

  • Client Access services Authentication, proxy, and limited redirection services, and the HTTP, POP, IMAP, and SMTP client access protocols.

To learn more about the functionality each of the services provide, check out the sections later in this topic.

importantImportant:
Mailbox servers aren't supported in perimeter networks; they need to be deployed within your internal Active Directory environment.

If you're coming from Exchange 2010, there have been some changes to client connectivity. First, RPC/TCP is no longer a supported direct access protocol. This means that all Outlook connectivity needs to use Outlook Anywhere or MAPI over HTTP. In addition, fewer namespaces are required for a site-resilient solution than were required in Exchange 2010, and the same namespaces can be used with Exchange 2013. Also, Outlook clients no longer connect to a server fully qualified domain name (FQDN) as they’ve done in versions of Exchange prior to Exchange 2013. Using Autodiscover, Outlook finds a new connection point made up of the user’s mailbox GUID + @ + the domain portion of the user’s primary SMTP address. This change makes it much less likely that users will see the dreaded message “Your administrator has made a change to your mailbox.”

Mailbox services include all of the components that enable the storage, processing, and transmission of mailbox and public folder data. Unified Messaging and several components that enable client connectivity and content rendering are also included in Mailbox services.

In Exchange 2013, Mailbox services interact directly with Active Directory, Client Access services, and Microsoft Outlook clients in the following process:

  • Mailbox services use LDAP to access recipient, server, and organization configuration information from Active Directory.

  • Client Access services send requests such as messages, free/busy data, client profile settings, and OAB data, to and from clients and Mailbox services.

  • Outlook access their mailboxes using Outlook Anywhere or MAPI or HTTP via Client Access services.

  • Client Access services use LDAP or Name Service Provider Interface (NSPI) to contact the Active Directory server and retrieve users' Active Directory information.

The Client Access services provide authentication, proxy and limited redirection services, and offers all the usual client access protocols: HTTP, POP, IMAP, and SMTP. The Client Access services don't do any data rendering and they don't store data.

In versions of Exchange prior to Exchange 2013, many of the Client Access protocols required session affinity. For example, Outlook Web App required that all requests from a particular client be handled by a specific Client Access server within a load balanced array of Client Access servers. In Exchange 2016, Client Access services on the Mailbox server enable stateless connections. In other words, because all processing for the mailbox happens "behind the scenes" in Mailbox services, it doesn’t matter which Exchange 2016 server receives each individual client request. This change in functionality means that session affinity is no longer required at the load balancer level. This allows inbound connections to be balanced using simple techniques provided by load balancing technology such as DNS round-robin. It also allows hardware load balancing devices to support significantly more concurrent connections.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2015 Microsoft