The old Exchange environment versus “modern” Exchange environment | Part 02#36

Page 1 of 30 | The old Exchange environment versus “modern” Exchange environment |

Part 02#36

Written by Eyal Doron | o365info.com | Copyright © 2012-2015

The old Exchange environment versus

“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 former version of Exchange

architecture that did not have the Autodiscover services.

http://o365info.com/the-old-exchange-environment-versus-modern-exchange-environment-part-02-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/


Part 02#36


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 really understand Exchange Autodiscover

infrastructure, we will need to understand 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






Part 02#36


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,

verse 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






Part 02#36


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 short summary of the main differences

between the “old Exchange environment” and the “modern Exchange server

environment”.

The characters of modern Exchange environment

versus the old Exchange environment

In the following section, we will review the major charters of the modern Exchange

architecture versus the “old Exchange architecture”.






Part 02#36


Finding the Exchange CAS server

To be able to understand one aspect of the Autodiscover process, let’s look at the

following diagram that represent the “thoughts” of the standard Exchange client

such as Outlook-






Part 02#36


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 who hosts his mailbox

The Exchange client doesn’t need to know what the name of the Exchange server

that host his mailbox because, he cannot address directly to the Exchange Mailbox

server who hosts his mailbox.

Exchange client will need to locate his Exchange CAS server; the Exchange CAS

server will accept the Exchange client request and locate the Exchange Mailbox

server who “hold” the Exchange client mailbox. Each of the Exchange client requests

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






Part 02#36


Instead, each time that the Exchange client need to “locate” an Exchange CAS

server, the Exchange client will use the Autodiscover mechanism for locating his

required Exchange CAS server.

The main characters of modern Exchange environment

versus 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 kind of “server role” definition described

as – front end versus back end but the basic concept of the Exchange architecture,

did not base on the concept of role separation.

Modern Exchange environment

The concept of Exchange server roles was 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 versus Exchange 2013 architecture

If we want to be accurate the concept of “Exchange server role” was undergoing a

significant change in Exchange 2013 architecture versus Exchange 2007, 2010

architecture.

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






Part 02#36


The Exchange 2013 architecture is based upon two Exchange server roles.






Part 02#36


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 who holds the “CAS

role”, is the gateway of the “door” for all other Exchange infrastructure.

Note – all the rest of the Exchange server roles such as, the Exchange mailbox role

and the Exchange Hub transport roles, are also “significant roles” in the Exchange

environment, but because the Exchange client doesn’t interact directly with these

roles, we will not relate to these “other parts” of the Exchange architecture.

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






Part 02#36


The way that the role assignment is 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 will be

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 versus Exchange 2007, 2010 architecture that define five

different server roles and 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 main 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 roles.

For example, the Exchange client will need to communicate with the “Exchange CAS

layer” to be able to access his mailbox content.

Additional reading

Understand the Exchange Server Roles in Exchange Server 2010

Overview of Exchange 2010 Server Roles

Exchange 2013 Server Role Architecture

Understanding Exchange 2013 Server Roles in the simplest way





http://technet.microsoft.com/en-us/magazine/ff381422.aspx

http://technet.microsoft.com/en-us/library/dd298026(v=exchg.141).aspx

http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx

http://social.technet.microsoft.com/wiki/contents/articles/16953.understanding-exchange-2013-server-roles-in-the-simplest-way.aspx


Part 02#36


2. No direct connection between Exchange client and “his

mailbox”

An additional main feature of the Exchange modern environment can be 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 client, will have to locate an available Exchange CAS server and, only after

a successful completion of the mutual authentication process, the Exchange CAS






Part 02#36


server will (on behalf of the Exchange client) locate the Exchange mailbox server

who hosts the user mailbox, proxy the Exchange client request and sends back the

information from the Exchange mailbox server to the Exchange client.

Note – the Exchange client “locate” the Exchange CAS server using the Autodiscover

mechanism. We will review the Autodiscover process thoroughly throughout the

series of articles.

As mentioned, in a modern Exchange environment (since Exchange 2007), the

Exchange mail client cannot directly connect to his mailbox.






Part 02#36


The only way for Exchange client for accessing their mailboxes is via the Exchange

server, which hold 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).






Part 02#36


Exchange legacy environment – clients have a 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.”






Part 02#36


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 special system public folders that serve as the container for

the data\information.

Exchange clients such as Outlook, access the information stored in the public

system folder by using the RPC protocol.






Part 02#36


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.






Part 02#36


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 was abandoned for the “new girl in the neighborhood”,

web-based services.






Part 02#36


The method in which Exchange services were based on a public folder was 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 versus Exchange 2013 architecture

The common denominator between Exchange 2007, 2010 and Exchange 2013

architecture is that Exchange client must address the Exchange server who holds

the Exchange CAS role, for asking a specific Exchange web service.

The main difference between Exchange 2007, 2010 architecture versus Exchange

2013 architecture is that in the Exchange 2007, 2010 architecture, 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.






Part 02#36


Just a small declaration about Exchange public folder concept

When the Exchange 2007 server was 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.






Part 02#36


It’s important to me to mention that for my opinion, the declaration about 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 special 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 needs a specific Exchange web services use a URL address for

addressing 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 specific Exchange web

services that the Exchange client request.






Part 02#36


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.

Note – The Exchange CAS server can provide a specific web service by himself,

proxy an Exchange client request to other Exchange CAS servers or send a

“redirection respond” to the Exchange client that includes an information about

other Exchange CAS servers.

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:






Part 02#36


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 relate to the

information about the available Exchange web services.

The communication channel in which the Exchange client request information from

the Exchange CAS server, is implemented via the Autodiscover process.






Part 02#36


The Exchange CAS server “answer” (the Autodiscover responds) includes two major

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) is 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.






Part 02#36


The information about the Exchange web services is provided by using an XML tag

that includes the URL address of a specific Exchange web service.

The XML tag “inform” the Exchange client what is the specific Exchange web service.

In the following diagram, we can see an example for 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 are depended on this information (the Autodiscover response

from the Exchange CAS server) so they will be able to connect the required host

who provide a specific Exchange web service.






Part 02#36


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 is 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 is needed for creating the communication channel with Exchange CAS

server.






Part 02#36


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 basic 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 was the name

of his Exchange mailbox server and all the rest of the process executes

automatically using the user domain cache credentials.

Versus 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 so simple task.

The reason is because 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 who serves as RPC Proxy, the internal name

if the Exchange mailbox server, the authentication protocol and more.






Part 02#36


Needless to say that besides the Inconvenience which required users to know many

technical details, many times, the process couldn’t be completed because human

error, wrong information, etc.






Part 02#36


Note – In the old Exchange environment, there was some kind of option for

implementing the task of “automatic Outlook mail profile creation” but, the

implementation of the “automation” was based on using tolls such as ORK (Office

Resource Kit) and PRF files, distributing the scripts to each of the domain users’

desktop and so on.

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.






Part 02#36


The task of creating a new Outlook mail profile in a non-Active Directory is also very

simple, the only deference from the client point of view, is the need for providing

user credentials besides of the E-mail address.

Note – technically, Exchange client such as Outlook, can be configured manually for

connecting their Exchange CAS server.

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 un-supported 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 is 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 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.

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.






Part 02#36


In the next article (Who are the Exchange Autodiscover clients? | Part 03#36), we

will thoroughly examine each of the different parts of the Exchange Autodiscover

infrastructure.





http://o365info.com/who-are-the-exchange-autodiscover-clients-part-03-of-36

Documents

The old Exchange environment versus “modern” Exchange environment | Part 02#36