Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Page 1 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

The current article, is the continuation of the previous article , in which we will continue to review in details the Autodiscover journey in Exchange Hybrid based environment

Autodiscover flow in an Exchange Hybrid environment | The article series The current article is the last article in a series of three articles.

The additional articles in the series are:  

Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36 Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36

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

Page 2 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 16/30: redirect (HTTP 301/302) response The Autodiscover client is “programmed” to use an HTTP redirect request, in case that the potential Autodiscover Endpoint cannot communicate using HTTPS. In our example, because the potential Autodiscover Endpoint cannot communicate using HTPTS, the Autodiscover client will “draw back” and, try to communicate with the Autodiscover Endpoint using the HTTP protocol.

The Autodiscover client HTTP request will include requests for information about “other Autodiscover Endpoint” name that can provide the required information.

In our scenario, the Autodiscover client addresses the host – autodiscover.o365info2.mail.onmicrosoft.com The autodiscover.o365info2.mail.onmicrosoft.com host, is a special Office 365 component, which serve as a “logical router”, that is responsible for redirecting Autodiscover clients to an additional nodes or elements (Autodiscover Endpoints), that can help the Autodiscover client to reach his final destination.

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

Page 3 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In our scenario, the HTTP redirect message that the Autodiscover Endpoint provide to his Autodiscover client, include the URL address of a Potential Autodiscover Endpoint named – autodiscover-s.outlook.com

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

Page 4 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In the following diagram, we can see the specific Autodiscover phase in which the Autodiscover client is redirected to the “next hop” – autodiscover-s.outlook.com

Step 16/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following informationThe Autodiscover Endpoint reply, using a redirection message code (HTTP 301/302) and provide to the Autodiscover client the “full URL” address of the destination

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

Page 5 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Autodiscover Endpoint – https://autodiscovers.outlook.com/Autodiscover/Autodiscover.xml The Microsoft Connectivity Analyzer is checking the host autodiscover.o365info2.mail.onmicrosoft.com for an HTTP redirect to the Autodiscover service. The redirect (HTTP 301/302) response was received successfully. Redirect URL: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

Step 17/30: Attempting to resolve the hostname autodiscovers.outlook.com Autodiscover client query the DNS server for the IP address of the host – autodiscover-s.outlook.com Before we continue, it’s important to stop for a minute and ask ourselvesQ1: Who is, or what is, the host autodiscover-s.outlook.com?

A1: The host named – autodiscover-s.outlook.com, is an additional Office 365 component that serves also as a “logical router.

Q1: If the autodiscover-s.outlook.com, considers also as a logical router, what is the difference from the former HTTP redirect mechanism?

A2: The former process was based on the HTTP protocol and the current redirection process is based on HTTPS redirect mechanism.

Q3: So… what is the big difference between HTTP versus HTTPS redirection?

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

Page 6 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

A3: The difference is that when using the HTTPS redirection method, the Autodiscover client will need to verify the Autodiscover Endpoint certificate so he will be able to “believe” him, The “redirect game”, is a very interesting concept that is implemented in the Office 365 cloud environment.

In a “standard” Exchange on-Premises environment, that Autodiscover client that communicates with his Exchange server, expects from the server to provide an SSL certificate that includes the FQDN of the Autodiscover Endpoint or the domain name (in case that the server use wildcard certificate).

For example, in our scenario, the Autodiscover client will use Alice E-mail address, domain name and when the Autodiscover client will start the HTTPS session with the Exchange server, the Autodiscover client will look at the server certificate looking for the hostname –autodiscover.o365info.com or for the domain name – o365info.com In case that the server certificate will not include the specified name, the Autodiscover client is “obliged” to stop the communication process and, move on to another method or display an error message.

In the Office 365 cloud environment, the interesting fact is that there is no “real” Exchange server that have a public certificate that include the “required hostname” such as – autodiscover.o365info.com In reality, there is no option to purchase a dedicated public certificate for each of the Office 365 tenants.

In this case, theoretically, the Autodiscover process should fail.

The solution for this “enigma” is – a process is which the Autodiscover client will be “instructed” to communicate with “other” Autodiscover Endpoint, that have a different host name from the “original host name” that the Autodiscover client try to use.

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

Page 7 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

