Should i use a single namespace for exchange infrastructure part 1#2 part 17#36

of 30 | Should I use a single namespace for Exchange Infrastructure? | Part 1#2 |
Part 17#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 versus external Exchange clients that is based on different
namespace.
The major question that I will try to answer in this article are:
1. Is it good or bad to use a different namespace?
2. What are the characters of Exchange environment that is based on two
different namespaces?

Part 17#36
Autodiscover infrastructure | Exchange infrastructure and
namespace convention | The article series
The article series include the following articles:
1. Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part
17#36
2. Exchange infrastructure | Implementing single domain namespace scheme |
Part 2#2 | Part 18#36
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?
4. Should I spend my precious time reading this article?
5. What is the meaning of life?
Ok, I promise to answer questions 1–4 and regarding question number 5, my
answer is Thin pizza with mozzarella, cheese, and basil leaves.

Part 17#36
Let’s jump to question number 4: Should I spend my precious time reading this
article?
My answer is -Yes
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.

Part 17#36
Relating the former 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 shortly answer this question 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 is implemented by addressing a specific Exchange
server by using his hostname.
The Exchange CAS server publishes Exchange web services to his clients, by
providing them a URL address that include the host name.

Part 17#36
Exchange architecture | Former versus modern
namespace conventions
Exchange server architecture Includes built-in ability to implement a different
interface with internal versus external Exchange clients.
The Realization of the different interfaces is based on three main elements
1. Communication protocol
2. Authentication protocol
3. Namespace
Former Exchange server architecture versus modern Exchange architecture |
Interface with internal Exchange clients versus external Exchange clients.
In former Exchange server versions such as Exchange 2003, 2007 and 2010, the
common convention was – to configure Exchange server for using different
interface with internal Exchange clients versus external Exchange clients.
The basic thought behind this configuration was that the internal network has
different needs and different characters versus external network and for this
reason, there is a need for configuring Exchange to use different configuration
setting when interacting with internal Exchange clients versus external Exchange
clients.
In a modern Exchange environment such as Exchange 2013, the differentiation
between the two environments (internal versus 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 versus
external Exchange clients, most of the time, the common practice is to use an
identical interface with internal Exchange clients versus external Exchange clients.
For example:
In former Exchange server versions (Exchange 2003, 2007, 2010) a common
configuration was to use different communication protocol and different
namespace with internal Exchange clients versus external Exchange clients.

Part 17#36
 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 “former 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 common convention, which dictates the need to differentiate and separate
Exchange interface with internal Exchange clients versus external Exchange clients
were changed over time into a new convention that was based on a “simplify the
concept”” in which the Exchange interface with internal Exchange clients versus
external Exchange clients will be configured as an identical interface.
For example, in an Exchange 2013 environment, the only available communication
protocol with Outlook client is – Outlook Anywhere (RPCHTTPS or MAPIHTTPS).
In other words, we cannot set a different communication protocol for internal
Outlook client versus external Outlook client.
Regarding the subject of “namespace”, theoretically, Exchange 2013 enables us to
use the option on “internal namespace” for internal Outlook client versus 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 versus external Exchange clients
is because in the current time, public certificate cannot and will not support host
name who includes non-public or public domain name suffix.
In other words – even in 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 host name as part of the certificate.

Part 17#36
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 former section, we have mentioned that modern Exchange environment is
moving toward consolidation or unification of the Exchange interface with internal
Exchange clients versus external Exchange clients.
However, in reality, there are many organizations that still use the former
convention in which we implement two different Exchange interfaces with internal
Exchange clients versus external Exchange clients.
In the next sections, we will review some examples for this type of infrastructure in
which we use two different Exchange interface, the characters of this environment
and the flow that is implemented between Exchange server and his client.
While reading the information, you could feel that my opinion is that organization
that use “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 versus external Exchange clients.
Exchange infrastructure – Host’s names and FQDNs
Most of the time when we use the term “Host name” 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.

Part 17#36
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.

Part 17#36
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 will be used by the “public” or the external
Exchange mail clients.
The possible namespace scenario matrix
To arrange things in clear format let’s review the possible “combination” of
namespaces.
The characters of this scenario that we will review are as follows:
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 will be based on a dual namespace
infrastructure.
 Internal Exchange clients, will address Exchange resources using the
internalprivate namespace –o365info.local
 External Exchange clients, will address Exchange resources using the
internalprivate namespace –o365info.com

Part 17#36
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 will be 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)
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 will be 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)

