Exchange Clients and Their Public Facing Exchange Server - Part 13 of 36

Page 1 of 26 | Exchange clients and their Public facing Exchange server | Part 13#36
Exchange clients and their Public

facing Exchange server | Part 13#36
The current article will be dedicated to the subject of Exchange clients that access
Exchange services from a public network.
The focus is on the public Exchange clients because, the characters of the
communication channel between the Exchange server and his Exchange client in a
public environment, have a different character from the communication channel
that is implemented between Exchange clients and Exchange server in an
environment that considers as private or internal network based environment.
The main characters of the public environment and the relationships of Exchange
server and his Exchange client are:
Written by Eyal Doron | o365info.com | Copyright 2012-2015
1. Public facing Exchange server to be able to address the Exchange server, the
Exchange server should be configured as Public facing Exchange server. The
translation of this term is Exchange server who has public FQDN, public IP and,
public certificate. In addition, we will need to make all the required
configurations in the Firewall\Proxy infrastructure that will allow access from
external client to the internal Exchange server.
2. Autodiscover flow\process the Autodiscover flow in a public environment in

which the Autodiscover client needs to locate his Autodiscover Endpoint, will not
be implemented by using access to Active Directory because in a public
environment, the Active Directory services are not available. Instead, the
Autodiscover client will try to locate his Autodiscover Endpoint by using a
predefined naming structure and DNS infrastructure for locating the required
Autodiscover Endpoint.
Q1: Does the Exchange server must be configured as Public facing Exchange
server?
A1: No, technicality we dont have to expose the Exchange server to the Exchange
client that located in the public network. In most of the modern working
environment, the business need is to enable external Exchange client to access
organization mail services but, this is not a mandatory requirement.
Q2: In a scenario in which the organization has multiple sites, and each of the sites
includes multiple Exchange servers, do we need to published all the existing
Exchange servers?
A2: The answer is no. For example, in a site that includes multiple Exchange servers,
we need to expose only one specific Exchange server who will serve as a
representative for all the internal Exchange infrastructure.
When public Exchange clients address the Public facing Exchange server, the
Exchange server know how to route their request to internal Exchange resources
and provide the answer from the internal Exchange resource to the external
Exchange client.
In this scenario, the Public facing Exchange server will have two different identities
or interfaces:
One interface for the internal\private Exchange infrastructure

One interface for Public Exchange clients
Public facing Exchange CAS server | The two worlds

To be able to demonstrate the two worlds of Exchange server the internal
versus the external interfaces and the characters of this different environment, lets
use a scenario of an infrastructure that have the following characters:
The charters of the Exchange environment in our scenario are as follows:
Active directory internal domain name is o365info.local

Public domain name is o365info.com
The E-mail address of the organization users is based on the mail suffix
o365info.com
Exchange\Active directory sites the organization has two Exchange\Active
Directory sites: New York Site and Los Angles Site (the New York site, is the
headquarters of the company).
The name of the Exchange CAS server in New York Site is exo1.o365info.local
The name of the Exchange CAS server in Los Angles Site is
exo2.o365info.local
John is an organizations user whom his mailbox is hosted on the New York
Exchange Site.
Alice is an organizations user whom his mailbox is hosted on the Los Angles
Exchange Site.
Exchange CAS server Internal and external FQDN

naming scheme
One of the main tasks when planning or building an Exchange infrastructure is the
subject of the naming scheme (namespace) that includes the internal and the
external Exchange server FQDNs.
The result depends on the specific organization scenario, and the services that the
organization needs or wants to provide to his internal and external mail clients.
In our example, we will review three different optional scenarios, of public
Exchange client that needs access to their Exchange server (to the Public facing
Exchange server).
Many times, the small and midsize organization will expose only one Exchange
CAS server who will serve as a Public facing Exchange CAS server.
In a scenario of enterprise company, that have multiple sites in different

geographical locations, the Exchange public infrastructure, will include more than
one Public facing Exchange CAS server.
For example, each of the company sites can have a Public facing Exchange CAS
server.
In the following section, we will review four different scenarios:
Scenario 1 and scenario 2, will demonstrate an Exchange infrastructure that

