Exchange Public infrastructure | Public versus non-Public facing Exchange site | 5#23

Page 1 of 20 | Part 05#23 | Exchange Public infrastructure | Public versus non Public

facing Exchange site

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

EXCHANGE PUBLIC INFRASTRUCTURE |

PUBLIC VERSUS NON PUBLIC FACING

EXCHANGE SITE | 5#23

The current article is dedicated to the subject of: Exchange public infrastructure.

When we relate to the subject 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 is located on the public network or

Exchange client that we locate in the internal\private organization’s network.

http://o365info.com/exchange-public-infrastructure-public-versus-non-public-facing-exchange-site


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

http://o365info.com/




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Exchange-CAS-server-as-a-representative-of-Public-facing-Exchange-site.jpg




2. Proxy or redirect

The Public facing Exchange CAS server who accepts the external Exchange client

requests makes the required decision, based upon the information that he “pull”

from the Active Directory regarding the Exchange user.

The “decision” that the Public facing Exchange CAS server gets, depend on a couple

of a factor such as: the location of the Exchange mailbox server who hosts the user

mailbox, is 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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-facing-Exchange-CAS-server-protect-the-internal-Exchange-infrastructure.jpg




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 “speak” 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 specific Exchange client.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-facing-Exchange-CAS-server-%E2%80%93-Smart-router.jpg








http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-Exchange-mail-infrastructure-Basic-terms.png




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 versus public Exchange infrastructure

| Synonyms and antonyms

The “confusing part” of Exchange private versus public environment is that there

are many synonyms that are used, for describing the different Exchange

infrastructures.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/publishing-the-Exchange-infrastructure-is-mandatory.jpg




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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Private-versus-public-Exchange-infrastructure-synonyms-and-antonyms.jpg




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 basic assumption is that we want to minimize the “exposure” to passable public

network threats.

To be able 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 passable public network threats, we “decided” a

very specific 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 identify the external Exchange clients and after he

can verify the identity of the External Exchange client, serve the External Exchange





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Protecting-the-internal-Exchange-infrastructure.jpg




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

passable scenarios.

In the following section we will review a couple of passable scenarios for the

implementation of: Exchange public mail infrastructure.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-facing-Exchange-sites-Exchange-CAS-server-as-a-Representative.png




Scenario 1: Public Exchange infrastructure | The centralized model

The Exchange infrastructure which I describe as: “centralized model” is based on

the following characteristics:

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

Only one company site: the New York site will be configured as: Public facing

Exchange site.

The “New York Public facing Exchange CAS” will be configured 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 will be 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 is 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 specific site will be 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 requites by

proxy their requests to the required internal Exchange resource.








In case that organization users who is 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 is 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 sits) 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 is not exposed to the

public network) will connect the Public facing Exchange CAS server in New York site.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-Exchange-infrastructure-The-Centralized-model.png




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 specific

Exchange client (the Exchange Mailbox server who hosts the Exchange user

mailbox).

Scenario 2: public Exchange infrastructure | The distributed model

The second model can be described as: “distributed model” or sometimes

described as the “regional model”





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-Exchange-infrastructure-Scenario-1-of-2-The-centralized-model.png




The “distributed model” is based upon a concept in which each of the company

physical sites (or specific company sites) will be represented by a dedicated Public

facing Exchange site.

The idea behind this model is to optimize the performance and the response time

that is 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 headquarters

company site in the USA and additionally the company site at Europe. Pay attention

that the company has an additional site in a different geographic which is not

exposed to the public network: the Los Angles site that will be described as: non-

internet facing site.

To be able to differentiate between the two public available Exchange sites, each

site will use a different namespace.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-Exchange-infrastructure-The-Distributed-model.png




For example: the Public facing Exchange CAS server in the headquarters will be

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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Public-Exchange-infrastructure-Scenario-2-of-2-The-Distributed-model.png




Exchange server Public availability versus

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 former section, we learn about the scenario in which the Exchange

organization is 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 or, provide Exchange clients

Autodiscover information that include “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” filed, considered as a “Public facing Exchange CAS server”.

When we fill-in the information (URL address) in the section of “external URL”, this

information is 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 specific host name (FQDN) or by addressing directly the specific host

name.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/How-to-recognize-Public-versus-non-Public-facing-Exchange-CAS-server-Exchange-CAS-server.png

http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Exchange-external-and-internal-FQDN%E2%80%99s-and-URL-address.jpg




In case that Exchange client have, a specific URL address of a specific Exchange

service, the Exchange client knows how to “extract” or “pull out” the part of the

FQDN from the URL address

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 specific FQDN (Host name) 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 who 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 versus internal FQDN





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Exchange-web-service-URL-address.png

http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Autodiscover-URL-address.png

http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/RPC-endpoint-name.png




Another important observation that relates to the public Exchange client

infrastructure is the subject of: External versus internal FQDN name.

Each of the Exchange server must be represented 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 is located on the

private company network will be able to address and access the specific

Exchange server using the specific host name.

Public FQDN name – the Exchange client host name could be described as: public

in case that external Exchange client can address and access a specific Exchange

server. To be able to be available for external Exchange clients, the Exchange

server will be 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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/External-versus-internal-Exchange-FQDN.jpg




For example, a company that had two Public facing Exchange sites, one site in New

York and 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

The Exchange 2013 coexistence article series index page





http://o365info.com/the-exchange-2013-coexistence-article-series-index-page

http://o365info.com/wp-content/gallery/exchange-2013-coexistence-05/Multiple-Public-facing-Exchange-site-and-the-namespace.png

http://o365info.com/exchange-2013-coexistence-environment-and-client-protocol-connectivity-flow-the-prefix

Exchange Public infrastructure | Public versus non-Public facing Exchange site | 5#23

Documents