Skip to content

Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36

The current article is dedicated to the Interesting and not so clear subject of – Exchange Infrastructure namespace.

Exchange server architecture, enable us to use a different interface with internal Exchange clients vs. external Exchange clients that based on various namespace.

The major questions that I will try to answer in this article are:

  • Is it good or bad to use a different namespace?
  • What are the characters of Exchange environment that is based on two different namespaces?

When reading the article title, the result is many questions that can pop out:

  1. What is the meaning of “public naming scheme” or “single name space” for Exchange Infrastructure?
  2. Why do I need to use a single public naming scheme?
  3. How does my current Exchange infrastructure is configured?

I think that is important to spend the time because very soon, every Exchange administrator will need to deal with the subject of – using ONE public naming scheme for Exchange Infrastructure.

Relating the previous questions

Q1 – What is the meaning of the public naming scheme for Exchange Infrastructure?

Q2 – Why do I need to use ONE public naming scheme?
We cannot answer this question by proving a short answer but, despite that obstacle I will try to respond to this question shortly and, to get a more detailed and comprehensive answer; you will need to read the rest of the article.

Exchange infrastructure objects are “addressed” by using host names and URL address.
The communication between Exchange client and the communication between Exchange servers themselves implemented by addressing a particular Exchange server by using his hostname.

The Exchange CAS server publishes Exchange web services to his clients, by providing them a URL address that includes the host name.

Exchange architecture | Previous vs. modern namespace conventions

Exchange server architecture Includes built-in ability to implement a different interface with internal vs. external Exchange clients.

The Realization of the different interfaces based on three main elements

  1. Communication protocol
  2. Authentication protocol
  3. Namespace

Previous Exchange server architecture vs. modern Exchange architecture | Interface with internal Exchange clients vs. external Exchange clients.

In previous Exchange server versions such as Exchange 2003, 2007 and 2010, the typical convention was – to configure Exchange server for using a different interface with internal Exchange clients vs. external Exchange clients.

The primary thought behind this configuration was that the internal network has different needs and different characters vs. external network and for this reason, there is a need for configuring Exchange to use different configuration setting when interacting with internal Exchange clients vs. external Exchange clients.

In a modern Exchange environment such as Exchange 2013, the differentiation between the two environments (internal vs. public network) diminishes and disappears.

In other words, despite the fact that an Exchange 2013 architecture includes the ability to implement a different interface with internal Exchange clients vs. external Exchange clients, most of the time, the standard practice is to use an identical interface with internal Exchange clients vs. external Exchange clients.

For example:

In previous Exchange server versions (Exchange 2003, 2007, 2010) a common configuration was to use different communication protocol and different namespace with internal Exchange clients vs. external Exchange clients.

  • The interface with the internal Outlook client, was implemented using RPC protocol and internal namespace based on an internal domain name such as “local” domain suffix.
  • The interface with external Outlook clients, was implemented using RPC/HTTPS protocol (Outlook Anywhere) and public namespace based on a public domain name such as “com” domain suffix.

Note: The definition of Exchange server 2010 as part of the “previous Exchange server version” is not a “scientific definition”. Many times, organizations implemented the Exchange 2010 infrastructure based upon the characters of modern mail environments.

The standard convention, which dictates the need to differentiate and separate Exchange interface with internal Exchange clients vs. external Exchange clients changed over time into a new convention that based on a “simplify the concept”” in which the Exchange interface with internal Exchange clients vs. external Exchange clients configured as an identical interface.

For example, in an Exchange 2013 environment, the only available communication protocol with Outlook client is – Outlook Anywhere (RPC\HTTPS or MAPI\HTTPS).

In other words, we cannot set a different communication protocol for internal Outlook client vs. external Outlook client.

Regarding the subject of “namespace”, theoretically, Exchange 2013 enables us to use the option on “internal namespace” for internal Outlook client vs. external namespace for an external Outlook client but most of the time we will not implement this option.

Another element that relates to the “new trend” in which we “cancel” the different Exchange interface with internal Exchange clients vs. external Exchange clients is because, in the current time, the public certificate cannot and will not support hostname which includes non-public or public domain name suffix.

