ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2007 coexistence | 4/4 | 19#23
The current article, is the fourth article of four articles series, on the subject of:…
The current article is the third article of four articles series, on the subject of – “Exchange 2013/2007 coexistence environment and mail client protocol connectivity flow”.
In this article, we will review the client protocol connectivity flow of:
OWA Exchange 2007 clients in an Exchange 2013/2007 coexistence environment.
To be able to understand the different “Exchange clients” connectivity protocol flow in Exchange 2013/2007 coexistence environment, we will review five types of “relationships” that exist between Exchange 2007 client and the Exchange CAS 2013 server:
The current section, is dedicated to the description of the OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment.
When reading the description of the different OWA client protocol connectivity scenarios and the details of each scene, you might experience a slight headache.
It’s ok, despite the risk of the “slight headache”, I think that it’s worth putting in the effort, to be able to understand the concept and the logic of the OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment.
The client protocol connectivity flow of OWA mail client has two main characteristics that are different from another mail client such as: Outlook or ActiveSync mail clients.
The main difference between the OWA client versus another Exchange mail client such as Outlook or Mobile (ActiveSync) client is that, most of the time, OWA client will manually type the URL address of the Exchange server instead getting the name of the “Exchange server” from the Autodiscover process. In other words, the OWA client needs to know their Exchange server name versus other Exchange clients that use the Autodiscover process for “locating for them” the required Exchange server name.
In case of that “regional OWA user” such as: OWA user whom his mailbox is located on a “regional Exchange site” (Madrid site in our scenario), OWA user who needs to access their mailbox, can use one of the following naming convention’s options for the Exchange server host name:
Note: The scenario of: “regional OWA mail client” and the redirection process is not unique or related only to Exchange 2007 OWA client, but instead, to any Exchange OWA client that is involved in a scenario of multiple Public facing Exchange site and regional namespace.
The process of serving Exchange 2007 OWA mail clients (Exchange users whom their mailbox hosted on Exchange 2007 Mailbox server), is different from the “other mail protocols” because Exchange 2013 “doesn’t know” how to proxy the OWA mail client requests.
Instead, the Exchange CAS 2013 will redirect the “Exchange 2007 OWA mail clients” to their Exchange 2007 CAS server.
This is the main reason for the using the “legacy namespace”. The “redirection message”, that the Exchange 2013 CAS server will send to the “Exchange 2007 OWA mail clients browser” includes the URL address of the Exchange 2007 CAS server who will be able to “serve” the Exchange 2007 OWA mail client requests.
The URL that the Exchange 2013 CAS server provide includes the FQDN (the “legacy namespace) that points to the Exchange 2007 CAS server.
In the former sections, we have a review two different scenarios in which the Exchange 2013 CAS will redirect Exchange 2007 clients to their “destination Exchange CAS server”.
The redirection method that is used by the Exchange 2013 CAS CU2, include two major improvements that are related to the process of: redirecting OWA mail client.
The 2013 CAS CU2 Improvements are:
Former version of Exchange CAS server and the OWA redirection method
Although the Exchange 2013 CU2 server version implements the “OWA redirection” process in an improved way, it’s important to emphasize that the “OWA redirection method”, is not a new Exchange method and that the OWA redirection method was included in former versions of Exchange server (as far as I know since the Exchange 2007 server version).
In a former version of Exchange server, the OWA redirection method that was implemented by the Exchange server for “redirecting OWA client” to their Exchange server, could be described as “passive”.
The “OWA redirection” was implemented by displaying a “message window”, which was sent by the Exchange server to the OWA client.
The “redirection information” was presented to the OWA user as a “clickable link”.
I describe this method as: “passive redirection”, because the only responsibility of the Exchange server was to display a message with the link to the OWA client.
The user’s responsibility is to:
Additionally to the user requirement to “understand” that he needs to click on the link, OWA users, had an experience that can be described as: ”double login”.
The meaning is that: OWA users, had to re provide their user credentials again, to the “new destination Exchange server“ (the “destination” Exchange 2007 CAS).
Exchange 2013 CAS server version CU2, includes two major features that significantly improve the “Exchange OWA client” experience:
The method which Exchange CAS 2013 use for redirecting OWA client described as: “silent” because, the OWA user is not involved throughout the process. The only thing that the OWA user “see” is a short flush on his browsers (the redirection process from the Exchange 2013 CAS OWA login page in the OWA login page from the destination Exchange server).
The “Exchange 2007 OWA client” is not aware of the complicated redirection process. From the “Exchange 2007 OWA client” point of view, this process is transparent.
Note: Although we mention the Exchange 2013 CAS method of: silent redirection + SSO in the context of the Exchange 2007 OWA client, this method is implemented in any type of Exchange OWA client in a scenario of multiple Public facing Exchange sites.
Q1: How actually the OWA client silent redirection process implemented?
A1: The “OWA redirection process”, is implemented by “cooperation” of the Exchange CAS 2013 and the client browser. Exchange CAS 2013 sends an HTTP redirection command that includes the “new URL address”. The client browser accepts the redirection command and addresses the “destination URL address”
Scenario 1: External 2007 OWA client | User mailbox located at the New York site.
Scenario charters: an external Exchange 2007 OWA client, need to get access to his mailbox.
The OWA protocol connectivity flow, will be implemented as follows:
Scenario 2: Exchange 2007 OWA client | User mailbox located at the Los Angles site.
Scenario charters: an external Exchange 2007 Outlook client, need to access his mailbox.
Note: To simplify the step’s description, we will relate only to the “external OWA 2007 client” but the same logic and flow are implemented also to the “internal OWA client”.
In this scenario, the same logic will be maintained. Exchange CAS 2013 server redirects the Exchange 2007 OWA client to the Public facing Exchange 2007 CAS server.
The “New York Public facing Exchange 2007 CAS server” authenticates the user, performs an Active Directory lookup and determines that the user mailbox is located at the Los Angles site.
In the following section, we will review the OWA client protocol connectivity flow of an external OWA Madrid user who tries to access his mailbox and use the primary namespace as the URL address.
When the OWA Madrid user uses the primary namespace (https://mail.o365info.com/owa), the Host name will be resolved to the IP address of the “New York Public facing Exchange CAS server”.
When the “New York Public facing Exchange CAS server” recognizes that the user considers as a “Madrid user” and that – this OWA client should access “his Public facing Exchange CAS server”, the “New York Public facing Exchange CAS” will implement a method which described as: silent redirection + SSO.
Note: The method of silent redirection and SSO is not related only to a scenario of Exchange 2007 OWA client, but, to any other type of external OWA client such as Exchange 2013 OWA clients.
The external OWA scenarios
In the next section, we will demonstrate OWA flow scenarios in which “OWA Madrid user” (user that his mailbox is hosted at Madrid site will use the primary namespace as the URL address: https://mail.o365info.com/owa
In the following diagram, we can see that the Exchange public infrastructure includes two Public facing Exchange sites: the New York site and the Madrid site. Each of the Exchange site has a Public facing Exchange CAS server.
“Regional OWA users” (Madrid user in our scenario) can choose to use one of the optional URL address.
The Madrid Public facing Exchange CAS server is represented by a dedicated namespace (regional namespace): europe.mail.o365info.com
In case that external OWA Madrid user is familiar with the “Madrid regional namespace”, he can use the URL address: https://europe.mail.o365info.com/owa
The additional option that the OWA Madrid user can use is: using the primary namespace which will “lead him” to the “New York Public facing Exchange CAS”.
In this case the OWA Madrid user can use the URL address: https://mail.o365info.com/owa
When the “New York Public facing Exchange CAS” gets the connection request from the “OWA Madrid user”, he will implement a method was described as: “silent redirection” which will redirect the OWA Madrid user, to “his Madrid Public facing Exchange CAS server”.
Scenario 3: OWA client | User mailbox located on the Madrid site | Regional namespace |destination site = Public facing
Scenario charters: an external Exchange OWA 2007 client, need to access his mailbox.
In the current scenario, an “OWA Madrid user” use the URL address: https://mail.o365info.com/owa for access his mailbox.
The OWA protocol connectivity flow will be implemented as follows: