The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36

of 27 | The basics of Domain name, FQDN and URL address | Exchange

infrastructure | Part 09#36

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

The basics of Domain name, FQDN and

URL address | Exchange infrastructure

|Part 09#36

The communication channel that between Exchange client and Exchange server is

based on a simple concept, in which Exchange client address the Exchange server

by using the Exchange host name or, if we want to be more accurate – the

Exchange server FQDN.

The variety of the services that are offered by Exchange server to his Exchange

client begging with Exchange web services and, ending with services for the

webmail client such as OWA, are implemented by the Exchange client that access

this Exchange service by using a URL address.

http://o365info.com/the-basics-of-domain-name-fqdn-and-url-address-exchange-infrastructure-part-09-of-36


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

http://o365info.com/




Regarding the relationships that exist between an Exchange server and Outlook

client, all of this information is packaged and shipped to an Outlook client via the

Autodiscover response that is provided by the Exchange server.

As mention in a former article, each public facing Exchange server has two

identities – the private versus the public identifies.

When Exchange provides information about the available Exchange web services,

the information is provided in two different “formats”:

Information relevant to internal Outlook client

Information relevant to external Outlook client

The main difference in the information that is provided for internal versus the

external Outlook client is the Exchange web services URL address.

The Information relevant for the internal Outlook client includes Exchange

web services URL address that uses the internal Exchange FQDN.

The Information relevant for external Outlook clients includes Exchange

web services URL address that uses the external Exchange FQDN.

URL address concept and Exchange web services

Although apparently, we are familiar with the concept of using a web address (URL),

I would like to devote the following section, to the subject the Autodiscover and URL

address because this subject is not as simple as it seems.

In our journey to become an “Autodiscover professional”, we need to be familiar

with

1. The structure of the Exchange web services URL address

2. The different part which consists the address web services URL address

3. The different URL address that Exchange provides for an internal mail client

versus external mail client.








Additionally, question that can appear could be:

1. How does the Exchange CAS server set the URL address for the web services?

2. Should we “Intervene” with the default settings of the Exchange web services

URL address?

3. What are the scenarios in which we need to implement this “Intervene”?

4. Are there any best practice for the URL address of the Exchange web services?

And as usual, there is no one simple answer for this question.

In the current article, we will focus on the “physical structure” of the Exchange web

services URL address.

The structure of URL address | High-level view

Let’s start with a very simple question:

Q. Do you know what URL stand for?

A: Well… I’m not going to bore you with academic discussions, but, for those of you

that did not know the answer, URL stand for -uniform resource locator.

Most of us, associatively link the term -” URL” with terms such as – browser, website

and so on.

A “browser” is just one example of a “client” that can consume web-based services.








In reality, there are many types of “clients” that can consume web-based services.

For example, Outlook is a client that heavily depends on the Exchange web services.

The structure of URL address

A URL address is like a puzzle, made up of many parts.

The “begging” of the URL address will “declare” the protocol (the language) in which

the client and the server will use. In Exchange based environment, the web services

are provided by using the HTTP protocol and the HTTPS protocol (the encrypted

version of the HTTP protocol).








The “middle part” of the URL address, include information about the host or the

“element” name that will provide the web service.

Most of the time, the naming conventions that we use for “pointing at” the host

who provide the specific web services is based on the FQDN (fully qualified domain

name) naming convention.

The “last part” or the “right part” of the URL address includes the path for the

specific web services. The “path” is not a mandatory part of the URL address.

We use the option of “path” in case that the specific host provided a couple of web

services, or we want to point the client for a specific folder or file.

For example, Exchange CAS server provides many types of web services. When

Exchange clients need a specific web service from the Exchange CAS server, the

Exchange clients will have to address the Exchange CAS server by using a URL that

includes the Exchange CAS server name + the path of the specific web service.








In this article, we will focus only in the “middle part” (the hostname or the FQDN

name) of the Exchange web services URL address because, in case that we need to

configure or adjust the URL address of a specific Exchange web service, we will

update or configure the part that relate to the Exchange host name.

The scenario in which we update the “path” part of the Exchange web services URL

address is very rare and not recommended.








Hostname versus FQDN name

A host name is a logical name whom we use to address a specific network

“element”.

We can define the term host name as a “single name” or a “one-word name”.

The term FQDN stands for – Fully Qualified Domain Name.

