Autodiscover and Outlook client protocol connectivity flow in Exchange 2013/2010 coexistence | 2/4 | 21#23
The current article is the second article in a series of three articles, which will…
In this article, I would like to focus on the term “legacy” that is used very often in the Exchange 2013 coexistence environment. As usual, the common assumption is that everyone knows and understands this term, but in reality, the term is not so clear, and we are as ashamed to admit that we don’t fully understand the meaning of the phrase.
In the context of Exchange 2013 coexistence environment, the term: “Legacy” can be translated into a couple of options:
In my opinion, the term “legacy” seems always a little out of place.
What is the meaning of legacy?
Does it mean that, up until now, the existing Exchange infrastructure that was sworn to “serve and protect” is useless or, not good anymore?
Does it mean that only the “new Exchange infrastructure” is meaningful and relevant?
I know it’s philosophizing but, I think that the “Exchange guys,” should choose a more politically-correct term because the association that appears to mind when I hear the term “legacy” is something like this:
Regardless of my reservations, as a loyal citizen of the Exchange nation, I will continue to use this term as long as it needed.
Let’s make it simple. When a new Exchange server version is released, and we want to “adopt” this new Exchange server version we have two basic options:
Option 1: “Wipeout” the existing Exchange infrastructure and “plant” the new Exchange server version or in more technical words: install the new Exchange server version and decommission the previous Exchange server version.
Option 2: Implement an Exchange infrastructure that can be described as – “side by side”. The meaning is, add the new Exchange server version (Exchange 2013 server, in our case) to the existing Exchange environment and, slowly start to “migrate” all the resources such as user mailboxes and Exchange web services to the “new Exchange infrastructure.”
Only after there is no Exchange client that relies on on\use the former Exchange infrastructure, we can start to decommission the “older Exchange environment”.
When implementing a project of Exchange coexistence, the Exchange 2013 infrastructure is the “new infrastructure” and all the rest of the former Exchange server versions can be described as:
In the following diagram, we can see that from the Exchange 2013 point of view, Exchange 2010 infrastructure and Exchange 2007 infrastructure consider as: Legacy Exchange infrastructure.
The term “legacy Exchange client” relates to Exchange client that their mailbox is hosted on the legacy Exchange mailbox server.
In our scenario of Exchange 2013 coexistence environment, each Exchange user who is a mailbox is hosted on Exchange 2007 Mailbox server or Exchange 2010 Mailbox server consider as “legacy Exchange client.”
Throughout the series of articles, I will not use the term: “legacy Exchange client” but instead, I will refer to “non-Exchange CAS 2013 server client” as Exchange 2007 clients or Exchange 2010 clients.
In an Exchange 2013 coexistence environment, “legacy Exchange clients” such as Exchange 2007/2010 clients will need to Initialize the communication process with the Exchange 2013 CAS server, and the “rest” of the process will be “determined” by the Exchange 2013 CAS.
Exchange CAS 2013 will decide how to continue the client protocol connectivity flow based the particular scenario parameters such as the Exchange client version, the Exchange client physical location and so on.
For example, the Exchange CAS 2013 can decide to Proxy the legacy Exchange client request to the legacy Exchange infrastructure by himself or send to the legacy Exchange client a redirection command, etc.
Q1: “Why does the Exchange 2013 server need to deal with legacy Exchange clients?
Why not implementing an architecture, in which Exchange 2013 will serve only Exchange 2013 client, and the “other legacy Exchange servers” will serve their legacy Exchange clients?
A1: Well, the simplified answer is that in an Exchange 2013 coexistence environment, the most updated Exchange server version (Exchange 2013 CAS in our scenario) will need to be configured as the “focal point” for all the Exchange clients, including native Exchange 2013 “native clients” + legacy Exchange clients (Exchange 2007/2010 clients).
Note – You can read more information about the concept of Exchange CAS 2013 serve as a focal point in the article – Exchange Public infrastructure | Public versus non-Public facing Exchange site
The Exchange 2013 CAS is “smart enough” to recognize Exchange client version such as Exchange legacy client and decide about the “next step” such as – Proxy the Exchange legacy client requires to the “right Exchange legacy infrastructure.”
For example, when Exchange 2007 Outlook client (Exchange user who is a mailbox is hosted on Exchange 2010 Mailbox server) address Exchange CAS 2013 server, the Exchange CAS 2013 server “understand” that the particular client “belong” to the Exchange 2010 infrastructure and for this reason, the Exchange CAS 2013 server will proxy the request to available Exchange 2007 CAS.
Note – from the Exchange 2007 client point of view, this process is transparent. The meaning is that the Exchange 2007 client is not where to the fact that his request was “routed” to the Exchange 2007 CAS.
From the Exchange 2007 client point of view, the Exchange CAS 2013 server is the element that provides the required mailbox data.
Let’s start from the end: the term “Exchange legacy namespace”, is relevant only in a scenario of Exchange 2013/2007 coexistence environment.
The use of the “Exchange legacy namespace”, will be implemented for Exchange 2007 OWA clients and Exchange 2007 Outlook clients that access the Exchange 2007 web services.
In Exchange 2013/2007 coexistence environment, Exchange 2013 CAS behaves differently with different Exchange 2007 client type.
This is one of the two reasons behind the need to create and use the legacy namespace in Exchange 2013/2007 coexistence environment.
Exchange CAS 2013 server, doesn’t know how to proxy, Exchange 2007 OWA client requests to Exchange 2007 CAS server.
Generally speaking, Exchange CAS 2013 server prefers to implement the proxy method because the Proxy method makes the Exchange client life simple. The Exchange client doesn’t need to be familiar with the complex infrastructure of the client protocol connectivity flow or play an “active role” in the communication process. When implementing the method of Proxy, Exchange CAS 2013 does all the “hard work,” work” and the Exchange client just enjoys from the ability to access his mailbox data.
Because the Exchange CAS 2013 server doesn’t know how to proxy, Exchange 2007 OWA clients’ request, Exchange 2013 CAS uses a method which described as a redirect or if we want to be more specific: silent redirect + SSO.
You can read more information about silent redirect + SSO in the article – OWA client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 3/4
The redirection method is implemented by sending the Exchange client a URL address of “other Exchange CAS servers” that can help the Exchange client.
In a scenario of Exchange 2007 OWA mail client, the Exchange CAS 2013 server will send the client the URL address of existing Exchange 2007 CAS server.
To be able to “refer” the Exchange 2007 OWA client to the Exchange CAS 2010, the Exchange CAS 2013 “send” the Exchange 2007 OWA client browser a redirection command with the URL address of the “destination Exchange CAS 2017” that include the Exchange CAS 2007 legacy namespace.
The term: legacy namespace, describe the namespace that is assigned or “attached” to the Exchange 2007 CAS server. For example: legacy.mail.o365info.com
In other words, to be able to refer to other or additional Exchange CAS servers (the Exchange CAS 2007) we will need to use a different namespace from the primary namespace. This is the reason or the need for using the: “legacy namespace”.
The second reason for using the legacy namespace in Exchange 2013/2007 coexistence environment is the subject of – providing Exchange web services to Exchange 2007 clients.
In Exchange 2013/2007 coexistence environment, Exchange 2007 client will need to get their Exchange web services from Exchange 2007 CAS and not from Exchange 2013 CAS.
The reason is Exchange 2013 CAS doesn’t know how to provide Exchange web services to the Exchange 2007 clients.
In the following diagram, we can see the concept of “redirecting Exchange 2007 clients” requests for Exchange web services to the – Exchange 2007 CAS.
In reality, there is no “real redirection process.
The Autodiscover information that Exchange 2013 CAS provides to the Exchange 2007 clients, includes the URL address and the FQDN that represents the legacy namespace of the Exchange 2007 CAS such as: legacy.mail.o365info.com
When Exchange 2007 client looks at the host who can provide him Exchange web services, Exchange 2007 client will use the URL address which includes the “referral” to the Exchange CAS 2007.
In Exchange 2013/2007 coexistence environment, Exchange CAS 2013 need to
To be able to “refer” to the Exchange CAS 2007, we will need to use a unique\dedicated namespace for the Exchange CAS 2007 infrastructure, which is different from the primary namespace.
The “additional namespace” that assigned to the Exchange CAS 2007 server described as: “legacy” because as we mention, Exchange relates to previous versions of Exchange server as a legacy.
The legacy namespace based on a concept in which we continue to use the existing domain name and add or use a different host name (prefix).
For example: in our scenario, the domain name is: o365info.com
The primary namespace that is used for publishing and addressing the Exchange CAS 2013 is: mail.o365info.com
To be able to differentiate the Exchange CAS 2007 from the “primary namespace”, we can use a naming convention such as: legacy.mail.o365info.com or another option is to add to host name: “legacy” to the existing primary namespace. For example: legacy.mail.o365info.com
Technically speaking, there is no mandatory need for using the host name: legacy. The legacy is not a reserve host name but instead, just a common naming convention.
For example: we can use the following namespace: unclesam.mail.o365info.com as the legacy namespace for Exchange CAS 2007 server.
It’s important to mention that will need to “publish” and update the “new legacy namespace” is different infrastructures.
We can use the following diagram as a “recap” for what we have to learn up until now.
At first look, the concept of: “two Public facing Exchange CAS server in a single Exchange site” seems a little odd. The standard convention of Exchange public infrastructure in a scenario of – a Public facing Exchange site, is implemented most of the time, by using a specific Exchange CAS server which serves as the “representative” of a Public facing Exchange site.
Even in a scenario in which we implement a fault tolerance and load balancing mechanism and use an array of Exchange CAS servers, the external client “see” only one entity or one namespace such as: mail.o365info.com
In a scenario of Exchange 2013/2007 coexistence environment, we need to implement a configuration, in which we need to use: two Public faces Exchange CAS servers at the same time.
Exchange CAS 2013 which will be the “leading Public facing Exchange CAS server” and additionally, an Exchange CAS 2007 which will also have to have a public availability.
The “Exchange 2007 Public facing server” will serve Exchange 2007 OWA clients.
The scenario in which external Exchange 2007 clients, will address the Public facing Exchange 2007 CAS server are as follows:
1. External Exchange 2007 OWA clients
Exchange 2007 OWA clients will address the “primary” or the “main” Public-facing Exchange CAS server meaning – the Exchange CAS 2013. When the Exchange CAS 2013 recognizes that the external client is: Exchange 2007 OWA client, the Exchange CAS, 2013 will start a process of silent redirection in which he redirects the Exchange 2007 OWA client browser, to the “Exchange 2007 Public facing server.”
Exchange 2007 OWA client addresses the Public facing Exchange 2013 CAS server by using the URL address: mail.o365info.com
The redirection command that will “refer” the Exchange 2007 client, to the Exchange 2007 Public facing server based on a URL address that includes the legacy namespace of the Public facing Exchange 2007 server. For example, the URL address could be: https://legacy.mail.o365info.com/owa
The Exchange 2007 OWA client, will need to
In simple words, to be able to enable this “flow”, we will need to “expose” also the Exchange 2007 CAS and configure the Exchange 2007 server as a Public facing Exchange CAS server.
2. External Exchange 2007 Outlook clients
Exchange 2007 Outlook clients will address the “primary” or the “main” Public-facing Exchange CAS server as the Autodiscover Endpoint. When the Exchange CAS 2013 recognizes that the external client is: Exchange 2007 Outlook client, the Exchange CAS, 2013 will create a “custom Autodiscover answer,” which includes the URL address of the “Exchange 2007 Public facing server.”
When Exchange 2007 Outlook clients need a particular web service, the client will address the Public facing Exchange 2007 CAS server using the legacy namespace.