has only one Public facing Exchange CAS server.
Scenario 3 and scenario 4, will describe Exchange infrastructure that uses a
Public facing Exchange CAS server for each of the company Exchange sites
(multiple Public facing Exchange servers).
We will begin with a simple scenario and move forward to more complicated or
advanced scenarios.
In the following table, we can see the naming scheme that was selected for the
specific organization (o365info.com )
Note the following table, includes the information for all the scenarios that we will
be reviewing. Some of the simple or the basic scenario, doesnt use all the
information that appears in the Exchange FQDNs table.
New York Exchange CAS server
The Exchange CAS server of New York site, will be configured as a Public facing
Exchange CAS server.
The internal or the private name of the New York Exchange CAS server is
exo1.o365info.local
We will use three public names for the New York Exchange CAS server:
autodiscover.o365info.com
mail.o365info.com
owa.o365info.com
Los Angles Exchange CAS server

The internal or the private name of the Los Angles Exchange CAS server is
exo2.o365info.local
We will use two public names for the Los Angles Exchange CAS server:
mail-la.o365info.com
owa-la.o365info.com
An additional consideration
Public DNS and A records

This public name will have to re registered at a public DNS and mapped to the
New York + Los Angles Exchange CAS server public IP.
Public IP address
In our scenario, despite the fact the Public facing Exchange server has multiple host
names, only one Public IP address is allocated for the New York Exchange CAS
server
The mail client is not interested in this fact.
The reason for using a multiple hosts name (FQDNs) is just for convenience
purposes.
For example, most of the time, the popular naming convention for accessing the
Exchange web mail services is by using the host name such as owa.o365info.com
Exchange CAS server public certificate

The certificate that will be provided to the external mail client by the Public facing
Exchange server, will need to include all the different FQDN names whom we
mention.
Note that the public server includes the internal names (FQDNs) of the New York
and Los Angles Exchange CAS servers.
The external mail client doesnt relate to this Internal FQDNs and doesnt need to
verify this Internal FQDNs.
This internal name, will be used only by an internal mail client that connects the
Exchange CAS server from inside of the organizations private network.
Public facing Exchange CAS server | Naming scheme and

Exchange services
A simple question that we can ask ourselves is why to use more than one public
name and what did we choose these specific names?
The answer is that these public names are based on a standard naming convention.
Technically speaking, we could have used only one public name, choose additional
public names or choose different host names (the exception is the Autodiscover
host name who considers as a reserved name).
The public names who were chosen for the Public facing Exchange server are just
standard names that use most of the time.
The Autodiscover public FQDN
External Exchange client (Autodiscover client) that will look for an Autodiscover
Endpoint will look for a specific host name autodiscover.o365info.com
For this reason, this host name is mandatory, and we cannot choose another or
different name.
Note there is an additional Autodiscover method based on an SRV record that

allows us to use a different name for the Public facing Exchange CAS server that
provide the Autodiscover services, but we will not review this option in the current
article.
Exchange web mail services public FQDN

External web mail clients, will address the Public facing Exchange server by using
the host name owa.o365info.com
Many organizations use the naming convention OWA + <Public domain name> for
publishing the Exchange services that provide external mail the option to access
their mailbox by using a web browser (web mail client).
As mentioned before, the organization can choose any name who will suit his needs
and there is no mandatory requirement to choose this specific host name (OWA)
The general public FQDN of the Public facing Exchange server
The public hostname mail.o365info.com, will be used for all the rest of the
Exchange web services such as Availability services (Free\Busy time), Automatic
reply (Out of office), unified messaging and so on.
Most of the time, this public name (mail.o365info.com) will also be used for
publishing the Exchange MX record.
LOS ANGLES SITE.
The Public facing Exchange server Los Angles Exchange server, will have to use a
different host name because, we cannot use the same host names for a different
Exchange server.
Note in the last scenario, we will review an exception for this rule. The ability to
use the same host names for a different Exchange server could be implemented by
using a GeoDNS.
Los Angles Exchange web mail services public FQDN
External webmail clients will address the Public facing Exchange server by using the
hostname owa-la.o365info.com
Los Angles general public FQDN of the Public facing Exchange server
The public hostname mail-la.o365info.com, will be used for all the rest of the
Exchange web services such as Availability services (Free\Busy time), Automatic
reply (Out of office), unified messaging and so on.
External Exchange mail client access scenarios

In the following section, we will review a couple of options of External Exchange
client access scenarios
The description of the workflow in each of the scenarios doesnt include all the
details that are involved in the communication process between the Exchange mail
client and the Public facing Exchange CAS server.
The main purpose is just to provide a high level view of the communication channel
that is implemented between the public Exchange clients and the Public facing
Exchange server.
How public Autodiscover client locates their Autodiscover Endpoint.

