The old Exchange environment vs. modern Exchange environment | Part 02#36

In this article, we will review how does the Autodiscover answer the needs and the requirements of the modern Exchange environment.

To be able to understand the immense significance of the Exchange Autodiscover infrastructure, we will take a look at the older or previous version of Exchange architecture that did not have the Autodiscover services.

To be able to understand what the charters of the Exchange modern environment are, we will need to walk a few steps back and take a brief glimpse at the “Exchange history.”

Q1: Why should I Bother to learn about the history of Exchange infrastructure?

A1: “A generation which ignores history has no past: and no future”. [Lazarus Long, from the works of Robert Heinlein]

In simple words, to be able to understand Exchange Autodiscover infrastructure really, we will need to figure out what is the “business need” of the modern Exchange environment, which was the reason for the birth of the Exchange Autodiscover infrastructure.

Old Exchange environment

Let’s start with the definition of the technical terms – “old Exchange environment” and, “Modern Exchange environment”.

Exchange server knew many incarnations. In the following diagram, we can see a list of Exchange Server versions and the classification of old Exchange environment, vs. what we describe as the “Exchange Modern Architecture.”

1. Old Exchange environment

The Exchange server versions that we can consider as – “Old Exchange server architecture” are the following Exchange Server versions:

• Exchange 5.5
• Exchange 2000
• Exchange 2003

Note – I have drawn a line between Exchange 5.5 and Exchange 2000 because, in those days, the birth of Exchange 2000, was a revolution. The Exchange 2000 architecture was completely changed and was customized to operate in the modern Active Directory environment.

2. Modern Exchange environment

In reality, there is no such formal term as the: “Modern Exchange environment”.
I use this term for describing the new generation of Exchange server, begging with Exchange 2007 and ending with the Exchange 2013 server.

In the following diagram, we can see a summary of the main differences between the “old Exchange environment” and the “modern Exchange server environment.”

The characters of modern Exchange environment vs. the old Exchange environment

In the following section, we will review the major charters of the modern Exchange architecture vs. the “old Exchange architecture”.

Finding the Exchange CAS server

To be able to understand one aspect of the Autodiscover process, let’s look at the following diagram that represents the “thoughts” of the standard Exchange client such as Outlook-

One of the most interesting characters of the modern Exchange environment is that the Exchange client, never need to know in advance:

1. Who (what is the name) is the Exchange server which hosts his mailbox

The Exchange client doesn’t need to know what the name of the Exchange server that hosts his mailbox because he cannot address directly to the Exchange Mailbox server which hosts his mailbox.

Exchange client will need to locate his Exchange CAS server; the Exchange CAS server will accept the Exchange client request and find the Exchange Mailbox server who “hold” the Exchange client mailbox. Each of the Exchange client applications will be proxy by the Exchange CAS server to the Exchange Mailbox server and vice versa.

In other words, the Exchange CAS server needs to know: what is the name of the Exchange server which hosts his mailbox but not the Exchange client himself.

2. Who (what is the name) is the Exchange CAS server whom he needs to address.

The task of “finding the required Exchange CAS server” is implemented by the Autodiscover process.

The Autodiscover mechanism or protocol, enable Exchange client to locate and find their Exchange CAS server.
And again, by default, the Exchange client doesn’t know the name of the Exchange CAS server or who are the available Exchange CAS servers.
Instead, each time that the Exchange client need to “locate” an Exchange CAS server, the Exchange client will use the Autodiscover mechanism for finding his required Exchange CAS server.

The main characters of modern Exchange environment vs. older Exchange architecture

1. The concept of “Exchange server roles.”

Older Exchange environment

The “old Exchange architecture”, didn’t use the concept of “Exchange server roles”. Exchange 2003 architecture includes some “server role” definition described as – front end vs. back end but the basic idea of the Exchange architecture, did not base on the concept of role separation.

Modern Exchange environment

The idea of Exchange server roles burned in the Exchange 2007 version and since then, this concept continues to be one of the major charters of the modern Exchange Architecture.

The use of the “server roles,” enable to implement a duty separation. Each of the Exchange server roles represents different “duty” or set of Exchange server tasks that define as a “role.”

Exchange 2007, 2010 architecture vs. Exchange 2013 architecture

