Outlook client protocol connectivity flow in an internal network environment | Part 12#36

Page 1 of 13 | Outlook client protocol connectivity flow in an internal network environment

| Part 12#36

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

Outlook client protocol connectivity

flow in an internal network

environment | Part 12#36

n the current article, we will review the basic concepts of the Autodiscover flow,

which is implemented by internal Outlook clients.

The term “internal”, relate to a private network environment that have On-Premise

Active Directory.

Getting Autodiscover information

http://o365info.com/outlook-client-protocol-connectivity-flow-in-an-internal-network-environment-part-12-of-36


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

http://o365info.com/


| Part 12#36


The first part of the Autodiscover process is implemented by the phase in which the

Autodiscover client locates an available Autodiscover Endpoint that could provide

him the required Autodiscover information.

One of the most interesting things about the Autodiscover protocol is that the

phase of locating available Autodiscover Endpoint is implemented in a completely

different way by the internal Outlook client that are located in a private

organization network and have to the On-Premise Active Directory versus external

Outlook client that doesn’t have access to On-Premise Active Directory.

Note – in next article – Exchange clients and their Public facing Exchange server |

Part 13#3613#36, will describe that Autodiscover process that is implemented by

external Outlook clients.





http://o365info.com/exchange-clients-and-their-public-facing-exchange-server-part-13-of-36

http://o365info.com/exchange-clients-and-their-public-facing-exchange-server-part-13-of-36


| Part 12#36


Scenario character’s description

To be able to demonstrate the Autodiscover flow Active Directory-based

environment, we will use a scenario with the following characters:

The charters of the Exchange environment in our scenario are as follows:

Active directory internal domain name – o365info.local

Public domain name – o365info.com

The E-mail address of the organization users is based on the mail suffix –

o365info.com

Exchange\Active directory sites -the organization has two Exchange\Active

Directory sites: New York Site and Los Angles Site (the New York site, is the

headquarters of the company).

The name of the Exchange CAS server in New York Site is – exo1.o365info.local

The name of the Exchange CAS server in Los Angles Site is – exo2.o365info.local

John is an organization’s user, whom his mailbox is hosted on the New York

Exchange Site.

Alice is an organization’s user, whom his mailbox is hosted on the Los Angles

Exchange Site.






| Part 12#36


General notes

The description of the Exchange workflow in the internal network that will be

provided in the next scenarios is a “simplified description” or a real flow.

I have dropped some of the “client\server processes” to make the information more

digestible because, I would like to focus on the subject of the “Exchange internal

FQDN and URL’s address.

Scenario 1: mail client needs access to his mailbox.

John’s mailbox is hosted at the New York site.

John is located on the internal company network and needs access to his mailbox.






| Part 12#36


Step 0 – the registration of available Autodiscover Endpoint in On-Premise

Active Directory

By default, each Exchange CAS server will automatically register himself in the

Active Directory SCP by using his internal hostname.

In some scenario, we will need to change this default behavior.

You can read more information about a scenario in which we will need to update

the Exchange CAS server hostname who is registered in the Active Directory in the

following article – xxx

In our specific scenario, the organization uses two Exchange CAS servers who

automatically registered themselves in the Active Directory SCP (number 0).






| Part 12#36


Step 1: Mail client Autodiscover process

In an On-Premise Active Directory environment, the first phase of the Autodiscover

process is implemented by a query to the local Active Directory (LDAP query).

The “answer” from the Active Directory will include the “internal FQDN name” of the

Exchange CAS server – exo1.o365info.local (number 1).

Note that the Active Directory includes information about two available Exchange

CAS servers. In case that we didn’t update the information in the On-Premise Active

Directory SCP regarding the “physical location” (the Active Directory site name) of

the Exchange CAS server, the Autodiscover client that gets the list of servers doesn’t

have a specific Preference.

The Autodiscover will randomly pick one of the host names who appears in the list.

In our scenario, the mail client will try the address the hostname

– exo1.o365info.local

Step 2: addressing the internal Exchange CAS server

The Autodiscover client initiates a connection attempts to the internal Exchange

CAS server (exo1.o365info.local) by using the HTTPS protocol.

The Autodiscover client will ask for the server to prove his identity by providing a

public certificate (number 2).

Step 3 – Verify the Exchange server public certificate

The Autodiscover client will verify that the server certificate includes the FQDN –

exo1.o365info.local

Step 4 – Autodiscover clients provide user credentials

In case that the mail Autodiscover verifies that the Exchange certificate is “OK”, the

Autodiscover client will need to provide user credentials to the Autodiscover

Endpoint meaning the Exchange CAS server (number 4).

Step 5 – asking from the Exchange server to provide the autodiscover.xml file

The mail client will ask from Exchange server to provide him the required

autodiscover.xml file. The exchange provides the Autodiscover client the

autodiscover.xml file, meaning the Autodiscover response (number 5).






| Part 12#36


In the following screenshot, we can see a small example from the content of the

autodiscover.xml file.

Exchange EWS services – we can see that the URL address of the Exchange EWS

services is provided by using the hostname – exo1.o365info.local

Exchange ECP – the URL address of the Exchange control panel (the web address

that is used by a webmail client to configure user settings) includes the hostname

– exo1.o365info.local

Scenario 2: internal mail client that needs to access mailbox

data that is hosted on a different Exchange\Active Directory site.