For me, the word FQDN always sounds strange.








The term – “Fully Qualified Domain Name” defines naming convention, but the term

FQDN relates to a “Full host name” verse the term -” Host” that rates with a single

hostname.

An FQDN is created by using the following formula:

To be able to understand better the difference between the term host name and

the term FQDN name, we can relate to a standard “human address”.








When we refer to somebody using the name – John, this is the equivalent of the

term host name. The name “John” couldn’t be considered as a unique identifier.

In case that we need to send a package to John, we will need to use an address that

will be unique identifier and will enable us to be sure that the package will be sent

to the required destination recipient.

In this case, we will use the “Full” or “complete” address of John that includes his

family name, street address, city and so on.

We can say that the “Full address” of John is identical to the scenario in which we

address a specific host by using his FQDN in the network environment.

Technically, in an internal network, we can address a specific “host” by using only

the host name but, most of the time, the preferred method to address “servers” or

hosts who provide services, is by using the FQDN of the host.

In a public network environment, the only way to address hosts is by using their

FQDN.

Domain name








A domain name is also a naming convention that is based on a specific structure.

A standard domain name is built from an organization name and the domain name

suffix.

Note – in reality, the term domain name is more complex than this simplified

description and can include additional part such as sub domains and much more.

Domain suffix

Every domain name has a suffix (like every bullet has an address). The domain

name could be classified as private or as public.

Private domain name suffix

A private domain name suffix, is based on non-public suffix (and yes, I know that

the sentence is not so clear).

In other words – a private domain name suffix cannot be published on the public

network. In case that we want to use a private domain name suffix, technically we

can invent any name whom we would like to.

For example, a passable option for a private domain name suffix could be blabla

and the full domain name could be – o365info.blabla








Public domain names suffix.

A public domain names suffix, is based on a public suffix.

In a case that we want to use a public domain name suffix, we will need to purchase

the domain name from a public provider and, there is a limited amount of public

domain name suffix that we can choose from.

Host with the public domain name suffix can be published and accessible by hosts

from external network (and also by hosts from the internal\private network).

In the following diagram, we can see an example of a domain name with a private

domain name suffix – o365info.lcoal

And additional example of a public domain name such as – o365info.com








Active Directory domain name

Every Active Directory, must have a domain name.

The Active Directory domain name is defended by the person that installs the first

DC server. Active Directory administrators can decide what type of domain to

choose as the Active Directory domain name suffix.

In case that the administrator prefers to use a private domain name for the Active

Directory, the common domain name suffix is – local

The domain name suffix local, is not published on the public network.

In the following diagram, we can see an example to the options that are available

for the Active Directory administrator.

The Active Directory administrator, can choose to use an “internal namespace” for

the Active Directory such as – o365info.lcoal or, “external namespace” such as

– o365info.com .

The “com” suffix is a public domain name suffix.








Active Directory domain name and Exchange

infrastructure

Exchange infrastructure is “Integrated” or “interwoven” into the Active Directory

infrastructure.

The exchange infrastructure cannot “live” outside the Active Directory or in other

words; the Active Directory serves as a platform for the Exchange infrastructure

and Exchange infrastructure is “bound” to the boundary of the Active Directory

forest.








Default FQDN of each Exchange server

The default FQDN of each Exchange server is built from the Exchange host name +

the local Active Directory domain name.

In case that we use a private domain name suffix for the Active Directory domain,

Exchange will “inherit” the Active Directory domain name and the result are that all

the Exchange servers FQDN’s will have the Active Directory private domain name

suffix.

Theoretically, there is no “harm” in this scenario, but the problem is realized

because of the different nature of the Active Directory infrastructure versus the

Exchange infrastructure.

When we relate to the Active Directory infrastructure, the basic assumption is that

we will never want\need to expose the Active Directory infrastructure to the public

network or enable the external host to access the internal Active Directory.








When relating to the Exchange infrastructure, the concept of “hiding” internal host

or prevent from external hosts accessing private hosts cannot be realized because

most of the time we will need to “expose” some of the Exchange server (Public

facing Exchange server) so external hosts such as external Exchange client will be

able to communicate with the Exchange server.

To be able to fulfil the requirement of – “publishing Exchange resources”, we will

need to use the public domain name for publishing the required host.

For example, external Exchange clients will address the Public facing Exchange CAS