How does the Public facing Exchange server identify himself by providing a public
certificate?
How does the Autodiscover client get the required Autodiscover information (the
Autodiscover server response).
Note as part of the description of the Autodiscover flow, we will display a sample
of the Autodiscover response. A standard Autodiscover response includes many
lines of information. To simplify the process, I have been chosen to display only a
small sample of the content of the autodiscover.xml that include the URL address
for the following Exchange web services:
1. ECP URL address
The ECP (Exchange Control Panel) is used by the webmail client such as OWA for
managing and configuring many user settings using the OWA web interface.
2. EWS URL address the EWS (Exchange Web Services) URL is used by Exchange
for providing a variety of web services such as: Availability services (Free/Busy
time), Auto Replay (Out of office), Mail tips and more.
Scenario 1: Exchange mail services for external mail clients |

Simple scenario
In this scenario, John is trying to access his mailbox that is hosted on the New York
Exchange site from a public network. John would like to create a new Outlook mail
profile.
The information that John will need to provide is his E-mail address
(John@o365info.com ) + his user credentials.
In this scenario we will ignore the other company Exchange site (Los Angles) and
concentrate only on the Autodiscover workflow when an external mail client
accesses the New York Public facing Exchange CAS server.
Step 1: external mail client | Autodiscover process

Because John is located on a public network, the Autodiscover method, in which the
Autodiscover client connects the local Active Directory for getting information about
the available Exchange CAS server\s is not available for him because, the internal
Active Directory is not exposed to the public network.
In that case, the Autodiscover process of locating a potential Autodiscover
Endpoint is implemented by looking for an Autodiscover Endpoint hostname,
which is extracted from the recipient E-mail address.
In our example, John will look for an Autodiscover Endpoint by using the hostname
o365info.com (number 1).
In our scenario, this host name is not published and because the Autodiscover
client will not find such host name, the Autodiscover client will create a new DNS
query looking for the hostname autodiscover.o365info.com
Step 2: connecting the Public facing Exchange CAS server
In our scenario, the organization uses the New York Exchange CAS server as a
Public facing Exchange CAS server.
The external mail client initiates a connection attempt to the Public facing Exchange
server by using the HTTPS protocol.
The mail client will ask for the server to prove his identity by providing a public
certificate (number 2).
Step 3 Verify the Exchange server public certificate
The mail client will verify that the server certificate includes the FQDN
Note in case that the Public facing Exchange server uses a wildcard certificate; the
Autodiscover client will verify only the part of the domain name, in our case
o365info.com .
In case that the external mail client verifies that the Exchange certificate is OK, the
client will also provide his identity (username and password).
Step 4 Exchange client request from the Exchange server to provide the
autodiscover.xml file
The external mail client will ask from Exchange server to provide him the required
autodiscover.xml file (number 4).
Step 5 Exchange server provides to the Exchange client the autodiscover
response (autodiscover.xml)
The Exchange server sends the external mail client the required autodiscover
response (number 5).
In the following screenshot, we can see a small example from the content of the
autodiscover.xml file.
Exchange EWS services we can see that the URL address of the Exchange EWS
services is provided by using the hostname o365info.com
Exchange ECP the URL address of the Exchange control panel (the web address
that is used by the webmail client to configure user settings) includes the host
name o365info.com