The following scenario describes an Exchange environment that includes two

different Exchange\Active directory sites.

In our scenario, John (mail client from the New York site), need to get information

about the Free\Busy time of Alice, mail recipient who is physically located at a

different Exchange\Active directory site – Los Angles site.






| Part 12#36


Step 1 – internal mail client submits a request for Free\busy information.

Lest assume that John was already successfully managed to connect his Exchange

CAS server. The process begins, at the stage in which John “submit a request” to

Free\Busy information to his Exchange CAS server (number 1).

Step 2 – Exchange verifies the location of the destination recipient.

John Exchange CAS server (exo1.o365info.local) accept John’s request and start a

process sin which he will find the Exchange server that host the destination

recipient mailbox.

“John Exchange CAS server”, doesn’t know where Alice’s mailbox is located.

To be able to find this information, the “New York Exchange CAS server” query the

local Active Directory for information about the location of Alice’s mailbox.

The answer from the Active Directory, includes the host name

– exo2.o365info.local (number 2).

Step 3 – New York Exchange CAS servers submit a request for Free\busy

information.






| Part 12#36


exo1.o365info.local create a communication channel to the “Los Angles Exchange

CAS server (exo2.o365info.local) and ask for information about Alice Free\Busy time

information (number3).

Step 4 – Los Angles Exchange CAS server sends the required information.

The Los Angles Exchange CAS server, send back the required information to the

New York Exchange CAS server (number 4).

Step 5 – John’s Exchange CAS server provide John the required information.

John’s Exchange CAS server, populate the “results” in John’s calendar (number 5).

Scenario 3: implementing load balancing and High availability of

Exchange CAS servers

The third scenario is suitable for mid and enterprise companies that use multiple

Exchange CAS servers for providing a solution to the business need of load

balancing between Exchange CAS servers.

The purpose of the current section is not to provide a detailed explanation about

the architecture of Exchange for implementing load balancing between Exchange

CAS servers, but instead just to provide a small glimpse this subject in the context

of registering the Autodiscover Endpoint in Active Directory.

In an Exchange 2010 based environment, the need for implementing a

solution for load balancing and High availability of Exchange CAS servers is

implemented by using a concept of RPC Client Access Array and most of the

time; a hardware loads balancer.

In an Exchange 2013 based environment, the need for implementing a

solution for load balancing and High availability of Exchange CAS servers is

implemented in a simpler way without the need for building RPC Client Access

Array





Page 10 of 13 | Outlook client protocol connectivity flow in an internal network



The main point when we are implementing load balancing and high availability of

Exchange CAS servers, the main idea is that this information is “hidden” from the

Exchange client.

The Exchange client should “see” one entity that is represented by a logical name.

The logical name is “translated” to host name and IP address of two or more

Exchange CAS servers.

Note – The term “Exchange CAS array” is wide term and, we can say much about it,

but at this time, our main concern is the subject if the Exchange FQDN and URL

address when using this option.

To demonstrate the Autodiscover characters in an Exchange environment that use

load balancing and High availability of Exchange CAS servers, we will describe an

Exchange 2010 based environment.

There are a couple of ways to implement a solution of the Exchange CAS array.

In our scenario, we use a load balancer that will “represent” two Exchange CAS

servers.

From the mail client point of view, there are “only one Exchange CAS server” and

the mail client doesn’t know that they are “talking” to a load balancer instead of the

Exchange CAS server.

Scenario description

The organization decides to add additional Exchange CAS server to the New York

Exchange\Active Directory site for solving problems of load and performance of the

existing Exchange CAS server- exo1.o365info.local

The host name of the “new Exchange CAS server” is – exo2.o365info.local








To be able to optimize the Exchange CAS server level of services, the two separated

Exchange CAS servers will be configured as members in an Exchange CAS array.

The logical name who will be allocated to the Exchange CAS array is

– cas.o365info.local

To be able to implement the Exchange CAS array configuration using the additional

component of the load balancer, we will need to implement the following

operations:

1. Remove the information from the Active Directory SCP about the New York

Exchange CAS servers.

We will need to “Delete\Remove” the information from the Active Directory SCP

about the “real names” of the existing two Exchange CAS servers

(exo1.o365info.local and exo2.o365info.local). The purpose of this step is to prevent








from Exchange CAS server client to “know” about the “real name” of each of the

existing Exchange CAS servers (number 1).

2. Register the “logical name” of the load balancer.

The Exchange CAS Array will be represented to the mail client by using a “logical

name” that will be “attached” to the load balancer.

In our example, the load balancer FQDN will be – cas.o365info.local (number 2).

3. Internal mail client asks for information about their Exchange CAS server.

From this day forwards, each time that a mail client (Autodiscover client) will query

the Active Directory about information for existing Exchange CAS server\s, the

Active Directory “answer” will include the name of the “Exchange CAS server”

– cas.o365info.local (number 3).

4. Internal mail client access to their Exchange CAS server

The internal mail client will try to connect the “Exchange CAS server” using the

FQDN-cas.o365info.local (number 4).

5. Load balancer forward the request to the Exchange CAS array members.

The Load balancer (cas.o365info.local) will accept the mail client requests and

“forward” the mail client request to one of the “real Exchange CAS servers”












Documents

Outlook client protocol connectivity flow in an internal network environment | Part 12#36