Should I Use A Single Namespace For Exchange Infrastructure Part 1-2 - Part 17 of 36

Page 1 of 30 | Should I use a single namespace for Exchange Infrastructure?
| Part 1#2 |
Part 17#36
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?
Written by Eyal Doron | o365info.com | Copyright 2012-2015
Page 2 of 30 | Should I use a single namespace for Exchange Infrastructure? | Part 1#2 |
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 14 and regarding question number 5, my
answer is Thin pizza with mozzarella, cheese, and basil leaves.
Part 17#36
Lets 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 (RPC\HTTPS or MAPI\HTTPS).
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 Hosts 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 lets 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

internal\private namespace o365info.local
External Exchange clients, will address Exchange resources using the
internal\private 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 its 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 doesnt 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 its 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 want\need to expose to the public network.
If we want to look of additional psychologists explanation for the private Active
Directory domain conspiracy theory is, that in the old days, the basic assumption
was that the organizations 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

external\public domain name is coming to its end because, the new standard or
public certificate doesnt 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 doesnt
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 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
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 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.
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 doesnt 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 external\public 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. Public\external DNS server
Every Public facing Exchange CAS server will have at least, two public host names.
These public names (FQDNs) 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 doesnt 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 of 36

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Should I Use A Single Namespace For Exchange Infrastructure Part 1-2 - Part 17 of 36

Încărcat de

Drepturi de autor:

Formate disponibile

Page 1 of 30 | Should I use a single namespace for Exchange Infrastructure?

Should I use a single namespace for

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

Autodiscover infrastructure | Exchange infrastructure and

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

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

Relating the former questions

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

Exchange architecture | Former versus modern

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

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

Exchange infrastructure Hosts names and FQDNs

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

If we want to be more accurate, in a Microsoft based environment, the Exchange

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

In a scenario in which we use a dual namespace meaning private namespace and

The possible namespace scenario matrix

Scenario 1 Active Directory private namespace | Exchange dual namespace

Internal Exchange clients, will address Exchange resources using the

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

Scenario 2 Active Directory private namespace | Exchange single namespace

Internal Exchange clients, will address Exchange resources using the

Scenario 3 Active Directory public namespace | Exchange single namespace

Internal Exchange clients, will address Exchange resources using the

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

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

Microsoft Active Directory and Private domain name

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

As mentioned, the default Exchange domain namespace infrastructure is built upon

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

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

Internal resources use a private IP scheme (Address Allocation for Private

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

The syndrome of mister jackal and mister Hyde

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

The trend in which we use a private domain name parallel to using an

The publicly available on Exchange infrastructure

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

Exchange infrastructure will have to expose himself to external Exchange

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

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

Option 2: Exchange infrastructure using a unified domain name scheme

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

Maintain two different domain name scheme scenario

The internal the private domain name is o365info.local

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

In our scenario, we will need to build two separate infrastructures- one

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

1. Active Directory SCP

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

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

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

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

The external\public Exchange infrastructure description

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

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

represent the Public facing Exchange CAS server

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

2. Mail client and Public facing Exchange CAS server

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

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

S-ar putea să vă placă și