If we want to be accurate the concept of “Exchange server role” was undergoing a significant change in Exchange 2013 architecture vs. Exchange 2007, 2010 architecture.

The Exchange 2007, 2010 architecture is based upon five Exchange server roles.

The Exchange 2013 architecture based upon two Exchange server roles.

In our context of Exchange Autodiscover infrastructure, the most prominent Exchange server role is the – Exchange CAS (Client access server) role.
In the Exchange modern environment, the Exchange server which holds the “CAS role,” is the gateway of the “door” for all other Exchange infrastructure.

Logical and physical separations or Exchange roles
The implementation of the Exchange role concept can be implemented by using two (or more) Exchange server or by using a single Exchange server who “holds“ two roles or positions at the same time (CAS server role + the mailbox role).

The way that the role assignment implemented doesn’t matter because the concept of “indirect access” to the mailbox that required from Exchange client to use the Exchange CAS server stays the same.

The concept of Exchange role separation.
The recommendation or the best practice in Exchange 2007, 2010 architecture was – implement a configuration, in which each of the Exchange server roles represented by a dedicated Exchange server.

In Exchange 2013 architecture, the concept of a server role still serves as the foundation for the Exchange server architecture.

The main difference is that in the Exchange 2013 architecture, there are only two Exchange server roles vs. Exchange 2007, 2010 architecture that defines five different server roles. Additionally, the best practice in Exchange 2013 architecture is not to use the concept of a “dedicated Exchange server” for each of the server roles but instead, implement a configuration in which each Exchange 2013 server will hold the two most important roles.

Technically speaking, in an Exchange 2007, 2010 environment, a single Exchange server can “hold” all of these five roles or the Exchange roles can be “spread” between many Exchange servers.

For example, it doesn’t matter if one Exchange server holds the three roles of CAS, Mailbox, and Hub Transport. Although these three roles are “hosted” on a one physical server, what is a matter is the “logic separation” between this role.

For example, the Exchange client will need to communicate with the “Exchange CAS layer” to be able to access his mailbox content.

2. No direct connection between Exchange client and “his mailbox.”

A main additional feature of the Exchange modern environment can described as -No direct connection between Exchange mail client and the Exchange mailbox server.

In a modern Exchange environment, the only way for an Exchange client to connect to his mailbox is via the Exchange CAS server.

Exchange clients have to locate an available Exchange CAS server. Only after a successful completion of the mutual authentication process, the Exchange CAS server will (on behalf of the Exchange client) locate the Exchange mailbox server which hosts the user mailbox. The CAS server will proxy the Exchange client request to the Mailbox server, and sends back the information from the Exchange mailbox server to the Exchange client.

As mentioned, in a modern Exchange environment (since Exchange 2007), the Exchange mail client cannot directly connect to his mailbox.

The only way for Exchange client for accessing their mailboxes is via the Exchange server, which holds the Exchange CAS (Client Access Server) role.

The Exchange CAS server is the factor or the element that “stand in the middle” and “separation” between the Exchange clients and the Exchange server who host the user mailboxes (the Exchange server who has the Mailbox roles).

legacy Exchange environment – clients have direct access to their mailbox.

In the good old days, the relationship between Exchange client and “his mailbox” was implemented by using a direct connection between the Exchange client and the Exchange server who holds, or hosts the user mailbox.

For example, to be able to complete the task of creating a new Outlook mail profile, a mandatory requirement was: the need to know the exact name of the Exchange server that host the user mailbox.

In the “old days”, the organization IT should have kept a detailed table with the information about each of the organization users and the name of their Exchange servers.

The person that was responsible for creating the “new Outlook mail profile”, should have to use this table, so he would be able to “connect” the Outlook client to the “right Exchange server.”

3. The migration from a public folder based services to web-based services.

The concept of “client-server server relationships,” in which the server provides different services for his clients, was always existed in the Exchange environment.
One of the main characters of the Exchange environment is the richness of the services that the Exchange server provides to his client.

In the Exchange “old environment”, the Exchange service such as -Free/Busy time was based on Exchange unique system public folders that serve as the container for the data\information.

Exchange clients such as Outlook, access the information stored in the system public folder by using the RPC protocol.

The described mechanism suffered from many problems that were related to the process, in which the information was needed to be saved in the public folder and replicated to other Exchanges public folder store and other Exchange sites.