In other words – even in the case that we decide to continue to use Exchange internal and external namespace when we need to renew our public certificate, we cannot ask to include the internal hostname as part of the certificate.

Note – you can read more information about the new public certificate standard in the article – Public SAN certificate | Deprecated support in the internal server name | Part 19#36

Existing Exchange infrastructure based on internal and external namespace

In the previous section, we have mentioned that modern Exchange environment is moving toward consolidation or unification of the Exchange interface with internal Exchange clients vs. external Exchange clients.

However, in reality, there are many organizations that still use the recent convention in which we implement two different Exchange interfaces with internal Exchange clients vs. external Exchange clients.

In the next sections, we will review some examples of this type of infrastructure in which we use two different Exchange interface, the characters of this environment and the flow that implemented between Exchange server and his client.

While reading the information, you could feel that my opinion is that organization that uses “separation” of Exchange interface should work toward unification if this Exchange interface into one global interface.

The next article – Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36, Will deal with the “how to” part in a scenario in which we decide to use a single namespace with internal Exchange clients vs. external Exchange clients.

Exchange infrastructure – Host’s names and FQDNs

Most of the time when we use the term “Hostname”, we are mean another term – FQDN.

The FQDN is the “full” or “complete” name of a host who includes two parts:

1. The hostname
Regarding the subject of Hostnames, whenever we install a new server, we will need to provide the server a unique name whom we can consider as the server host name.

If we want to be more accurate, in a Microsoft-based environment, the Exchange server Host name is a NetBIOS name.

Note: Many times, we will “attached” to the Exchange server additional host names by using the DNS infrastructure but, we will discuss this issue later.

2. The Domain name
By default, Exchange infrastructure inherits his domain name from the Active Directory domain name.

In case that the Active Directory was configured using a private domain name, the Exchange infrastructure will also use the private domain name suffix.

In a scenario in which we use a “dual namespace” meaning private namespace and public namespace, Internal Exchange clients, will address Exchange resources by using the internal FQDN of the Exchange servers and Exchange URL address that include the internal or the private domain name.

External Exchange clients, cannot address, or access Exchange resources using the “private naming scheme” and for this reason, we will need to build additional namespace infrastructure, which used by the “public” or the external Exchange mail clients.

The possible namespace scenario matrix

To arrange things in a clear format, let’s review the possible “combination” of namespaces.

The characters of this scenario that we will review are as follows:

Internal and external namespace possible combinations-01

Scenario 1 – Active Directory private namespace | Exchange dual namespace

In this scenario, the Active Directory is based on a private namespace such as o365info.local

The Exchange namespace infrastructure based on a dual namespace infrastructure.

  • Internal Exchange clients, will address Exchange resources using the internal\private namespace – o365info.local
  • External Exchange clients, will address Exchange resources using the internal\private namespace – o365info.com

Scenario 2 – Active Directory private namespace | Exchange single namespace

In this scenario, the Active Directory is based on a private namespace such as – o365info.local

The Exchange namespace infrastructure based on a single namespace infrastructure meaning – the private, and the public namespace will be identical.

In this scenario, we will need to change the default Exchange servers FQDN that by default, use the Active Directory private domain name (o365info.com)

  • Internal Exchange clients, will address Exchange resources using the internal\private namespace – o365info.com
  • External Exchange clients, will address Exchange resources using the internal\private namespace – o365info.com

Scenario 3 – Active Directory public namespace | Exchange single namespace

In this scenario, the Active Directory is based on a public namespace such as o365info.com

The Exchange namespace infrastructure based on a single namespace infrastructure, meaning – the private and the public namespace will be identical.

In this scenario, we will not need to change the default Exchange servers FQDN that by default, use the Active Directory public domain name (o365info.com)

  • Internal Exchange clients, will address Exchange resources using the internal\private namespace – o365info.com
  • External Exchange clients, will address Exchange resources using the internal\private namespace – o365info.com
Internal and external namespace possible combinations-02

Q: Why should I avoid from using the option of – “Exchange dual namespace”?

A: The short version of the answer to that question is – because of two main two reasons:

1. No internal server names on SAN certificates after 2015

In case that we use the Exchange dual-naming scheme infrastructure, the Exchange public certificate will need to include the host name of the internal host (host that use the Active Directory private domain name) and the Public host name.

