Skip to content

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 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:

  • 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 the external client to the “internal” Exchange server.
The meaning of Public facing Exchange server
  • 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 determining the required Autodiscover Endpoint.

Q1: Does the Exchange server must configure as Public facing Exchange server?

A1: No, technicality we don’t 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 vs. the external interfaces and the characters of this different environment, let’s 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 organization’s user whom his mailbox is hosted on the New York Exchange Site.
  • Alice is an organization’s user whom his mailbox is hosted on the Los Angles Exchange Site.
Exchange infrastructure scenario description

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 FQDN’s.

The result depends on the particular 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 an enterprise company, which 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 doesn’t use all the information that appears in the “Exchange FQDN’s” table.

New York Exchange CAS server

The Exchange CAS server of New York site is 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
Exchange CAS server -Internal and external FQDN naming scheme

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 DNS infrastructure Exchange public host names

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 to the “New York Exchange CAS server.”

The mail client is not “interested” in this fact.

The reason for using a multiple hosts name (FQDN’s) 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

Public-facing Exchange CAS server - Single public IP is mapped to multiple Hosts names

Exchange CAS server public certificate

The certificate that 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 (FQDN’s) of the “New York and Los Angles Exchange CAS servers.
The external mail client doesn’t relate to this “Internal FQDN’s” and doesn’t need to verify this “Internal FQDN’s.”

This internal name will be used only by an internal mail client that connects the Exchange CAS server from “inside” of the organization’s private network.

Public certificate - Exchange public host names

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 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 hostname who considers as a reserved name).

The public names which 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 hostname – 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 webmail services public FQDN

External webmail clients, will address the Public facing Exchange server by using the hostname – 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 particular 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 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 hostname 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 implement by using a GeoDNS.

Los Angles Exchange webmail 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.

Public facing Exchange CAS server- Naming scheme and Exchange services

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 doesn’t include all the details that are involved in the communication process between the Exchange mail client and the Public facing Exchange CAS server.

The primary purpose is just to provide a high-level view of the communication channel that 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 – 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.

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

Scenario 1 - Public facing Exchange CAS server - Simple scenario-01

Step 1: external mail client | Autodiscover process

Because John 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 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 – autodiscover.o365info.com

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 request 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 of 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
Scenario 1 - Public facing Exchange CAS server - Simple scenario-02

Scenario 2: Exchange mail services for external mail clients | 
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. Alice’s mailbox hosted on the Exchange CAS server which 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 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 Outlook, Outlook client will try to look for Autodiscover Endpoint.

In that case, the Autodiscover process is implemented by looking for an Autodiscover Endpoint hostname, which 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 Alice’s 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 –autodiscover.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 – 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 (number 5).

In the following diagram, we can see an 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 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
Scenario 3 -Multiple Public facing Exchange servers - Multiple Exchange sites-02

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 Alice’s mailbox.

When the New York Exchange CAS server finds that the Exchange CAS server that hosts Alice’s mailbox is – exo2.0365info.com he will create a connection request, asking to “fetch” the information from Alice’s mailbox (number 6).

The method in which Exchange CAS server sends a record for data from another Exchange CAS server (the Exchange CAS server which 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).

Scenario 2 - Single Public facing Exchange server - Multiple Exchange sites

Prefix

The following two scenarios relate to Exchange infrastructure that includes multiple Exchange sites and additionally, various 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.

Scenario 3: Exchange mail services for external mail clients |
 Multiple Public facing Exchange CAS servers | Multiple Exchange sites

In the following scenario, each of the Exchange sites is represented by a Public facing Exchange server.

Before we begin with the details of the Autodiscover workflow, it’s 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 siteExchange CAS server to or, should we point the
autodiscover.o365info.com DNS record to the Los Angles siteExchange CAS server on the ?

Pointing the Autodiscover to what site

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 particular redirection message that will point the external mail client to their “Public-facing Los angles Exchange CAS server”.

Scenario 3 -Multiple Public facing Exchange servers - Multiple Exchange sites-01

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 completed successfully, the outer 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 above 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 hostname who 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 –
mail-la.o365info.com

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 provides his certificate, the mail client will check that the server certificate includes the hostname –
mail-la.o365info.com

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 from 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 3 -Multiple Public facing Exchange servers - Multiple Exchange sites-02

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 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 hostname – 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 hostname – 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”.

Scenario 4 - Multiple Public facing Exchange servers - Multiple Exchange sites - Using GeoDNS -01

John is a user whom his mailbox hosted at the New York Exchange site, and Alice is a user whom his mailbox hosted at the Los Angles Exchange site.

Let’s 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 file 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 contain the public host names (FQDN’s) 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 host’s names of the Los Angles Public facing Exchange CAS server.

Scenario 4 - Multiple Public facing Exchange servers - Multiple Exchange sites - Using GeoDNS -02
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *