microsoft connectivity analyzer (mca) | autodiscover troubleshooting tools | part 3#4 | part 23#36

of 20 | Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools

| Part 3#4 | Part 23#36

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

Microsoft Connectivity Analyzer (MCA)

| Autodiscover troubleshooting tools |

Part 3#4 | Part 23#36

The Microsoft Connectivity Analyzer (MCA) tool is the “installable client” or the

“software client” version of the ExRCA (Microsoft Remote Connectivity Analyzer

Tool) Autodiscover test.

The main purpose of using the Microsoft Connectivity Analyzer (MCA) tool versus

the Microsoft Remote Connectivity Analyzer web Tool is the ability to test the

Autodiscover process from inside the organization’s network or by testing the

Autodiscover process from a specific user desktop.

Autodiscover Troubleshooting tools | The article series

http://o365info.com/microsoft-connectivity-analyzer-mca-autodiscover-troubleshooting-tools-part-3-of-4-part-23-of-36


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

http://o365info.com/


| Part 3#4 | Part 23#36


The article series include the following articles:

1. Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools |

Part 1#4 | Part 21#36

2. Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting

tools | Part 2#4 | Part 22#36

3. Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools |

Part 3#4 | Part 23#36

4. Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part

24#36

ExRCA (Microsoft Remote Connectivity Analyzer Tool)

When using the ExRCA (Microsoft Remote Connectivity Analyzer Tool) web-based

tool, we are acutely using and external public server who uses for simulating the

Autodiscover flow.

In reality, the Autodiscover communication channel can be implemented from the

internal \ private organization network or from a public network.

The important issue is that the way that the Autodiscover channel is implemented

in a scenario of private organization’s network versus external \public network is

different because different components are involved in the Autodiscover process.

An additional important observation regarding the Microsoft Connectivity Analyzer

(MCA) toll is – that although this tool is installed on the user desktop, the Microsoft

Connectivity Analyzer (MCA) tool cannot use for checking or using the Autodiscover

method which is implemented in an Active Directory-based environment.

In other words, we cannot use the Microsoft Connectivity Analyzer (MCA) tool for

testing the Autodiscover LDAP method in which the Autodiscover client addresses

the local Active Directory.





http://o365info.com/outlook-test-e-mail-autoconfiguration-autodiscover-troubleshooting-tools-part-1-of-4-part-21-of-36

http://o365info.com/outlook-test-e-mail-autoconfiguration-autodiscover-troubleshooting-tools-part-1-of-4-part-21-of-36

http://o365info.com/microsoft-remote-connectivity-analyzer-exrca-autodiscover-troubleshooting-tools-part-2-of-4-part-22-of-36




http://o365info.com/using-fiddler-for-autodiscover-troubleshooting-scenarios-part-4-of-4-part-24-of-36

http://o365info.com/using-fiddler-for-autodiscover-troubleshooting-scenarios-part-4-of-4-part-24-of-36


| Part 3#4 | Part 23#36


MCA advantages and disadvantages

Advantages

The Microsoft Connectivity Analyzer (MCA) serves as an Autodiscover and

enables us to inspect and analyze the Autodiscover and Outlook Anywhere

flow with Outlook the need of installing a mail client such as Outlook.

The Microsoft Connectivity Analyzer (MCA) enables us to simulate the

Autodiscover process by executing the Autodiscover process from a specific

host and a specific network versus the ExRCA tool that is implemented by

using a Microsoft public server.

Disadvantages

The Microsoft Connectivity Analyzer (MCA) client cannot monitor and inspect

the Autodiscover in an Active Directory environment (the Autodiscover based

on the LDAP query, etc.).

The Microsoft Connectivity Analyzer (MCA) doesn’t include all the options that

include when using a tool such as the ExRCA.

The Microsoft Connectivity Analyzer (MCA) toll considers as a software that we

download + install versus the ExRCA tool that is a web-based tool.

Microsoft Connectivity Analyzer (MCA) versus ExRCA

(Microsoft Remote Connectivity Analyzer).






| Part 3#4 | Part 23#36


1. Software component versus web application

The most noticeable difference between the Microsoft Connectivity Analyzer (MCA)

and the ExRCA (Microsoft Remote Connectivity Analyzer) is that the MCA is a

software component which we need to install versus the ExRCA that is

implemented as a web application (Using the ExRCA is implemented by accessing

the ExRCA URL etc.).

2. Restricted number of “tests” options

An additional difference is that we can relate to the Microsoft Connectivity Analyzer

(MCA) as a “minimized version” or a limited version that offers only a restricted set

of “tests” compared to the option that are available when using the Remote

Connectivity Analyzer Tool.

3. User interface

The user interface of the Microsoft Connectivity Analyzer (MCA) is different from the

ExRCA (Microsoft Remote Connectivity Analyzer).