This type of configuration will be no longer supported since 1 November 2015

Note – If you need to read more information about this subject, read the article – Public SAN certificate | Deprecated support in the internal server name | Part 19#36

2. Because it’s the “right way”

The “short version” of the answer is that using the option of Exchange dual-naming scheme infrastructure instead of using ONE public naming scheme for Exchange Infrastructure is not the “right way”.

The reason for using dual namespace is because historical reasons that are not valid or relevant anymore to the modern environment.

Using the option of Exchange dual-naming scheme infrastructure makes thing complicated, makes it difficult for Exchange client that needs to memorize two different naming convention, makes it difficult to troubleshoot “Exchange issues” and much more.

Microsoft Active Directory and Private domain name

On-Premise Active Directory” is represented by a domain name.

The domain name that we use as an Active Directory domain name can consider as “Private domain name” or a “public domain name.”

Technically speaking, the Active Directory “doesn’t care” if we use a private domain name or a public domain name.

As mentioned, the default Exchange domain namespace infrastructure is built upon the Active Directory domain name infrastructure.

Many organizations use a private domain name for the Active Directory if the results are that the Exchange infrastructure will have to use two domain names infrastructure.

Q1: What is the meaning of a private domain name?

A2: The “technically implementation” of a private domain name is, by using a domain name that uses the “local” as a suffix.

The “local” domain suffix is a preserved suffix, and there is no option of purchasing a domain name with the “local” suffix.

The term “public domain name” is used in the case that we have purchased the domain name from a public provider such as GoDaddy etc.

Q2: Why does the Active Directory use a private domain name?

A2: In the good old days, the general concept was that using a private domain name for the Active Directory, is the preferred method because this is a good security practice.

My opinion always was that this is just a mambo jumbo of a security personnel because I have never managed to understand the reason for this assumption and no one never could provide me a real explanation for this assumption.

This “theory” of using a private domain name for the Active Directory domain name based on a faulty assumption. The thought was that the use of “private domain name” is required or mandatory for protecting the private origination network from the risks and hazards that exist in the “public network” that will harm the private organization resources.

I use the term -”mambo jumbo” for describing the theory of “using a private domain name” for protecting internal network resources because it’s simply not true.

Internal resources use a private IP scheme (Address Allocation for Private Internets). For this reason, there is no option for internal resources to directly communicate with “external resource” that use a public IP address.

The only possible way is via “a broker” such as Firewall that protects the internal network and based on a Firewall ”rule that “expose” specific network hosts (servers) based on what the administrator want\need to expose to the public network.

If we want to look for additional psychologist’s explanation for the “private Active Directory domain conspiracy theory” is, that in the old days, the underlying assumption was that the organization’s network is an isolated place that should never need to expose to “external network” or external user who reside on the public network.

This assumption looks a little radical in nowadays because, now the common is the opposite – most if the organization users are using a public network and must have access to “internal network resources” such as the Exchange CAS server on an hourly basis.

The syndrome of mister jackal and mister Hyde

So what is my point?

My point is that because many or even most of the organizations obeys to this “Private domain miss assumption” the results are quite a mess.

An organization that uses the Active Directory private domain naming scheme will have to manage two separated naming infrastructure.

The “private naming scheme” will be utilized only by the internal network client and the public naming scheme will be utilized only by the public client.

I can even compare this scenario, to a person that suffer from the illness of Split Personality!

The trend in which we use a private domain name parallel to using an “external\public” domain name is coming to its end because the new standard or public certificate doesn’t support anymore the use of host names that have a private domain name such as the local domain name suffix.

The publicly available on Exchange infrastructure vs. the private Active Directory infrastructure.

As mentioned, vs. the Active Directory the serve only internal clients and doesn’t “expose herself” to the public client, the character if the Exchange infrastructure are the opposite.

  • Exchange infrastructure will have to “expose” himself to external Exchange clients located on a public network
  • The public network infrastructure must use public host names

In the following diagram, we can see an example of the “two worlds” in which Public facing Exchange CAS server needs to operate.

The Public facing Exchange CAS server - Two different interfaces

