Exchange Public infrastructure | Public vs. non-Public facing Exchange site | 5#23

The current article dedicated to the subject of Exchange public infrastructure.
When we relate to the topic of Exchange 2013 coexistence environment and client protocol connectivity flow, one of the most fundamental factors that determine and influence, the “client protocol connectivity flow” is the physical location of the Exchange clients.

In simple words – whether the Exchange client that addresses the Exchange CAS server considers as Exchange client that located on the public network or Exchange client that we find in the internal\private organization’s network.

For this reason, it is very necessary that we will be able to understand better some basic concepts and the characters of the Exchange public infrastructure.

Exchange public infrastructure | Basic terms

Let’s start with the most basic terms: Public facing Exchange CAS server and Public facing Exchange site.

The term: “Public-facing Exchange site”, relates to Exchange infrastructure that is “Exposed” or “available” for Exchange client that locates at a public network.

Technically speaking, there is no such thing as: “Public-facing Exchange site” because, in reality, we don’t publish the Exchange site, but instead, a “representative” of the site which described as Public facing Exchange CAS server.

The responsibilities of the Public facing Exchange CAS server

1. Serve and Protect

The “job” of the Public facing Exchange CAS server is to hide and protect the “internal Exchange infrastructure” that is not exposed to the public network.

2. Proxy or redirect

The Public facing Exchange CAS server which accepts the external Exchange client requests makes the necessary decision, based upon the information that he “pulls” from the Active Directory regarding the Exchange user.

The “decision” of the Public facing Exchange CAS server, depend on a couple of a factor such as – the location of the Exchange mailbox server which hosts the user mailbox, if the “destination Exchange site” consider as private (intranet) or “public” (Public facing Exchange site), the type of the Exchange client and so on.

Based on the weighting of the different factors, the Public facing Exchange CAS server will decide whether to proxy the external Exchange client requests by himself to the destination Exchange server or direct the external Exchange client to address other Public facing Exchange CAS server or other Public facing Exchange site.

3. Handle connection requests of different Exchange clients

The Public facing Exchange CAS server has to be smart enough and “speak” a number of languages simultaneously.

Each of the different Exchange client “speaks” different language and the Public facing an Exchange CAS server need to recognize the specific Exchange client type such as Outlook, ActiveSync or OWA and use the required “languages” for communicating with the particular Exchange client.

Does the need for publishing the Exchange infrastructure is mandatory?

Technically speaking, there is no mandatory need for “exposing” Exchange infrastructure or services to the Public environment, but, 99% of the time, the organization business’s requirement dictates the need for exposing at least some part of the Exchange environment to Exchange client that is located on the public network.

Private vs. public Exchange infrastructure | Synonyms and antonyms

The “confusing part” of Exchange private vs. public environment is that there are many synonyms that are used, for describing the different Exchange infrastructures.

For example, the next terms are used for describing an Exchange environment that is available or “exposed” for external Exchange clients:

• Public facing Exchange CAS server
• Public facing Exchange site
• Internet facing site
• The internet Facing AD Site
• External client connectivity flow

We use the following term list, for describing an Exchange site that is not exposed to the public network (can be connected by the external client) and is available only to Exchange client that is connected to the private organization’s network:

• Intranet site
• Internal site
• Internet Facing AD Site
• Non-Internet Facing AD Site
• Non Internet facing site
• Internal client connectivity flow
• External client connectivity flow

The concept of the “Representative”

The implementation of public Exchange mail infrastructure is based upon a concept on which I describe as: “Exchange CAS server as a representative”

When we need to “expose” our mail infrastructure to the public\external network, the underlying assumption is that we want to minimize the “exposure” to possible public network threats.

To enable the mechanism in which we enable external Exchange clients to access “internal Exchange mail services”, and at the same time, “protecting” the internal Exchange mail infrastructure from possible public network threats, we “decided” a very particular Exchange CAS server that will serve as a: Public facing Exchange CAS server.

External Exchange client’s request for mail service, will be “pointed” to the dedicated Public facing Exchange CAS server.
The Public facing Exchange CAS server will perform a process of identifying the external Exchange clients and after he can verify the identity of the External Exchange client, serve the External Exchange client by Proxy his request to internal Exchange server or in some scenario, redirect the External Exchange client to “other Exchange servers.”
or – “other Public facing Exchange site”.

Exchange public mail infrastructure | A variety of scenarios

The term: “Exchange public mail infrastructure” can be translated into many possible scenarios.

In the following section, we will review a couple of possible scenarios for the implementation of – Exchange public mail infrastructure.

Scenario 1: Public Exchange Infrastructure | The centralized model

The Exchange infrastructure which I describe as: “centralized model” based on the following characteristics:

An organization, which has multiple sites in a different geographic location.

Only one company site: the New York site configured as – Public facing Exchange site.

The “New York Public facing Exchange CAS” will be set as public Autodiscover Endpoint and will be published using the host name: autodiscover.o365info.com

Additionally, the “New York Public facing Exchange CAS” will be published using the public host name: mail.o365info.com
This public name used by the external Exchange client that addresses the “New York Public facing Exchange CAS” as a “mail server” that will enable them access to their mailbox content.

In a scenario of: ”public Exchange clients” all the company employees, from all over the company site such as Los Angles, Madrid, and New York will address the Public facing Exchange site, which represented by the “New York Public facing Exchange CAS.”

The public Autodiscover recorded: autodiscover.o365info.com is pointing to the “New York Public facing Exchange CAS”.

In the following diagram, we can see the infrastructure if the centralized model. Only one particular site considered as: “Public-facing Exchange site.” All the external Exchange client will be “pointed” to the Public facing Exchange site or if we want to be more accurate: to the Public facing Exchange CAS server and the Public facing Exchange CAS server will “handle” the external Exchange client requests by proxy their requests to the required internal Exchange resource.