If you are a suspicious fellow, a paranoid thought could appear in your mind – if the Autodiscover client looks for a very specific host name (such as autodiscover.o365info.com in our scenario) and the “cloud” redirect the Autodiscover client to other Autodiscover Endpoint hostname such as – autodiscover-s.outlook.com , how can we know that this is not a fraud or a conspiracy that could lead the “Autodiscover client” to un-trusted elements?

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

Page 8 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

The answer to this “fears” is that the Autodiscover Endpoint which the Autodiscover client is “redirected to” (the autodiscover-s.outlook.com) will have to prove his identity and to the fact that he is trustworthy, by providing a public certificate.

The Autodiscover Endpoint – autodiscover-s.outlook.com have a public certificate that includes all of the required “parts” that will be verified by the Autodiscover client.

Only after all of the “certificate parts” will be tested and verified by the Autodiscover client, then the Autodiscover client will be able to “believe” that the host – autodiscover-s.outlook.com is a reliable source of information.

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

Page 9 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In the next sections, we will see that the autodiscover-s.outlook.com is not the last hope in our Autodiscover journey, but for now, let’s carry on with the description of the Autodiscover steps.

The Autodiscover client query the DNS server for the IP address of the host – autodiscover-s.outlook.com The DNS answer includes a range of IP address because, in reality, Office 365 infrastructure is a couple of “nodes” or “hosts” that “play the role” of the autodiscover-s.outlook.com host.

Step 17/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: Attempting to resolve the host name autodiscover-s.outlook.com in DNS. The host name resolved successfully. IP addresses returned: 157.56.241.102, 157.56.245.166, 157.56.232.166, 157.56.245.70, 157.56.236.214, 157.56.236.6.

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

Page 10 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 18/30: Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it’s listening and open The Autodiscover client will try to verify if the autodiscover-s.outlook.com , supports an HTTPS communication.

In our scenario, the test completes successfully meaning that autodiscovers.outlook.com support HTTPS communication.

Note – in case that you are wondering about the name of the host – “autodiscovers”, I could not find any formal explanation for the “S” in the host name but my belief is that the “S” stand for security.

Step 18/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: Autodiscover client checks if the destination host can communicate using port 443 (HTTPS).

The results of the “HTTPS test” is -success.

Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it’s listening and open. The port was opened successfully.

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

Page 11 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 19/30: Attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com The Autodiscover client, ask from the Autodiscover Endpoint (autodiscovers.outlook.com) to prove his identity by providing a valid public certificate.

Step 19/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information:   

The Autodiscover client request from the Autodiscover Endpoint to send him his certificate.

The Autodiscover Endpoint sends his certificate.

The certificate was successfully accepted by the Autodiscover client.

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

Page 12 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com on port 443. The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.

Remote Certificate Subject: CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US, Issuer: CN=Microsoft IT SSL SHA2, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US. In the information details, we can see that the certificate “belong” to the Microsoft Corporation (OU=Microsoft Corporation) and, that the certificate include the domain name -outlook.com (Remote Certificate Subject: CN=outlook.com).

Step 20/30: Testing the autodiscover-s.outlook.com SSL certificate to make sure it’s valid The certificate validation test which the Autodiscover client performs, includes three distinct different parts.

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

Page 13 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

1. Validating the certificate name The Autodiscover client, address the potential Autodiscover Endpoint using the host name –autodiscover-s.outlook.com To be able to know that this is the valid or reliable source of information, the Autodiscover client will check if the certificate includes the specified host name – autodiscover-s.outlook.com or the domain name – *.outlook.com in a scenario of wildcard certificate.

2. Validating the certificate trust The public certificate that the server provide was provided by a CA (certificate authority). The Autodiscover client will need also to validate the CA certificate that provides the server his certificate.

3. Verify that the certificate date is valid The Autodiscover client will need to verify that the server certificate date is valid

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

Page 14 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Note – In case that you want to read more detailed information about the subject of Autodiscover, security mechanism and certificates, read the article: Autodiscover process and Exchange security infrastructure | Part 20#36

Step 20/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: 1. Validating the certificate name The Autodiscover client, verify that the server certificate includes the server FQDN or the server domain name.

Validating the certificate name. The certificate name was validated successfully.

Host name autodiscover-s.outlook.com was found in the Certificate Subject Alternative Name entry.

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

Page 15 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

2. Validating the certificate trust  

The Autodiscover client verifies the trust chain that appears in the server certificate.

