Exchange CAS server | Proxy vs. redirection | 4#23

Let’s start from the end – what is the only purpose of the Exchange CAS server?
And the answer is: “deliver” information or a specific service to his clients (By Proxy the Exchange client request to additional Exchange server) or, by “point” (Redirect) Exchange client to an “element” that can provide them the required information or service.

Exchange 2013 CAS server doesn’t consider the “data owner” or the element the “generate” or produce the data.
So, the obvious question is: who is the part that considers as the “data owner” or the element the “generate” or “produce” the data?
The simple answer: in a legacy Exchange environment (Exchange 2007 and Exchange 2010) this element could be:

• Exchange Legacy CAS server (Exchange 2007/2010)
• Exchange Legacy Mailbox server (Exchange 2007/2010)
• Exchange 2013 Mailbox server

If we want to simplify the definition of the Exchange CAS 2013 server purpose, we can relate to the Exchange CAS 2013 server as a waiter who brings “food” (information) to his customer table. And if we want to be more accurate, in some scenario, ask his customer to choose another restaurant (redirect).

The available options for Exchange CAS for serving his Exchange clients

To accomplish the task of “serving” his client, the Exchange CAS server has two options:

1. Proxy – when Exchange 2013 CAS server contact “other sources” (other Exchange servers) for retrieving data or information on behalf of his Exchange clients, we describe this process as Proxy
2. Redirect- When the Exchange CAS 2013 server “inform” his client, that he cannot help them, and he needs to point them to “other Exchange servers,” we describe this procedure as Redirect

By default, Exchange CAS 2013 server will prefer to use the option of: “Proxy” instead of the “redirection” option because the Proxy process is transparent to the Exchange client.

In reality, the proxy process could be considered as a complicated or complex process, but, from the “Exchange client” point of view, this process is transparent.
The only thing that the Exchange clients need to know is that he needs to locate and contact the Exchange CAS 2013 server, and that’s all!
All that the Exchange clients need to do is – ask, and the Exchange CAS 2013 server will fulfill his wish!

Exchange CAS 2013 server | The decision-making table

The Exchange CAS server has a very precise “decision-making table”, which he uses for choosing the most suitable “routing decision”.
The “decision-making table” will help Exchange CAS server to decide if he will proxy the Exchange client request or send a redirection response to the Exchange client.

In case that the Exchange 2013 CAS decides to Proxy the Exchange client request, he will need to plan the precise charters of the particular flow.

For example, in the case that the Exchange CAS server decides to proxy the Exchange client request, to which Exchange server he will proxy the request.

The client protocol connectivity flow that will be implemented by the Exchange 2013 CAS depends on the particular environment in which he operates.

1. Native Exchange 2013 environment

In a Native Exchange 2013 environment that include only Exchange CAS 2013 server and Exchange 2013 Mailbox servers, Exchange CAS 2013 server proxy everything to the Exchange 2013 Mailbox server.
Exchange CAS 2013 server will proxy all the different types of Exchange 2013 client “requests”:

• Exchange 2013 clients that need access to their mailboxes.
• Exchange 2013 clients request for Autodiscover information.
• Exchange 2013 clients for Exchange web services.

2. Exchange 2013 coexistence environment

In an environment that described as – Exchange 2013 coexistence environment, Exchange CAS 2013 server will use a mixture of “responds”: Proxy or Redirect Exchange client requests, based on specific scenarios.

Exchange 2013/2007 coexistence environment

In an Exchange 2013/2007 coexistence environment, Exchange CAS 2013 will implement the following methods:

Exchange 2007 client

Outlook + ActiveSync (mobile) client that request access to mailbox content. The result: Exchange CAS 2013 server will proxy these requests to the Exchange 2007 CAS

OWA client that request access to mailbox content. The result: Exchange CAS 2013 server will respond to a redirection command (silent redirection + SSO) that will “point” Exchange 2007 OWA clients to Exchange 2007 CAS.