Exchange web service | Modern Exchange environment

One of the biggest changes since Exchange 2007 was, the Insight that the “world global language protocol” is – the HTTP protocol.

The method of using Exchange public folder for storing system data and, for providing Exchange service abandoned for the “new girl in the neighborhood”, web-based services.

The method in which Exchange services based on a public folder replaced with a new web-based method described as – EWS (Exchange web services).

Each time that Exchange client – Outlook, for example, need information such as Free/Busy time of the other Exchange recipient, the Outlook client will need to address Exchange server who holds the Exchange CAS role using the HTTP (or HTTPS) protocol and, the Exchange CAS server is responsible for “fetching” the required information for his Exchange client.

Exchange 2007, 2010 architecture vs. Exchange 2013 architecture

The common denominator between Exchange 2007, 2010 and Exchange 2013 architecture is that Exchange client must address the Exchange server which holds the Exchange CAS role, for asking a particular Exchange web service.

The main difference between Exchange 2007, 2010 architecture vs. Exchange 2013 architecture is that in the Exchange 2007, 2010 structure, the Exchange CAS server is responsible for “holding” or providing the infrastructure of the Exchange web services and at the same time, serve as a focal point for Exchange clients that ask for Exchange web services.

In the Exchange 2013 environment, the Exchange 2013 CAS is still serving as a “focal point” for the Exchange client request for Exchange web services but the Exchange 2013 CAS is not the element the generate or “produce” by himself the Exchange web services.

Instead, the element that is responsible for serving as the infrastructure for the Exchange web services is the Exchange 2013 Mailbox server.

Just a small declaration about Exchange public folder concept

When the Exchange 2007 server first published, the formal declaration of Microsoft was that “Exchange public folder is dead” or, not needed anymore because the Exchange services have “shift” from the concept of a public folder and RPC Protocol to the concept of – web services.

It’s important to me to mention that in my opinion, the declaration of the “death of the Exchange public folder” in those days, was a little hasty.

The new Exchange web-based services, replace the need for the awkward and inefficient implementation of the Exchange system public folder but the forgotten part was that many organizations use the “standard Public folder infrastructure” (not the particular system public folder) as a shared storage between the Exchange user and heavily depend on the Exchange public folder.

The Exchange web services

The infrastructure for the Exchange web service is the IIS server.

Exchange clients that need a specific Exchange web services use a URL address for sending the Exchange CAS server who will “help” the Exchange client to get the specific Exchange web services.

The URL address includes the “name” (FQDN) of the Exchange CAS server whom the Exchange client address + the path (the name) of the particular Exchange web services that the Exchange client request.

In the following diagram, we can see an example to the verity of the web services that provide by the Exchange CAS server to his clients such as Offline address book, Availability Services, Automatic Reply (Out of office) and much more.

Exchange web services and Autodiscover

We will review the connection between the Exchange web services and the Exchange Autodiscover services in details many times throughout this current article series but just a brief review:

The Exchange client “know in general” that there are Exchange web services, but technically he doesn’t know “who is the Exchange CAS server whom he needs to address for getting a specific Exchange web service”?

The “element” that is responsible for “notifying” Exchange client about existing Exchange web services is the Exchange CAS server, and the information about existing Exchange web services is “delivered” to Exchange client such as Outlook as part of the Autodiscover process.

Exchange CAS server as an information source

The relationships between Exchange client and his Exchange CAS server are complicated and, composed of several different parts.

Exchange clients look at the Exchange CAS server in a couple of ways. One way in which the Exchange client such as Outlook looks at the Exchange CAS server is a: “source of information”.

The information that the Exchange CAS server provides to his client includes different parts of information and one of this part, is the part which relates to the information about the available Exchange web services.

The communication channel in which the Exchange client request information from the Exchange CAS server implemented via the Autodiscover process.

The Exchange CAS server “answer” (the Autodiscover responds) includes two primary type of information:

1. Information about the available Exchange web services
2. Information that is needed by Exchange Outlook mail client for creating a new Outlook mail profile.

Part 1: The Autodiscover responds |Providing information about Exchange web services.

The Exchange web service (like any other web service) addressed or accessed, by the client by using a URL address.

The Autodiscover responds that the Exchange CAS server provides to his client, includes information about all the available existing Exchange web services.

