With the release of Exchange Server 2016, I thought it would be best to document our guidance around utilizing Kerberos authentication for MAPI clients. Like with the last two releases, the solution leverages deploying an Alternate Service Account (ASA) credential so that domain-joined and domain-connected Outlook clients, as well as other MAPI clients, can utilize Kerberos authentication.

Depending on your environment, you may utilize a single ASA or have multiple ASA accounts during the coexistence period.

Exchange 2016 Coexistence with Exchange 2010

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to Exchange 2016 and host the http SPN records.

For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authenticationarticle.

Exchange 2016 Coexistence with Exchange 2013

A single ASA credential will be utilized and configured on all Exchange 2013 and Exchange 2016 servers.

For more information, see the Exchange 2013 Configuring Kerberos authentication for load-balanced Client Access serversarticle.

Note: The RollAlternateserviceAccountCredential.ps1 script included in Exchange 2016 scripts directory utilizes the new cmdlets, Get/Set-ClientAccessService. This cmdlet will not execute correctly on Exchange 2013 servers. Copy the RollAlternateserviceAccountCredential.ps1 script included in Exchange 2013 CU10 scripts directory to an Exchange 2016 server. Execute the copied script in order to deploy the ASA across Exchange servers.

Exchange 2016 Coexistence with both Exchange 2010 and Exchange 2013

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to the Exchange 2013 and Exchange 2016 servers to host the http SPN records.

For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authenticationarticle.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Our goal with this article is to articulate the various client connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

As you can see from the above diagram, this environment contains three Active Directory sites:

• Internet Facing AD Site (Site1) - This is the main AD site in the environment and has exposure to the Internet. This site has Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 infrastructure.
• Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2010 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2010 infrastructure located within this AD site.
• Non-Internet Facing AD Site (Site3) - This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure.

Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURL property populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the three users.

Autodiscover

The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location.

Note: The recommended practice is to configure the 2010 Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUri to a value that resolves to the load balanced VIP for the 2010 Client Access servers in your environment.

For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations.

Outlook Anywhere

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.
2. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server hosting the mailbox is located in another AD site (in this case Site3) and proxy the Outlook RPC data to the target Exchange 2010 Client Access server.
3. OrangeUser will connect to mail-region.contoso.com as his RPC proxy endpoint. CAS2010 in Site2 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.

Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response.

Outlook Web App

For more information, see the article Upgrading Outlook Web App to Exchange 2010.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2010 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
3. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is configured to do a cross-site silent redirection, therefore, CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any EAS ExternalURLs. CAS2010 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
3. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2

Exchange Web Services

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site1 will service the request.
2. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site2 will service the request.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2016 Client Access component infrastructure.

To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the MBX2016 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the MBX2016 infrastructure and depending on the mailbox version, different behaviors occur:

1. For mailboxes that exist on Exchange 2010, MBX2016 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
2. For mailboxes that exist on Exchange 2016 (Purple User), MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.

When you have an Exchange 2016 mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2016 mailboxes.