Autodiscover client that requests Autodiscover information. The result: Exchange CAS 2013 server will proxy the requests to Exchange 2013 mailbox server

Exchange 2007 web services client – the Exchange 2007 connects directly to Exchange CAS 2007 server

Exchange 2013/2010 coexistence environment

In an Exchange 2013/2010 coexistence environment, Exchange CAS 2013 will implement the following methods:

Exchange 2010 client
Outlook + ActiveSync (mobile) and OWA client that require access to mailbox content. The result: Exchange CAS 2013 server will proxy these requests to the Exchange 2010 CAS
Autodiscover client that requests Autodiscover information. The result: Exchange CAS 2013 server will proxy the requests to Exchange 2010 CAS
Exchange 2010 web services client The result: Exchange CAS 2013 server will proxy the requests to Exchange 2010 CAS

Exchange CAS 2013 server | Proxy scenarios

The formal definition of the term Proxy: In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource.

This definition describes the way the Exchange CAS server uses to serve its clients.

The term “Proxy” describes an operation in which Exchange CAS server, accepts the Exchange client requests and, “do whatever he needs to do” for getting the required information for his client.

In other words: Exchange CAS server access other resources on behalf of his clients, get the necessary information and “deliver back” this infrastructure for his client.

The Exchange clients, cannot know or cannot “see” what is behind the scenes or doesn’t need to understand a complex Exchange infrastructure and logic. The element that “work hard” for the client is the Exchange CAS server.

To be able to demonstrate the “proxy process” let’s review a couple of optional scenarios:

Scenario 1: Exchange 2013 client need access to his mailbox.

The charters of the scenario are as follows:

The internal Outlook client that is a mailbox hosted on Exchange 2013 Mailbox server needs to access to his mailbox content. The Exchange infrastructure is a “Native Exchange 2013”.

The process in which Exchange 2013 user will access his mailbox implemented as follows:

1. Exchange 2013 client connects the Exchange 2013 CAS server.
2. CAS2013 will authenticate the user and perform an Active Directory lookup.
3. CAS2013 determines that: the mailbox version is 2013 + the user Exchange. Mailbox server (and CAS2013 server) is located is on the same AD site.
4. CAS2013 proxy the Exchange client request to the Exchange 2013 Mailbox server.

Scenario 2: Exchange 2013 in coexistence environment | Legacy Exchange CAS server in the same Active Directory site

The current scenario and the next scenarios, describes an Exchange CAS 2013 in coexistence environment.
In an Exchange 2013 coexistence environment, legacy Exchange user mailbox is hosted on “legacy Exchange infrastructure (Exchange 2007 Mailbox server or Exchange 2010 Mailbox server).

The charters of the scenario are as follows:

Internal Exchange 2010 Outlook client (an Exchange client that is a mailbox hosted on Exchange 2010 Mailbox server), need access to his mailbox.

The process in which Exchange 2010 client will access his mailbox implemented as follows:

1. Exchange 2010 clients connect the Exchange 2013 CAS server.
2. CAS2013 will authenticate the user and perform an Active Directory lookup.
3. CAS2013 determines that: the user mailbox version is 2010 + there is an Exchange 2010 CAS server on the same AD site.
4. CAS2013 proxy the request of the “Exchange 2010 client” to the Exchange 2010 CAS server (Step 2 in the diagram).
5. Exchange 2010 CAS server will proxy the request to the Exchange 2010 Mailbox server (Step 3 in the diagram).

Scenario 3: Exchange 2013 in coexistence environment | Legacy Exchange CAS server in the same Active Directory site | User mailbox in a different Active Directory site

In the current scenario, we add additional factor.
The user mailbox is hosted at the legacy Exchange 2010 infrastructure, but the Exchange 2010 Mailbox server, who hosts the user mailbox, is located at a different Active Directory site (Site 2).

The charters of the scenario are as follows:

Internal Outlook client that is a mailbox hosted on Exchange 2010 Mailbox server on Madrid site is visiting in the company New York site. The Outlook client needs access to his mailbox.