Versus the Microsoft Remote Connectivity Analyzer that is based on the concepts of

“tabs” and a list of optional tests that the user can choose from, the MCA (Microsoft

Connectivity Analyzer) interface is on a “wizard-based” interface.

The user chooses the description if the problem that he experiences and, based on

the “user section” the Microsoft Connectivity Analyzer (MCA) offers the most

appropriate test.

4. Integrated test implemented – Autodiscover + Outlook Anywhere.

As part of the simplified user interface, the MCA (Microsoft Connectivity Analyzer)

combines two separate tests into one.

When a user reports that he cannot create a new Outlook mail profile the problem

could be related to the Autodiscover infrastructure or to the Outlook Anywhere

sitting on the server side.

In the previous article (Microsoft Remote Connectivity Analyzer (ExRCA) |

Autodiscover troubleshooting tools | Part 2#4 | Part 22#36) we review the ExRCA

interface and the option of choosing a “dedicated” Autodiscover test.








| Part 3#4 | Part 23#36


Versus this option, the MCA (Microsoft Connectivity Analyzer wizard offers the user

to choose an option named – “I can’t log on with office Outlook”.

In case that the user selects this option, the MCA will perform two different tests at

the same time – the Autodiscover test + the Outlook Anywhere (RCP/HTTPS) test.

General notes about the MCA interface

My opinion or wish is that – the user interface should have designed differently and

provide an interface that is similar or even identical to the Remote Connectivity

Analyzer Tool.

I hope that in future, somebody will read what I have written and adapt my

recommendations (yes, I know that I live in a la la land; -))

Download and install the MCA (Microsoft Connectivity Analyzer)

software component.

Go to the -Microsoft Remote Connectivity Analyzer

(https://testconnectivity.microsoft.com/) site and, choose the Client tab and click on

the Install now option.

MCA – requirement for installation

The requirement for installation MCA (Microsoft Connectivity Analyzer) on a

desktop are:





https://testconnectivity.microsoft.com/


| Part 3#4 | Part 23#36


The tool supports the following operating systems: Windows Vista, Windows 7,

Windows Server 2008, Windows 8

Microsoft .NET Framework 4.5 is required

Using the MCA (Microsoft Connectivity Analyzer)

To demonstrate the use of the use of the MCA (Microsoft Connectivity Analyzer), we

will use the following scenario:

A user named John that uses the E-mail address – [email protected] , what to

create a new Outlook mail profile.

John desk is a domain joined and, John is located in the private company network.

Note – Don’t forget that the MCA (Microsoft Connectivity Analyzer) doesn’t know

how to use the Active Directory Autodiscover method and the MCA (Microsoft

Connectivity Analyzer) can only use the Autodiscover method that is implemented

in a non-Active Directory environment.

We would like to review the Autodiscover workflow that is implemented between

the Autodiscover client and the Autodiscover Endpoint.






| Part 3#4 | Part 23#36


Step 1- Choosing the required test

To be able to perform the Autodiscover test, we will need to choose the option – “I

can’t log on with office Outlook”.

Note – In case this option is selected the MCA will perform two tests at the same

time -the Autodiscover test + the Outlook Anywhere (RCP/HTTPS) test.

Step 2- Providing user credentials

In case that we use an Exchange on-Premises server infrastructure, most of the

time the authentication naming convention will be based on the “formula” of –

<Doman name>\<User name>






| Part 3#4 | Part 23#36


Step 3- viewing or saving the test results

After the test is completed, we can choose one of the following options:

Viewing the test results or saving the test results.






| Part 3#4 | Part 23#36


Analyzing the content of the test results

In the following screenshot, we can see that the test result completes successfully,

but it’s important to notice that the test was implemented by using two different

Exchange services:

1. Autodiscover infrastructure test

2. Outlook Anywhere infrastructure (RPC\HTTPS) test

In our scenario, we can see that both of this test were completed successfully.

The result’s screen is divided into two parts:

1. General summary of the test results (Part A in the screenshot)






| Part 3#4 | Part 23#36


2. A detailed report about each of the operations that was included in the test

(Part B in the screenshot)






| Part 3#4 | Part 23#36


The MCA (Microsoft Connectivity Analyzer) result is display based on the same

hierarchical concept that is used by the ExRCA tool.

The “top level” result can be “expanded” so we can see each of the “steps” that were

involved in a specific test and most of the time, we also have the ability to “expand”

each of the specific steps to get more detailed information.

Part B.1 – analyzing the Autodiscover test results

Step 1: Trying to connect the Autodiscover Endpoint host using the Root domain

name

In the following screenshot, we can see that the Autodiscover process in non-Active

Directory environment is implemented by using the recipient E-mail address,

domain name and then, using the domain name as a potential Autodiscover

Endpoint host name.






| Part 3#4 | Part 23#36


In our scenario, although the host manage to resolve the hostname to IP address,

when the Autodiscover client tries to verify if the potential Autodiscover Endpoint

can communicate using HTTPS, the test fails (number 1).

Step 2: Trying to connect the potential Autodiscover Endpoint using the

Autodiscover standard host name

In the following screenshot, we can see that the Autodiscover client “move on” to

the next host name option in which he will try to look for the potential Autodiscover

Endpoint using the naming convention: Autodiscover + recipient SMTP domain

name.

In our scenario, the potential Autodiscover Endpoint will be

– autodiscover.o365info.com

We can see that the steps of: Resolving the host name to IP and Verify the potential

Autodiscover Endpoint can communicate using HTTPS complete successfully

(number 2).






| Part 3#4 | Part 23#36


Looking at the details of the Autodiscover test

To be able to get more detailed information about the specific steps that was

implemented and a full description of the results for each if this step, all we need to

do is just double-click on the “expand icon” that appear to the left of the

Autodiscover method title

(attempting to test Potential Autodiscover URL

https://autodiscover.o365info.com/Autodiscover/autodiscer.xml)

In the following screenshot, we can see the “headers” of the five steps that were

implemented by the Autodiscover client

Step 1 – Attempting to resolve the host names autodiscover.o365info.com

Step 2 – testing TCP port 443






| Part 3#4 | Part 23#36


Step 3 – Testing the SSL certificate

Step 4 – Checking the IIS configuration for client certificate authentication

Step 5 – attempting to send an Autodiscover Post request to the Potential

Autodiscover URLs

The End of the Journey – the client gets the required Autodiscover.xml file

In the following screenshot, we can see that the Autodiscover client sends to the

Autodiscover Endpoint a request:

attempting to send an Autodiscover POST request to Potential Autodiscover URLs.






| Part 3#4 | Part 23#36


The Autodiscover Endpoint generates the required information and sends it to the

Autodiscover client. We can see that the content of the information includes the

data in an XML format.

The Autodiscover server response includes the URL address of the different

Exchange web services such as – Availability services, OOO and so on.

Part B.2 – analyzing the Outlook Anywhere test results

The next part of the MCA (Microsoft Connectivity Analyzer) result relates to the

Outlook Anywhere service (or the former name RPC/HTTPS).

In case that the mail client needs access from an external network, the

Autodiscover serves as infrastructure for the Outlook Anywhere services.

Only when the first part of the Autodiscover process will be successful completed,

then the “second part” of Outlook Anywhere can be also completed.






| Part 3#4 | Part 23#36


We will not go into a detailed review of the Outlook Anywhere service test results,

but it’s important to understand that the Outlook Anywhere includes a complete set

of “steps” that need to be implemented.

In case that we want to view a detail report of the Outlook Anywhere results, we

need to expand the required section.

In the following screenshot, we can see all the steps that are involved in an Outlook

Anywhere communication channel.

For example, we can see that the Outlook Anywhere client is “talking” with the

internal name of the Exchange On-Premise server, by using the host name

– exo1.o365info.lcoal (number 5).






| Part 3#4 | Part 23#36


The Outlook Anywhere “journey” is not finished it!

In following screenshot, we can see the “reset” of the steps that are implemented

by the Outlook Anywhere client.

For example, the Outlook Anywhere client will try to “RPC ping” the RPC Proxy

server. In our scenario, the RPC proxy server name is

– mail.o365info.com (number 6).






| Part 3#4 | Part 23#36


Saving the test results

In case that we want to save the report for additional analyses, we can save the

report to an HTML file.

In the report result choose the option of- save results.






| Part 3#4 | Part 23#36


In the HTML result file, we can see the report information.

The upper part includes a general summary and on the bottom part we can use,

the expand button to get a detailed overview about each of the steps that was

implemented.






| Part 3#4 | Part 23#36


Additional reading

Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote

Connectivity Analyzer (RCA) 2.1

What’s new with Microsoft Remote Connectivity Analyzer? A lot!

Video link

Microsoft Connectivity Analyzer Introduction





http://blogs.technet.com/b/exchange/archive/2013/03/11/announcing-microsoft-connectivity-analyzer-mca-1-0-and-microsoft-remote-connectivity-analyzer-rca-2-1.aspx

http://blogs.technet.com/b/exchange/archive/2013/03/11/announcing-microsoft-connectivity-analyzer-mca-1-0-and-microsoft-remote-connectivity-analyzer-rca-2-1.aspx

http://blogs.technet.com/b/exchange/archive/2012/11/19/what-s-new-with-microsoft-remote-connectivity-analyzer-a-lot.aspx

https://www.youtube.com/watch?v=RaXMWdUDyq8

microsoft connectivity analyzer (mca) | autodiscover troubleshooting tools | part 3#4 | part 23#36

Documents