In case that organization users who located in the public network, need access to the Exchange infrastructure, the “gateway” or the “door” to the Exchange infrastructure is the: company headquarter site, which has a Public facing Exchange CAS server.
The Public facing Exchange CAS server serves as a “focal point” for Exchange client that their mailbox hosted on the New York site and all the rest of the company site (Madrid + Los Angles sites).

The “other “company sites (Madrid + Los Angles sites) don’t have a “Public availability” or on other, words cannot be accessed directly by external Exchange clients.

Exchange users from Madrid + Los Angles sites (the site that not exposed to the public network) will connect the Public facing Exchange CAS server in New York site.

When the “New York Public facing Exchange CAS” accepts a connection request from external Exchange clients, he will decide “what to do” or, “how to proxy” the client request to the appropriate server based upon the location of the particular Exchange client (the Exchange Mailbox server who hosts the Exchange user mailbox).

Scenario 2: public Exchange infrastructure | The distributed model

The second model can describe as: “distributed model” or sometimes described as the “regional model.”

The “distributed model” is based on a concept in which each of the physical company sites (or specific company sites) represented by a dedicated Public facing Exchange site.

The idea behind this model is to optimize the performance and the response time that offered by the Public facing Exchange CAS servers.

Exchange client that belongs to site A will access a Public facing Exchange CAS server who representative site A and so on.

In this scenario, the organization decides to “expose” more than one Exchange site.
For example – the Exchange public infrastructure will include the company headquarters site in the USA and additionally the company site in Europe.

Pay attention that the company has an additional site in a different geographic which not exposed to the public network: the Los Angles site that described as the non-internet facing site.

To be able to differentiate between the two public available Exchange sites, each site will use a different namespace.

For example – the Public facing Exchange CAS server in the headquarters published by using the FQDN: mail.o365info.com and the Public facing Exchange CAS server at the Europe site will be published by using the FQDN: europe.mail.o365info.com

External Europe Exchange users, will use the “Europe namespace” for connecting Exchange infrastructure.

All the rest of the external Exchange users will connect to the Public facing Exchange CAS server in the headquarters.

Exchange server Public availability vs. internal Exchange server

Exchange external and internal FQDN’s and URL address

Another point that I would like to clarify is the Exchange external and internal URL address.

In a previous section, we learn about the scenario in which the Exchange organization based on more than one Internet-facing site, and that in some scenarios, Exchange CAS server can decide to redirect Exchange clients’ request to “other Exchange CAS servers” on other Exchange sites. Other option is to provide Exchange clients Autodiscover information that includes “links” (URL address and FQDN’s) of “other Public facing Exchange CAS server.”

The question that can appear now is: how does the Exchange CAS server know about “other Public facing Exchange CAS servers”?

The answer is quite simple: Exchange CAS server who has a “value” in the “external URL address” field, considered as a “Public-facing Exchange CAS server.”

When we fill in the information (URL address) in the section of “external URL”, this information published in Active Directory and this information is available for all the Exchange servers.

Each time we use a term such as: “Public-facing Exchange CAS server” the meaning is a “presence” of Exchange CAS servers whose virtual directories have the ExternalURL property populated.

We can say the same thing in a “negation”: Non-Internet facing Exchange site, simply means, any Active Directory site containing Exchange CAS server\s whose virtual directories do not have ExternalURL property populated.

Exchange external and internal FQDN’s and URL address

Another building block of the Exchange public infrastructure is the terms: URL address and FQDN

Exchange client access or address Exchange server by using a URL address that includes a particular hostname (FQDN) or by addressing the specific hostname directly.

For example. In the following diagram, we can see an example of a URL address of Exchange web service.

The Exchange host who provides the Exchange web service is: mail.o365info.com
When an Exchange client uses this URL, he knows that the Exchange server that he should address is: mail.o365info.com

In other scenarios, Exchange client will use a particular FQDN (Hostname) that representative an Exchange server,

For example, an external Exchange client that “belong” to organize named: o365info.com, will start the communication process by looking for Autodiscover Endpoint named: autodiscover.o365info.com

Another example could be the name of the RPC endpoint name which is used by Outlook client. In our scenario, the Public facing Exchange CAS server who serves as: RPC Endpoint for an external Outlook client named: mail.o365info.com

The Autodiscover information that will be provided to external Exchange, Outlook client will include a reference to the host name:

External vs. internal FQDN

Another important observation that relates to the public Exchange client infrastructure is the subject of External vs. internal FQDN name.

Each of the Exchange servers must represent by a Hostname (FQDN).

• Internal FQDN name – the Exchange client host name could be described as private, in this case, that the only internal Exchange client that located on the private company network will be able to address and access the particular Exchange server using the specific hostname.
• Public FQDN name – the Exchange client host name could be described as – public in case that external Exchange client can address and access a particular Exchange server. To be able to be available for external Exchange clients, the Exchange server configured as – Public facing Exchange CAS server and the Exchange server host name, must be published in the external\public DNS server.

Multiple Public facing Exchange site

In a scenario of Multiple Public facing Exchange site, each of the Public facing Exchange site will need to have a representative: Public facing Exchange CAS server who will accept the communication requests from the external Exchange clients.

For example, a company that had two Public facing Exchange sites, one site in New York and an additional site in Madrid.

• The Public facing Exchange CAS server who representative the New York will be published by the Host name (FQDN): mail.o365info.com
• The Public facing Exchange CAS server who representative the Madrid will be published by the Host name (FQDN): europe.mail.o365info.com