The current article is the third article of four articles series, on the subject of:…
Implementing an Exchange 2013 coexistence environment, could consider a challenging project because to be able to build the “coexistence environment successfully,” we will need a good understanding of the Exchange 2013 CAS architecture and the “Legacy Exchange infrastructure” (Exchange 2010 or Exchange 2007).
Additionally to the lack of “comprehensive understanding” of the new and “old Exchange infrastructure”, we need to know:
- How to “combine” the Exchange 2013 infrastructure with the legacy Exchange infrastructure
- Understand the client protocol connectivity flow in Exchange 2013 coexistence environment
Did sound complicate and hard? I prefer to use the words: exciting and challenging!
The purpose of the following article series is to clarify the fog around the subject of the Exchange 2013 coexistence environment.
The goal of this article series is not to provide a “step by step” instruction for building Exchange 2013 coexistence environment.
My primary purpose was to enable the reader to understand the “logic” or the “why” part, for doing a particular task or follow a specific instruction when implemented an Exchange 2013 coexistence environment.
The requested result was to review the client protocol connectivity flow in the Exchange 2013 coexistence environment of – Exchange 2013/2010 coexistence environment, and Exchange 2013/2007 coexistence environment.
It’s almost impossible to start right ahead with the technical description of the client protocol connectivity flow in the Exchange 2013 coexistence environment without knowing the different parts of the Exchange architecture and infrastructure and, without understanding the unique charters of Exchange clients such as Outlook, OWA or ActiveSync (mobile).
Table of contents
- The reasons + the infrastructure for the current Exchange 2013 coexistence environment article series
- The building blocks of Exchange 2013 coexistence environment
- The term client protocol connectivity flow versus the term mail flow
- The term “Exchange coexistence”
- Implementing the project of the Exchange 2013 coexistence environment
- Why should I use Exchange coexistence environment?
- Why should I learn about Exchange coexistence environment?
- Why does it have to be so complicated?
The reasons + the infrastructure for the current Exchange 2013 coexistence environment article series
My wish was to clarify and simplify the “client connectivity in an Exchange 2013 Coexistence Environment” because the common denominator of the lecture and the article is that the “reader” is a person that is very familiar with the Exchange architecture and infrastructure. In reality, not all of us are Veteran Exchange Warriors to know Exchange from the moment he created, etc.
The building blocks of Exchange 2013 coexistence environment
The current article series, is about the subject of: Exchange 2013 coexistence environment and client protocol connectivity flow, but, there is one and a very major problem!
To be able to understand the connectivity protocol flow in an Exchange 2013 coexistence environment, we need to be familiar with the Exchange 2007 environment and architecture, the Exchange 2010 environment and architecture and the Exchange 2013 environment and architecture.
The subject of “protocol connectivity flows in an Exchange 2013 coexistence environment” deal with the relationships of Exchange 2013 infrastructure with the legacy Exchange infrastructure (Exchange 2007, 2010). If we want to be honest, most of the time we do not know well each of the Exchange versions and for this reason, the task of understanding the meaning of Exchange 2013 coexistence environment is not so simple.
My point is that before we can start with the details and the specific charters of Exchange 2013 coexistence environment, we first need to understand the different building block of the Exchange environment and especially, the building block and the unique charters on the Exchange 2013 coexistence environment.
The current article serious includes 16 articles. The “building block” that will be reviewed in the current article are:
- Namespace – primary namespace, legacy namespace, regional namespace.
- Public facing Exchange site and Public facing Exchange CAS server
- General concept of: Exchange Legacy infrastructure
- Proxy versus redirection
- Exchange 2013 as a focal point concept
- Public versus external Exchange infrastructure
The term client protocol connectivity flow versus the term mail flow
It’s important that we distinguish between the term: “client connectivity” and another popular term that is often used: “Mail flow”
1. Client connectivity
If we want to simplify the whole Exchange infrastructure, we can say that the Exchange infrastructure exists for:
- Enable Exchange client access to their mailbox data.
- Enable a mail client to send and receive mail.
In the context of the Exchange environment, the term: client connectivity or client protocol connectivity, relate to the path or the “road” between the Exchange clients and his destination: his mailbox. In the Exchange environment, Exchange clients cannot access directly to their mailbox or their Exchange Mailbox server. Instead, Exchange clients will need to address the Exchange server which holds the CAS (Client Access Server) role, and the Exchange CAS server will have to find the “right” way to the particular user mailbox.
The “way to the user mailbox” or the “path” to the user mailbox depends on many variables such as the Exchange client’s mailbox version, the Active Directory site structure, the available Exchange CAS servers, the mail protocol that the Exchange clients use and so on.
The path that will be selected by the Exchange CAS server to get to the user mailbox described as client connectivity or client protocol connectivity.
We can relate to the term “client protocol connectivity flow” as a “journey” that the Exchange client must pass for
- Reaching the content of his mailbox
Getting a specific Exchange web service
The diagram display only simplified path through the client protocol connectivity flow because in an Exchange 2013 coexistence environment, we will see that the “journey” is much more complicated and consists of many “steps”
2. Mail flow
The term “Mail flow”, is used for describing the path or the road that a particular mail item will need to get through from the point that is sent by the source recipient, until the end point in which he accepted by the “destination receipt.” The subject of: “Mail Flow” is a very essential component in the Exchange environment, but in this article series, we will not relate to this area and instead will focus only on the subject of client connectivity or client protocol connectivity.
The term “Exchange coexistence”
The term “Exchange coexistence” describes an environment which includes a couple of Exchange Server versions. The maximum number of “Exchange generations” described as N-2. The meaning is that the most updated Exchange server versions, can “living together” with former Exchange generations, up to two generations back.
For example – Exchange 2013 can be installed and successfully communicate with existing Exchange 2007 and Exchange 2010 infrastructure but not with Exchange 2003 infrastructure.
Implementing the project of the Exchange 2013 coexistence environment
The amount of information that we need to know about the existing Exchange technology, the “new Exchange technology” such as Exchange 2013 and the combination of these technologies could be quite Overwhelming.
In simple words, if you do not know exactly what you need to do, and what are the exact task that needs to be implemented to complete the migration project successfully, don’t do it!
The implementation of Exchange 2013 coexistence environment is related to a couple of different “sections” such as:
- Mail flow – the flow of the mail that is sent to the internal Exchange recipient to external recipients and vice versa.
- Mailbox migration – the process of the migrating user mailboxes from the legacy Exchange infrastructure to the Exchange 2013 Mailbox server
- High availability – the ability to use an array of Exchange CAS server which will enable us to implement high availability and load balancing.
- Site resilient – the subject of building a redundant data center and in the case that a particular data center is not available automatically switch Exchange client to the “other data center”
- Namespace management – the namespace that we will use for the internal Exchange client, the namespace that we use for an external Exchange client, the namespace that we use for legacy infrastructure, etc.
- Client protocol connectivity flow – this is that part that relates to the way or the path that the different Exchange mail client use for “reaching” to their mailboxes.
Why should I use Exchange coexistence environment?
Although we use the name “Exchange” for describing the Microsoft mail server product, each of the Exchange versions is very different from the previous Exchange versions.
In theory, each time that is new Exchange server appear, we could pull out the new Exchange DVD, choose yes, as the answer for: would you like to upgrade your existing Exchange infrastructure, drink a cup of coffee and after a 15, minutes be impressed with the new Exchange interface.
In a real life, the project of “upgrade existing Exchange infrastructure” could consider as sophisticated and definitely cannot be implemented as a “one-click process.”
The reasonable solution for a medium and large Exchange environment is to implement the scenario which described as – Exchange coexistence environment. The Exchange coexistence solution is a solution that created as a “temporary solution” for a particular time frame that will enable us to migrate the existing Exchange infrastructure to the “new Exchange infrastructure”.
In other words: we are building two separate Exchange environments, which “live together side by side.” The migration process is implemented by “moving” parts of the existing Exchange infrastructure to the “new Exchange infrastructure” until we finish moving all the “parts” such as user mailboxes, etc. Only after a successful migration of the data, from the “old Exchange environment” to the “new Exchange environment”, we can “shut down” or decommission the “old Exchange environment”.
The Exchange coexistence environment implemented as follows:
- We add the “new Exchange version” into the existing Exchange infrastructure.
- We point and direct current Exchange services such as Autodiscover and Exchange web services to the “new Exchange server”.
- We start to migrate Exchange users’ mailboxes from the “old Exchange infrastructure” to the “new Exchange infrastructure.”
- We remove and decommission the legacy Exchange infrastructure.
The Exchange coexistence environment required during the phase that requested for the completion of the migration process.
Why should I learn about Exchange coexistence environment?
There are a couple of answers to this question:
1. Planning for the implementation of Exchange coexistence environment
In case that you need to implement a configuration of Exchange coexistence environment, there are a lot of “details” and “parts” that you need to be aware of. As mentioned, the purpose of current article series is not to provide you a technical instruction of “how to” or serve as a manual of “step by step.” by step.”
Instead, the purpose is to expand the level of your knowledge about the Exchange coexistence environment and provide a high-level view
- The different component of the Exchange 2013 coexistence environment
- The relationships between this component
- The different connectivity flow the Exchange 2013 implemented for each of the mail protocol and services.
- The different connectivity flow the Exchange 2013 implemented for different type of client such: internal and external Exchange mail client or different versions of Exchange client such as – Exchange 2007, Exchange 2010 and Exchange 2013 mail clients.
2. Troubleshooting client protocol connectivity flow Exchange coexistence environment
It’s easy to say: “I need to troubleshoot client protocol connectivity flow in an Exchange coexistence environment” but it’s very hard to implement a troubleshooting process in case that you have no idea about: how does the client protocol connectivity flow Exchange coexistence environment is implemented in practice regarding a scenario of:
- Different mail protocols.
- Different Exchange services.
- Different version of Exchange clients (2007, 2010, and 2013).
- Different location of the mail client such as: internal versus mail clients.
The good news that the Exchange coexistence infrastructure is very interesting and challenging. The less good news is that if you don’t spend the required time for “understanding” this infrastructure and planning this infrastructure, you can expect difficult times.
3. Pure curiosity
Curiosity is not a rude word! This is the “sticky part” in which I praise the beauty of the Exchange coexistence environment. I relay thinks that the architecture of Exchange is fascinating and challenging, and I’m always happy to learn and understand more and more about the Exchange architecture, and at the same time, except that I can never understand all of this infrastructure, and really knows each of his parts.
Why does it have to be so complicated?
Many times when I read articles that deal with the subject of migration to new Exchange version, the question that appears in my mind is: Why does it have to be so complicated?
The answer is that to be able to provide our customers an excellent service in which the transition to the “new Exchange 2013 infrastructure” will be transparent to users and, to implement a migration that will measure in zero downtime, we will need to work hard, learn about each of the Exchange components, make the required preparation and so on.
However, this “declaration” still doesn’t answer the question.
The answer to the question of:” Why does it have to be so complicated?” is because the Exchange architecture is very rich and includes many “moving parts”, complex infrastructures, protocols, settings, etc. So here is\are the answers:
1. Exchange infrastructure abundance of mail protocol and services
One of the most prominent charters of Exchange architecture is what I call – an abundance of the mail protocol and services.
Exchange infrastructure provides many web services such as Autodiscover, the Availability service (Free/Busy time), Automatic reply (out of office), mail tips, calendar sharing, offline address book and much more. Regarding the subject if: mail client, Exchange provides services for a variety of mail client such as:
- Internet client that uses the mail protocols: POP3, IMAP4 and SMTP
- Mobile client that uses the ActiveSync protocol.
- Web client that uses HTTP and HTTPS protocol.
- Outlook client that uses: RPC, RPC/HTTP, RPC/HTTPS or MAPI/HTTPS
Add to this “salad” the subject of different authentication protocols such as Basic, NTLM and Kerberos and we get quite a mess.
Each of the Exchange versions relates and implements this services and protocols in a different way and, in an Exchange coexistence environment, we will need to make all of these protocols, and services work together.
2. Exchange multi-role architecture
Exchange architecture is based upon a concept that described as multi-role architecture. Each of the “Exchange role” has different responsibilities and specific way for communication with the “other Exchange roles” and guesses what? Each of the Exchange versions is implementing the “role architecture” in a different way.
For example, the multi-role architecture that was very popular in the Exchange 2007 and Exchange 2010 environments are updated, and the new Exchange 2013 architecture based on a different implementation of the multi-role architecture.
Instead of “spreading” the roles between the various Exchange servers, the Exchange 2013 architecture relies on a concept in which a single Exchange server will have most of the “Exchange roles” and the responsibility for each of the Exchange roles significantly changed in the Exchange 2013 architecture. An Exchange coexistence environment should “contain” all of this different Exchange architectures and enable to all the different Exchange versions to work together.
3. Complex infrastructure
In the following diagram, we can see a brief summary of the modern environment or in other words, the thing that Exchange server need to deal with. For example:
- Outlook version – the term: “Outlook client” can be translated to many types of Outlook client versions such as: Outlook 2007, 2010, and 2013. Despite the fact that we use the term: “Outlook” for describing these clients, each of the Outlook versions is different and implemented the communication channel with an Exchange server in a different way.
- Outlook communication protocols – at the current time, Outlook version 2013 support the following type of communication protocols: RPC, RPC/HTTP, RPC/HTTPS or MAPI/HTTPS. So when we say a sentence such as: Outlook client is communicating with the Exchange server, to which protocol we are referring?
- Outlook – internal versus external client
Before we start with the actual description of the client protocol connectivity flow Exchange 2013 in a coexistence environment, it’s important to review the different parts of the Exchange environment, the charters of these “parts” in the Exchange legacy environment verse the Exchange 2013 environment and how to “create the magic” that will “glue” of these parts together.
In more technical words: what are the required configurations setting that we will need to implement and what the reason for these settings is.
So let’s start our journey into the mysterious and fascinating world of the Exchange 2013 coexistence environment!