The New York site includes the following Exchange server infrastructure: one Exchange 2013 server which holds the Exchange CAS server + the Exchange Mailbox role, Exchange 2010 CAS server and Exchange 2010 Mailbox server.

The Madrid site includes the following Exchange server infrastructure: Exchange 2010 CAS server and Exchange 2010 Mailbox server.

The process in which Exchange 2010 user will access his mailbox implemented as follows:

1. Exchange 2010 client connects the Exchange 2013 CAS server.
2. CAS2013 will authenticate the user and perform an Active Directory lookup.
3. CAS2013 determines that:
   • The user mailbox version is: 2010
   • The local site includes local Exchange 2010 CAS
4. CAS2013 proxy the Exchange 2010 client request to the Exchange 2010 CAS server (Step 2 in the diagram).
5. CAS2010 will do a service discovery.
6. CAS2010 determines that:
   • The user mailbox version is: 2010
   • The user mailbox is hosted on Exchange 2010 Mailbox server in a different AD site (Madrid site).
7. Exchange 2010 CAS server from the New York site, will proxy (Cross-Site Proxy) the request to the Exchange 2010 CAS server of Madrid site (Step 3 in the diagram).
8. Exchange 2010 CAS server from the Madrid site, will proxy the request to the Exchange 2010 Mailbox server (Step 4 in the diagram).

Scenario 4: Exchange 2013 in coexistence environment | No legacy Exchange CAS server in the same Active Directory site | User mailbox in a different Active Directory site

The main charter of this scenario is that site in which the Exchange 2010 resides doesn’t have an Exchange 2010 legacy infrastructure.

The charters of the scenario are as follows:

Internal Outlook client that is a mailbox hosted on Exchange 2010 Mailbox server on Madrid site is visiting in the company New York site.
The Outlook client needs access to his mailbox.
The New York site includes the following Exchange server infrastructure: one Exchange 2013 server which holds the Exchange CAS server + the Exchange Mailbox role

Madrid Site includes the following Exchange server infrastructure: Exchange 2010 CAS server and Exchange 2010 Mailbox server.

The process in which Exchange 2010 user will access his mailbox implemented as follows:

1. Exchange 2010 client connects the Exchange 2013 CAS server.
2. CAS2013 will authenticate the user and perform an Active Directory lookup.
3. CAS2013 determines that: the user mailbox version is 2010 + there is no Exchange 2010 CAS server on the same AD site.
4. CAS2013 will need to locate an Exchange 2010 CAS server who is located in Madrid site (the Active Directory site of the Exchange 2010 Mailbox server who hosts the user mailbox).
5. CAS2013 proxy (Cross-Site Proxy) the Exchange client request to the Exchange 2010 CAS server is Madrid site (Step 2 in the diagram).
6. Exchange 2010 CAS server for Madrid site, will proxy the request to the Exchange 2010 Mailbox server (Step 3 the diagram).

Exchange CAS 2013 server | Redirect scenarios

The subject of redirection vs. proxy in Exchange environment could be quite confusing because a couple of reasons:

1. The ability to understand what happened in a “redirection process” vs. “Proxy process”
2. The ability to understand in which scenario Exchange CAS server uses the option of redirection instead of proxy.
3. The ability to understand the different “redirection types” that Exchange CAS server use

So, let’s start. If we want to simplify the explanation of the term – “Redirection” in an Exchange 2013 coexistence environment, we can say that the term“redirection,” describes an operation, in which Exchange CAS server cannot provide specific information or service to the Exchange client. Instead, the Exchange CAS server point (redirect) the Exchange client, to “other Exchange servers” that can probably provide the required service.

The process of “redirection” is implemented by providing the Exchange client a different URL address that includes the hostname (FQDN) of “other Exchange servers.”

When does the Exchange CAS server use the option of redirection?

Exchange CAS 2013 server will implement the option of redirection instead the option of “Proxy” only for a webmail client (OWA client) and only in the following two specific scenarios:

1. Exchange 2013/2007 coexistence environment and Exchange 2007 OWA clients
2. Multiple Public facing Exchange sites and regional namespace

The following diagram emphasizes the operation that will be implemented by the Exchange 2013 CAS for different type of Exchange clients.

In a scenario of Outlook or ActiveSync (Mobile client) Exchange 2013, CAS will always implement the Proxy method.

The redirection process will be performed only in a scene of Exchange 2007 OWA client or a scenario of multiple Exchange sites and a regional namespace.

The redirection process will be implemented for Exchange 2007 OWA clients because the Exchange CAS 2013 server doesn’t know how to implement a Proxy process of the Exchange 2007 OWA client to Exchange 2007 CAS.

The other scenario in which Exchange CAS 2013 server will use the redirection option is in a particular scene that includes very specific charters.

The second option for using the “redirection method” is implemented in a situation with the following charter:

An Exchange public infrastructure, based upon a structure of a multiple Public facing Exchange site.
When an external OWA client from B site address the Public facing Exchange CAS server which represents site A, the Public facing Exchange CAS server will recognize that the user “belong”
to site B.

In this case, the Public facing Exchange CAS server from site A, will be sent to the external OWA client a redirection message, which include the URL address of the Public facing Exchange CAS server form site B.

You can read more detailed information about this OWA redirection and silent redirection + SSO scenario in the article: OWA client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 3/4

Exchange Redirection type classifications

In Exchange 2013 coexistence environment, when we mention the term: “Exchange CAS server redirection”, the more accurate term is: silent redirection + SSO.

The process of: “silent redirection + SSO” that is implemented by the Exchange CAS 2013, is an evolution of previous and fewer sophisticated Exchange redirection methods.

The evolution of the Exchange redirection process can describe as three “generations”.

1. Standard Exchange CAS server Redirection

The type of redirection which I describe as: “standard Exchange CAS server redirection” was the methods that were implemented by previous version of Exchange server and by Exchange 2013 CAS server before Exchange CAS 2013 version CU2.

The “Standard Exchange CAS server Redirection” can be described as “passive method” because the Exchange CAS server which provides the information about the “redirection” is not doing anything besides providing the data to the Exchange client. In other words, the expectation I that the Exchange client will “redirect himself”.

The charter of a simple redirection process implemented as follows:

1. The OWA mail client connects Exchange CAS server asking to get access to his mailbox.
2. The user will provide his credentials (username + password).
3. Exchange CAS server process the request and “understand” that: he needs to inform the OWA mail client that he needs to contact “other Exchange CAS server.”
4. The Exchange CAS server sends to the OWA mail client, a “notification message” which includes the URL address if the destination Exchange CAS server.
5. The user needs to click on the link that appears in the notification message.
6. When the OWA client reaches the destination Exchange server, he will need to
   re-authenticate by re-entering his user credentials.

2. The redirection method: silent redirect.

This type of the Exchange redirection which described as – silent redirect is more “smarter” types of redirection then the “standard redirection” that was a review in the previous section.

The advantage of the Silent redirect method is that we are avoiding from the “manual operation”, in which the user needs to use his mouse to double-click on the link that appears on the redirection notification message.

Instead of “asking the user to click on a link”, the Exchange CAS server sends a redirection message to the client browser.

The operation described as – “silent” because the redirection command is “happening behind the scenes” (in silent). The user is not aware of the redirection process, but instead, he will notice a “short blink” and his browser will display the welcome authentication page of the “target Exchange CAS server.”

Pay attention that the user will still need to will need to re-authenticate (re-enter his credentials) before the “destination Exchange CAS server.”

3. Silent redirect + SSO (Single sign on)

This method is the most advanced and “sophisticated” Exchange CAS server redirection process. The term SSO (Single sign on), describes a method in which the user doesn’t need to authenticate twice (provide twice his user credentials).

In a standard redirection process, the user will need to provide his credentials to the “first Exchange CAS server” that he connects and after the user is “redirected” to the “destination Exchange CAS server”, the user needs to provide his credentials again.

The user will need to provide his credentials again because the “target Exchange CAS server” is not aware of the fact that the user has to provide his credentials to the “first Exchange CAS server” in the chain.

In other words, the process of Silent redirect + Single sign-on (SSO), was created for preventing the “double login experience”, and the “second login page” that OWA mail client where experience in a previous version of Exchange server, which did not support Silent redirect + Single sign-on (SSO).

We can describe this method is “fully transparent” because the Exchange OWA client is not aware of this process. The only thing that the user “know” is that is successfully managed to access his mailbox.

When does the Exchange 2013 CAS server implement the redirection process?

The description of redirection scenario in an Exchange environment and especially in Exchange 2013 in coexistence environment could be quite confusing.

The reason for this “confusion” is because Exchange 2013 CAS server will choose to implement the redirection method only for a particular mail client and only in specific scenarios.

To be able to arrange things in a logical order let’s use the following “roles”:

1. Exchange 2013 CAS server will always use the redirection method for Exchange 2007 OWA mail clients.
2. Exchange 2013 CAS server will use the redirection method for “other external OWA Exchange clients in a scenario that have the following charters: external OWA client that his mailbox hosted at site B, and site B consider as a Public facing Exchange site. The external OWA client addresses the Public facing Exchange CAS server. In this scenario, the Public facing Exchange CAS server from site A will redirect to the OWA mail client to “his Public facing Exchange site” (Site B).

Scenario 1: Exchange 2013 coexistence with Exchange 2007 | Exchange 2007 OWA mail clients

In an Exchange 2013/2007 coexistence environment, Exchange CAS server know how to proxy, Exchange 2007 client’s requests apart from the scenario of: “Exchange 2007 OWA clients.” Exchange 2013 CAS server doesn’t know how to proxy, Exchange 2007 OWA mail clients.

The only way that Exchange 2013 CAS server can use for “helping” Exchange 2007 OWA mail clients is – by redirecting them to the “legacy Exchange 2007 infrastructure” (to an Exchange 2007 CAS server).

The redirection process implemented by using a legacy namespace that “represent” the Exchange 2007 CAS server.

The redirection method that applied by the Exchange 2013 CAS server (since CU2) is Silent redirect + SSO (Single sign on).

Note – we need to use a legacy namespace because, the “new Exchange 2013 infrastructure” use the organization’s primary namespace and, he needs “another namespace” for referencing the Exchange 2007 CAS.

You can read more about the subject legacy namespace in the article Exchange 2013 coexistence environment and the Exchange legacy infrastructure

The redirection method of Exchange 2007 OWA clients will be implemented for internal and external Exchange 2007 OWA clients.

To be able to understand better the redirection process that Exchange 2013 CAS server performs with Exchange 2007 OWA mail clients, let’s use the following scenario:

Scenario 2: External 2007 OWA client | User mailbox located on the New York site.

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

• Exchange user type: Exchange 2007 client (Exchange user which his mailbox is hosted on Exchange 2007 mailbox server).
• Exchange mailbox server location: the Exchange 2007 Mailbox server who hosts the user mailbox, is located at the New York site.
• The New York site includes two public Exchange CAS servers: Exchange 2013 CAS and Exchange 2007 CAS.

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

1. The “New York Exchange 2007 OWA client”, type the following URL addresses https://mail.o365info.com/owaThe URL address that the OWA client use, includes the FQDN: mail.o365info.com 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: 2007
   • That the local site include a Public facing Exchange 2007CAS server
   • That the URL address of the Public facing Exchange 2007 CAS server is: https://legacy.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 “external Exchange 2007 OWA client browser” that includes the FQDN of the “Public facing Exchange 2007 CAS server”: legacy.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 2007 OWA user credentials, to the “Public facing Exchange 2007 CAS server” (Number 8).
