The parts which we will review are:
- The relationships between Exchange 2013 CAS and legacy Exchange CAS servers in Exchange 2013 coexistence environment
- The relationships between Exchange 2013 CAS and legacy Outlook Exchange clients in Exchange 2013 coexistence environment
- The required configuration setting that needed for “CAS to CAS communication” meaning:
1. Outlook Anywhere (RPC\HTTP) support and setting on the legacy Exchange CAS servers – The requirement of enabling the option of Outlook Anywhere (RPC\HTTP) on the legacy Exchange CAS servers
2. The authentication protocol settings-
The required setting of the authentication protocol that is involved in the Outlook client protocol connectivity flow:
- The authentication protocol that is used by Outlook client when he needs to provide his identity to the Exchange CAS server.
- The authentication protocol that is used by Exchange 2013 CAS when he proxy the Outlook user credentials to the Exchange CAS server legacy infrastructure.
In the last part of the article, we will provide a brief example of the implementation of the required configurations setting using PowerShell.
Article Table of content | Click to Expand
- Exchange 2013 coexistence environment and Outlook client | The required configuration settings
- RPC Endpoint name versus Exchange host name
- Outlook client protocol connectivity flow | The two interfaces
- Exchange 2013 coexistence environment | Outlook client | Required preparations check list
- Manage Exchange Outlook Anywhere settings
Article Series Table of content | Click to Expand
Exchange coexistence environment | Article Series
- Part 00/23 | The Exchange 2013 coexistence article series index page
- Part 01/23 | Exchange 2013 coexistence environment and client protocol connectivity flow | The prefix
- Part 02/23 | The importance of Exchange 2013 CAS in Exchange 2013 coexistence environment | Part 1/2
- Part 03/23 | The importance of Exchange 2013 CAS in Exchange 2013 coexistence environment | Part 2/2
- Part 04/23 | Exchange CAS server | Proxy versus redirection
- Part 05/23 | Exchange Public infrastructure | Public versus non Public facing Exchange site
- Part 06/23 | Exchange web services in an Exchange 2013 coexistence environment | Part 1/2
- Part 07/23 | Exchange web services in an Exchange 2013 coexistence environment | Part 2/2
- Part 08/23 | Exchange 2013 coexistence environment and the Exchange legacy infrastructure
- Part 09/23 | The checklist for preparing your Exchange 2007 infrastructure for
Exchange 2013 coexistence - Part 10/23 | The checklist for preparing your Exchange 2010 infrastructure for Exchange 2013 coexistence
- Part 11/23 | Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 1/2
- Part 12/23 | Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 2/2
- Part 13/23 | Basic concepts of Outlook connectivity in Exchange 2013 coexistence environment | Part 1/2
- Part 14/23 | Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2
- Part 15/23 | Manage legacy Exchange URL address using a PowerShell script
- Part 16/23 | Client protocol connectivity flow in Exchange 2013/2007 coexistence environment | Introduction and basic concepts| 1/4
- Part 17/23 | Autodiscover and Outlook client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 2/4
- Part 18/23 | OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 3/4
- Part 19/23 | ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 4/4
- Part 20/23 | Client protocol connectivity flow in Exchange 2013/2010 coexistence environment | Introduction and basic concepts| 1/4
- Part 21/23 | Autodiscover and Outlook client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 2/4
- Part 22/23 | OWA client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 3/4
- Part 23/23 | ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Client protocol connectivity flow in Exchange 2013/2007 coexistence environment
Client protocol connectivity flow in Exchange 2013/2010 coexistence environment
Exchange 2013 coexistence environment and Outlook client | The required configuration settings
To be able to demonstrate the flow in an Exchange 2013 coexistence environment, let’s use the following scenario:
Exchange site, which include Exchange CAS 2013 server + Exchange 2010 infrastructure (Exchange 2010 CAS server + Exchange 2010 Mailbox server).
An Exchange, Outlook client that his mailbox hosted at the Exchange 2010 Mailbox server, need access to his mailbox.
The Outlook client protocol connectivity flow, will be implemented as follows:
- Outlook client communication requests will be “pointed” to the Exchange 2013 CAS server.
- The communication channel between Outlook mail client and the Exchange 2013 CAS server must be implemented as “Outlook Anywhere” (RPC/HTTP/S).
RPC over HTTP/s is the default method for Outlook client connections – there are no more direct RPC connections to the servers for Outlook clients. - The Outlook client will provide the user credentials using an authentication protocol that is supported by the “server side”. The available options are: Basic, NTLM or negotiation.
- Because the user mailbox hosted at a “legacy Exchange infrastructure” (Exchange 2010 CAS server), Exchange 2013 CAS server, will proxy the Outlook communication request to the suitable legacy Exchange CAS server.
- In the process of “proxying” the request to the “legacy Exchange infrastructure” (Exchange 2010 CAS server), the Exchange CAS 2013 server will “forward” the user credentials to the “destination” legacy Exchange 2010 CAS server.
- To be able to “forward” the user credentials to the “legacy Exchange infrastructure” (Exchange 2010 CAS server), the authentication protocol settings for the Exchange 2013 CAS server + the “legacy Exchange infrastructure” (Exchange 2010 CAS server), must be set to NTLM.
RPC Endpoint name versus Exchange host name
The flow of legacy Exchange, Outlook client in an Exchange 2013 coexistence environment, could be sometimes confusing.
The general concept of this flow is that legacy Exchange, Outlook clients, will need to address the Exchange 2013 CAS as their “RPC Endpoint” server and in his turn, the Exchange 2013 CAS will need to proxy their request to the appropriate legacy Exchange CAS server.
We have mentioned before that in an Exchange 2013 coexistence environment; we will need to enable the Outlook Anywhere (RPC\HTTP) on each of the legacy Exchange CAS servers.
The primary configuration parameter that when enabling Outlook Anywhere (RPC\HTTP) on the Exchange CAS server is: the “external hostname.”
The external hostname is the RPC Endpoint name who “represent” the Exchange CAS server which provides the Outlook Anywhere (RPC\HTTP) services.
When Outlook client address Exchange CAS server, looking for Autodiscover information, part of the Autodiscover information that Exchange CAS server will provide, include a “reference” to the “Exchange CAS server” that is dedicated to serving the Outlook Anywhere client or in other words, can act as the RPC Endpoint server.
In the following screenshot, we can see an example of an “Autodiscover answer” that sent to the Outlook client by the Exchange CAS server.
In our example, the Exchange CAS server “tell” Outlook client that is the RPC Endpoint server name is: europe.mail.o365info.com
The information about the RPC Endpoint server appears in the section:
Protocol: Exchange HTTP under the server parameter.
In the Exchange 2013 coexistence environment, we need to change the default Outlook client protocol connectivity flow.
Instead of the configuration in which legacy Outlook client will connect a legacy Exchange CAS server which serves as an RPC Endpoint, in the Exchange 2013 coexistence environment, we need to implement a new configuration in which native Outlook client and legacy Outlook client will address only the Exchange 2013 CAS as – RPC Endpoint server.
Additionally, we need to enable the Outlook Anywhere service on each of the legacy Exchange CAS servers.
In our scenario, we want to use the following namespace: mail.o365info.com as the name if the RPC Endpoint that will be “published” to all the Outlook clients (native Exchange 2013 client and legacy Exchange clients such as 2007/2010).
When a legacy Exchange Outlook client addresses the Exchange 2013 CAS as the: “RPC Endpoint”, the Exchange 2013 CAS will know how to proxy the legacy Exchange Outlook client request to the proper legacy Exchange CAS server.
For this reason, when we enable the Outlook Anywhere service from a legacy Exchange CAS server, such as Exchange 2007/2010 CAS, we will need to set the value of the “external host name” using the “primary namespace” such as: mail.o365info.com
The namespace (mail.o365info.com in our scenario) will point to the Exchange 2013 CAS.
Outlook client will refer to the Exchange 2013 CAS as an RPC Endpoint using the name: mail.o365info.com
When the Exchange 2013 CAS needs to Proxy the request for the legacy Exchange CAS server, he will address the legacy Exchange CAS server\s by using the server “standard host name.”
In the following diagram, we can see an example of an Exchange 2010 Outlook client protocol connectivity flow.
Exchange 2010 client address the Exchange 2013 CAS using the host name: mail.o365info.com
Exchange 2013 CAS will proxy the Outlook client request to the Exchange 2010 CAS and address the Exchange 2010 CAS using the server name: Exc2010.o365info.com
In the following screenshot, we can see an example of the configuration setting that relates to the “external host name” in Exchange 2010 CAS.
In our example, we enable the Outlook Anywhere on the Exchange 2010 CAS + configure the value of the “external host name” to: mail.o365info.com
In case that you are wondering: what will happen if I use a different “external host name” for each of the existing Exchange CAS servers, the answer is that the Exchange 2013 CAS will provide a different RPC Endpoint name to Outlook client based on their “Exchange version.”
Outlook client protocol connectivity flow | The two interfaces
In the Exchange 2013 coexistence environment, Outlook client protocol connectivity flow is consisted of two parts:
- Outlook Exchange 2013 CAS communication
- Exchange 2013 CAS and Exchange CAS server legacy communication.
By looking at the following diagram, we can see the concept of the “two interface” or “two parts” that building the Outlook client protocol connectivity flow.
- The “A Part” is the area that describes the relationships between the Exchange 2013 CAS server and his Outlook client.
- The “B Part”, is the area that describes the relationships between the Exchange 2013 CAS server and the legacy Exchange CAS server infrastructure.
PART A| Outlook client and the “user credentials”
The “A part” of the Outlook client protocol connectivity flow is the “circle” that exists between the Outlook client and the Exchange 2013 CAS server.
The first part of the Outlook client protocol connectivity flow, start with the “authentication” in which Outlook client will need to provide the user credentials to Exchange CAS server.
In an Exchange environment, Outlook client can provide the user credentials using one of the following authentication protocols:
- NTLM
- Basic
- Negotiate
Just to make it more complicated, Exchange 2013 CAS server support to Outlook Anywhere interface: internal Outlook Anywhere interface + external Outlook Anywhere interface.
Each of these “interface”, can be configured using a different setting such as different authentication configuration.
In the Exchange 2013 environment, the “outcome” is that technically we can set two “sets” of Outlook Anywhere configuration settings:
One set of internal Outlook Anywhere client and another set for external Outlook Anywhere client while each of these “sets” uses the different authentication protocol.
To required Outlook Anywhere configuration setting implemented by using one of the following options:
- Exchange 2013 – Web-based management interface
- Exchange 2013 – PowerShell interface
The Exchange 2013 CAS server graphical (web) interface, enable us to choose the required authentication protocol. The authentication protocol that we will choose will apply to the booth of the Exchange 2013 CAS interfaces”: internal Outlook Anywhere interface + external Outlook Anywhere interface.
The disadvantage of the Exchange 2013 web-based management interface is, when we select a particular authentication protocol, the setting will apply to the booth of the Outlook Anywhere interface: the internal Outlook Anywhere interface + external Outlook Anywhere interface.
In other words, the Exchange 2013 CAS server graphical (web) interface doesn’t include an option for selecting a different authentication protocol for internal Outlook Anywhere interface versus the external Outlook Anywhere interface.
In the following screenshot, we can see that the Exchange 2013 CAS server management interface enables us to set the required authentication protocol, but the setting applied to the booth, of the “Outlook Anywhere client” (the internal + external Outlook Anywhere).
Q1: What is the recommended authentication protocol?
A1: The most simple and if I may say recommended way, is to choose the same authentication protocol for the internal + external Outlook Anywhere client.
Note that an external Outlook Anywhere client supports only the option of basic authentication.
Technically, we can set a different authentication method for internal Outlook Anywhere client versus an external Outlook Anywhere client. My mantra is: KIS – keep is the simple meaning, I like to keep it simple and use the same authentication protocol (Basic) for the both of the Outlook Anywhere client (internal + external)
Just to strengthen the subjects that we have reviewed, I add some Quotes from a Microsoft article that deals with this topic:
[Source of information: Exchange 2007 And 2013 Outlook Anywhere Co-Existence ]Note the two different authentication settings that are listed. ClientAuthenticationMethod and IISAuthenticationMethods. For the detail oriented people out there, you saw that one was plural and the other singular.
When you configure OA for Basic auth, then the ClientAuthenticationMethod and IISAuthenticationMethods are both set to Basic.
The same goes for when OA is set to NTLM auth. In that case, ClientAuthenticationMethod and IISAuthenticationMethods are both set to use NTLM.When co-existing Exchange 2007 and 2010 with Exchange 2013, we need to ensure that the correct authentication settings are in place.
There are two things that we need to pay attention to. Authentication at the IIS layer and authentication at the client layer. This is the IISAuthenticationMethods and ClientAuthenticationMethod properties respectively.
As specified in the Exchange Server Deployment Assistant, to allow CAS 2013 to redirect Outlook Anywhere connections to Exchange 2010 and 2007, Outlook Anywhere must be enabled and correctly configured on Exchange 2007 and 2010.
If Outlook Anywhere previously deployed, then ensure that their configuration will support Exchange 2013. The follow permission considerations need to address:
Client authentication, which is used to allow clients like Outlook 2013 to authenticate with Exchange correctly configured. The same consistent OA client authentication scheme should deploy on legacy CAS and CAS 2013.Internet Information Services (IIS) authentication, which is used to allow Exchange servers to communicate must include NTLM auth.
[Source of information: Outlook Anywhere ]“In a coexistence scenario that still has 2007 or 2010 Client Access Servers, you need to enable Outlook Anywhere on each legacy Client Access Server. For instructions on enabling Outlook Anywhere for Client Access Servers running on Exchange Server 2007”
[Source of information: Configure Outlook Anywhere on Outlook 2013 ]“Customization of Outlook Anywhere settings is optional and only needed if you want to change the settings from the default configuration. By default, Exchange pushes down the Outlook Anywhere settings by using the Autodiscover service the first time that Outlook is started”.
PART B | Outlook client Proxy process and the “user credentials”
The “second part” of the Outlook client protocol connectivity flow relates to the part which can be described as: CAS to CAS communication. In this part, the Exchange 2013 CAS “forward” (Proxy) the Outlook client requites to the legacy Exchange CAS server.
To be able to complete the communication channel successfully, two conditions will need to fulfil:
- The legacy Exchange CAS server should be configured to support Outlook Anywhere.
- The Exchange 2013 CAS + the legacy Exchange CAS server should be configured to support IIS Authentication Method using NTLM ( IISAuthenticationMethods: {Basic, Ntlm})
Exchange 2013 CAS and the process of Proxy the Outlook user credentials
Don’t forget the simple fact: when a “legacy Exchange server” such as Exchange 2010 CAS server, get the “proxy request” from the Exchange CAS 2013 server, he doesn’t “see” the Outlook user or directly communicate with the Outlook client.
This is a classic scenario of “man in the middle”. The “legacy Exchange server” cannot “trust” the Outlook user, or “understand” how to route the communication request until he gets the required user credentials.
To the solution for this “trust” problem, is implemented by using an “authentication proxy mechanism” in which the Exchange 2013 CAS server “forward” (Proxy) the user credentials to the required legacy Exchange CAS server.
In theory, the process of “forwarding” the user credentials can be implemented by a variety of authentication protocols, but in reality, the only supported authentication protocol that could use for “forwarding the user credentials” is the NTLM protocol.
In simple words: to be able to implement the communication channel between the Exchange CAS 2013 server and the legacy Exchange CAS servers, we will need to verify that both of the sides support the use of the authentication protocol: NTLM
In the following diagram, we can see the Outlook client protocol connectivity flow that relates to the subject of user credentials.
- The Outlook client authentication protocol is: Basic
- When Exchange 2013 CAS Proxy the user credentials to Exchange 2010 CAS, the authentication protocol is: NTLM
Exchange 2013 coexistence environment | Outlook client | Required preparations check list
Ok, I exhaust myself with the boring talks about Exchange, authentication protocol and more. So… just a quick recap:
Manage Exchange Outlook Anywhere settings
In the following section, we will review the way that we use PowerShell commands for creating the required configuration of the Exchange 2013 coexistence environment and the Outlook Anywhere infrastructure.
1. Viewing an existing configuration settings
The first step is to view the existing configuration setting and based upon the information, create the required configuration updates.
Example 1 : Get information about the Outlook Anywhere settings of a particular Exchange CAS server
To be able to see the Outlook Anywhere settings on the Exchange 2013 CAS server, we can use the PowerShell command:
Get-OutlookAnywhere -Server <Exchange CAS server>
In the following screenshot, we can see the information about the Outlook Anywhere setting of Exchange 2013 CAS server named: STS
The following values relate to the authentication protocol that the Outlook Anywhere client will use when they provide the user credentials to the Exchange 2013 CAS server.
In our scenario, the server setting configured as follows:
- External Outlook Anywhere are instructed to use the basic authentication protocol: ExternalClientAuthenticationMethod: Basic
- Internal Outlook Anywhere clients are instructed to use the NTLM authentication protocol: InternalClientAuthenticationMethod: NTLM
- The Exchange 2013 CAS server IIS component supports the following authentication protocols: basic, NTLM and Negotiate: IISAuthenticationMethods: {Basic, Ntlm, Negotiate}
Example 2: Get a list of all the available Exchange 2010 CAS server, display the information about the Outlook Anywhere settings.
Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and $_.IsClientAccessServer} | Get-OutlookAnywhere | fl servername,externalhostname,*auth*
2. Configure Exchange CAS server Outlook Anywhere settings
The following PowerShell command syntax is an example of “all the available settings”, that relate to Exchange 2013 CAS server Outlook Anywhere settings:
Get-OutlookAnywhere –Server <Exchange 2013 CAS server>| Set-OutlookAnywhere -InternalHostname <Domain name> -InternalClientAuthenticationMethod NTLM -InternalClientsRequireSsl $true -ExternalHostname <Domain name> -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl $true -IISAuthenticationMethods NTLM,Basic -ssloffloading:$false
3. Enable NTLM on the IIS /RPC directory of your Exchange 2007/2010 servers
Example 1: Get a list of all of the available Exchange CAS servers beside Exchange 2013 CAS servers, enable (set) the Outlook Anywhere option and configure the required IIS authentication protocol
Get-OutlookAnywhere | ?{ $_.AdminDisplayVersion -notlike "Version 15.*"} | Set-OutlookAnywhere -IISAuthenticationMethods NTLM,Basic
Example 2: configure the Outlook Anywhere authentication settings of a specific Exchange CAS server (configure the required IIS authentication protocol + the Client Authentication Method).
Set-OutlookAnywhere -Identity '<ServerName>\Rpc (Default Web Site)' -ClientAuthenticationMethod Basic -IISAuthenticationMethods NTLM, Basic
Example 3: enable the Outlook Anywhere of a specific Exchange CAS server + configure the Outlook Anywhere authentication settings of a specific Exchange CAS server (configure the required IIS authentication protocol + the Client Authentication Method).
Set-OutlookAnywhere -Identity '<ServerName>\Rpc (Default Web Site)' -ClientAuthenticationMethod Basic -SSLOffloading $False –ExternalHostName <Exchange 2013 CAS server> -IISAuthenticationMethods NTLM, Basic
Additional reading about the subject of: Exchange 2013 and Outlook clients
- How does Outlook Anywhere work (and not work)?
- How to resolve several issues when running both Exchange 2010 and 2013
- Users of Exchange Server 2013 or Exchange Online can’t open public folders or shared mailboxes on an Exchange 2010 or Exchange 2007 server
- Exchange Server 2010 to 2013 Migration – Preparing for Co-Existence
- RPC Proxy doesn’t work: 2013/2010 Co-Existence with Outlook Anywhere
- Exchange 2013: Configuring Outlook anywhere
- Outlook Exchange Proxy Settings dialog box always displays the internal host name as the Proxy server in an Exchange Server 2013 environment
- Things to consider before configuring Autodiscover in Exchange 2010/2013 coexistence scenarios
- Exchange 2010/2013 Co-Existence Experience
- Outlook Anywhere coming to a CAS server near you soon
- Exchange 2013 Outlook Anywhere Considerations
- Authentication pop ups and annoyances with Exchange 2007 / 2010 and Outlook Anywhere
- RPC Client Encryption in Exchange 2013
- Exchange 2007 And 2013 Outlook Anywhere Co-Existence
- Client Connectivity in an Exchange 2013 Coexistence Environment
Video links – general migration
- Microsoft Exchange Server 2013 Client Access Server Role
- Microsoft Exchange Hybrid Deployment and Migration on Your Terms
- Microsoft Exchange Server 2013 On-Premises Upgrade and Coexistence
General information
- Exchange Server 2010 to 2013 Migration – Preparing for Co-Existence
- Exchange Server 2010 to 2013 Migration – Reviewing Autodiscover Configuration
- Exchange 2007/2013 CoExistence URLs
- Exchange 2010/2013 Co-Existence Experience
- NTLM AND Basic Authentication for Outlook Anywhere (both)
- Exchange 2007 And 2013 Outlook Anywhere Co-Existence
- Client Connectivity in an Exchange 2013 Coexistence Environment
RPC Endpoint
Exchange 2013 coexistence | Article series index
It is important for us to know your opinion on this article
The post Exchange 2013 coexistence and Outlook infrastructure | Part 2/2 | 14#23 appeared first on o365info.com.