The Autodiscover client successfully manages to verify the trust chain.

Certificate trust is being validated. The certificate is trusted and all certificates are present in the chain. The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US.

3. Verify that the certificate date is valid.

The Autodiscover client verifies that the server certificate is still valid and was not expired.

In our example, the test complete successfully meaning the server certificate is valid.

Testing the certificate date to confirm the certificate is valid. Date validation passed.

The certificate hasn’t expired. The certificate is valid.

NotBefore = 2/18/2014 11:41:01 PM, NotAfter = 2/18/2016 11:41:01 PM

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

Page 16 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 21/30: Checking the IIS configuration for client certificate authentication The Autodiscover client, verify if the destination host (the Autodiscover Endpoint) needs a client certificate. A client certificate, is a method in which the client can be proof his identity.

Step 21/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see that.  

The Autodiscover client asks the server if a client certificate is required.

The server replies that he doesn’t need a client side certificate.

Checking the IIS configuration for client certificate authentication. Client certificate authentication wasn’t detected. Accept/Require Client Certificates isn’t configured.

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

Page 17 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 22/30: Providing user credentials to the Autodiscover Endpoint After the certificate validation, test was successfully completed and the Autodiscover client can “trust” the destination host, the Autodiscover client will also need to proof his identity.

The Autodiscover client will identify himself by providing a user’s credentials” (user name + password).

Step 22/30: Analyzing the data from the ExRCA connectivity test

Note – the part of “providing user credentials“, doesn’t appear in the Microsoft Remote Connectivity Analyzer result page.

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

Page 18 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 23/30: Attempting to send an Autodiscover POST request to autodiscover-s.outlook.com The Autodiscover client will attempt to send an Autodiscover POST request to the Autodiscover Endpoint for, getting the required Autodiscover information.

The host named – autodiscover-s.outlook.com is not the last node in our Autodiscover journey but instead, “additional router” that will route the Autodiscover Endpoint to his final destination – his Exchange server.

The redirection is implemented by using an additional – “HTTPS redirection”.

The Autodiscover client “trust” the host autodiscover-s.outlook.com but, the autodiscover-s.outlook.com is not the “expected Exchange CAS server”.

In our specific scenario, autodiscover-s.outlook.com send an HTTPS redirection message that includes the following URL address – https://pod51049.outlook.com/Autodiscover/Autodiscover.xml The Autodiscover client will “extract” from this URL address the host name – Pod51049.outlook.com and in the next step, we will see the process in which the Autodiscover Endpoint tries to communicate with this host for completing the Autodiscover process.

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

Page 19 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In the following diagram, we can see the phase in which we are located in our Autodiscover journey

Step 23/30: Analyzing the data from the ExRCA connectivity test

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

Page 20 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user Alice@o365info2.mail.onmicrosoft.com. The Autodiscover XML response was successfully retrieved. An HTTPS redirect was received in response to the Autodiscover request. The redirect URL is https://pod51049.outlook.com/Autodiscover/Autodiscover.xml.

Step 24/30: Attempting to resolve the host name pod51049.outlook.com The Autodiscover client creates a DNS query looking for the host named- Pod51049.outlook.com From the DNS server answer, we can see that the resolution for this specified host name (Pod51049.outlook.com) include a range of IP addresses.

Despite the logical assumption that the host – Pod51049.outlook.com is a single server, in reality, the host “Pod51049.outlook.com” represent many “units” of Office 365 Exchange server who serve Office 365 clients requests.

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

Page 21 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 24/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the range of the IP4 and the IP6 address that are mapped to the specified host name.

Attempting to resolve the host name pod51049.outlook.com in DNS. The host name resolved successfully. IP addresses returned: 157.56.250.66, 157.56.254.178, 132.245.229.146, 132.245.226.34, 157.56.251.217, 157.56.255.60, 132.245.210.9, 132.245.212.98, 2a01:111:f400:9434::2, 2a01:111:f400:9850::2, 2a01:111:f400:8000::9, 2a01:111:f400:9428::2, 2a01:111:f400:9800::12, 2a01:111:f400:882a::2, 2a01:111:f400:803c::2, 2a01:111:f400:9814::9

Step 25/30: Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and open.

The Autodiscover client, will try to verify if the host named – Pod51049.outlook.comAutodiscover Endpoint, support an HTTPS communication.

