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.
Article Table of content | Click to Expand
Article Table of content – Exchange Public infrastructure | Public versus non-Public facing Exchange site
- Exchange public infrastructure | Basic terms
- The responsibilities of the Public facing Exchange CAS server
- Does the need for publishing the Exchange infrastructure is mandatory?
- Private versus public Exchange infrastructure | Synonyms and antonyms
- The concept of the “Representative”
- Exchange public mail infrastructure | A variety of scenarios
- Exchange server Public availability versus internal Exchange server
Article Series Table of content | Click to Expand
Exchange and Autodiscover infrastructure | Article Series
Exchange Autodiscover – Article series – INDEX
Exchange and Autodiscover infrastructure | The building blocks
- Exchange Autodiscover infrastructure – Introduction | Part 01#36
- The old Exchange environment versus “modern” Exchange environment | Part 02#36
- Who are the Exchange Autodiscover clients? | Part 03#36
- The Autodiscover information | Part 04#36
- The Autodiscover algorithm for locating the “source of information” | Part 05#36
- Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36
- Exchange CAS server as information + Web service provider | Part 07#36
- The dual identity of the Exchange server | Part 08#36
Autodiscover infrastructure | FQDN and URL address
- The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36
- Exchange Web services | Manage the Internal and external URL address | Part 10#36
Exchange Autodiscover flow in different environments
- The content of the Autodiscover server response | Part 11#36
- Outlook client protocol connectivity flow in an internal network environment | Part 12#36
- Exchange clients and their Public facing Exchange server | Part 13#36
- Outlook Autodiscover decision process | Choosing the right Autodiscover method | Part 14#36
- Autodiscover flow in Active Directory based environment | Part 15#36
- Autodiscover scenarios in enterprise environment | Part 16#36
Autodiscover infrastructure | Exchange infrastructure and namespace convention
- Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36
- Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
- Public SAN certificate | Deprecated support in the internal server name | Part 19#36
Exchange, Autodiscover and security infrastructure
Autodiscover Troubleshooting tools
- Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools | Part 1#4 | Part 21#36
- Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36
- Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools | Part 3#4 | Part 23#36
- Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part 24#36
Autodiscover major flow scenarios
Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 2#3 | Part 27#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
Autodiscover flow in an Office 365 based environment
- Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Autodiscover flow in an Exchange Hybrid environment
- Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36
- Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36
- Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
Exchange Stage migration and Autodiscover 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 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.
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 passable 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 passable 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 passable scenarios.
In the following section, we will review a couple of passable 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 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 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 versus internal FQDN
Another important observation that relates to the public Exchange client infrastructure is the subject of External versus 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
Exchange 2013 coexistence | Article series index
It is important for us to know your opinion on this article