OWA client protocol connectivity flow in Exchange 2013/2010 coexistence | 3/4 | 22#23 5/5 (1)

The current article is the third article of four articles series, on the subject of: “Exchange 2013/2010 coexistence environment and mail client protocol connectivity flow”.

In this article, we will review the client protocol connectivity flow of:
OWA Exchange 2010 clients in an Exchange 2013/2010 coexistence environment.

Exchange 2013 - 2007 coexistence - OWA client

Article Table of content | Click to Expand

To be able to understand the different “Exchange clients” connectivity protocol flow in Exchange 2013/2010 coexistence environment, we will review five types of “relationships” that exist between Exchange 2010 client and the Exchange CAS 2013 server:

  • Autodiscover client – protocol connectivity flow (Part 2#4)
  • Outlook client – protocol connectivity flow (Part 2#4)
  • OWA client – protocol connectivity flow (Part 3#4)
  • ActiveSync client – protocol connectivity flow (Part 4#4)
  • Exchange web service client – protocol connectivity flow (Part 4#4)


Article Series Table of content | Click to Expand

Exchange coexistence environment | Article Series

Exchange 2013 and Exchange 2010 coexistence OWA connectivity flow

The general concept of the Exchange 2010 OWA client protocol connectivity flow in Exchange 2013/2010 coexistence environment is based on a similar flow concept of “other Exchange 2010 clients” such as Outlook and ActiveSync clients.

The client protocol connectivity flow logic based on the following flow:

  1. Exchange 2010 OWA client addresses the Exchange CAS 2013
  2. Exchange CAS 2013 recognizes that the OWA client is an Exchange 2010 client.
  3. Exchange CAS 2013 Proxy the Exchange 2010 OWA client to Exchange CAS 2010

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 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 conventions options for the Exchange server host name:

  1. Using the primary namespace – in our scenario, the “main namespace” that represents the “New York Public facing Exchange CAS” is: mail.o365info.com
    In case that a “Madrid OWA user” use the primary namespace as the Exchange server name (OWA URL), the “New York Public facing Exchange CAS” recognizes that the user is a “Madrid OWA users” and, redirect him to the “Madrid Public facing Exchange CAS.”
  2. Using the regional namespace – in a scenario of “Madrid OWA user”, the OWA user can use the regional namespace as the Exchange server name (OWA URL). For example – europe.mail.o365info.com. In this scenario, the OWA Madrid user will access ”his Exchange server” directly.
Note – the situation of – “regional OWA mail client” and the redirection process is not unique or related only to Exchange 2010 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 external OWA scenarios

In the current article, we will demonstrate the client protocol connectivity flow of two OWA users: New York OWA user ( the user that his mailbox hosted at the New York site) and OWA Madrid user (user whom his mailbox hosted at Madrid site).
Booth of this OWA client 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 sites has a Public facing Exchange CAS server.

  • The public name of the “New York Public facing Exchange CAS” is: mail.o365info.com
  • The public name of the “Madrid Public facing Exchange CAS” is: europe.mail.o365info.com

Exchange 2013 2010 coexistence - OWA client - The optional URL address

“Regional OWA users” (Madrid user in our scenario) can choose to use one of the optional URL addresses.

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”.

Exchange 2013 2010 coexistence - OWA client - Regional namespace

Scenario 1: External 2010 OWA client | User mailbox located at the New York site.

Scenario charters: an external Exchange 2010 OWA client, need to get access to his mailbox.

  • Exchange user type: Exchange 2010 client (Exchange user whom his mailbox hosted on the Exchange 2010 mailbox server).
  • Exchange mailbox server location: the Exchange 2010 Mailbox server which hosts the user mailbox, is located on the New York site.

The OWA protocol connectivity flow, will be implemented as follows:

  1. The “New York Exchange 2010 OWA client”, type the following URL addresses: https://mail.o365info.com/owa
    The URL address that the OWA client use includes the FQDN: https://mail.o365info.com/owa, which points to the Public facing CAS2013 server in New York site (Number 1).
  2. The external OWA client, provide his user credentials.
  3. CAS2013 uses the user credentials and performs the Active Directory lookup. CAS2013 determines that:
    • The user mailbox version is: 2010
    • the Exchange 2010 mailbox server that host the user mailbox is located at the New York site
    • The New York site includes a local Exchange CAS 2010
  4. CAS2013 will proxy the OWA client connectivity request to an Exchange 2010 CAS (Number 2).
  5. CAS2010, proxy the OWA client connectivity request to the Exchange 2010 mailbox server who hosts the user mailbox (Number 3).
  6. Exchange 2010 mailbox server, provides the required user mailbox content to the CAS2010.
  7. CAS2010 provides the necessary user mailbox content to the CAS2013.
  8. CAS2013 “provide” the necessary user mailbox content to – the External OWA client (Number 4).

Exchange 2013 2010 coexistence - External OWA client

OWA client protocol connectivity flows in a multiple Public facing Exchange site environment

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 main namespace (mail.o365info.com), the Hostname 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 2010 OWA client, but, to any other type of external OWA client such as Exchange 2013 OWA clients.

The concept of silent redirection and SSO

In the former sections, we have a review scenario in which the Exchange 2013 CAS will redirect Exchange 2010 clients to their “destination Exchange CAS server”.

The redirection method that used by the Exchange 2013 CAS CU2 includes two significant improvements that are related to the process of Redirecting OWA mail client.

The 2013 CAS CU2 Improvements are:

  1. Silent redirect
  2. SSO

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 included in former versions of Exchange server (as far as I know since the Exchange 2007 server version).

In a previous 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:

  • “Understand” that the link that presented in the message is the link to the “right Exchange server.”
  • That he needs to click on the link that will redirect him to his Exchange CAS server.

Additionally to the user requirement of: “understand” that he needs to click on the link, OWA users, had an experience that can describe as: ”double login.”

double login OWA users experience

The meaning is that: OWA users, had to re-provide their user credentials again, to the “new destination Exchange server“ (the “destination” Exchange 2010 CAS).

Exchange 2013 CAS server version CU2 and the OWA redirection method

Exchange 2013 CAS server version CU2, includes two major features that significantly improve the “Exchange OWA client” experience:

  • A silent redirection (active redirection) – The Exchange 2013 CAS server knows how to send a redirection “command” to the Exchange 2010 OWA browser, that will redirect the OWA session to the “new URL address” (the legacy URL address of the Exchange 2010 CAS server).
  • SSO – Exchange 2013 CAS server knows how to “transfer” or “forward” (Proxy) the OWA user credentials to the “destination” Exchange 2010 CAS server.

The method which Exchange CAS 2013 use for redirecting OWA client described as: “silent” because the OWA user 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 to the OWA login page from the destination Exchange server).

The “Exchange 2010 OWA client” is not aware of the complicated redirection process. From the “Exchange 2010 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 2010 OWA client, this approach is implemented in any type of Exchange OWA client in a scenario of multiple Public facing Exchange sites.

Exchange 2013 CAS server Silent Redirection + SSO

Q1: How the OWA client silent redirection process implemented?

A1: The “OWA redirection process”, is performed 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.”
New York Public facing Exchange CAS server send instructions

Scenario 2: OWA client | User mailbox located on the Madrid site | Regional namespace | Destination site = Public facing

To simplify the OWA flow step’s description, we will relate only to the “external OWA client” but the same logic and flow are also implemented to the “internal OWA client.”

Note – you can read more information about the concept of silent redirection and SSO in the article: Exchange CAS server | Proxy versus redirection

Scenario charters: an external Exchange 2010 OWA client, need to get access to his mailbox.

  • Exchange user type: Exchange 2010 client (Exchange user whom his mailbox hosted on the Exchange 2010 mailbox server).
  • Exchange mailbox server location: the Exchange 2010 Mailbox server which hosts the user mailbox, is located on the Madrid site.
  • The “Madrid Exchange site” considers as Public facing Exchange site.
  • The “Madrid Exchange site” considers as Public facing Exchange site.
  • The external OWA user uses the primary namespace as the URL address of the Exchange server (https://mail.o365info.com/owa).
  • The regional namespace that was “allocated” to the Madrid site is: europe.mail.o365info.com

In the current scenario, an “OWA Madrid user” use the URL address: https://mail.o365info.com/owa for accessing his mailbox.

The OWA protocol connectivity flow implemented as follows:

  1. Madrid Exchange 2010 OWA client, type the following URL addresses: https://mail.o365info.com/owa
    The FQDN:mail.o365info.com points to the “New York Public facing Exchange CAS server” (Number 1).
  2. The external OWA client, provide his user credentials.
  3. CAS2013 uses the user credentials and performs the Active Directory lookup. CAS2013 determines that:
    • The user mailbox version is: 2010
    • the Exchange 2010 mailbox server that host the user mailbox located at the Madrid site
    • The remote site (Madrid site) is a Public facing Exchange site
    • the “OWA address” of the “Madrid Public facing Exchange CAS server” is: https://europe.mail.o365info.com/owa
  4. The Exchange CAS2013 will implement two different procedures:
    1. Initiate silent redirect process – the “New York Public facing Exchange 2013” sends a redirection command to the “Madrid Exchange 2010 OWA client browser” that includes the FQDN of the “Madrid Exchange 2010 Public facing Exchange CAS”: europe.mail.o365info.com(Number 2).
    2. Initiate SSO process – the “New York Public facing Exchange 2013” implements the process of SSO, by forwarding (proxy) the Exchange 2010 OWA user credentials, to the “Europe Exchange 2010 Public facing Exchange CAS” (Number 8).
  5. The “Madrid Exchange 2010 OWA mail client browser, “gets” the redirection command from the CAS2013 and starts a new HTTPS session with the “Madrid Exchange 2010 Public facing Exchange CAS” (Number 3).
  6. The Madrid Exchange 2010 Public facing Exchange CAS (europe.mail.o365info.com) will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server (Number 5).
  7. The Madrid Exchange 2010 Mailbox server, provides the required user mailbox content to the Madrid CAS2010 (Number 6).
  8. The Madrid CAS2010 sends the information to the “external Exchange 2010 OWA client” (Number 7).

Exchange 2013 2010 coexistence - Multiple Public facing Exchange sites

Exchange 2013 coexistence | Article series index

The Exchange 2013 coexistence article series index page

0/23

Exchange 2013 coexistence environment and client protocol connectivity flow | The prefix

1/23

The importance of Exchange 2013 CAS in Exchange 2013 coexistence environment | Part 1/2

2/23

The importance of Exchange 2013 CAS in Exchange 2013 coexistence environment | Part 2/2

3/23

Exchange Public infrastructure | Public versus non Public facing Exchange site

4/23

Exchange Public infrastructure | Public versus non Public facing Exchange site

5/23

Exchange web services in an Exchange 2013 coexistence environment | Part 1/2

6/23

Exchange web services in an Exchange 2013 coexistence environment | Part 2/2

7/23

Exchange 2013 coexistence environment and the Exchange legacy infrastructure

8/23

The checklist for preparing your Exchange 2007 infrastructure for Exchange 2013 coexistence

9/23

The checklist for preparing your Exchange 2010 infrastructure for Exchange 2013 coexistence

10/23

Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 1/2

11/23

Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 2/2

12/23

Basic concepts of Outlook connectivity in Exchange 2013 coexistence environment | Part 1/2

13/23

Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2

14/23

Manage legacy Exchange URL address using a PowerShell script

15/23

Client protocol connectivity flow in Exchange 2013/2007 coexistence environment | Introduction and basic concepts| 1/4

16/23

Autodiscover and Outlook client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 2/4

17/23

OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 3/4

18/23

ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 4/4

19/23

Client protocol connectivity flow in Exchange 2013/2010 coexistence environment | Introduction and basic concepts| 1/4

20/23

Autodiscover and Outlook client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 2/4

21/23

OWA client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 3/4

22/23

ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 4/4

23/23

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Article Name
OWA client protocol connectivity flow in Exchange 2013/2010 coexistence | 3/4 | 22#23
Description
The current article is the third article of four articles series, on the subject of: “Exchange 2013/2010 coexistence environment and mail client protocol connectivity flow”.In this article, we will review the client protocol connectivity flow of: OWA Exchange 2010 clients in an Exchange 2013/2010 coexistence environment.
Author
Publisher Name
o365info.com
Publisher Logo

Please rate this

Print Friendly

Related Post

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

Your email address will not be published. Required fields are marked *