Q: In case that the Active Directory uses a private domain name, how does Exchange serve external clients?

A: There are two possible “solutions”:

Option 1: Maintain two different domain name scheme

In this scenario, the Active Directory private domain namespace will also be used by the Exchange infrastructure for – communicating with internal Exchange clients.

Exchange infrastructure will use the public domain name scheme for communication with an external mail client.

In this scenario, the Exchange infrastructure is “linked” to two different domain names at the same time.

Scenario 1 - Using TWO different domain naming scheme for the Exchange infrastructure-01

For example – in a scene in which we use an Exchange CAS server who will also provide service for external mail clients (Public facing Exchange CAS server), an internal Exchange client will address the Exchange CAS server by using the host named- ex01.o365info.local

The external Exchange client will address the Public facing Exchange CAS server by using the host named – mail.o365info.com

Scenario 1 - Using TWO different domain naming scheme for the Exchange infrastructure-02

Option 2: Exchange infrastructure using a “unified domain name scheme”

In this scenario, Exchange infrastructure will use only a public domain name scheme that employed by both internal + external mail clients.

The Exchange infrastructure will be “attached” or “linked” only to the public domain name and not, to the Active Directory private domain name.

Scenario 2- Using a single domain name space for the Exchange infrastructure -01

For example, in a scenario in which we use an Exchange CAS server who will also provide service for external mail clients (Public facing Exchange CAS server), an internal Exchange client will address the Exchange CAS server by using the hostname – mail.o365info.com

The external Exchange client will address the Public facing Exchange CAS server by using the host named – mail.o365info.com

Scenario 2- Using a single domain name space for the Exchange infrastructure -02

Maintain two different domain name scheme scenario in more details

In the previous section, we provide am high-level review of the possible “Exchange namespace scenarios”

In the following section, we will continue to review the scenario of- “Maintaining two different domain namespace scheme” situation in more details.

In case you are wondering about the second scenario of -Exchange infrastructure using a “unified domain name scheme,” you will have to be patient because I have deducted a different article for this type of scenario.

The charters of our scenario are as follows:

  • The internal private domain name is –o365info.local
  • The Public domain name that the company has and that is used for publishing hosts in the external network is – o365info.com
  • By default, each of the internal hosts in the Active Directory will have a hostname or if we want to be more accurate, FQDN that is based on the following naming convention – <host>.o365info.local
  • All of the “internal hosts”, is automatically registered at the Active Directory DNS server under the domain named – o365info.local
  • The company Exchange server, serve as “Public facing Exchange server”, that provide services to external mail clients.
    In this case, external mail clients will address the Public facing Exchange server by using the “public domain name scheme”, in our scenario – o365info.com
  • The public name of the Public facing Exchange server is mail.o365info.com and additional name, which is used for the Autodiscover service for an external mail client – autodiscover.o365info.com
  • The same Exchange server is published in the internal network by using the internal FQDN – o365info.com

In our scenario, we will need to build two separate infrastructures- one infrastructure for the internal company users that use the internal company network and additional public infrastructure, which will be used by external company users that are located at the public network.

The Internal Exchange infrastructure description

In this part, we review the charters and the workflow of the “internal network environment” that is available only for internal clients.

Exchange infrastructure -The relationships with internal Exchange clients

1. Active Directory SCP
The Autodiscover infrastructure in the “internal Active Directory environment” is implemented in the following way:
Internal Exchange client will query the Active Directory for a name\s of existing Exchange CAS server\s. Exchange CAS server “know” how to register himself automatically at the Active Directory SCP.

By default, the Exchange CAS server, will register himself at the Active Directory Service connection point (SCP) using the FQDN –exo1.o365info.local

2. Internal DNS

The Active Directory internal DNS configured as an authoritative for the Active Directory private domain name – o365info.com

By default, the Active Directory, DNS supports the feature of DDNS (Dynamic DNS) and authenticated hosts such as our Exchange server, can register themselves automatically.

In our scenario, the internal Exchange CAS server registers himself automatically in the DNS zone- o365info.local

The FQDN of the Exchange CAS server is – exo1.o365info.local

The private IP address of the Exchange CAS server is – 192.168.1.5

3. Server certificate