The information about the Exchange web services provided by using an XML tag that includes the URL address of a particular Exchange web service.

The XML tag “inform” the Exchange client what is the particular Exchange web service. In the following diagram, we can see an example of a “line” from the Autodiscover server response.

The XML tag is- ASUrl, meaning availability services URL.
Inside the XML tag, we can see the URL address of the Availability service.

The Exchange clients depend on this information (the Autodiscover response from the Exchange CAS server), so they will be able to connect the required host who provides a particular Exchange web service.

Part 2: The Autodiscover responds | Providing information about required configuration setting for a new Outlook mail profile.

A major part of the Exchange CAS server Autodiscover responds is related to the information that is required by Exchange client, in particular – Outlook, that considers as a mandatory information (configuration settings) that needed for the task of creating a new Outlook mail profile.

Outlook mail profile and the required configuration settings

Outlook client, connect to Exchange server by using Outlook mail profile.

We can relate to the Outlook mail profile as a “container” for the configuration setting that needed for creating the communication channel with Exchange CAS server.

Exchange old environment: Outlook mail profile | Manual setting and the need for the users to be familiar with specific technical details

In the “good old days,” a primary task such as creating a new Outlook mail profile, was implemented by using a manual configuration.
The task of configuring Outlook mail profile in the internal\private network could be considered as an easy task because all the user would need to know the name of his Exchange mailbox server, and all the rest of the process executes automatically using the user domain cache credentials.

Vs. the task of configuring a new Outlook mail profile in the internal network, the task of creating a new Outlook mail profile for external users who need to configure their Outlook using the Outlook Anywhere settings (in that days, the external outlook client was described as RPC\HTTPS), was not such a simple task.

The reason is that the user, who was creating the new Outlook mail profile, would have to prepare in advance, a list of technical details that include details such: the name of the Exchange server which serves as RPC Proxy, the internal name if the Exchange mailbox server, the authentication protocol and more.

Needless to say that besides the Inconvenience, which required users to know many technical details, many times, the process couldn’t complete because a human error, wrong information, etc.

Creating a new Outlook mail profile in a modern Exchange environment

Compared to this complex process, the task of creating a new mail profile in a modern Exchange environment is just a piece of cake for the Exchange users.

For example, in an Active Directory environment the only operation that the user need to “excite” is just double-clicked on the Outlook icon.
The “double click operation”, will activate a series of actions in which Outlook will automatically detect and connect the local Exchange CAS server, implement a mutual authentication process and get from the Exchange CAS server all the required settings for compilation the task of New Outlook mail profile.

The task of creating a new Outlook mail profile in a non-Active Directory is also very simple, the only difference from the client point of view is the need for providing user credentials besides of the E-mail address.

Although theoretically there is an option to implement the “manual method” without using the Autodiscover for “finding” or locating the Exchange CAS server, this method is unsupported in most of the scenario.

A rule of thumb says that: if we have to use the option of manual settings, most of the chances that our Exchange infrastructure not configured correctly or the Exchange client has many other problems that prevent him from using the Autodiscover services.

Summary and recap

As we show in the current article, in a modern Exchange environment, Exchange client is fully dependent on the Exchange CAS server.

The Exchange CAS server is reasonable for – “connecting” Exchange client to their mailbox, provide them Exchange web service (or in Exchange 2013 provide the Exchange client request to the Exchange mailbox server) and provide his client and in particular Outlook client, information about the required configuration setting for creating new mail profile and information about existing Exchange web service.

1. “Connecting” Exchange client to their mailbox, provide them Exchange web service (or in Exchange 2013 provide the Exchange client request to the Exchange mailbox server) and provide his client and in particular Outlook client, information about the required configuration setting for creating new mail profile and information about existing Exchange web service.
2. Provide them Exchange web service (or in Exchange 2013 provide the Exchange client request to the Exchange mailbox server) and provide his client and in particular Outlook client, information about the required configuration setting for creating new mail profile and information about existing Exchange web service.
3. provide his client and in particular Outlook client, information about the required configuration setting for creating new mail profile and information about existing Exchange web service.

The process in which the client locates the required Exchange CAS server and the step in which the Exchange CAS server provides Exchange client the required information is implemented via the Autodiscover process.