Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
The current article is the continuation of the previous article, in which we review the…
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 previous 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.
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.
In the previous 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.
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
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.
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.
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 possible 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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
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).
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 – 22.214.171.124
DNS server B “claim” that the IP address of a host named mail.o365info.com is – 126.96.36.199
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.
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 – 188.8.131.52, 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.
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
In the diagram, we can see the following information:
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
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.
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.
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?”
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”.
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.
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.
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
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.
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.
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:
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”
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.
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:
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.
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
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
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.
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
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"
As you already manage to understand, my opinion is that the preferred method or the most efficient or preferable method is – using a single namespace, meaning assigned to the public domain name scheme for the Exchange infrastructure instead of maintaining two separate name schemes (private and public).
In case that until this point you are not quite convinced, here is a quick review of the pros and cons of 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 are quite easy and straightforward.
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 vs. 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.
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.
This Post Has 0 Comments