server by using an FQDN such as – mail.o365info.com








The two identities of Public facing Exchange CAS server

In case that Exchange CAS server, is a “Public facing Exchange server” and the Active

Directory is based on a private domain name the outcome is-

The exchange CAS server will have two different “identities”.








1. Internal – “Active Directory” identity

2. Public identity

The term “identity” describes the FQDN that the Exchange CAS server will use.

When an Exchange client needs to address an Exchange CAS server, the

Exchange client will address the Exchange CAS server private or public identity

(FQDN).

When Exchange clients need to use a specific Exchange web service, the

Exchange client will use a URL address that includes the private or public

identity (FQDN) of the Exchange server who provides the specific Exchange

web service.

EXCHANGE WEB SERVICE AND URL ADDRESS

Exchange server, provide a variety of web services to his Exchange clients.








The way that the Exchange CAS server “expose” a specific Exchange web service is,

by using a URL address. In other words – Exchange clients access the Exchange web

service by using a URL address.

In this section, I would like to focus on a very specific part of the URL address that

we use for Exchange web services -the FQDN.

In the former section, we discuss a scenario in which the Active Directory is based

on a private domain name, and we also discuss the need for using an additional

domain name: a public domain name, which will be used by Public facing Exchange

server who needs to communicate with external Exchange clients.

In this scenario, we will need to implement a scenario that I describe as “two

different identities” that will be assigned to the Public facing Exchange server. The

external identity and internal identity.

Example 1 – Outlook client looking for Exchange CAS server

When the Outlook client tries to locate available Exchange CAS server, the following

process will be implemented.

An internal Outlook client (Outlook client located on the internal company

network), will address the Exchange CAS server by using his “private FQDN”.

An external Outlook client (Outlook client located on the internal company

network), will address the Exchange CAS server by using his “public FQDN”.

Example 2 – publishing information about the Exchange web service








When the Exchange CAS server replies to an Autodiscover request, the

Autodiscover responds will include two types of information about Exchange web

services:

Information for internal Autodiscover clients, which based on URL address

that includes the private FQDN of the Exchange server who provides the

specific Exchange web service.

Information for external Autodiscover clients, which based on URL address

that includes the public FQDN of the Exchange server who provides the

specific Exchange web service.

Exchange web services and URL address structure

Exchange server, provide a variety of web-based services. Each of the different

Exchange web services is “represented” by a dedicated URL address.

Despite that we use a dedicate URL of the different Exchange web services, the URL

address that we use is based on a basic structure that is used in all the Exchange

web services URL addresses.

A “standard” Exchange web service URL address will include four parts:








1. Protocol name

The first part of the URL address is the protocol name.

Exchange web services are implemented by using the HTTP or the HTTPS protocol.

Most of the time, the communication between Exchange server and his clients will

be implemented by using the HTTPS protocol.

Note – the exception in this role, is when an Exchange server provides a redirection

for the Autodiscover client by using the HTTP protocol (non-encrypted

communication).

2. FQDN name

The FQDN name is the “Full host name” that includes the host name + the domain

name.

In case that the Exchange server is not exposed to a public network, the Exchange

CAS server FQDN is built from the “true server name” (the server NetBIOS name) +

the internal Active Directory domain name.

In case that the Exchange CAS server is configured as a “Public facing Exchange

server”, the Exchange CAS server “exposed” himself by using a public FQDN and

additionally, can and will most of the time have a couple of FQDN names.

The need for more than one “public FQDN” depends on the services that the “Public

facing Exchange server” provides.

3. Folder name

For each of the web services that Exchange provides, there is a “dedicated virtual

folder.”

For example, the Autodiscover service of Exchange server is implemented by using

a dedicated folder named – Autodiscover.








When Exchange clients need to get a specific service, the Exchange client will need

to know and to use the URL address that includes a specific “folder name” that

represents the specific services that he needs.

Note – a specific web folder can serve for different Exchange web services. For

example – the EWS folder serves for the Exchange available service, Mail tips and

more.

4. The file name

The last part of the URL address, can include a file name. For example, In the

scenario of Autodiscover services, the URL address that the Autodiscover client use,

contain the name of the specific file that the client requests from the server.

Autodiscover client will request a file named – autodiscover.xml

Note – the need to include the file name in the URL address is a not mandatory

requirement the need for a file name is depended on the specific service that the

