Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36

Page 1 of 42 | Exchange infrastructure | Implementing single domain namespace scheme

| Part 2#2 | Part 18#36

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

Exchange infrastructure | Implementing

single domain namespace scheme | Part

2#2 | Part 18#36

The current article is the second article in which we review the concept of Exchange

infrastructure and the use of a single namespace.

In the former article, we review the concept and the reason for the

recommendation of using an Exchange single namespace.

The current article is focused on a scenario in which we want to convert our existing

Exchange infrastructure into an Exchange single namespace.

http://o365info.com/exchange-infrastructure-implementing-single-domain-namespace-part-2-of-2-part-18-of-36


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

http://o365info.com/

http://o365info.com/should-i-use-a-single-namespace-for-exchange-infrastructure-part-1-of-2-part-17-of-36


| Part 2#2 | Part 18#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

The meaning of the term – unified domain namespace

Along this article, we will mention the term – unified domain namespace many

times. Technically speaking, there is no such formal term.

This is the term that I use for describing an environment or a scenario in which the

internal identity of the Exchange servers and the public identity of the Exchange

servers is based on identical namespace meaning public namespace.










| Part 2#2 | Part 18#36


In the former article (Should I use a single namespace for Exchange Infrastructure?

| Part 1#2 | Part 17#36) we have reviewed the default Exchange infrastructure that

is implemented in a scenario in which the Active Directory domain name is private.

Invalid Fully Qualified Domain Names – the main reason

I have also mentioned my reservations about the concept of “using a private

domain name for Active Directory” but the infrastructure is popular or common, in

many organizations.

Regardless of my opinion on the use of the Active Directory private domain name

for the Exchange internal infrastructure, here is a very strong argument for

changing this type of configuration – Invalid Fully Qualified Domain Names.








| Part 2#2 | Part 18#36


The term “Invalid Fully Qualified Domain Names”, relates to a new certificate

standard in which a public SAN certificate will not support the use of “single

hostname” and host names (FQDN) that use the private domain name suffix such

as – local

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

Note – you can read additional information about the subject of Invalid Fully

Qualified Domain Names in the article – Autodiscover process and Exchange

security infrastructure | Part 20#36

There are additional reasons for using the option on -”unified domain namespace

for Exchange infrastructure” such as – more Intuitive, more convent

troubleshooting processes, simplified management and much more.





http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36

http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36


| Part 2#2 | Part 18#36


In a modern Exchange environment, we can say that there is no escape from the

need to use a single domain namespace for the Exchange infrastructure.






| Part 2#2 | Part 18#36


Let’s assume that you convinced, and you want to avert the existing Exchange

infrastructure that is based upon the concept of- two different domain namespace

to the infrastructure of – unified domain name scheme for Exchange infrastructure.

The main questions are:

Q: Can it be done? Is there an option to “convert” my existing Exchange domain

name infrastructure to a unified domain namespace?

A: And the answer is: “yes”

Additional important questions are:

Q1. What are the steps that are involved throughout this process?

Q2. Does this “change” can impact the availability of the Exchange services?

Q3. Given that I will read the article thoroughly, will I be able to do it without a need

for involving an external help?

And the answers for this question are:






| Part 2#2 | Part 18#36


A1. In the following article, we will review each of the “steps”, infrastructure and

components that involve in the process of converting the existing Exchange

infrastructure to a ”unified domain namespace”

A2. Now, given that you make the required “planning process” and implemented all

the required necessary configurations, there will be no “down time” for your

Exchange clients.

A3. The answer is “Yes”. It is always good if it is passable to get help or advice from

an experienced people, which has “hands-on experience”. However, if you are an

experienced Active Directory and Exchange administrator who “migration” is quite

simple.

Converting the existing Exchange infrastructure to a –

“unified domain namespace” | Tasks list

The most important phase, in the migration process to – “Exchange infrastructure

that is based on unified domain namespace” is the planning process, in which we

will need to consider all the components and task that will be involved.






| Part 2#2 | Part 18#36


We can define three main elements, that will be involved throughout the migration

process of – converting the existing Exchange infrastructure to a – “unified domain

namespace”.

1. Internal DNS server

In a scenario in which the Active Directory is based on a private domain name, we

will need to add the additional domain name (the public domain name) to the local

DNS server that will “host” the public domain name.

Please note that parallel to the local\internal Active Directory, DNS server, the

public domain name will be hosted also at the Public DNS server.

This scenario, in which the same domain namespace is managed by two different

and separated DNS servers named – Split DNS.

(We will review the subject of Split DNS in the next sections).

2. The Active Directory SCP






| Part 2#2 | Part 18#36


We will need to update the information that was registered in the Active Directory

SCP and “replace” the existing Exchange CAS server\s name\s.

By default, each of the existing Exchange CAS server\s will automatically register

himself at the Active Directory SCP using his private meaning, the FQDN which

includes the Active Directory private domain name suffix.

3. Exchange CAS server

Part of the Exchange CAS server includes the URL address of the Exchange CAS

server web services. This URL address includes the private host name of the

Exchange CAS server.

When we implement the method of – “unified domain namespace for internal +

external Exchange infrastructure”, we will also need to update all the Exchange CAS

server URL addresses so the “new URL address” will include the “new public name”

of the Exchange CAS server.

In the following diagram, we can see a summary that points out the element, and

the infrastructure that we will need to update with the “new Exchange server host

name” and Exchange web service URL address.






| Part 2#2 | Part 18#36


Implementing “unified domain namespace” Exchange

infrastructure | Task list

In the following section, we will describe each of the “major steps” that involved in

the process of – Implementing “unified domain namespace” in Exchange

infrastructure”.

The main components that are involved throughout the process are:

1. Split DNS

When we use a unified domain namespace for the internal and the external

Exchange FQDN name, in a scenario in which the Active Directory domain name is a

private domain name, we will need to add to the local DNS additional zone that will

“host” the public domain name.

The internal DNS server will be configured as “authoritative” for the public domain

name.

In this scenario, we will need to manually add all of the DNS records that relate to

the Exchange infrastructure such as:

The A record for the Exchange server host name, the Autodiscover record, the MX

record and so on.

2. Active Directory SCP

We will need to remove from the Active Directory SCP the hostname who includes

the Exchange FQDN that uses the Active Directory private domain name and

instead adds information for the Exchange CAS server\s that exists using use the

public domain name suffix.

3. Exchange CAS server configurations

We will need to update all the Exchange web service URL addresses that include the

Exchange host name who use a private domain name to the “new Exchange FQDN”

that uses the public domain name suffix.






| Part 2#2 | Part 18#36


Step 1: implementing Split DNS infrastructure

The implementation of Split DNS, enable us to bypass the obstacle in which the

Exchange server host names (FQDN) are based by default on the Active Directory

domain naming scheme.

In case that the Active Directory is a private domain name space, we would like to

“disconnect” or to “detached” the Exchange infrastructure namespace from the

Active Directory private domain name and, to “associate” the Exchange domain

name space with a public domain name.

Q: How making this magic happened?

A: Using the option of Split DNS

The next question could be:

Q: What is the meaning of Split DNS and if Split DNS is good to me, I should I

implement this configuration?






| Part 2#2 | Part 18#36


Basic concept of DNS as a distributed database and single

source of authority

The DNS world is a very interesting and complex world, which can share data

between Infinite numbers of DNS servers.

Despite the fact, that many DNS servers can share any information such as

information about a specific domain name (zone transfer and so on) logically, there

is only “one source of authority”.

The meaning is that only one DNS server can be considered as “authoritative” for

the information that he holds.

This “source of authority” (the primary DNS), can replicate the information to

additional DNS servers but the basic role is that the information should be identical

on all the DNS servers who hold a replica of the zone file (the domain name) that

was accepted from the primary DNS (the source of authority).






| Part 2#2 | Part 18#36


In the following diagram, we can see that the primary DNS server is replicating

information about a specific domain name (the domain name that considers “under

his authority”) to the additional DNS server.

DNS clients, can access or query each of the DNS servers and the “answer” that the

DNS client will get is supposed to be identical in each of the DNS servers.

What is the meaning of – Split DNS?

The simple explanation for the term “Split DNS” is – a configuration, in which two

different and separated DNS servers serve as “source of authority” at the same time

for the same namespace (domain name).

Note – additional popular terms for this configuration are – Split-Horizon DNS and

Split-Brain DNS






| Part 2#2 | Part 18#36


When using the configuration of Split DNS, we are “violating” one of the most basic

concepts of the DNS infrastructure because we create a scenario in which two

different DNS servers “think” that they are the only owner of a specific domain

name while, in reality, there are two DNS infrastructures – internal Active Directory

DNS infrastructure and external public DNS infrastructure that define as

authoritative for the same domain name.

Each of the DNS infrastructure, is “sure” that he is the “only one” and each of the

DNS infrastructure doesn’t know of the existence of the other DNS infrastructure.






| Part 2#2 | Part 18#36


Q: Why do we need to use the option of Split DNS?

A: The answer is that – when we use a configuration of Split DNS, we have the

ability to provide different answers, for different clients based on their physical

location.






| Part 2#2 | Part 18#36


Public facing Exchange CAS server – one name and two different

IP address

In a scenario in which we are converting the existing Exchange domain scheme

from – “Two domain name infrastructure” to a – “single unified domain name”, the

main target is to enable internal + external Exchange clients to use the same FQDN

(the same host name who uses the public domain name suffix).

However, at the same time, we should not forget that despite the concept of “single

unified domain name” relates, to the domain name and, not to the IP address of the

Exchange CAS server.






| Part 2#2 | Part 18#36


In the following diagram, we can see an example of a scenario, in which the

Exchange on-Premises servers have two sets of IP address.

In our scenario, the Exchange server will be represented by the host name

– mail.o365info.com

This host name will be “published” in the internal and the external DNS server using

a different IP address.

Internal Exchange clients, which will try to access the host name

– o365info.com will try to communicate the Exchange CAS server using the

private IP address – 192.168.1.5

External Exchange clients, which will try to access the host name

– o365info.com will try to communicate the Exchange CAS server using the

private IP address – 212.25.80.239






| Part 2#2 | Part 18#36


Note – in reality, we are not physically assigning the public IP address to the

Exchange on-Premises server but instead, use a Firewall that has the specific public

IP address range.

Each connection attempt from external mail client that needs access to the Public

facing Exchange CAS server, will be automatically “forwarded” to the Exchange CAS

server using the private IP address (this is the implementation of NAT

configuration).

Implementing Split DNS configuration by using two DNS servers

In our example, the “Green DNS server” (server A in the diagram), is the Active

Directory internal DNS server who will be accessible or available only for hosts who

are located on the company private network and the “purple DNS server” will be

available only for external clients.

Each of these DNS servers, hold or consider as an “SOA – source of authority” for

the domain name – o365info.com

Each of the DNS servers, publish “different information” about the IP address of

specific hosts.

In the following diagram, we can see an example of the Split DNS concept.






| Part 2#2 | Part 18#36


We can see that there are two DNS servers, which “claim to be a source of

information”

Additionally, we can see that the information in each of the DNS database (the zone

file) is different.

The DNS server at “claim” that the IP address of a host named mail.o365info.com is –

192.198.1.5

DNS server B “claim” that the IP address of a host named mail.o365info.com is

– 212.25.80.239

In the next diagram, we can see the concept of Split DNS but this time, from the

DNS client point of view.

When an internal DNS client, query the DNS server for a host

named mail.o365info.com, the DNS server reply, will include the private IP address

of the host.

When an external DNS client, query the DNS server for a host

named mail.o365info.com, the DNS server reply will include the public IP address of

the host.






| Part 2#2 | Part 18#36


The Public facing Exchange CAS server public IP address and

Firewall infrastructure

As mentioned, most of the time, there is no “direct” communication between the

external mail client and the Public facing Exchange CAS server.

Instead, the Public facing Exchange CAS server is “published” or “represented” to

the external client by using a Firewall server.

The Firewall is “impersonating” himself and appear as the “Public facing Exchange

CAS server”.

When an external client tries to communicate the Public facing Exchange CAS

server using the IP address – 212.25.80.239, the communication requests will be

“intercepted” by the Firewall and, automatically will be forwarded to the Exchange

CAS server, using the private IP of the Exchange server.

All of this “process” is “transparent” to the external mail client.






| Part 2#2 | Part 18#36


Managing the Split DNS configuration

The implemented of Split DNS infrastructure is implemented by using at least two

separated DNS servers. The internal Active Directory, DNS infrastructure and a

Public DNS infrastructure.

In case that the Active Directory uses a private domain name, we will need to add to

the internal DNS server, additional domain (the technical term is “zone”) with the

public domain name.

In our scenario, the Active Directory private domain name is – o365info.local and the

company public domain name is – o365info.com

In the diagram, we can see the following information:






| Part 2#2 | Part 18#36


1. The organization uses two different DNS servers – internal DNS server who is

available for internal “Active Directory users” and additional “Public DNS

server” that will be used by external clients.

2. The internal DNS server is authoritative for two different domains

– o365info.local + o365info.com

3. The “public host name” that was chosen for the Exchange CAS server is- mail.

This host name, will be configured twice – in the internal DNS server + in the

external DNS server.

Pay attention to the fact that the “real host name” (the NetBIOS name) of the

Exchange CAS server is – ex01

Technically, this name will be registered automatically in the private Active

Directory domain name (o365info.local) but in our scenario, we don’t want to enable

the use of the “default Exchange server name who is based on the Active Directory

private name suffix.

The host name who will be used by the internal, and the external mail client is

– mail

The FQDN of the Exchange CAS server will be – mail.o365info.com






| Part 2#2 | Part 18#36


Managing the internal Active Directory DNS

server

In the following screenshot, we can see an example to the internal DNS that

includes two different domain names.

1. o365info.local DNS zone

The Active Directory domain name is – o365info.local we be managed automatically.

By default, the DNS zone is configured to support the future of DDNS (Dynamic

DNS). Each of the internal hosts in the domain, “know” how to register himself in

the DNS under the Active Directory domain name.

2. o365info.com DNS zone

The additional domain name that represents the Public domain name (in our

scenarioo365info.com) will be managed manually because, the Active Directory

hosts (domain joined hosts) doesn’t “belong” or associated with this domain name.

We will need to add manually, each of the host names that we need to “publish”

under the public domain name and additionally, add his private IP address.






| Part 2#2 | Part 18#36


In the following screenshot, we can see that under the Public domain name, we add

the host name – mail, which represent the Exchange CAS server and his private IP

address.

Regarding the Autodiscover record, technically, we don’t need to add this record,

because internal hosts that configured as a domain joined, will not use the DNS

services for locating the name of the Exchange CAS server, but instead, will access

the Active Directory for getting the name of the Exchange CAS server (the name

whom the Active Directory will provide in our scenario is mail.o365info.com)

The need for adding the Autodiscover record is only for internal host who are not

the domain joined.

What will happen in the case that we don’t use the Split DNS

configuration?

An interesting question that could appear in our suspicious mind is – ”What will

happen in the case that we don’t use the Split DNS configuration?”






| Part 2#2 | Part 18#36


The answer is that in some scenarios, everything will work fine without all the

“headache” of Implemented a Split DNS configuration which requires to add

additional zones to the internal DNS server, add A records to the public name DNS

zone, etc.

The reason for implementing the configuration of Split DNS, is for preventing from

the internal clients, to use the Public IP address of the “internal host” (the Exchange

CAS server in our scenario).

Instead, we would like that the internal Exchange clients will the Exchange CAS

server by using his private IP address.






| Part 2#2 | Part 18#36


In case that the internal Exchange clients will address the Exchange CAS server by

using his public IP address, the communication channel, can be configured as-

“twisted”.

The communication channel between: internal hosts and external host

A “normal” communication channel between- internal hosts and external host is

implemented in the following way:

When an internal client, need to access to “external host” (host with public IP

address), the internal host, will need the help of a “gateway” such as a Firewall or

Proxy server, that will “forward his request” to the destination external host and

vice versa.

When the external host reply, the Gateway will forward the response to the internal

host.






| Part 2#2 | Part 18#36


The described communication channel is “acceptable” when we really need access

to external hosts, but in our scenario, the Exchange CAS server is not an external

host.

None recommended communication channel between-internal hosts

and external host

In case that we will not use the configuration of Split DNS, each of the DNS queries

for host the “belong” to the public domain name (such as DNS query for the host

name- mail.o365info.com), will be “redirected” to the authoritative authority of the

public domain name.

By default, the authoritative authority is the external DNS server who host the

domain name –o365info.com

This scenario, in which we use the public DNS as authoritative authority of the

public domain name, will cause to an “Incident”, in which Internal Exchange clients

will try to address them Exchange CAS server using a public IP address instead of

using his “standard” private IP address.






| Part 2#2 | Part 18#36


The outcome of this scenario is that the communication channel will be

implemented in a non – optimal way that could lead to – slowdown in performance

or even logical error and other problem that will prevent the communication

between the internal mail client and his internal Exchange CAS server.

To demonstrate what will happen in the case that we will not use the split DNS

configuration, let’s use the following example:

An internal mail client needs to access his Exchange CAS server.

The mail client connects the local Active Directory and the Active Directory replay

with the name of the Exchange CAS server – mail.o365info.com

1. The internal client connects the local DNS looking for the IP address of the host –

mail.o365info.com

2. The local DNS server, will connect an external Root DNS server for getting the

name and the IP address of the DNS server who “host” (authoritative) for the

domain – o365info.com

3. The internal DNS provides to the internal client the public IP address of the host

– 212.25.80.239

4. The internal client “understand” that this IP is not local, and for this reason

connects hos Gateway.

5. The Gateway “bounce” the request to his “external leg” because he is responsible

for this public IP (in our scenario – 212.25.80.239).






| Part 2#2 | Part 18#36


6. The Gateway, address the internal host using the Private IP address of the host

(192.168.1.5 in our scenario).

7. The internal host (the Exchange CAS server) “answer” to the “host” that makes to

the connection attempt.

Pay attention to the fact that from the internal Exchange CAS server point of

view, the host who try to contact him is the “internal leg” of the Firewall server.






| Part 2#2 | Part 18#36


8. The firewall takes the “Exchange CAS server respond” and forward the “answer”

to the internal mail client.

Sound strange and a little twisted?

Yes, this is the point. In case that we don’t use the option of Split DNS and use a

public domain name scheme for our Exchange infrastructure, this is how the

communication workflow will be implemented.

The consequence of this “workflow” could be – unnecessary load on the Firewall

server, reduction of network performance because the communication path is

considerably complicated, single point of failure in case that the Firewall server is

not available and much more.

Step 2: Exchange public domain naming scheme and

Active Directory






| Part 2#2 | Part 18#36


An additional element in the scenario of – Exchange public domain naming scheme

is the component of the Active Directory and the Exchange CAS server information

that is registered in the Active Directory SCP (service connection point).

In a scenario in which the Active Directory uses a private domain name, each of the

Exchange CAS servers automatically registers himself at the Active Directory SCP

(Service Connection Point) using his host name who includes the Active Directory

private domain name.

In a scenario of – ”single naming scheme for Exchange Infrastructure”, we will need

to “remove” the existing information that was registered at the Active Directory SCP

and instead, update the information so it will “point” to the “new Exchange CAS

server name who is based on the public domain name suffix.

To demonstrate this concept, let’s use the following example:

The Active Directory uses a private domain named – o365info.lcoal






| Part 2#2 | Part 18#36


The public name of the company is – o365info.com

The host name of the local Exchange CAS server is – exo1 and, the “Full name”

(the FQDN) of the Exchange CAS server is – mail.o365info.local

The name whom we want to assign, to on-Premises Exchange CAS server

using the public domain name is – mail.o365info.com

Pay attention to the fact that by default, the Exchange CAS server was already

registered himself at the Active Directory SCP using the host name

– ex01.o365info.local

In our scenario, we want that each time that a mail client (Autodiscover client) will

query the Active Directory for the name of the available Autodiscover Endpoint (the

Exchange CAS server\s), the answer that the Active Directory will provide will be the

“public name” of the Exchange CAS server.

To be able to accomplish this requirement, we will need to update the existing

value that was automatically registered at the Active Directory SCP to the “new

name” of the Exchange CAS server.

In our example, we will need to update the Exchange CAS server name who was

registered in the Active Directory SCP to the “new name” by using a PowerShell

command such as:

Set-ClientAccessServer -Identity “EX01″ -AutodiscoverServiceInternalURI

“https://mail.o365info.com/Autodiscover/Autodiscover.xml”

Step 3: updating the Exchange CAS server web services

URL address.

The Exchange CAS server “tell” his client about the available web services by using a

URL address.

We can relate to the URL address that the Exchange CAS server provides as a

“pointer” to the required Exchange web service.






| Part 2#2 | Part 18#36


As mentioned, the Exchange CAS server uses two separate interfaces for internal

Exchange clients and for external Exchange clients.

Each of the Exchange CAS server web services is published using an internal URL

address and external URL address.

The internal URL address is supposed to be used by the internal Exchange client,

and the external URL address is supposed to be used by the external Exchange

client.

In our scenario, in which we use only one domain name (the public domain name),

we will need to update the URL address of each of the Exchange web services so

that internal URL address that is configured by default with the private domain

name, will be updated and will be configured as identical to the external URL

address that is based on the Public domain name suffix.

The Exchange web service that we will need to update their URL addresses are:

Exchange web services (EWS)






| Part 2#2 | Part 18#36


ActiveSync

OWA

ECP

OAB

Updating the Exchange CAS server URL address by using the

Exchange graphical management interface.

Most of this Exchange web services, can be updated by using the Exchange

graphical management interface.

In the Exchange 2010 server version, we can use the use the graphical management

interface for updating all the Exchange web service URL beside the Exchange web

services (EWS).

In case that you use Exchange 2013, we can use the web management interface for

updating all the Exchange web services, including the Exchange web services (EWS).

In the following screenshot, we can see an example for the option that are available

for us when using the Exchange 2010 graphical management interface.

Under the Server Configuration, Client Access, we can see the “tabs” for each of the

Exchange web services.






| Part 2#2 | Part 18#36


For example, let’s take a look at the setting of the Exchange OWA web service.

In the following screenshot, we can see that the OWA internal URL is configured by

default using the Exchange CAS server internal name.

In our scenario the Exchange internal host name is – o365info.local






| Part 2#2 | Part 18#36


In a scenario of “single unified domain name scheme”, we would like to implement

a configuration, in which the Exchange CAS server domain name will be based on a

public domain name suffix and additionally, the internal and the external URL will

be identical.

In the following screenshot, we can see the “updated URL address”. The internal

URL address was updated to the following URL address – mail.o365info.com






| Part 2#2 | Part 18#36


Updating the Exchange CAS server web services URL address by

using the Exchange PowerShell interface.

Another option for updating the Exchange CAS server web services URL address is

by using the PowerShell interface.

In the following section, you can see an example of the PowerShell command that

could be used for updating the Exchange internal URL address.






| Part 2#2 | Part 18#36


Note – if you want more detailed information about the available PowerShell

command that we can use for managing the CAS server web services URL address

by using the Exchange PowerShell interface, you can read the article- Exchange

Web services | Manage the Internal and external URL address | Part 10#36

Set\update the URL address of – Exchange web services (EWS)

In the following example, we will update the internal and the external URL address

of the Exchange EWS services using the “New” Exchange CAS server host name

– mail.o365info.com

PowerShell command:

Set-WebServicesVirtualDirectory -Identity “CAS01\EWS (Default Web Site)”

–InternalUrl “https://mail.o365info.com/ews/exchange.asmx”

–ExternalUrl “https://mail.o365info.com/ews/exchange.asmx”

Set\update the URL address of – ActiveSync Exchange web service


of the Exchange ActiveSync services using the “New” Exchange CAS server host

name –mail.o365info.com

Set-ActiveSyncVirtualDirectory -Identity “EX01\Microsoft-Server-ActiveSync”

-InternalUrl “mail.o365info.com/Microsoft-Server-ActiveSync”

-ExternalUrl “mail.o365info.com/Microsoft-Server-ActiveSync”

Set\update the URL address of – OWA Exchange web service


of the Exchange OWA (web mail services) using the “New” Exchange CAS server host

name –mail.o365info.com

Set-OwaVirtualDirectory -Identity “ex01\owa (default Web site)”

-InternalUrl “https:// mail.o365info.com/owa”

-ExternalUrl “https://mail.o365info.com/owa”

Set\update the URL address of – Exchange ECP





http://o365info.com/exchange-web-services-manage-the-internal-and-external-url-address-part-10-of-36

http://o365info.com/exchange-web-services-manage-the-internal-and-external-url-address-part-10-of-36


| Part 2#2 | Part 18#36



of the Exchange ECP (Exchange control panel) using the “New” Exchange CAS server

host name –mail.o365info.com

Set-EcpVirtualDirectory -Identity “ex01\ECP (Default Web Site)”

-InternalUrl “https://mail.o365info.com/ecp”

-ExternalUrl “https://mail.o365info.com/ecp”

Exchange OAB (offline address book)


of the Exchange OAB (Offline address book) using the “New” Exchange CAS server

host name –mail.o365info.com

Set-OABVirtualDirectory -identity ” ex01\OAB (Default Web Site)”

-InternalUrl “https://ex01.o365info.local/oab”

-ExternalUrl “https://mail.o365info.com/oab”

Exchange Private Domain name versus Public Domain

name pros and cons.

As you already manage to understand, my opinion is that the preferable method or

the most efficient or preferable method is – using a single namespace, meaning,

assign to the public domain name scheme for the Exchange infrastructure instead

of maintaining two separated name scheme (private and public).

In case that until this point you are not quite convinced, here is a quick review of

the pros and cons for each of the options.

Before we review these pros and cons, I would like to summarize my mantra – after

we “invest” the required resources for planning and creating the required Split DNS

infrastructure, our life should be very easy and simple and, despite that it took me a

lot of “words” to explain the Split DNS infrastructure the “resources” that we will

need to allocate is quite easy and simple.






| Part 2#2 | Part 18#36


Using the public domain naming scheme for Exchange

infrastructure

Advantages

1. Simplify the user’s interaction with mail services

When using the Public domain name scheme for the Exchange infrastructure, the

Exchange clients will no longer need to memorize two separated host names for

addressing Exchange server from internal network verses address Exchange from

external\public network.

2. Simplify the certificate host name management.






| Part 2#2 | Part 18#36


In case that we use only one naming scheme (the public name scheme), we will no

longer need to “populate” the Exchange public certificate with external + internal

host names.

3. Simplify the troubleshooting process of Autodiscover and other Exchange related

issues.

In case that we will need to deal with a troubleshooting scenario that relates to the

Autodiscover and other Exchange web services, it’s much easier to troubleshoot the

problem when using only one naming scheme (the public domain name scheme).

4. Prevention of – future problems with the Exchange infrastructure when the new

standard of: “Invalid Fully Qualified Domain Names” will be enforced\implemented

We have already reviewed the subject of – Invalid Fully Qualified Domain Names in

public certificate and, it looks like that, there will be no option besides of embracing

the scenario of using only a public naming scheme and “get rid of” the assignment

of the private Active Directory naming scheme to Exchange infrastructure.

Disadvantages

1. The required resources for building a Split DNS infrastructure

Theoretically, we will need to allocate resources for building the “Split DNS

infrastructure” that will serve as a foundation for assigning only a public name

scheme to the Exchange infrastructure.

In reality, the only real resource that we will need to allocate is the time that we will

need to spend on reading “how to build Split DNS infrastructure”.

The implementation of Split DNS infrastructure, doesn’t need any dedicated servers

or hardware resources.

All we need to do is just add additional zone (domain name) to the build on a DNS

server that comes from a part of every DC (Active Directory server).

2. The need to re-register the Exchange CAS server\s name in the Active Directory

SCP

The need for re-register the Exchange CAS server\s name in the Active Directory

SCP can be implemented very easily by using a PowerShell command and the basic






| Part 2#2 | Part 18#36


assumption is that this is “one time operation” because we will need to run the “ re

registration process” only when a new Exchange CAS server will be added.

Additional reading

Namespace Planning in Exchange 2013

Understanding Client Access Server Namespaces

‘Single Global Namespace Support’ in Exchange 2013

Overview of Namespace Planning

Exchange 2013 Client Access Server Role

The Preferred Architecture





http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx

https://technet.microsoft.com/en-us/library/dd351198(v=exchg.141).aspx

http://social.technet.microsoft.com/wiki/contents/articles/17880.single-global-namespace-support-in-exchange-2013.aspx

https://technet.microsoft.com/en-us/library/cc535021(v=exchg.80).aspx

http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx

http://blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx

Documents

Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36