Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36 No ratings yet. 30 min read

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 present article focused on a scenario in which we want to convert our existing Exchange infrastructure into an Exchange single namespace.

Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

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 based on same namespace meaning public namespace.

Exchange unified domain namespace

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 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 utilization of the Active Directory private domain name for the Exchange internal infrastructure, here is an adamant argument for changing this type of configuration – Invalid Fully Qualified Domain Names.

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

No use of private domain name suffix and single host name will be allowed

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.

Exchange infrastructure and the domain name scheme

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.

we want that the Internal Exchange infrastructure, uses a public domain name

Let’s assume that you convinced, and you want to avert the existing Exchange infrastructure that based on 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 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:

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 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 - ONE unified domain name - Simple process or hard work

Converting the existing Exchange infrastructure to a – “unified domain namespace” | Tasks list

The most critical phase, in the migration process, to – “Exchange infrastructure that 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.

Exchange infrastructure based on ONE unified domain name

We can define three main elements, which 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 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 also be hosted on 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

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 current 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 hostname” and Exchange web service URL address.

Converting existing Exchange infrastructure namespace to a -unified domain namespace -The five main elements

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 which 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 hostname who use a private domain name to the “new Exchange FQDN” that uses the public domain name suffix.

Implementing unified domain namespace ” Exchange infrastructure - Task list

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 go I implement this configuration?

how to i build an SPLIT DNS infrastructure

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 particular domain name (zone transfer and so on) logically, there is only “one source of authority”.

The meaning is that only one DNS server can consider 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 which hold a replica of the zone file (the domain name) that accepted from the primary DNS (the source of authority).

In the following diagram, we can see that the primary DNS server is replicating information about a particular 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 supposed to be identical in each of the DNS servers.

Standard DNS infrastructure - Master and Slave module

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

Split DNS infrastructure

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 infrastructures 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.

Split DNS - Each of the DNS server doesn’t know about the existence of the other DNS server

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.

Split DNS - different answer for different client

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.

The Public facing Exchange CAS server - Two different set of IP address -01

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 hostname 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

Exchange CAS server have two identities - Public IP address and Private IP address -02

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.

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

Split DNS infrastructure -Two source of authority at the same time -03

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.

Split DNS Infrastructure - Two different DNS servers serve two different type of DNS clients -04

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.

Split DNS Infrastructure - Two type of Mail clients that need access the Exchange CAS server -05

Managing the Split DNS configuration

The implemented of Split DNS infrastructure implemented by using at least two separate 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

Public versus private domain name

In the diagram, we can see the following information:

  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 which 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

Split DNS Infrastructure - The 2 DNS servers

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 scenario o365info.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.

Split DNS Infrastructure - Internal DNS settings- Add the public domain name

In the following screenshot, we can see that under the Public domain name, we add the hostname – 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. 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 an internal host who are not the domain joined.

Split DNS Infrastructure - Internal DNS settings - Add A records

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?”

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

The answer is that in some scenarios, everything will work fine without all the “a 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.

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”.

Twisted communication channel

The communication channel between: internal hosts and external host

A “normal” communication channel between- internal hosts and external host 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.

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 that “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 the 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.

Internal Exchange client will try to address Exchange CAS server using a public IP address instead of private IP a

The outcome of this scenario is that the communication channel will implemented in a not – optimal way that could lead to – a 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).
  6. The Gateway, address the internal host using the Private IP address of the host (192.168.1.5 in our scenario).
    What will happened in case that we don’t use the Split DNS configuration -01
  1. The internal host (the Exchange CAS server) “answer” to the “host” that makes the connection attempt.
    Pay attention to the fact that from the internal Exchange CAS server point of view, the host who tries to contact him is the “inner leg” of the Firewall server.
  2. The firewall takes the “Exchange CAS server respond” and forward the “answer” to the internal mail client.
    What will happened in case that we don’t use the Split DNS configuration -02

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 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

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 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 hostname which includes the Active Directory private domain name.

Exchange CAS server know how to automatically register himself at the Active Directory SCP

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 which 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
  • 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 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”

Using an a Public name scheme for Exchange infrastructure - Exchange CAS server re – registration at the Active Directory SCP

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.

updating the Exchange CAS server web services URL address

As mentioned, the Exchange CAS server uses two separate interfaces for internal Exchange clients and 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 utilized by the internal Exchange client, and the external URL address is expected 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 configured by default with the private domain name, will be updated and will be set as identical to the external URL address that 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)
  • 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 besides 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 of the option that is available to 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.

Updating the Exchange CAS server web services URL address

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

Exchange OWA internal and external URL address 01

In a scenario of “single unified domain name scheme”, we would like to implement a configuration, in which the Exchange CAS server domain name 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

Exchange OWA internal and external URL address 02

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.

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 hostname – 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

In the following example, we will update the internal and the external URL address of the Exchange ActiveSync services using the “New” Exchange CAS server hostname –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

In the following example, we will update the internal and the external URL address of the Exchange OWA (webmail services) using the “New” Exchange CAS server hostname – 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

In the following example, we will update the internal and the external URL address of the Exchange ECP (Exchange control panel) using the “New” Exchange CAS server hostname – 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)

In the following example, we will update the internal and the external URL address of the Exchange OAB (Offline address book) using the “New” Exchange CAS server hostname – 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 separate 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 examine these advantages and disadvantages, I would like to summarize my mantra – after we “invest” the required resources for planning and creating the necessary Split DNS infrastructure, our life should be very easy and straightforward. 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 straightforward.

Building the required infrastructure for using the public domain naming scheme for Exchange infrastructure

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 separate hostnames for addressing Exchange server from internal network verses address Exchange from the external\public network.

2. Simplify the certificate host name management.

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 difficulties 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 the 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 underlying 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 add.

Implementing unified domain namespace for the Exchange infrastructure - Pros and cons

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
Article Name
Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
Description
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.
Author
Publisher Name
o365info.com
Publisher Logo

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

Your email address will not be published. Required fields are marked *