Part 17#36
Q: Why should I avoid from using the option of – “Exchange dual namespace”?
A: The short version of the answer for 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 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”.

Part 17#36
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 be
considered 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.

Part 17#36
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 case that we have purchased the domain
name from a public provider such as GoDaddy etc.

Part 17#36
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 personal 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
was based on a faulty assumption that the use of “private domain name” is
required or mandatory for protecting the origination private 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.

Part 17#36
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 passable 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 wantneed to expose to the public network.
If we want to look of additional psychologist’s explanation for the “private Active
Directory domain conspiracy theory” is, that in the old days, the basic assumption
was that the organization’s network is an isolated place that should never need to
be exposed to “external network” or external user who reside on the public
network.
This assumption looks a little radical in now days because, now the common is the
opposite – most, if the organization users are using public network and must have
access to “internal network resources” such as the Exchange CAS server on an
hourly basis.

Part 17#36
Additional reading
You can read additional information about the concept of private domain name
and the local domain name suffix in the following articles:
 .local
 Multicast DNS
 Top-level domain
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 used only by the internal network client and
the public naming scheme will be used only by the public client.
I can even compare this scenario, to a person that suffer from the illness of Split
Personality!

Part 17#36
The trend in which we use a private domain name parallel to using an
“externalpublic” 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
versus the private Active Directory infrastructure.

Part 17#36
As mentioned, versus 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 for the “two worlds” in which
Public facing Exchange CAS server needs to operate.
Q: In case that the Active Directory uses a private domain name, how does
Exchange serve external clients?
A: There are two passable “solutions”:
Option 1: Maintain two different domain name scheme

Part 17#36
In this scenario, the Active Directory private domain namespace will be used also 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.
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 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

Part 17#36
Option 2: Exchange infrastructure using a “unified domain name scheme”
In this scenario, Exchange infrastructure will use only a public domain name
scheme that will be used 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.

Part 17#36
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
Maintain two different domain name scheme scenario
in more details
In the former section, we provide am high-level review of the passable “Exchange
namespace scenarios”
In the following section, we will continue to review the scenario of- “Maintaining two
different domain namespace scheme” scenario in more details.
In case that 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 the private domain name is –o365info.local

Part 17#36
 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.

Part 17#36
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 names of existing
Exchange CAS servers. 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

Part 17#36
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.

Part 17#36
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 servers
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.

Part 17#36
When the Exchange CAS server provides his certificate to the mail client, the mail
client will check and verify only one host name – 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).
The externalpublic Exchange infrastructure description

Part 17#36
The mail infrastructure that is used by the external mail client has a very different
character.
The external 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
who 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. Publicexternal DNS server
Every Public facing Exchange CAS server will have at least, two public host names.
These “public names” (FQDN’s) will have to be registered at the public DNS server
who 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

Part 17#36
“represent” the Public facing Exchange CAS server
(autodiscover.o365info.com and, mail.o365info.com)
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).

Part 17#36
2. 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 andmail.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)

Part 17#36

Should i use a single namespace for exchange infrastructure part 1#2 part 17#36

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to Should i use a single namespace for exchange infrastructure part 1#2 part 17#36

Similar to Should i use a single namespace for exchange infrastructure part 1#2 part 17#36 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Should i use a single namespace for exchange infrastructure part 1#2 part 17#36