5. The “external Exchange 2007 OWA mail client browser, “gets” the redirection command from the CAS2013 and, starts a new HTTPS session with the ” Public facing Exchange 2007 CAS server” (Number 3).
6. The Public facing Exchange 2007 CAS server (legacy.mail.o365info.com) will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server (Number 5).
7. The Exchange 2007 Mailbox server, provides the required user mailbox content to the CAS2007 (Number 6).
8. The CAS2007 sends the information to the “external Exchange 2007 OWA client” (Number 7).

A more detail description of this scenario appears in the article OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 3/4

Scenario 3: External OWA client | Multiple Public facing Exchange CAS servers | Regional namespace.

The relationships that Exchange 2013 CAS server have with Exchange 2010,2013 OWA mail client are different from the relationships that Exchange 2013 CAS server have with Exchange 2007 OWA mail client.

Exchange 2013 CAS server will use the proxy method for serving internal Exchange 2010, 2013 OWA mail clients. For example:

• When an internal Exchange 2010 OWA mail client, contact Exchange 2013 CAS server, asking access to his mailbox, the Exchange 2013 CAS server will proxy the request to Exchange 2010 CAS.
• When an internal Exchange 2013 OWA mail client, contact Exchange 2013 CAS server, asking access to his mailbox, the Exchange 2013 CAS server will proxy the request to Exchange 2013 Mailbox server.

Serving external OWA mail client

The ‘logic” that Exchange 2013 CAS server implement for “external” Exchange 2010, 2013 OWA mail client is different.

In a scenario which based on a single Public facing Exchange site”, when Exchange 2013\2010 OWA mail client connects the Public facing Exchange CAS server, the Exchange CAS server will proxy their request to internal Exchange server (Exchange CAS server or Exchange Mailbox server).

The exception is a scenario in which the Exchange infrastructure based on a multiple Public facing Exchange siteת and each of this Exchange sites are “represented” by a unique or dedicated namespace (in our article series we refer this single namespace as: ”regional namespace).

In this scenario, in case that the Public facing Exchange CAS server recognizes that the external OWA mail client mailbox located at other Exchange site + the Exchange site is a Public facing Exchange site, the Exchange CAS server “choose” to redirect the External OWA client request instead of Proxy the request.

Scenario charters

To be able to understand better the redirection process that Exchange 2013 CAS server implements in a multiple Public facing Exchange site environment, let’s use the following scenario:

• The organization, public domain name is: o365info.com
• The company had two Public facing Exchange sites: New York site and Europe site (Madrid site).
• The Public facing Exchange CAS server in the New York site is published using the name space: mail.o365info.com
• The Public facing Exchange CAS server in the Europe site is published using the name space: europe.mail.o365info.com

Scenario 3: OWA client | user mailbox located on the Madrid site | Regional namespace | destination site = Public facing

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

• The Exchange user mailbox, is hosted on the Madrid site (the Exchange 2013 Mailbox server located at the Madrid 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 access his mailbox.

The OWA protocol connectivity flow implemented as follows:

1. Madrid Exchange 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: 2013
   • The Exchange 2013 mailbox server that host the user mailbox, is located at the Madrid site
   • The remote site (Madrid site) is a Public facing Exchange site
   • That 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 OWA client browser” that includes the FQDN of the “Europe Exchange 2013 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 2013 user credentials, to the “Europe Exchange 2013 Public facing Exchange CAS” (Number 8).
5. The “Madrid Exchange 2007 OWA mail client browser, “gets” the redirection command from the CAS2013 and, starts a new HTTPS session with the “Madrid Exchange 2007 Public facing Exchange CAS” (Number 3).
6. The Madrid Exchange 2007 Public facing Exchange CAS (europe.mail.o365info.com) will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server (Number 5).
7. The Madrid Exchange 2007 Mailbox server, provides the required user mailbox content to the Madrid CAS2013 (Number 6).
8. The Madrid CAS2013 sends the information to the “external Exchange OWA client” (Number 7).