The old exchange environment versus modern exchange environment part 02#36

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.

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

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 datainformation.
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 internalprivate 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 RPCHTTPS), 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.

The old exchange environment versus modern exchange environment part 02#36

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to The old exchange environment versus modern exchange environment part 02#36

Similar to The old exchange environment versus modern exchange environment part 02#36 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

The old exchange environment versus modern exchange environment part 02#36