In an Exchange environment, the server certificate is a mandatory component. Because the Exchange CAS server should be available also for the external mail client, the certificate that was acquired is a public certificate that includes the following host names:

  • o365info.local – the name whom the Exchange server use for his internal mail client for all types of communications and services.
  • o365info.com – the “external” or the public name of the Public facing Exchange CAS server who is “allocated” for the Autodiscover services. External mail client will use this name for locating their Exchange CAS server (Autodiscover Endpoint).
  • o365info.com – the “external” or the public name of the Public facing Exchange CAS server who external mail client use for accessing and communicating with their Exchange server.
Internal network infrastructure - Exchange infrastructure using a private name scheme - The Registration process

When an internal Exchange client needs to access his mailbox, he needs to find + communicate his Exchange CAS server. In the internal network, the communication path between the Exchange client and the Exchange CAS server is based on the following workflow:

1. The mail client connects the local Active Directory (SCP) and asks for a list of available Exchange CAS server\s

In our scenario, the Active Directory reply with an answer such as –

https://exo1.o365info.local/autodiscver/autodiscover.xml

2. The mail client connects the local DNS server and asks for the IP address of
exo1.o365info.local (the DNS reply will include the Private IP address: 192.168.1.5)

3. Mail client connects to the local Exchange CAS server, verify that he can communicate using HTTPS and ask for the server certificate.

When the Exchange CAS server provides his certificate to the mail client, the mail client will check and verify only one hostname – exo1.o365info.local
The internal Exchange client will “ignore” all the rest of the host names who appear in the certificate.

The reason for this is that the Exchange client “acknowledge” or relate to the internal Exchange CAS server, using only the hostname – exo1.o365info.local

The mail client “doesn’t care” about additional host names who exist in the certificate that the Public facing Exchange CAS server provides (mail.o365info.com and o365info.com).

Internal network infrastructure - Exchange infrastructure using a private name scheme - Mail client access their Exchange server

The external\public Exchange infrastructure description

Exchange infrastructure - The relationships with external Exchange clients

The mail infrastructure that is used by the external mail client has a very different character.

The outer mail infrastructure will include the following “parts” and components:

1. Public IP
A public IP address should be acquired and assigned to the Exchange CAS server which serves as a “Public-facing Exchange CAS server”. Most of the time, this public IP address will be assigned to the company Firewall server who will forward requests from external mail client to the internal IP address of the Exchange CAS server.

2. Public\external DNS server
Every Public facing Exchange CAS server will have at least, two public host names.
These “public names” (FQDN’s) will have to register at the public DNS server which hosts the company public domain name.
In our scenario, we will need to register under the o365info.com zone (domain name) the following host names – mail and autodiscover

3. Public Exchange server certificate
The Exchange CAS server certificate will need to include the two public names who “represent” the Public facing Exchange CAS server (autodiscover.o365info.com and, mail.o365info.com)

External network infrastructure - Exchange infrastructure using a Public name scheme - Pre requirements -01

When an external Exchange client needs to access his mailbox, the following flow is implemented:

  1. Locking for the Public IP of the Autodiscover Endpoint

The mail client connects the public DNS looking for the IP address of – mail.o365info.com (in the reality, the mail client will start the Autodiscover process by looking for the host name –o365info.com and only if he cannot find or connect to this host, he will create an NDS query looking for the FQDN of the Autodiscover Endpoint).

  1. Mail client and Public facing Exchange CAS server

The Exchange client, connect to the Public facing Exchange CAS server and verify that he can communicate using HTTPS.
In case that the server supports HTTPS communication, the mail client asks for the server certificate.

When the Public facing Exchange CAS server provides his certificate, to the mail client, the mail client will check and verify, only two host names:

autodiscover.o365info.com and, mail.o365info.com

The reason for this, is that the Exchange client “acknowledge” or relate to the Public facing Exchange CAS server using only the host names – autodiscover.o365info.com and mail.o365info.com

The mail client “doesn’t care” about additional host names, the exists in the certificate that the Public facing Exchange CAS server provides (ex01.o365info.lcoal)

External network infrastructure - Exchange infrastructure using a Public name scheme - Mail client access their Exchange server -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 *