In our scenario, the test complete successfully meaning that, Pod51049.outlook.com support HTTPS communication.

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

Page 22 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 25/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: The Autodiscover client tries to verify if the “destination host” support the HTTPS protocol and the answer is “yes”.

Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and open. The port was opened successfully.

Step 26/30: Asking from the potential Autodiscover Endpoint to provide a public server certificate Autodiscover client, ask from the Autodiscover Endpoint (Pod51049.outlook.com) to proof his identity by providing a valid public certificate.

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

Page 23 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 26/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server pod51049.outlook.com on port 443. The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.

Remote Certificate Subject: CN=outlook.com, OU=Exchange, O=Microsoft Corporation, L=Redmond, S=Washington, C=US, Issuer: CN=Microsoft IT SSL SHA1, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US.

Step 27/30: Testing the pod51049.outlook.com SSL certificate to make sure it’s valid.

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

Page 24 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

The certificate validation test which the Autodiscover client performs, includes three distinct different parts.

1. Validating the certificate name The Autodiscover client address the potential Autodiscover Endpoint using the host named –Pod51049.outlook.com To be able to know that this is the “real host”, Autodiscover client will check if the certificate includes the specified host name (Pod51049.outlook.com) or, the domain name – *.outlook.com 2. Validating the certificate trust The public certificate that the server provides, was provided by a CA (certificate authority). The Autodiscover client will need to validate also the CA certificate that provides the server hos certificate.

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

Page 25 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

3. Verify that the certificate date is valid.

The Autodiscover client will need to verify that the server certificate date is valid.

Note – In case that you want to read more detailed information about the subject of Autodiscover, security mechanism and certificates, read the article: Autodiscover process and Exchange security infrastructure | Part 20#36

Step 27/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: 1. Validating the certificate name The Autodiscover client, verify that the server certificate includes the server FQDN or the server domain name.

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

Page 26 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Validating the certificate name. The certificate name was validated successfully.

Host name pod51049.outlook.com was found in the Certificate Subject Alternative Name entry.

2. Validating the certificate trust The Autodiscover client verifies the trust chain that appears in the server certificate.  The Autodiscover client successfully manages to verify the trust chain.

Certificate trust is being validated. The certificate is trusted, and all certificates are present in the chain. The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=outlook.com, OU=Exchange, O=Microsoft Corporation, L=Redmond, S=Washington, C=US. One or more certificate chains were constructed successfully 

3. Verify that the certificate date is valid.

The Autodiscover client verifies that the server certificate is still valid and was not expired.

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

Page 27 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In our example, the test complete successfully meaning the server certificate is valid.

Testing the certificate date to confirm the certificate is valid. Date validation passed.

The certificate hasn’t expired. The certificate is valid.

NotBefore = 7/24/2014 6:34:15 PM, NotAfter = 7/23/2016 6:34:15 PM

Step 28/30: Checking the IIS configuration for client certificate authentication The Autodiscover client, verify if the destination host (the Autodiscover Endpoint) need a client certificate. A client certificate, is method in which the client can proof his identity.

Step 28/30: Analyzing the data from the ExRCA connectivity test In the Microsoft Remote Connectivity Analyzer result page, we can see that

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

Page 28 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

The Autodiscover client asks the server if a client certificate is required.  The server replies that he doesn’t need a client side certificate.

Checking the IIS configuration for client certificate authentication. Client certificate authentication wasn’t detected. Accept/Require Client Certificates isn’t configured. 

Step 29/30: Providing user credentials to the Autodiscover Endpoint After the certificate validation, test was successfully completed and the Autodiscover client can “trust” the destination host, the Autodiscover client will also need to proof his identity.

The Autodiscover client will identify himself by providing a user’s credentials” (user name + password).

Step 29/30: Analyzing the data from the ExRCA connectivity test Note – the part of “providing user credentials“, doesn’t appear in the Microsoft Remote Connectivity Analyzer result page.

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

Page 29 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

Step 30/30: Attempting to send an Autodiscover POST request to potential Autodiscover URL: https://pod51049.outlook.com/autodiscover/autodiscover.xml This is the last stop on Outlook Autodiscover journey in the Hybrid environment.

Outlook or the “Autodiscover client”, fined his Exchange CAS server.