Single Public facing Exchange CAS server | Multiple Exchange
sites
In the next scenario, Alice is trying to connect to her mailbox from a public network.
As mentioned, the organization has two Exchange sites. Alices mailbox is hosted on
the Exchange CAS server who resides in the Los Angeles site.
The Exchange CAS server in Los Angles site is a non-Public facing Exchange CAS
server.
In simple words, an external mail client cannot directly connect this Exchange
server.
To be able to provide mail services to the external mail client, the Exchange CAS
server who was selected as a representative that will have a public availability
(Public facing Exchange CAS server) is the Exchange CAS server from New York site.
Step 1: external mail client | Autodiscover process
When Alice starts, he Outlook client, the mail client will try to look for Autodiscover
Endpoint.
In that case, the Autodiscover process is implemented by looking for an
Autodiscover Endpoint hostname, which is extracted from the recipient E-mail
address.
In our example, Alice Outlook client will look for an Autodiscover Endpoint by using
the hostname o365info.com (number 1).
In our scenario, this host name is not published and because the Autodiscover
client will not find such host name, the Autodiscover client will create a new DNS
query looking for the hostname autodiscover.o365info.com
Step 2: connecting the Public facing Exchange CAS server
In our scenario, the organization uses the New York Exchange CAS server as a
Public facing Exchange server.
Note that Alices mailbox, is located on the Exchange CAS server at the Los Angles
site.
The external mail client initiates a connection attempt to the Public facing Exchange
server by using the HTTPS protocol.
The mail client will ask for the server to prove his identity by providing a public
certificate (number 2).
Step 3 Verify the Exchange server public certificate
The mail client will verify that the server certificate includes the FQDN
In case that the external mail client verifies that the Exchange certificate is OK, the
client will also provide his identity (user name and password).
Step 4 Requesting from the Exchange server to provide the autodiscover.xml
file
The external mail client will ask from Exchange server to provide him the required
autodiscover.xml file (number 4).
Step 5 Exchange provides the mail client the autodiscover.xml
The Exchange server sends the external mail client the required autodiscover.xml
file (number5).
In the following diagram, we can see an example form the content of the
autodiscover.xml file.
Exchange EWS services we can see that the URL address of the Exchange EWS
services is provided by using the host name o365info.com
Exchange ECP the URL address of the Exchange control panel (the web address
that is used by the web mail client to configure user settings) includes the host
name
o365info.com
Step 6 access to the mailbox data by the external mail client | Proxy
mechanism
Pay attention to the interesting fact that Alice, cannot connect directly her Los
Angles Exchange CAS server exo2.0365info.com
Instead, each time that Alice will need to access data in her mailbox, the request will
reach the New York Exchange server (the Exchange server with public availability);
the New York Exchange server will create an LDAP query looking for the Exchange
CAS server who host Alices mailbox.
When the New York Exchange CAS server finds that the Exchange CAS server that
hosts Alices mailbox is exo2.0365info.com he will create a connection request,
asking to fetch the information from Alices mailbox (number 6).
The method in which Exchange CAS server sends a record for data from another
Exchange CAS server (the Exchange CAS server who provides access to the required
user mailbox) described as Proxy.
Step 7 returning the required data
The Los Angles Exchange CAS server (exo2.0365info.com) returns the required
mailbox data to the New York Exchange CAS server (exo1.0365info.com).
The New York Exchange server, send or provide the required mailbox data to the
external mail client (number 7 and Number 8).
PREFIX
The following two scenarios relate to Exchange infrastructure that includes multiple
Exchange sites and additionally, multiple Public facing Exchange CAS servers.
In theory, there could be only one focal point that represents the domain
Autodiscover Endpoint.
Later (in scenario 4), we will see how to implement a different network
infrastructure that will enable us to override this theoretical limitation.

Multiple Public facing Exchange CAS servers | Multiple Exchange
sites
In the following scenario, each of the Exchange site is represented by a Public facing
Exchange server.
Before we begin with the details of the Autodiscover workflow, its important to
understand that the Autodiscover client knows how to look for a predefined host
name who represents the Autodiscover Endpoint.
In our example, the Autodiscover Endpoint name whom the external mail client will
look for is autodiscover.o365info.com
The challenge that we face now is how can we publish two different Public facing
Exchange CAS servers using the same host name?
Should we point the autodiscover.o365info.com DNS record to the New York site
Exchange CAS server to or, should we point the
autodiscover.o365info.com DNS record to the Los Angles site Exchange CAS server
on the ?
In our scenario, we will continue to point the autodiscover.o365info.com record to