Exchange server provides.

Internal versus external Autodiscover URL address example

To be able to demonstrate the concept of “dual identity” of Exchange CAS server”

let’s review the Autodiscover URL address that is used by internal Exchange clients

versus the Autodiscover URL address that is used by external Exchange clients.

Scenario charters:

An organization uses a private domain name as the Active Directory domain name.

The Active Directory domain name is – o365info.lcoal

The organizing public domain name is – o365info.com

The Exchange CAS server name is – exo1








In a scenario, the Exchange CAS server serves internal Exchange clients and in

addition, serve public or external Exchange clients.

In the following diagram, we can see the base structure of the Autodiscover web

service URL address.

Autodiscover URL Address | internal Exchange clients

In our example, the Exchange CAS server will automatically register himself at the

SCP of the Active Directory, by using the following host name – ex01.o365info.local

If we want to be more accurate, the Exchange CAS server registers the Autodiscover

URL address in the SCP of the Active Directory by using the following URL:

https://ex01.o365info.local/autodiscover/autodiscover.xml

When the internal Outlook client starts the Autodiscover process, the Outlook client

will get from the On-Premise Active Directory the URL address of the Exchange

Autodiscover service and “extract” from the URL address the Exchange CAS server

host name – ex01.o365info.localand, query the internal DNS for this host name.

The DNS “answer” will include the internal\private IP address of the Exchange CAS

server.








Autodiscover URL Address | external Exchange clients

In our example, when an external mail client such as Outlook need to create a new

Outlook mail profile for [email protected] , Outlook “assume” that the

Autodiscover URL address is as

follow: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

To be able to connect the Public facing Exchange server, Outlook will “extract” the

FQDN name of the Exchange server from the public Autodiscover address.

In our scenario – autodiscover.o365info.com

Outlook client will address public DNS server and send a query looking for

information about the public IP address of this host.

Exchange dual identity | using identical or different

FQDN?

One of the most basic and important decision that we have as an Exchange

administrator is the decision about the Exchange namespace infrastructure.

Our basic assumption is that part of the Exchange infrastructure will be configured

as a Public facing and for this reason the Exchange will need to serve internal +

external Exchange clients.

In other words, Public facing Exchange server will have two different interfaces.








Option 1 – using a separated namespace

In this case, each of the Public facing Exchange servers will use a different

namespace for each of his “identities”.

To demonstrate this concept let’s use the following scenario:

The internal Active Directory domain name is – o365info.local

The organization public domain name is – o365info.com

For example

The “internal identity” of the Exchange server, will be represented by the host

name –ex01.o365info.local

The “external identity” of the Exchange server, will be represented by the host

name –mail.o365info.com and, autodiscover.o365info.com








An internal Exchange client that will need to address the Exchange server, looking

for Autodiscover infrastructure will address the Exchange server by using the host

name –ex01.o365info.local

An external Exchange client that will need to address the Exchange server, looking


name –autodiscover.o365info.com

Option 2 – using a unified namespace

In this case, we will use the identical namespace for each of the Exchange server

“identities”.

To demonstrate this concept let’s use the following scenario:

The internal Active Directory domain name is – o365info.local

The organization public domain name is – o365info.com

The main difference is that in this scenario we will not use, the local Active Directory

domain name as part of the Exchange host name.








In the scenario which I describe as a unified namespace, the Exchange server will

be “published” for internal + external Exchange client by using the public domain

namespace.

The “internal identity” of the Exchange server, will be represented by the host

names –mail.o365info.com and, autodiscover.o365info.com

The “external identity” of the Exchange server, will be represented by the host

names –mail.o365info.com and, autodiscover.o365info.com

An internal Exchange client that will need to address the Exchange server, looking



An external Exchange client that will need to address the Exchange server, looking



In the past, the “trend” was to emphasize the difference that exists between the

“internal Exchange environments” versus the “external Exchange environment”.








The reason for this trend was based on the assumption that using a separated

namespace is more secured because the “separation” protects the internal

Exchange infrastructure from unwanted access by external hosts.

My opinion is that the “logical separation” doesn’t really protect the internal

Exchange infrastructure because, in reality, the protection and the separation will

be implemented by different solutions.

Using the concept of separated namespace will make the life of the Exchange

administrator more complicated and confuse users.





The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36

Documents

Transcript of The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36