In this phases all the “pre requirements tasks” have already successfully completedAutodiscover manage to verify the Autodiscover Endpoint identity and provides his identity to the Autodiscover Endpoint.

The last step, is the step in which the Autodiscover Endpoint (Exchange CAS server named –Pod51049.outlook.com) will generate and send the Autodiscover response to our Autodiscover client.

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

Page 30 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In our scenario, the “client” is an Outlook client that will use the information in the Autodiscover response for two main purposes: 1. Creating a new Outlook mail profile The “declared mission” in our scenario was to enable Alice to create a new Outlook mail profile.

The information that included in the Autodiscover response, will include all the required information that is needed for creating a new Outlook mail profile using the Outlook Anywhere settings.

2. Using the URL address of the Exchange web services After the task of creating new Outlook mail profile is completed, Outlook will us the URL address of the different Exchange web services that was included in the Autodiscover answer, each time that Outlook will need a specific Exchange to serve such as availability services (Free/Busy time), OAB (Offline address book) and so on.

Step 30/30: Analyzing the data from the ExRCA conne ctivity test The Exchange CAS server Autodiscover responds is implemented as an XML file that includes tons of “information lines” (XML Tags).

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

Page 31 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

We will not get into a detailed review of each of this “information bank line” but instead, review just a small sample of the Autodiscover respond content.

In the Microsoft Remote Connectivity Analyzer result page, we can see the following information: The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml for user Alice@o365info2.mail.onmicrosoft.com.

The Autodiscover XML response was successfully retrieved.

The information in the Exchange Autodiscover response is dived into section.

The purpose of these sections is – to provide a different information for a different mail profile of Outlook clients.

Exchange relates to the “different Outlook mail profile” as Outlook providers.

The different type classified as EXCH, EXPR, WEB and EXHTTP EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings.

In the following screenshot, we can see an example for the XML tag’s names and the information that included between these XML tags.

For example: 1. Outlook GUID\session ID

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

Page 32 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In an Exchange 2013 environment, the Outlook client doesn’t use the name of the Exchange CAS server but instead, use a unique session ID. The value of the unique session ID is provided by using the <Server> XML tag. <Server>61b3c3e6-97ba-4714-bcbb-d45efe969e56@o365info.com</Server> 2. Availability services (Free/busy time) Each time that a user accesses his calendar and, ask to view the Free/busy time of other users, the Outlook client will send a query to the Exchange web service’s URL address that is dedicated to this purpose. <ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl> 3. Automatic reply (Out of office) The Exchange Automatic reply web services, enable Exchange clients, to respond with an Automatic reply when a recipient sent mail to their mailbox.

In case that the Exchange client need to create an Automatic reply respond, the client will use the following URL address: <OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl> 4. Offline address book The default setting for Outlook mail profile is Cache mode. When using the option of cache mode, Outlook client will download an “off line” version of the Exchange address book.

Outlook will need to know the exact URL address that he will need to use for downloading the Offline address book + the name of the offline address book file or file version. <OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be536ccebb70c82a/</OABUrl>

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

Page 33 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

In the next screenshot, we can see the setting under the EXPR section (the setting for an External Outlook Anywhere).

Here we can see additional details that are relevant or unique only when using the Outlook Anywhere profile.

We can see that under the “EXPR profile” (<Type>EXPR</Type>) we can see a similar setting such as the Exchange web services URL address: <Server>outlook.office365.com</Server> <ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl> <OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl> <OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be536ccebb70c82a/</OABUrl> And additionally, a specific setting that are unlike for Outlook Anywhere such as the authentication and encryption requirements.

In our example, the Autodiscover responds “inform” the Outlook client that 1. The name of the Exchange CAS server The name of the Exchange CAS server who server that provides the Outlook Anywhere services (RPC Proxy) is – outlook.office365.com

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

Page 34 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36

<Server>outlook.office365.com</Server> 2. Encryption requirement The communication channel between the Outlook client and the Exchange server muse be implemented using HTTPS and the authentication protocol is – Basic <SSL>On</SSL><AuthPackage>Basic</AuthPackage> 3. The RPC\HTTPS hostname provider and the public certificate To be able to verify that the Exchange server is “reliable” and can be trusted, the Outlook client will check if the server certificate includes the value that described in the msstd. <CertPrincipalName>msstd:outlook.com</CertPrincipalName>;

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