the public IP address of the Public facing New York Exchange CAS server.
When an external mail client that their mailbox is hosted at the Los Angles site will
connect the Public is facing New York Exchange CAS server, the Public facing New
York Exchange CAS server will reply with a special redirection message that will
point the external mail client to their Public facing Los angles Exchange CAS
server.
To make the Autodiscover workflow more digestible I will omit some parts of the
process.
Step 1, 2, 3 and 4 the external mail client finds the public IP address of the host
autodiscover.o365info.com and tries to create an HTTPS session.
The external mail client will ask for the server certificate and verify the certificate is
valid.
Because the certificate test was completed successfully, the external mail client
assumes that he reaches the right Exchange CAS server.
The mail client will request from the server the autodiscover.xml file
Now, is the main difference between the former scenarios: instead of providing to
the mail client the required autodiscover.xml file, the New York Public facing
Exchange CAS server sends a redirection message.
The redirection message includes the host name who is used by the Los Angles
Public facing Exchange CAS server.
In our scenario, the host name is mail-la.o365info.com
Now, the journey of the external mail client starts all over again.
The external mail client will need to get the public IP address of the host
After the external mail client gets the required Public IP address, the mail client
checks if the host mail-la.o365info.com can communicate using the HTTPS
protocol.
In case that the Los Angles Public facing Exchange server is open to
communication using port 443, the external mail client will send a request for a
server certificate.
When the Los Angles Public facing Exchange CAS server will provide his certificate,
the mail client will check that the server certificate includes the host name
After the completion of the mutual authentication process, the external mail client
requests the autodiscover.xml file.
In the following diagram, we can see; we can see a small example form the content
of the autodiscover.xml file.
Note that the URL address includes the Public FQDN that belong to the Los Angles
Public facing Exchange CAS server
Scenario 4: Exchange mail services for external mail clients

|Multiple Public facing Exchange CAS servers | Multiple
Exchange sites | GeoDNS
In the following scenario, we will review a nice solution which is based on using
features that described as: GeoDNS.
The term GeoDNS describe a technology of smart DNS server.
Instead of a standard DNS session in which the DNS client query the DNS server for
a specific host name and the DNS server reply using the information that he has in
his database, the feature of GeoDNS enables the DNS server to recognize the
geographical location of his client and based on this information provide different
answers.
In the following scenario, we will use the option of GeoDNS for publishing the
information about the Autodiscover records.
The host name Autodiscover will point to two different Exchange server at the
same time.
When a user who is geographical location is in New York query the DNS server
regarding the host name autodiscover.o365info.com , the DNS server will
recognize his geographical location and provide him the public IP address of the
New York Public facing Exchange server.
The same goes for Exchange client that their geographical location is at Los Angles.
Each time that a Los Angeles mail client will query the DNS for the public IP of the
host- autodiscover.o365info.com , the DNS server will provide him the public IP
address of the Los Angles Public facing Exchange server.
John is a user whom his mailbox is hosted at the New York Exchange site, and Alice
is a user whom his mailbox is hosted at the Los Angles Exchange site.
Lets assume that both passed through all the phases of finding the Public facing
Exchange CAS server, authentication and so on.
When John asks his Autodiscover Endpoint for the autodiscover.xml that include
the required information about existing public Exchange services, the answer will
be sent by the New York Public facing Exchange CAS server and will include the
public host names (FQDNs) that are mapped to the public IP address of the New
York Public facing Exchange CAS server.
When Alice gets her autodiscover.xml, the content of the file will include different
information that points to the public hosts names of the Los Angles Public facing
Exchange CAS server.

Exchange Clients and Their Public Facing Exchange Server - Part 13 of 36

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exchange Clients and Their Public Facing Exchange Server - Part 13 of 36

Uploaded by

Copyright:

Available Formats

Page 1 of 26 | Exchange clients and their Public facing Exchange server | Part 13#36

Exchange clients and their Public

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

2. Autodiscover flow\process the Autodiscover flow in a public environment in

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

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

One interface for the internal\private Exchange infrastructure

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

Public facing Exchange CAS server | The two worlds

Active directory internal domain name is o365info.local

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

Exchange CAS server Internal and external FQDN

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

In a scenario of enterprise company, that have multiple sites in different

Scenario 1 and scenario 2, will demonstrate an Exchange infrastructure that

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

Los Angles Exchange CAS server

Public DNS and A records

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

New York + Los Angles Exchange CAS server public IP.

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

Exchange CAS server public certificate

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

Public facing Exchange CAS server | Naming scheme and

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

Note there is an additional Autodiscover method based on an SRV record that

Exchange web mail services public FQDN

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

External Exchange mail client access scenarios

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

How public Autodiscover client locates their Autodiscover Endpoint.

Scenario 1: Exchange mail services for external mail clients |

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

Step 1: external mail client | Autodiscover process

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

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

Scenario 2: Exchange mail services for external mail clients |

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

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

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

Scenario 3: Exchange mail services for external mail clients |

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

In our scenario, we will continue to point the autodiscover.o365info.com record to

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

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

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

Scenario 4: Exchange mail services for external mail clients

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

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

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

You might also like