Important: When you introduce Exchange 2016 into a native Exchange 2010 environment, MAPI/HTTP will be enabled by default. Prior to moving any mailboxes to Exchange 2016, ensure you have configured your load balancer and/or firewall rules to allow traffic on /mapi/* via TCP443.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2016, you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the Outlook Updates for more information). Outlook will process the ExHTTP in order – internal first and external second.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must use different names for Outlook Anywhere inside and out. Outlook will also prefer the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings. By utilizing two namespaces for Outlook Anywhere, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2016 internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

In environments that are native Exchange 2010, when you introduce Exchange 2016, MAPI/HTTP will be enabled by default. As long as the client supports the protocol, once a mailbox is moved to Exchange 2016, the client will reconfigure itself to use MAPI/HTTP. Upon next boot of the client, MAPI/HTTP will be utilized. It is very important to ensure that you have the correct firewall and load balancer settings in place prior to moving mailboxes, otherwise client connectivity will fail.

External Outlook Anywhere & MAPI/HTTP Connectivity

In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.

The Exchange 2016 Client Access component’s RPC proxy component sees the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 CAS or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. MBX2016 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. MBX2016 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
4. Orange User will continue to access his mailbox using the Exchange 2010 regional namespace, mail-region.contoso.com.

Outlook on the web

For Outlook on the web, the user experience will depend on the mailbox version and where the mailbox is located.

1. Red User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. MBX2016 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. In this case, MBX2016 is not involved in any fashion.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. MBX2016 in Site1 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2016 no longer supports the 451 redirect response – Exchange 2016 will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. MBX2016 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. For the Orange User, there are two possible scenarios depending on how the device is configured:
   1. Orange User’s ActiveSync client is configured to connect to mail-region.contoso.com as the namespace endpoint. In this case, MBX2016 is not involved in any fashion. Note that any new device that is configured will automatically be configured to use mail-region.contoso.com.
   2. Orange User’s ActiveSync client is configured to connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within another AD site. MBX2016 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox.

Exchange Web Services

Coexistence with Exchange Web Services is rather simple.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL.

Offline Address Book

Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
2. For thePurple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

How MBX2016 Picks a Target Legacy Exchange Server

It’s important to understand that when MBX2016 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value. But how does MBX2016 choose which legacy Client Access server to proxy the connection?

When a MBX2016 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, MBX2016 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping. MBX2016 expects a response - a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, MBX2016 immediately retries to determine if the error was a transient error. If this second attempt fails, MBX2016 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), MBX2016 will attempt to determine the health state of the down CAS to determine if it is available.

The IIS log on a legacy Client Access server will contain the ping events. For example:

2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 302 0 0 277 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 309 177 15
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 245 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 301 0 0 213 169 171
2015-08-11 14:00:01 W3SVC1 DF-C14-02 192.168.1.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 293 194 31
2015-08-11 14:00:04 W3SVC1 DF-C14-02 192.168.1.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 261 170 171

If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010:

Set-ClientAccessServer <server> -IsOutofService $True

IMAP & POP Coexistence

All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2016 Client Access component to a target server (whether that be an Exchange 2016 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services.

When the Exchange 2016 Client Access component receives a POP or IMAP request, it will authenticate the user and perform a service discovery.

If the target mailbox is E2010, MBX2016 will enumerate the POP or IMAP InternalConnectionSettings property value for each Exchange 2010 Client Access server within the mailbox’s site. Therefore, it is important to ensure that the InternalConnectionSettings maps to the server's FQDN, and not a load-balanced namespace.

MBX2016 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, MBX2016 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, MBX2016 will try to locate a plaintext proxy target first, SSL next, TLS lastly.

Important: Exchange 2016 Mailbox servers do not validate that the POP or IMAP services are actually running on the target Client Access servers. It's important, therefore, to ensure that the services are running on every legacy Client Access server if you have POP or IMAP clients in your environment.

Conclusion

Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with Exchange 2010. Please let us know if you have any questions.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

As you can see from the above diagram, this environment contains three Active Directory sites:

• Internet Facing AD Site (Site1) - This is the main AD site in the environment and has exposure to the Internet. This site has Exchange 2013 and Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure.
• Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 infrastructure located within this AD site.
• Non-Internet Facing AD Site (Site3) - This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure.

Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURLproperty populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records for all Client Access servers resolve to the CAS2013 infrastructure located in Site1. Outlook clients, ActiveSync clients (on initial configuration), and EWS clients will submit Autodiscover requests to the CAS2013 infrastructure and depending on the mailbox version, different behaviors occur:

1. For mailboxes that exist on Exchange 2010, CAS2013 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
2. For mailboxes that exist on Exchange 2013 (Purple User), CAS2013 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Note: The recommended practice is to configure the Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUrito a value that resolves to the internal load balanced VIP for the 2013 Client Access servers in your environment.

For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.

Outlook Anywhere & MAPI/HTTP Clients

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.

When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the OutlookUpdates for more information). Outlook will process the ExHTTP in order – internal first and external second.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must use different names for Outlook Anywhere inside and out. Outlook will also prefer the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings. By utilizing two namespaces, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2013 (and Exchange 2016) internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs embedded in the HTTP protocol and obtain the data.

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response.

Outlook Web App

For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version, where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3.
4. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.

Exchange ActiveSync

For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

Note: Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com.

To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the five users.

Autodiscover

Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request as follows.

1. For mailboxes that exist on Exchange 2010, CAS2013/MBX2016 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
2. For mailboxes that exist on Exchange 2013 (Purple User), CAS2013/MBX2016 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.
3. For mailboxes that exist on Exchange 2016 (Yellow User), CAS2013/MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Outlook Anywhere & MAPI/HTTP Connectivity

For Outlook Anywhere’s connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component will receive the incoming connections, authenticate and choose which server to route the request to (regardless of version), and proxy the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server or Exchange 2016 Mailbox server).

For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013/MBX2016 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013/MBX2016 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
5. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Outlook on the web

For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
5. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013/MBX2016 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.

Exchange ActiveSync

The Exchange 2013 Client Access server or Exchange 2016 Mailbox server will receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server, or Exchange 2016 Mailbox server).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013/MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013/MBX2016 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
5. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the YellowUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
5. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Offline Address Book

Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
2. For the Yellow User andPurple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

Conclusion

Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with both Exchange 2010 and Exchange 2013. Please let us know if you have any questions.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

When installing a brand new Exchange server, there are several things that you should consider. One of them is that things will go smoother if you deploy a new currently supported version of Exchange server into a live production environment by leveraging an Active Directory (AD) deployment site design option.

Whenever a new Exchange server that holds the Client Access Server Role, or any Exchange 2016 server, is installed the setup process adds a new Service Connection Point (SCP) record within Active Directory. SCP records are used by internal domain joined clients and applications to locate the Autodiscover service. Depending on your environment’s configuration, there is a chance clients may see this new SCP record and begin sending Autodiscover requests directly to the new server before you have had a chance to configure it. However, since the default self-signed certificate is not trusted by clients, then any client contacting this new server will start presenting certificate errors to end users. This is not the best experience, and it is easily preventable!

To prevent clients from sending Autodiscover requests directly to this new server you may already be “nulling out” the new SCP record’s AutodiscoverServiceInternalUri value or setting it to your friendly load balanced URL. This step will ensure clients will either not attempt to use the SCP at all, or if they do they will be sent to your load balancer with valid certificates already in place. While either method prevents clients from sending Autodiscover requests directly to the new server until you have had a chance to configure it, you are not out of the woods just yet. Clients sending Autodiscover requests to a server is only one half of the Autodiscover equation. We must also consider how Autodiscover responses are generated before being sent back to the clients.

It is important to understand the server receiving the Autodiscover request not simply use its own settings to create the response. Instead, the receiving server identifies what version mailbox the user has, identifies what Active Directory site the user’s mailbox is currently mounted in, identifies information about the client being used, and identifies whether or not the user’s mailbox site is Internet facing. Once the receiving server has all of the information it needs it will then determine where to obtain the values it will use to create the Autodiscover response. Some of the values will be chosen from a random server in the same AD site as the user’s mailbox, and if necessary due to the mailbox site being non-Internet facing other values will be from a random server in the AD site with the least cost path that is Internet facing. The receiving server then compiles the values and returns them in the form of a single Autodiscover response to the client. If your brand new Exchange server resides in the same AD site as the user’s mailbox or the chosen Internet facing site, then your clients have a chance of seeing certificate popups due to your new server’s virtual directories and Outlook Anywhere configuration still having the default FQDN values in place. For example if Outlook where to attempt to download your Offline Address Book using the new server’s default setting of https://exch2016-01.corp.contoso.com/oaby, then the client would see a certificate prompt.

With this understanding we now should understand there are two things required to prevent a new server from introducing certificate warnings in an environment. First, we must prevent the new server from getting any requests directly from clients. Second, we must prevent this server’s default values from being used in a response generated by any other Client Access Servers (or Exchange 2016 servers) that receives an Autodiscover request.

How to avoid this situation

AD is smart enough to be ‘most restrictive’ when a site subnet is defined. If you have a 192.168.0.x/24 subnet defined to an AD Site and a more restricted subnet of 192.168.0.1/32 to a different AD Site, the most restricted value is defined for that AD Site. (Note: a /32 is a single IP address, which would be enough for a single server deployment.)

Some options exist that you can leverage:

• Keep reusing the same IP to deploy a server, and then change the IP of that server once the URL’s are configured and the certificate is installed.
• Change the subnet definition in AD Sites and Services for each server you build and its’ specific IP address.
• Use a small subnet with several IP’s available, like a /29 subnet, which has 6 IP addresses (192.168.0.128/29) (range: 192.168.0.129-192.168.0.134), and setup up to 6 new Exchange servers. Then once they are fully configured, just remove the /29 subnet from AD Sites and Services, bounce the Exchange servers, reset the AutoDiscoverSiteScope values, and then they’ll answer proper values to your clients.

What AD Site is the server in?

Before you install Exchange, check to see what AD site the server is in. In PowerShell on the local Exchange server:

nltest /dsgetsite

After you install Exchange, you can change the IP or change the AD Site subnet definition, restart the server, and update the AutoDiscoverSiteScope value. Check the server again to ensure it is in the correct AD Site and also check to see if the other Exchange servers think it is in the correct AD Site by running:

Get-ExchangeServer | FT Name,Site –Autosize

And to see the Exchange AutoDiscoverSiteScope values: (pre-2016 server)

Get-ClientAccessServer | FT Name,AutoDiscoverSiteScope –Autosize

Or 2016 and above:

Get-ClientAccessService | FT Name,AutoDiscoverSiteScope –Autosize

One last step after you’ve either changed the IP of the server, or removed the AD site, you need to update the AutoDiscoverSiteScope. In PowerShell:

Set-ClientAccessService <server name> –AutoDiscoverSiteScope <name of AD Site>

You can then re-run the Get cmdlet to confirm that the values are what you need for your environment. This will help ensure that you typed the correct AD Site information in the previous cmdlet.

Conclusion

This process helps to ensure that clients will not be getting annoying pop-ups while you are installing additional Exchange servers into your production environment. It is still best to follow your companies change process and inform end users of potential notifications, but this should eliminate any unexpected Outlook interruptions.

Mike O'Neill

The Exchange team is announcing the availability of our latest quarterly update for Exchange Server 2013 as well as updates for Exchange Server 2010 Service Pack 3 and Exchange Server 2007 Service Pack 3.

Cumulative Update 11 for Exchange Server 2013 and UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 11 contains the latest set of fixes and builds upon Exchange Server 2013 Cumulative Update 10. The release includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved can be found in Knowledge Base Article KB3099522. Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 11. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 11 directly.

Cumulative Update 11 does not include updates to Active Directory Schema, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to CU11. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.

We are also releasing Update Rollup 12 for Exchange Server 2010 Service Pack 3 (KB3096066). The Exchange Server 2010 update includes a DST update as well as a collection of important fixes. Update Rollup 18 for Exchange Server 2007 Service Pack 3 (KB3078672) is also being released. Update Rollup 18 is primarily a DST fix with an additional opportunistic fix.

We would like to call attention to two particularly important changes included in these updates:

• Cumulative Update 11 and Update Rollup 12 each contain a time zone calculation fix to resolve the issue reported in KB3048372 – Exchange Calendar Items are shifted incorrectly when some Windows DST updates are applied. Customers in impacted time zones are encouraged to deploy these updates to address the issue identified after the release of the OS time zone changes in KB3039024.
• Cumulative Update 11 also includes a change in behavior when deploying/administering Exchange Server 2013 in a co-existent manner with Exchange Server 2010 or 2016. These changes are outlined in the following blog article: Exchange Management Shell and Mailbox Anchoring.

For our customers running Exchange Server 2016, Exchange Server 2016 Cumulative Update 1 will be added to our next set of quarterly updates for Exchange Server.

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU11) or the prior (e.g., CU10) Cumulative Update release.

For the latest information and product announcements please read What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post was published.

The Exchange Team

The Office 365 Hybrid Configuration wizard has been updated to support Exchange 2010. This new wizard comes with the following advantages:

• An updated user experience that simplifies the hybrid configuration process
• The error handling experience allows for simple remediation of issues, meaning you can actually read and understand the error
• Fixes for HCW can happen quickly and are no longer tied to the on-premises product release cycle
• Inefficient code that caused the HCW to take hours to run has been completely reworked and now you should be in and out in minutes
• Many more enhancements explained in our previous blog post

Please stop using the old HCW for Exchange 2010 that was bundled in the Exchange 2010 Exchange Management Console and instead use the Office 365 Hybrid Configuration wizard.

Video Walkthrough of the new experience

The following is a short video that walks you through the new Office 365 Hybrid Configuration wizard experience for Exchange 2010:

How to run the HCW in your Exchange 2010 environment

In order to run the new Office 365 Hybrid Configuration wizard, you need to change one behavior. Instead of going to the on-premises Exchange Management Console in Exchange 2010, open the Exchange Admin Center in Exchange Online. To do this follow these steps:

1. From a Domain joined machine, go to http://portal.office.com and log in with your tenant administrator credential

2. From the portal landing page select the Admin Icon

3. In the left tree menu of the admin page, expand ADMIN then select Exchange to open the Exchange Admin Center

4. On the Left side of the Exchange Admin Center select the Hybrid node, then select the Configure button to download the wizard

Alternatively, you can click on this link: http://aka.ms/HybridWizard to directly download the new wizard instead.

NOTE: We do plan on updating the Exchange Management Console in Exchange 2010 SP3 RU13 with the new HCW, but there is no reason to wait for that. Just click on the link to the HCW when you are ready to run it, there is no need to even open the EMC.

A few common questions answered:

Why did we update the Office 365 Hybrid Configuration wizard for Exchange 2010?

The new Office 365 Hybrid Configuration wizard, which was released a few months back for Exchange 2013 and 2016, has allowed us to really understand the Hybrid Configuration experience. We can see if there was a failure or slow experience, what the issue was, and we collect and act on any feedback that is provided. All of this telemetry allows us on the engineering side to prioritize and address the issues that need to be addressed quickly. Since we have included Exchange 2010 support in this wizard, now all hybrid customers will see these benefits.

To find out more about the benefits of running the new HCW you can review our previous blog were we introduced the Office 365 Hybrid Configuration wizard.

What Update needs to be installed for the new wizard to work against Exchange 2010?

All you need is Exchange 2010 service pack 3, we do not check for the existence of any rollups. However, newer rollups will have plenty of code and security fixes, so (while not required for HCW to complete) I would make sure you try to stay current. To see the list of the latest updates for each version of Exchange go here.

Can I run the new wizard even though I have already run the old HCW in my environment?

Yes, the new wizard will run even if the old wizard completed or partially completed in your environment. If there is no reason for you to update your old configuration you do not need to run the wizard now, but the next time you have an update to make you should use this new experience.

Is this new hybrid wizard different than the Exchange 2013/2016 hybrid wizard that was announce a few months back?

No, this is the same wizard. However, the wizard has been updated to support the unique configurations that are required for Exchange 2010 Hybrid environments. For example, in a 2010 Hybrid environment you need additional Remote Domain configurations for mail flow features. These Exchange 2010 Explicit configurations needed to be added.

Is this new wizard considered BETA or test software?

No, in fact this is the supported way to configure hybrid moving forward.

Conclusion

Do you want to shave hours off of your hybrid deployment, have a more stable environment, and want to simplify the hybrid configuration experience? Stop using the old Hybrid Configuration wizards and use the new Office 365 Hybrid Configuration wizard instead. If you have an issue or any feedback on the wizard, provide it, there is a feedback button on every page in the wizard and we are eager to read and act on it.

Spread the word to anyone that you know who has run or is getting ready to run the Hybrid Configuration wizard.

Office 365 Hybrid Team

The Exchange team is happy to announce our spring quarterly updates for Exchange Server are now available on the Microsoft Download Center. Exchange Server 2016 receives its first Cumulative Update, and Exchange Server 2013 Cumulative Update 12 is also released. Exchange Server 2007 and Exchange Server 2010 Update Rollups provide an updated OWA S/MIME control signed with a SHA-2 certificate. More information and highlights of all these releases can be found below.

Updated OWA S/MIME control

All of the packages released today include an update to the OWA S/MIME control. The control itself has not changed, but has now been signed with a SHA-2 compliant certificate. All of the updates released will install the updated control onto the Exchange Server. Users who have installed the control into their browser will need to re-install this onto devices where the previous version was installed. Installing the control is straight forward and can be done quickly using OWA Options, Exchange Control Panel or Exchange Admin Center depending upon the release of Exchange you are using.

New distribution package for Exchange Server 2016 updates

With the introduction of Cumulative Updates for Exchange Server 2016, we are making a change to the update package type for this product version. Previous versions of Exchange used self-extracting packages to deliver service packs and cumulative updates. We have heard requests to release these updates as .ISO’s. With the capability to mount .ISO’s directly in Windows Server 2012 and later, we think it makes sense to ship Cumulative Updates as .ISO’s. At this time, we are not planning to do this for Exchange Server 2013 Cumulative Updates but could be persuaded to do so if enough people ask for it. One down side to this approach is that the package is much larger. However, copying a single .ISO vs. the ever growing number of files and folders over the network is much more efficient and faster. We hope you like this change.

Change to Mailbox Anchoring for Remote PowerShell

We heard your feedback on the changes to load balancing Remote PowerShell introduced into Exchange Server 2013 and 2016. As announced by Ross here, we have reverted this behavior in the Cumulative Updates being released today.

Additional languages for Outlook on the Web

Exchange Server 2016 Cumulative Update 1 adds support for 17 additional languages in Outlook on the Web. These languages will appear automatically in the language selection drop down after a server is updated to Cumulative Update 1.

.Net 4.6.1 Support

We know that many of you have been asking about .Net 4.6.1 and Exchange. Rest assured we are working closely with the .Net Framework team to resolve issues preventing us from supporting .Net 4.6.1 with Exchange Server. While we are not there yet, we hope to be very soon. Support for .Net 4.6.1 is planned for future Cumulative Updates for Exchange Server 2013 and 2016.

Slow installations on Windows Server 2012 R2

For customers who are running Exchange on Windows Server 2012 R2, we want to make certain you are aware of a condition which can substantially increase the amount of time it takes to install Exchange Updates on this OS. Working with the .Net team, we have discovered that systems which have applied Windows Update KB3097966 can take 50% more time to install Exchange. The .Net team is working on a resolution to this and will include a fix in a future product update. In the meantime, customers who have deployed this Windows update can take a one-time action on their server before installing Exchange or a Cumulative Update to bring installation time back to normal. This procedure needs to be done once on every Exchange server running Windows Server 2012 R2. The command to execute is:

“%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update”

Errors and warnings encountered running this command can be safely ignored provided the final exit status code of 0 is reported in the output.

Support for Standalone Hybrid Configuration Wizard in Exchange Server 2010

Customers using Exchange Server 2010 in Hybrid mode with Office 365 will notice a new link in the EMC to use the Updated Standalone Hybrid Configuration Wizard. We encourage all customers to use this updated version of the Hybrid Configuration Wizard.

Release Details

KB articles which contain greater depth on what each release includes are available as follows:

• Exchange Server 2016 Cumulative Update 1 (KB3134844), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 12 (KB3108023), Download, UM Lang Packs
• Exchange Server 2010 Service Pack 3 Update Rollup 13 (KB3141339), Download
• Exchange Server 2007 Service Pack 3 Update Rollup 19 (KB3141352), Download

Note: Documentation may not be fully available at the time this post was published.

Exchange Server 2016 Cumulative Update 1 does include updates to Active Directory Schema. These updates will apply automatically during setup if the permissions and AD requirements are met during installation. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin should execute SETUP /PrepareSchema before installing Cumulative Update 1 on your first server. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.

Exchange Server 2013 Cumulative Update 12 does not include updates to Active Directory or additional RBAC changes. However, depending on the version you are upgrading from, it may be required. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission, otherwise, setup will require you to re-run setup with sufficient permissions.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU12) or the prior (e.g., CU11) Cumulative Update release.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

The Exchange Team

We are happy to announce the fact that the Exmon tool (aka Microsoft Exchange Server User Monitor) for Exchange 2013 and 2016 is now available!

http://aka.ms/exmon2013

Please note that once you press the Download button, you can also download the updated documentation for this version, in PDF format.

Thanks to Jeff Mealiffe and Nasir Ali for all the work they did to make this possible!

Nino Bilic

The Office 365 Hybrid Configuration wizard has been updated to support Exchange 2010. This new wizard comes with the following advantages:

• An updated user experience that simplifies the hybrid configuration process
• The error handling experience allows for simple remediation of issues, meaning you can actually read and understand the error
• Fixes for HCW can happen quickly and are no longer tied to the on-premises product release cycle
• Inefficient code that caused the HCW to take hours to run has been completely reworked and now you should be in and out in minutes
• Many more enhancements explained in our previous blog post

Please stop using the old HCW for Exchange 2010 that was bundled in the Exchange 2010 Exchange Management Console and instead use the Office 365 Hybrid Configuration wizard.

Video Walkthrough of the new experience

The following is a short video that walks you through the new Office 365 Hybrid Configuration wizard experience for Exchange 2010:

How to run the HCW in your Exchange 2010 environment

In order to run the new Office 365 Hybrid Configuration wizard, you need to change one behavior. Instead of going to the on-premises Exchange Management Console in Exchange 2010, open the Exchange Admin Center in Exchange Online. To do this follow these steps:

1. From a Domain joined machine, go to http://portal.office.com and log in with your tenant administrator credential

2. From the portal landing page select the Admin Icon

3. In the left tree menu of the admin page, expand ADMIN then select Exchange to open the Exchange Admin Center

4. On the Left side of the Exchange Admin Center select the Hybrid node, then select the Configure button to download the wizard

Alternatively, you can click on this link: http://aka.ms/HybridWizard to directly download the new wizard instead.

NOTE: We do plan on updating the Exchange Management Console in Exchange 2010 SP3 RU13 with the new HCW, but there is no reason to wait for that. Just click on the link to the HCW when you are ready to run it, there is no need to even open the EMC.

A few common questions answered:

Why did we update the Office 365 Hybrid Configuration wizard for Exchange 2010?

The new Office 365 Hybrid Configuration wizard, which was released a few months back for Exchange 2013 and 2016, has allowed us to really understand the Hybrid Configuration experience. We can see if there was a failure or slow experience, what the issue was, and we collect and act on any feedback that is provided. All of this telemetry allows us on the engineering side to prioritize and address the issues that need to be addressed quickly. Since we have included Exchange 2010 support in this wizard, now all hybrid customers will see these benefits.

To find out more about the benefits of running the new HCW you can review our previous blog were we introduced the Office 365 Hybrid Configuration wizard.

What Update needs to be installed for the new wizard to work against Exchange 2010?

All you need is Exchange 2010 service pack 3, we do not check for the existence of any rollups. However, newer rollups will have plenty of code and security fixes, so (while not required for HCW to complete) I would make sure you try to stay current. To see the list of the latest updates for each version of Exchange go here.

Can I run the new wizard even though I have already run the old HCW in my environment?

Yes, the new wizard will run even if the old wizard completed or partially completed in your environment. If there is no reason for you to update your old configuration you do not need to run the wizard now, but the next time you have an update to make you should use this new experience.

Is this new hybrid wizard different than the Exchange 2013/2016 hybrid wizard that was announce a few months back?

No, this is the same wizard. However, the wizard has been updated to support the unique configurations that are required for Exchange 2010 Hybrid environments. For example, in a 2010 Hybrid environment you need additional Remote Domain configurations for mail flow features. These Exchange 2010 Explicit configurations needed to be added.

Is this new wizard considered BETA or test software?

No, in fact this is the supported way to configure hybrid moving forward.

Conclusion

Do you want to shave hours off of your hybrid deployment, have a more stable environment, and want to simplify the hybrid configuration experience? Stop using the old Hybrid Configuration wizards and use the new Office 365 Hybrid Configuration wizard instead. If you have an issue or any feedback on the wizard, provide it, there is a feedback button on every page in the wizard and we are eager to read and act on it.

Spread the word to anyone that you know who has run or is getting ready to run the Hybrid Configuration wizard.

Office 365 Hybrid Team

If you’re running Exchange 2013 and you’ve configured a hybrid deployment with Office 365, this post contains important information that might impact you. Please evaluate this information and take any necessary action before April 15, 2016. If your latest run of the Hybrid Configuration Wizard was initiated from Exchange 2010 than you are NOT affected.

Note: This information is now also published in KB3145044.

On April 15 2016, the Office 365 TLS certificate will be renewed. This certificate is used by Office 365 to provide TLS encryption between Office 365 and external SMTP servers. The new certificate, which will help improve the security of mail sent to and from Office 365, will be issued by a new Certificate Authority and it will have a new Issuer and Subject.

This change has the potential to stop hybrid mailflow between Office 365 and your on-premises Exchange servers if one of the following conditions applies to you:

• Your on-premises Exchange servers are running Exchange 2013 Cumulative Update 8 (CU8) or lower.
• You’ve upgraded the Exchange 2013 servers that handle hybrid mailflow to Exchange 2013 CU9 or higher. However, since upgrading to CU9, you HAVE NOT re-run the Hybrid Configuration wizard (either from the Exchange Admin Center or via the direct download link).

If one of the previous conditions applies to your organization, hybrid mailflow between Office 365 and your organization will stop working after April 15, 2016 unless you complete the steps below.

Note: This only affects hybrid mailflow. Regular mailflow and TLS encryption is NOT affected.

How to keep hybrid mail flowing (MUST be completed before 4/15/2016)

Let the new Hybrid Configuration wizard do it for you

You can use the latest Hybrid Configuration wizard (HCW) to configure your Exchange 2013 servers to work with the new TLS certificate. Just follow these steps:

1. If the Exchange 2013 servers handling hybrid mailflow are running Exchange 2013 CU8 or lower, follow the instructions in Updates for Exchange 2013 to install the latest cumulative update on at least one server.
2. After you install the latest cumulative update, download the new HCW application and run the wizard following the instructions here .

Note: For information on which releases of Exchange are supported with Office 365, see Hybrid deployment prerequisites.

Manual update

If you can’t upgrade Exchange 2013 to latest cumulative update right now (although we would like to remind you of our support policy), you can manually configure your servers to work with the new TLS certificate. On each Exchange 2013 server that’s used for hybrid mailflow, open the Exchange Management Shell, and run the following commands:

$rc=Get-ReceiveConnector |where {$_.TlsDomainCapabilities -like "*MSIT Machine Auth CA 2*"}

$rc | foreach {Set-ReceiveConnector -Identity $_.identity -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail”}

Office 365 Hybrid Team

In Exchange 2013 CU11, we introduced a change to the way Remote PowerShell (RPS) functioned.

Prior to CU11, Exchange 2013 routed Remote PowerShell requests by finding a random mailbox that is either higher than the ExchClientVer that is specified in the URL, or if the ExchClientVer is not specified, by using the current CAS version in which the client connected. We refer to this behavior as server version-based routing.

With CU11, we changed Remote PowerShell to route requests to an anchor mailbox. Typically, this anchor mailbox would be the mailbox of the user attempting the connection. In the event the user attempting the connection did not have a mailbox, the request would be routed to the organization arbitration mailbox.

There were several perceived benefits with this approach:

1. This approach solved an issue with coexistence and ensured that RPS is executed based on the version of the mailbox executing the action. The server version-based routing behavior prior to CU11 led to scenarios where a client could receive the following error:

   New-PSSession : [ems.contoso.com] Processing data from remote server ems.contoso.com failed with the
   following error message: [ClientAccessServer=E2K13-1,BackEndServer=e2k13-1.contoso.com,RequestId=76229690-2343-4
   f-9a51-48184587c5cf,TimeStamp=8/14/2015 2:20:36 PM] [FailureCategory=WSMan-InvalidShellID] The request for the Window
   Remote Shell with ShellId DD266254-5C1F-43C0-A4DA-1797C253C0C0 failed because the shell was not found on the server.
   Possible causes are: the specified ShellId is incorrect or the shell no longer exists on the server. Provide the
   correct ShellId or create a new shell and retry the operation. For more information, see the
   about_Remote_Troubleshooting Help topic.
   At C:\Scripts\test.ps1:8 char:12
   + $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht …
   + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemoti
   gTransportException
   + FullyQualifiedErrorId : CannotConnectTargetSessionDoesNotExist,PSSessionOpenFailed
   Import-PSSession : Cannot validate argument on parameter 'Session'. The argument is null. Provide a valid value for
   the argument, and then try running the command again.
   At C:\Scripts\test.ps1:10 char:18
   + Import-PSSession $Session
   + ~~~~~~~~
   + CategoryInfo : InvalidData: (:) [Import-PSSession], ParameterBindingValidationException
   + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.ImportPSSessionCommand

   This error occurs when a load balanced RPS request shifts from one version of Exchange to another, whether that be Exchange 2013 coexisting with Exchange 2016, or different versions of cumulative updates for the same version of Exchange.

2. This approach utilized the same code path for Remote PowerShell proxying in Office 365.

Unfortunately, the changes in CU11 introduced several issues with Remote PowerShell in the on-premises world that we did not anticipate. After reviewing each issue and performing an in-depth code review, we made the decision to revert the CU11 change and return to utilizing server version-based routing for Remote PowerShell requests beginning in Exchange 2013 CU12. Exchange 2016 (including CU1) will also use server version-based routing.

If you were planning to take advantage of the changes in Remote PowerShell routing in CU11, you may now be wondering what options are available to you beginning in CU12. Fortunately, you have several options:

1. When connecting to Exchange via Remote PowerShell, specify a server FQDN instead of a load balanced namespace.

   $cred = Get-Credential
   $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://servername.contoso.com/powershell -Authentication Kerberos -Credential $cred
   Import-PSSession $Session

   For more information, please see the TechNet article, Connect to Exchange servers using Remote PowerShell.

2. When connecting to Exchange via Remote PowerShell and specifying a load balanced namespace, specify the ExchClientVer value for the server version you wish to connect against.

   $cred = Get-Credential
   $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://lb.contoso.com/powershell?serializationlevel=Full;ExchClientVer=15.0.225.0" -Authentication Basic -Credential $cred
   Import-PSSession $Session

3. Configure the load balancer to use session affinity for Remote PowerShell requests.
4. Remove the older Exchange versions from the load balanced pool.

We will continue to evaluate ways we can improve the routing of Remote PowerShell requests for on-premises deployments.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

The high availability capabilities of the lagged database copy are enhanced in the upcoming release of Exchange 2016 Cumulative Update 1.

ReplayLagManager

As you may recall, lagged copies can care for themselves by invoking automatic log replay to play down the log files in certain scenarios:

• When a low disk space threshold (10,000MB) is reached
• When the lagged copy has physical corruption and needs to be page patched
• When there are fewer than three available healthy HA copies for more than 24 hours

Play down based on health copy status requires ReplayLagManager to be enabled. Beginning with Exchange 2016 CU1, ReplayLagManager is enabled by default. You can change this via the following command:

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $false

Deferred Lagged Copy Play Down

When one of the above conditions is triggered, the Replication Service will initiate a play down event for the lagged database copy. However, there are times where this may not be ideal. For example, consider the scenario where there are four database copies on a disk, one passive, one lagged, and two active. Initiating a play down event on the lagged copy has the potential to impact any active copies on that disk – replaying log files generates IO and introduces disk latency as the disk head moves, which impacts users accessing their data on the active copies.

To address this concern, beginning with Cumulative Update 1 for Exchange 2016, the lagged copy’s play down activity is tied to the health of the disk. When a play down event is initiated, the disk’s IO latency is evaluated:

1. If the disk’s read IO latency is above 25ms, the play down event is deferred. In the event that there is a disk capacity concern, the disk latency deferral will be ignored and the lagged copy will play down.
2. If the disk’s read IO latency is below 25ms, the play down event is allowed.

As a result, deferred lagged copy play down reduces the IO burstiness of lagged copy play down events and ensures that local active copies on the lagged copies disk are not affected. IO sizing of a lagged database copy does not change with this feature (nor does it affect the IO sizing of an active copy); you still must ensure there is available IO headroom in the event that the lagged copy becomes active.

Consider the following example:

The y axis is disk latency, measured in milliseconds. The x axis is a 24-hour period.

As you can see from the graph, between the hours of 1am to 9am, the disk IO latency is below 25ms, meaning that lagged copy replay is allowed. At 10am, the latency exceeds 25ms and this continues until about 2pm; during this time period, lagged copy replay is delayed or deferred. At 2pm, the latency drops below 25ms and lagged copy replay resumes. Latency increases again at 3pm and the process repeats itself.

By default, the maximum amount of time that a play down event can be deferred is 24 hours. You can adjust this via the following command:

Set-MailboxDatabaseCopy <database name\server> -ReplayLagMaxDelay:<value in the format of 00:00:00>

If you want to disable deferred play down, you can set the ReplayLagMaxDelay value to 00:00:00.

The following events are recorded in the Microsoft-Exchange-HighAvailability/Monitoring crimson channel when log replay is deferred or resumed:

• Event 750 – Replay Lag Manager requested activating replay lag delay (suspending log replay) for database copy '%1\%2' after a suppression interval of %4. Delay Reason: %6"
• Event 751 – Replay Lag Manager successfully activated replay lag delay (suspended log replay) for database copy '%1\%2'. Delay Reason: %4"
• Event 752 – Replay Lag Manager failed to activate replay lag delay (suspend log replay) for database copy '%1\%2'. Error: %4"
• Event 753 – Replay Lag Manager requested deactivating replay lag (resuming log replay) for database copy '%1\%2' after a suppression interval of %4. Reason: %5"
• Event 754 – Replay Lag Manager successfully deactivated replay lag (resumed log replay) for database copy '%1\%2'. Reason: %4
• Event 755 – Replay Lag Manager failed to deactivate replay lag (resume log replay) for database copy '%1\%2'. Error: %4
• Event 756 – Replay Lag Manager will attempt to deactivate replay lag (resume log replay) for database copy '%1\%2' because it has reached the maximum allowed lag duration. Detailed Reason: %5

The following events are recorded in the Microsoft-Exchange-HighAvailability/Operational crimson channel when log replay is deferred or resumed:

• Event 748 – Log Replay suspend/resume state for database '%1' has changed. (LastSuspendReason=%3, CurrentSuspendReason=%4, CurrentSuspendReasonMessage=%5)
• Event 2050 – Suspend log replay requested for database guid=%1, reason='%2'.
• Event 2051 – Suspend log replay for database guid=%1 succeeded.
• Event 2052 – Suspend log replay for database guid=%1 failed: %2.
• Event 2053 – Resume log replay requested for database guid=%1.
• Event 2054 – Resume log replay for database guid=%1 succeeded.
• Event 2055 – Resume log replay for database guid=%1 failed: %2.

Summary

The changes discussed above continue our work in improving the Preferred Architecture by ensuring that users have the best possible experience on the Exchange platform.

As always, we welcome your feedback.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Did you know that today is 20 years since we declared RTM (Released to Manufacturing) of Exchange 4.0?

Okay, so maybe this did not happen in the galaxy far away, but it sure feels like it! Here is a great overview of Exchange's earlier years (up to Exchange 2007).

Exchange has been evolving for over 20 years now, and is still going strong! From our humble beginnings, adding SMTP protocol through an IMC connector as well as web access to email in Exchange 5.0 back in 1997 (that was some cutting edge stuff back then!), starting to play in service waters 10 years later in 2007 (ever heard of Exchange Labs?) all the way to where we are today with Exchange Server 2016 and Exchange Online – we have gone through many a transformation.

One thing is certain, though – we would not have been here without you, our customers. You keep pushing us to get better and bring you more features. When we do something wrong (yeah, that happens), the incredible Exchange community is always quick to let us know. And for those of you wishing that this virtual birthday celebration could somehow take place in person, you’ll want to sign up to attend Microsoft Ignite in Atlanta.

Thank you for all the support and amazing ride! Anyone up for 20 more?

(Hat tip, Tony.)

The Exchange Team

The Exchange team is happy to announce our spring quarterly updates for Exchange Server are now available on the Microsoft Download Center. Exchange Server 2016 receives its first Cumulative Update, and Exchange Server 2013 Cumulative Update 12 is also released. Exchange Server 2007 and Exchange Server 2010 Update Rollups provide an updated OWA S/MIME control signed with a SHA-2 certificate. More information and highlights of all these releases can be found below.

Updated OWA S/MIME control

All of the packages released today include an update to the OWA S/MIME control. The control itself has not changed, but has now been signed with a SHA-2 compliant certificate. All of the updates released will install the updated control onto the Exchange Server. Users who have installed the control into their browser will need to re-install this onto devices where the previous version was installed. Installing the control is straight forward and can be done quickly using OWA Options, Exchange Control Panel or Exchange Admin Center depending upon the release of Exchange you are using.

New distribution package for Exchange Server 2016 updates

With the introduction of Cumulative Updates for Exchange Server 2016, we are making a change to the update package type for this product version. Previous versions of Exchange used self-extracting packages to deliver service packs and cumulative updates. We have heard requests to release these updates as .ISO’s. With the capability to mount .ISO’s directly in Windows Server 2012 and later, we think it makes sense to ship Cumulative Updates as .ISO’s. At this time, we are not planning to do this for Exchange Server 2013 Cumulative Updates but could be persuaded to do so if enough people ask for it. One down side to this approach is that the package is much larger. However, copying a single .ISO vs. the ever growing number of files and folders over the network is much more efficient and faster. We hope you like this change.

Change to Mailbox Anchoring for Remote PowerShell

We heard your feedback on the changes to load balancing Remote PowerShell introduced into Exchange Server 2013 and 2016. As announced by Ross here, we have reverted this behavior in the Cumulative Updates being released today.

Additional languages for Outlook on the Web

Exchange Server 2016 Cumulative Update 1 adds support for 17 additional languages in Outlook on the Web. These languages will appear automatically in the language selection drop down after a server is updated to Cumulative Update 1.

.Net 4.6.1 Support

We know that many of you have been asking about .Net 4.6.1 and Exchange. Rest assured we are working closely with the .Net Framework team to resolve issues preventing us from supporting .Net 4.6.1 with Exchange Server. While we are not there yet, we hope to be very soon. Support for .Net 4.6.1 is planned for future Cumulative Updates for Exchange Server 2013 and 2016.

Slow installations on Windows Server 2012 R2

For customers who are running Exchange on Windows Server 2012 R2, we want to make certain you are aware of a condition which can substantially increase the amount of time it takes to install Exchange Updates on this OS. Working with the .Net team, we have discovered that systems which have applied Windows Update KB3097966 can take 50% more time to install Exchange. The .Net team is working on a resolution to this and will include a fix in a future product update. In the meantime, customers who have deployed this Windows update can take a one-time action on their server before installing Exchange or a Cumulative Update to bring installation time back to normal. This procedure needs to be done once on every Exchange server running Windows Server 2012 R2. The command to execute is:

“%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update”

Errors and warnings encountered running this command can be safely ignored provided the final exit status code of 0 is reported in the output.

Support for Standalone Hybrid Configuration Wizard in Exchange Server 2010

Customers using Exchange Server 2010 in Hybrid mode with Office 365 will notice a new link in the EMC to use the Updated Standalone Hybrid Configuration Wizard. We encourage all customers to use this updated version of the Hybrid Configuration Wizard.

Release Details

KB articles which contain greater depth on what each release includes are available as follows:

• Exchange Server 2016 Cumulative Update 1 (KB3134844), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 12 (KB3108023), Download, UM Lang Packs
• Exchange Server 2010 Service Pack 3 Update Rollup 13 (KB3141339), Download
• Exchange Server 2007 Service Pack 3 Update Rollup 19 (KB3141352), Download

Note: Documentation may not be fully available at the time this post was published.

Exchange Server 2016 Cumulative Update 1 does include updates to Active Directory Schema. These updates will apply automatically during setup if the permissions and AD requirements are met during installation. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin should execute SETUP /PrepareSchema before installing Cumulative Update 1 on your first server. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.

Exchange Server 2013 Cumulative Update 12 does not include updates to Active Directory or additional RBAC changes. However, depending on the version you are upgrading from, it may be required. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission, otherwise, setup will require you to re-run setup with sufficient permissions.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU12) or the prior (e.g., CU11) Cumulative Update release.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

The Exchange Team

If you’re an Exchange Online or Exchange Online Protection (EOP) subscriber and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action at your earliest convenience.

The change will impact you if one of the following scenarios apply to your organization:

• Your organization needs to send NDR (non-delivery report) messages to a recipient on the Internet and needs to relay them through Office 365.
• Your organization needs to send messages from your own email server (on-premises environment) from domains that your organization has not entered in Office 365 (see Add Domains in Office 365). For example, your organization Contoso needs to send email as the domain fabrikam.com, which doesn’t belong to your organization.
• There is a forwarding rule configured on your on-premises server, and messages need to relay through Office 365. For example, contoso.com is your organization’s domain, a user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding. All her messages go to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization.

Beginning February 1, 2017, Office 365 will no longer by default support relaying messages for the scenarios described above. If your organization needs those scenarios to continue to work, you need to make sure that the following are all true:

• You have created a connector in Office 365 that instructs the service to use certificate to authenticate emails coming from your organization’s own email server (on-premises environment).
• Your own email server (on-premises environment) is configured to use the certificate to send email to Office 365.
• This certificate is CA signed and its certificate name (CN) or subject alternative name (SAN) contains a domain that you have entered in Office 365.

To do so, use the following instructions.

Create or Edit a certificate-based connector in Office 365

For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps.

1. Sign in to Office 365 admin center, and go to Admin > Exchange.

2. Go to mail flow > connectors, and do one of the following:

If there are no connectors, choose ’+’ (Add) to create a connector.

If a connector already exists, select the connector, and choose Edit to modify it.

3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your on-premises server is the sending source for your messages.

4. Enter connector name and other information, and then choose Next.

5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match with the CN name or SAN in the certificate that you’re using. The domain you use needs to be a domain that belongs to your organization and you need to have added the domain to Office 365. For example, contoso.com belongs to your organization, and it’s part of CN name or SAN name in the certificate that your organization uses to communicate with Office 365.

Configure your on-premises environment

Use the following steps to prepare your on-premises servers to relay messages through Office 365:

1. If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section.
2. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access.

For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365.

Carolyn Liu

Today marks the start of the one-year countdown before Exchange Server 2007 reaches the end of extended support. If Exchange Server 2007 is still part of your messaging infrastructure, it’s not too early to start planning an update.

It’s hard to believe that it’s been 9+ years since we released CCR, LCR and SCR. These technologies of course laid the ground work for the Database Availability groups we’ve relied upon since Exchange Server 2010. Exchange Server 2007 also marked the start of the transition to building Exchange Server on .Net Frameworks as well. We have continued that investment and the .Net Frameworks is now the foundation of all critical Exchange processes in Exchange Server 2013, 2016 and Office 365. PowerShell, also new to Exchange Server 2007, is even more prevalent in current versions of Exchange and is the de facto management tool for modern Exchange Servers.

As revolutionary as Exchange Server 2007 was at the time, our latest versions of Exchange Server and Office 365 have even more to offer. Customers running Exchange Server 2007 have the option to upgrade via mailbox move to Exchange Server 2010, 2013 or migrate directly to Office 365. Customers wanting to migrate to our latest version of Exchange Server, Exchange Server 2016, will need to first decrement Exchange Server 2007. Customers wanting to maximize their on-premises server investment should strongly consider migrating to Exchange Server 2016 as Exchange Server 2013 is already three years into its own 10-year lifecycle.

Below are links which you may find helpful to start planning your migration off of Exchange Server 2007 and be on your way to experiencing the latest capabilities of Exchange Server.

• Microsoft Exchange Server Deployment Assistant
• Upgrade from Exchange Server 2007 to Exchange 2013
• Planning and Deployment of Exchange Server 2016
• Office 365 Fast Track Center

The Exchange Team

Wanted to let you all know that it is not your imagination, our blog does look quite different now.

We have moved blogging platforms and are figuring out how it all fits and how we can customize the look. In other words – there will be more changes in the future. The new blog URL is https://blogs.technet.microsoft.com/exchange/ but any of the older URLs should still be redirecting you here.

Thanks for your patience while we are working through this!

Some known issues:

– Search does not seem to return any results
– Most of the URLs tried redirect correctly, but there seem to be some that do not redirect to posts themselves but rather to the whole “month” of posts
– Currently, the new blog does not have the ability to email subscribe to new posts; we suggest subscribing to the blog feed instead

Nino Bilic

If you plan to implement Exchange Server 2016 or Exchange Online, or if you want to make sure that your implementation was done right, these online training courses are for you! We are excited to announce the release of four new edX online training courses for Microsoft Exchange Server 2016:

• Course 1x: Microsoft Exchange Server 2016 Infrastructure: Learn how to plan, configure, and manage Active Directory infrastructure requirements for Microsoft Exchange Server 2016.
• Course 2x: Microsoft Exchange Server 2016 Client Access Services: Find out how to plan and implement mobile messaging, Outlook, and secure Internet access to improve client access services.
• Course 3x: Microsoft Exchange Server 2016 Mailbox Databases: Get the details on planning and configuring mailbox databases, including backup, recovery, and restoration.
• Course 4x: Microsoft Exchange Server 2016 Transport Services: Explore planning and configuring message transport services, including anti-virus, malware-filtering, and spam-filtering solutions.

Each Exchange course is targeted to the IT Professional audience, with hands-on labs that reinforce student learning. Students are graded on completing each module, as well as on module assessment exams and a final course exam. A Certificate can be earned by completing each course with a passing grade. Courses are self-paced, allowing IT Professionals to build Exchange skills at their own pace as their schedules permit.

The first course, CLD208.1x: Microsoft Exchange Server 2016 Infrastructure, is free. The remaining three courses are for-fee courses, at a cost of $49 USD per course.

edX is a massive open online course (MOOC) provider that was developed by MIT and Harvard University. The Microsoft Learning Experiences team has created a wide range of online training courses for edX, and these four Exchange courses are the team’s latest Office releases. They are the first of seven courses that cover the core skills an Exchange administrator needs to proficiently design, implement, and manage an Exchange 2016 and Exchange Online implementation.

Microsoft Learning Experiences team

Customers currently in the process of finalizing a migration from legacy Public Folders in Exchange 2010/2007 to Modern Public Folders in Exchange Online or Exchange 2016/2013, should read KB3161916. We’ve identified a scenario which, although it doesn’t appear to be common, could result in a loss of data.  If you have previously completed a migration of legacy to modern public folders and believe you may have encountered data loss, please contact support services for additional assistance.

Exchange Team

Some of relatively common and difficult issues we see in support are related to Outlook connectivity to Exchange.  There are several variations that we classify as connectivity (related to server performance or otherwise).  They can include:

• Clients prompting for credentials (intermittently or continuously)
• Clients getting disconnected
• Clients are unable to establish a connection
• Clients freezing or going unresponsive

There are many factors that can contribute to these symptoms, and each one can lead down a completely different troubleshooting path. In this particular post we will focus on methods and tools to troubleshoot these. There are too many potential underlying causes to cover them all but hopefully this will serve as a good starting point for troubleshooting.

This post is not meant to be a post that you necessarily read from start to finish, but rather serve as a guidance for when you need to troubleshoot hard to find issues related to client connectivity. It can be a bit overwhelming, sure, but depending on the depth that you need to get into – it might be all worth it!

Note: If you are an Office 365 customer with users having mailboxes in Exchange Online, we highly recommend using our new Office 365 Support and Recovery Assistant (aka SaRA) to troubleshoot Outlook connectivity and other common issues. SaRA is available at http://diagnostics.office.com.

In every case, it’s best to spend some time understanding what the user is actually experiencing. Understanding the full client experience and effect can help determine the logging and troubleshooting path. When you define the users issue, you should also run the Microsoft Office Configuration Analyzer Tool (OffCAT) on the client to have a good view of configuration that can impact their experience.

Client configuration

Here are some examples of things to consider when troubleshooting these issues.

• Are the clients connecting with Outlook Anywhere or MAPI/HTTP? Try to use the Outlook “Connection Status” window to access more information on the user’s connection by holding down the CTRL key and clicking the Outlook icon in the system tray so that the “Connection Status” window appears. Here you can see the protocol, the connection type, and so on RPC/HTTP indicates Outlook Anywhere, whereas HTTP indicates MAPI/HTTP.

• Are clients online or in cached mode? Cached mode is recommended. Moving critical users to cached mode to improve their experience might be a good thing. You can enable BitLocker if there are local storage considerations. What devices are clients traversing to hit the CAS? Run Tracert to the CAS to determine the devices in the path of the client.
• Test several clients with a hosts file pointing to the IP address of CAS using the external host name. The Hosts file is located in C:\Windows\System32\Drivers\etc directory.
• What is the user attempting to do when they experience issues? Accessing a calendar, public folders or just moving around in the Inbox?
• Are effected mailboxes on the same database, same server?
• What is the Outlook full build number? Always make sure that you are working with an updated client. Information about recent updates can be found in the following references:
  • How to install the latest applicable updates for Microsoft Outlook
  • Outlook and Outlook for Mac Update File Versions
• Using the OffCAT output, examine which add-ins are being used and consider disabling those for testing. Make sure that you restart Outlook and verify the add-ins remain disabled.
• Try running Outlook in safe mode for a few clients. Not all add-ins are removed when using safe mode so ensure you have verified they are no longer loaded with Process Explorer if you suspect they are still loaded.
• Enable Outlook logging.

CAS configuration

The first step for the Exchange server checks is to review all the settings noted in TechNet article, Exchange 2013 Sizing and Configuration Recommendations. Several items such as setting power management to “High Performance” and verify the OS isn’t turning off power to the NIC. Making sure the server is running updated and supported .NET version, and so on are extremely important:

• Run the Exchange Performance Health Checker script. Review the output for any results that have to be updated.
• As of right now, Exchange 2013 should be running .NET 4.5.2. Please see the Supportability Matrix for current version supported.
• Turn off hyper-threading
• Update outdated Outlook clients
• Update NIC drivers
• Eliminate any slow disk issues identified in Perfmon
• Set Power Management to “High Performance”
• Locate the NIC “Properties |Configure | Power Management” and verify the box for “Allow the computer to turn off this device to save power” is unchecked.
• Verify RSS and Chimney offload on CAS.
• Verify that all the noted hotfixes are installed from Exchange 2013 Sizing and Configuration Recommendations.
• CAS Keep Alive values should be set to 30 minutes and no less than 15 minutes. If there’s no entry in the registry for KeepAliveTime then the value is 2 hours. This value, if not set correctly, can affect both connectivity and performance as noted in KB, Unable to connect using Exchange ActiveSync due to Exchange resource consumption. You must make sure that the load balancer and any other devices in the path from client to CAS be set correctly. More information on load balancer settings are listed later in this document under Load Balancing Configuration section. The goal is to set CAS with the lowest value so that client sessions when ended, are ended by the CAS and not by a device.

Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
Value name: KeepAliveTime
Value Type: 1800000 (30 minutes, in milliseconds) (Decimal)

• Max Core Count – In Exchange 2013 and 2016, you can encounter performance problems if you go too far off of the preferred architecture, particularly when referring to core count. This can even include having too many cores. The maximum number of cores on a server should be no more than 24. Hyper-threading can artificially inflate this value so it’s important to disable it as mentioned. For more information, refer to following articles:
  • Troubleshooting High CPU utilization issues in Exchange 2013
  • Ask the Perf Guy: How big is too BIG?
• As a general statement, Preferred Architecture should be your guidance.

Load balancer configuration

Please note that for 3rd party load balancer configuration, you should always refer to product documentation / guidance. The following are some general best practices and things we see misconfigured:

1. Verify the client TCP Idle Time-Out is a slightly larger value than the Keep Alive setting on CAS, as noted earlier.

In this example, we are using the 30-minute Keep Alive on CAS and we have both a firewall and load balancer in front of the clients. Here is the connection path.

Clients > Firewall > Load Balancer > CAS

In this example, if you have a firewall in the path from client to CAS, we are referencing the firewall “idle” time out and not the persistence time out. This value should be greater than the load balancer and the load balancer time out should be greater than CAS. Note that it is not recommended to go below 15 minutes for Keep Alive on CAS or TCP idle timeout on the load balancer.

Firewall time out = 40 minutes
LB TCP Idle time out = 35 minutes
CAS Keep Alive = 30 minutes

2. If the load balancer supports it, the preferred option is to configure it to use “Least Connections” with “Slow start” during typical operation.

With the “least connections” method, be mindful it is possible for a CAS to become overloaded and unresponsive during a CAS outage or during patching/maintenance. In the context of Exchange performance, authentication is an expensive operation.

The TechNet article Exchange 2013 Sizing and Configuration Recommendations describes the differences as:

A hardware or software load balancer should be used to manage all inbound traffic to Client Access servers. The selection of the target server can be determined with methods such as “round-robin,” in which each inbound connection goes to the next target server in a circular list, or with “least connections,” in which the load balancer sends each new connection to the server that has the fewest established connections at that time. These methods are detailed further in the following blog Load Balancing in Exchange 2013 and TechNet Load balancing.

3. For ActiveSync persistence setting, set the load balancer to use “Authorization header cookie” to avoid one CAS becoming overloaded because source IP will send all the connections to one server as per this.

Additional troubleshooting steps

If you have completed the previous steps and you are still experiencing issues, the following data is necessary:

• Start Perfwiz on CAS and Mailbox server to run for 4 hours during the busiest part of the day (assuming this is when issues are happening). Download ExPerfwiz from here. Example command line: \experfwiz.ps1 -server MBXServer -interval 10 -filepath D:\Logs. Once you have the performance data, see blog on Troubleshooting High CPU Utilization issues in Exchange 2013
• Review the application logs for any 4999 events that occurred around the time of problems.
• In the Application log, review the 2080 event to make sure that all domain controllers are responding with correct Boolean values. If there are any responses that are not accurate, the DC’s should be repaired or excluded.

Expected values are“CDG 1 7 7 1 0 1 1 7 1” as shown in the following table.

For testing, a DC can be excluded by using the Set-Exchangeserver –StaticExcludedDomainControllers parameter as shown in this section, however, troubleshooting Global Catalog access should also be done as soon as your testing is completed. Statically excluding a GC takes effect immediately and will be viewable on the next 2080 Event ID with all zero values. Some additional resources on the subject:

• The PDC column should show 0 and not be used by Exchange
• More information for Set-ExchangeServer is located here
• More information about Event ID 2080 from MSExchangeDSAccess can be found here
• When in Application log, also check for Event ID 2070 or 2095. A 2070 event occurs when Exchange tries to query a DC and fails and it cannot contact/communicate with a DC. If this event occurs during the time when clients have issues (or frequently), then it should be investigated. If you only see this event occasionally over several days, it could be a result of the DC being restarted during maintenance. The same is true with event 2095; infrequent isn’t a concern but continued logging of this event could be a sign of a problem.
• Always ensure MaxConcurrentApi bottlenecks are not present in the environment. To avoid this problem now or in future review the following information:
  • You are intermittently prompted for credentials or experience time-outs when you connect to Authenticated Services
  • Updated – NTLM and MCA Concerns
  • Quick Reference: Troubleshooting, Diagnosing, and Tuning MaxConcurrentApi Issues
• LDAP latencies can impact server and client performance. When you work with client connectivity issues, the LDAP counter can help point delays with communications to the DC’s. These are under the MSExchange ADAccess Domain Controllers(*) LDAP Read Time and LDAP Search Time, and is recommended that the average be within 50ms and spikes no greater than 100ms. More information here.

Coexistence with Exchange 2010 and 2007

In order to coexist with newer versions of Exchange, certain configuration steps are necessary. This section outlines typical organization changes that are needed to connect through an Exchange 2013 CAS.

• Verify that legacy servers are at the latest available Service Pack and RU.
• If Outlook Anywhere is not enabled on legacy Exchange servers, we recommend that you enable Outlook Anywhere on every CAS in the organization with NTLM authentication for ClientAuthenticationMethod and NTLM and Basic for IISAuthenticationMethods. The external host name should be the DNS name of the Exchange 2013 CAS external URL.

Example:
Enable-OutlookAnywhere -Server ‘ConE10′ -ExternalHostname Mail.Contoso.com’ -ClientAuthenticationMethod ‘Ntlm’ -SSLOffloading $false –IISAuthenticationMethod Basic, NTLM

• Configure the Exchange 2010 SCP for AutoDiscover to point to Exchange 2013 CAS. The AutoDiscover SCP is used for the internal clients only. In some cases, you can just update DNS to point to Exchange 2013. DNS would have to point AutoDiscover to Exchange 2013 for all the external clients also. We do not recommend that you use separate URL’s for legacy mailboxes. All connections should use an Exchange 2013 CAS.

To set the SCP for AutoDiscover (example):
Set-ClientAccessServer ConE10 -AutoDiscoverServiceInternalUri https://Mail.Contoso.com/autodiscover/autodiscover.xml

• Verify all legacy CAS are pointed to 2013 for the SCP AutoDiscover URI.

Example:
Get-ClientAccessServer |fl *uri*
AutoDiscoverServiceInternalUri : https://Mail.Contoso.com/autodiscover/autodiscover.xml

• Be aware that Exchange 2007 mailboxes will access EWS and OAB by using “Legacy.Domain.com” as discussed here.

Known issues in coexistence

• Mailboxes located on 2010 Unable to Connect through Exchange 2013
• Users may be prompted for credentials when accessing additional mailboxes, calendars or Public Folders on Exchange 2010 server. See #2 in the previous section indicating that NTLM is not enabled on legacy CAS for Outlook Anywhere.

Troubleshooting Logs and Tools

HTTP Proxy RPCHTTP Logs

In Exchange 2013, there are several logs in the logging folder. For Outlook clients one of the first logs to examine are the HTTP Proxy logs on CAS. The connection walk-through section shows the process that is used to connect to Exchange 2013. This complete process is logged in the HTTP Proxy log. Also, if it is possible, add Hosts file to the client for one specific CAS to reduce the number of logs.

The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp

HTTP Proxy AutoDiscover Logs

Exchange 2013 has HTTP Proxy logs for AutoDiscover that are similar to the logs shown earlier that can be used to determine whether AutoDiscover is failing.

The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\AutoDiscover

HTTP Error Logs

HTTP Error logs are failures that occur with HTTP.SYS before hitting IIS. However, not all errors for connections to web sites and app pools are seen in the httperr log. For example, if ASP.NET threw the error it may not be logged in the HTTP Error log. By default, HTTP error logs are located in C:\Windows\System32\LogFiles\HTTPERR. Information on the httperr log and codes can be found here.

IIS Logs

IIS logs can be used to review the connection for RPC/HTTP, MAPI/HTTP, EWS, OAB, and AutoDiscover. The full data for the MAPI/HTTP and RPC/HTTP is not always put in the IIS logs. Therefore, there is a possibility that the 200 connection successful may not be seen. IIS codes.

In Exchange 2013 IIS logs on the CAS should contain all user connections on port 443. IIS logs on the Mailbox server should only contain connections from the CAS server on port 444.

Most HTTP connections are first sent anonymously which results in a 401 challenge response. This response includes the authentication types available in the response header. The client should then try to connect again by using one of these authentication methods. Therefore, a 401 status found inside an IIS log does not necessarily indicate an error.

Note that an anonymous request is expected to show a 401 response. You can identify anonymous requests because the domain\username is not listed in the request.

RPC Client Access (RCA) Logs

The RCA logs can be used to find when a user has made a connection to their mailbox, or a connection to an alternate mailbox, errors that occur with the connection, and more information. RCA logs are located in the logging directory which is located at %ExchangeInstallPath%\Logging\RpcClientAccess. By default, these logs have a maximum size of 10MB and roll over when size limit is reached or at the end of the day (based on GMT), and the server keeps 1GB in the log directory.

Outlook ETL Logging

ETL logs are located in %temp%/Outlook Logging and are named Outlook-#####.ETL. The numbers are randomly generated by the system.

To enable Outlook logging

In the Outlook interface:

• Open Outlook.
• Click File, Options, Advanced.
• Enable “Enable troubleshooting logging (requires restarting Outlook)”
• Restart Outlook.

How to enable Outlook logging in the registry:

• Browse to HKEY_CURRENT_USER\Software\Microsoft\Office\xx.0\Outlook\Options\Mail
• DWORD: EnableLogging
• Value: 1
• Note: xx.0 is a placeholder for your version of Office. 15.0 = Office 2013, 14.0 = Office 2010

ExPerfwiz (Perfmon for Exchange)

You can use Perfmon for issues that you suspect are caused by performance. http://experfwiz.codeplex.com/

Exchange 2013 has daily performance logs that captures the majority of what is needed. These logs are by default located in C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs

Log Parser Studio

Log Parser Studio is a GUI for Log Parser 2.2. LPS greatly reduces complexity when parsing logs. Additionally, it can parse many kinds of logs including IIS Logs, HTTPErr Logs, Event Logs (both live and EVT/EVTX/CSV), all Exchange protocol logs from 2003-2013, any text based logs, CSV logs and ExTRA traces that were converted to CSV logs. LPS can parse many GB of logs concurrently (we have tested with total log sizes of >60GB).

Blog with tips/how to about LPS: http://blogs.technet.com/b/karywa/

Exmon tool (aka Microsoft Exchange Server User Monitor)

We use this tool to get detailed information about client traffic.

Hopefully this is helpful; we expect that we will make some updates to this checklist as time goes on!

Thanks to Brendon Lee, Marc Nivens, Nasir Ali, Louise Budrow and The Exchange Performance V-Team for technical review.

Charlene Weber