Microsoft remote connectivity analyzer (ex rca) autodiscover troubleshooting tools part 2#4 part 22#36

of 37 | Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover
troubleshooting tools | Part 2#4 | Part 22#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Microsoft Remote Connectivity Analyzer
(ExRCA) | Autodiscover troubleshooting
tools | Part 2#4 | Part 22#36
In the current article, we will learn to know the ExRCA also known as Microsoft
Connectivity Analyzer web-based tool, that serves as the name implies for testing
and analyzing information that is related to “relationships” of different Exchange
clients with their Exchange server.

Autodiscover Troubleshooting tools | The article series
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
Microsoft Remote Connectivity Analyzer (ExRCA)
Q: What is the purpose of the – Microsoft Remote Connectivity Analyzer (ExRCA)?
A: The Microsoft Connectivity Analyzer is Actually a “collection of web-based tools”
that enable us to simulate the communication channel that exists between the
different Exchange client and a different environment such as Exchange on-
Premises versus Exchange Online and additional troubleshooting tools that are not
directly real ties to the Exchange client such as the message analyzer tool.
Over the years, the Microsoft Connectivity Analyzer web-based tool evolved into a
very useful and “must know” tool, that every Exchange on-Premises or Exchange
Online administrator should be familiar with.
In the current article, we will learn to know and understand the interface and the
logic, if the Microsoft Remote Connectivity Analyzer Tool but it’s important to
emphasize that we will use only a very specific tool from the verity of the tools that
the Microsoft Connectivity Analyzer includes.
Our main focus is on the specific test named – Microsoft Office Outlook Connectivity
Tests | Outlook Autodiscover
In the current article, we will not review in details the Autodiscover flow details that
appear in the Microsoft Remote Connectivity Analyzer Tool test results, but instead,

I will review only the general concepts such as – how to read the results, the logical
structure of the test results, etc.
Autodiscover in Active Directory environment versus
Autodiscover in a non-Active Directory environment
Versus an Autodiscover troubleshooting tool such as the Outlook Test E-mail
AutoConfiguration tool that knows how to “perform” in the two different
environment, the Microsoft Remote Connectivity Analyzer Tool as the name implies
(Remote Connectivity), know how to inspect and analyze the Autodiscover flow that
is implemented in a non-Active Directory environment.
In simple words, we can use the Microsoft Remote Connectivity Analyzer Tool for
Autodiscover troubleshooting scenario in case of an “external mail client” that tries
to access a Public facing Exchange server.
Exchange On-Premise infrastructure verse Exchange
Online and Office 365 infrastructure
The Microsoft Connectivity Analyzer Tool can be used for testing Exchange client
remote access in a scenario in which the user mailbox is hosted on Exchange on-
Premises infrastructure or, Exchange Online infrastructure.
In the following screenshot, we can see the web interface of the Microsoft
Connectivity Analyzer Tool.

1. Different Exchange environments
The test that is offered by the Microsoft Connectivity Analyzer Tool can be
implemented by testing an Exchange on-Premises environment versus Office 365
(Exchange Online) environment.
We can see that the different test options are “grouped” by using a different tab.
 A – Under the “Exchange Server” tab, we can find all the available tests that can
be used when we need to test the Exchange On-Premise services.
 B – Under the “Office 365” tab, we can find all the available tests that can be used
when we need to test the Exchange Online infrastructure.
2. Different type of remote connectivity test
In the following screenshots, we can see that the Autodiscover connectivity test
appears under the “Exchange server” tab (Exchange on-Premises).
For example, we can implement a connectivity test for Outlook (RPCHTTPS) mail
client, ActiveSync (mobile Exchange client) etc.
Note that under the section – “Microsoft Office Outlook Connectivity Tests”, we
have two different connectivity tests.
For example, there are two different types of – Outlook connectivity tests.
 Outlook Autodiscover – test the Autodiscover flow and infrastructure that is
implemented by Outlook client.
 Outlook Connectivity – a “combined” test that includes the Autodiscover
remote connectivity test + the RPCHTTPS remote connectivity test.
3. Microsoft Connectivity Analyzer Tool and Office 365 environment
As mentioned, Microsoft Connectivity Analyzer Tool enables us to test the Office
365 environment and the Exchange on-Premises environment.

The test that can be implemented in the Exchange on-Premises environment exists
also for the Office 365 environment but, the Microsoft Connectivity Analyzer Tool
includes additional tests that are relevant only to Office 365 environment.
Microsoft Connectivity Analyzer Tool | Testing different
Exchange services
As mentioned, the Microsoft Connectivity Analyzer Tool includes many types of
“Exchange tests”.
For example:
 Microsoft Office Outlook Connectivity Tests – a connectivity test that inspect
Outlook client session that uses the Outlook Anywhere service. This test
inspects the complete communication process that is based on the
Autodiscover services and then move on to the “next layer”, to the process of
creating the RPCHTTPS communication link.
 Microsoft Exchange ActiveSync Connectivity Tests – enable us to simulate the
connectivity session between mobile clients that use the ActiveSync protocol.

In the following screenshot, we can see that the “interface” of Office 365
environment include seven different connectivity test versus the Exchange on-
Premises tab that includes four connectivity tests.
4. Another type of connectivity tests
The Microsoft Remote Connectivity Analyzer Tool includes a test for additional
Microsoft infrastructures such as – Lync On-Premise, Lync Online and, SSO (single
Sign on) services such as ADFS.

In the following screenshot, we can see that there are additional “tabs” beside the
test that relate to Exchange.
5. The “test client” Microsoft Remote Connectivity Analyzer Tool | The “Host”
that perform the test
The subject of the “Host who performs the test” is a very important subject and a
little confusing.
The Microsoft Remote Connectivity Analyzer Tool is a Microsoft public server whom
we can use for simulating access to various exchange services such as
Autodiscover.
It is very important that we understand the specific charters of the Microsoft
Remote Connectivity Analyzer Tool because, the way that the Microsoft Remote
Connectivity Analyzer Tool performs the Autodiscover test will not cover every
passable scenario.
When we face an Autodiscover troubleshooting scenario, we cannot be sure if the
problem is related to:
1. A specific user’s desktop from which the user tries to access the Autodiscover
Endpoint.

2. A specific network from which the user tries to access the Autodiscover
Endpoint.
3. A “general problem” in the Autodiscover infrastructure that affects all the
“external mail client” that needs to access their Autodiscover Endpoint.
The Microsoft Remote Connectivity Analyzer Tool, is implemented by using a public
Microsoft server that performs the different connectivity tests.
The “Public server” server for simulating Exchange client sessions with the
Exchange server.
We should be aware of the important fact that the Microsoft Remote Connectivity
Analyzer Tool Autodiscover test can be used only for testing a very specific scenario,
a scenario in which the Exchange client (Autodiscover client) is addressing the
“public interface” of the Exchange server.
In other words, a scenario in which the Exchange client is located on a public
network and the Exchange server configured as Public facing Exchange server.
The option of testing the Autodiscover flow from “external Exchange client” is
suitable for many scenarios, but in some Autodiscover troubleshooting scenarios,
we will need to perform the Autodiscover connectivity test from a “different
direction”.

The meaning is – performing the Autodiscover test by using a specific user desktop
or performing the Autodiscover test from a specific network such as the
organization’s private network.
In case that we want to perform the Autodiscover test from an internal network or,
from a specific network in which the Exchange client is located, we can download
and install the – “Microsoft Connectivity Analyzer client”.
In the following screenshot, we can see the “client tab” that we can use for
downloading the: Microsoft Connectivity Analyzer client.

Performing – Microsoft Office Outlook Connectivity
Tests | Outlook Autodiscover
To be able to demonstrate the use of Microsoft Remote Connectivity Analyzer Tool,
we will choose to perform the Outlook Autodiscover test.
Scenario description
The characters of our scenario are as follows:
The public domain name of the organization is – o365info.com
A user named John that is located in the externalpublic network, wish to create a
new Outlook mail profile. The John E-mail address is – John@o365info.com
We want to verify that the Exchange On-Premise server was “published” correctly
and that is accessible and available for “external client”.

Performing the Outlook Autodiscover test
To verify the required Autodiscover setting in our Exchange On-Premise server we
will use the following steps:
1. Access the Microsoft RCA – Remote Connectivity Analyzer Tool by using the
following URL:https://testconnectivity.microsoft.com/
Small tip – if you if you have trouble remembering the “complete URL address” you
can open any search engine and type the word – ExRCA.
The first result that will appear in the search result will “lead you” to the Microsoft
RCA – Remote Connectivity Analyzer page.

2. Click on the Exchange Server tab and under the Microsoft Office Outlook
connectivity test, choose the option – Outlook Autodiscover
3. On the bottom right corner, click on the Next option

In the following screen, we will need to provide the “user credentials”.
The credentials will be used by the ExRCA for “impersonating himself” to an
Exchange client, try to connect the Exchange On-Premise server, complete the
Autodiscover process and get the required Autodiscover response.
1. Email address – enter the recipient E-mail address. In our scenario, the recipient
E-mail address is – John@o365info.com
2. Domain User name (or UPN) – in this box we need to provide the On-Premise
Active Directory or domain user credentials. Most of the time, the “standard
convention” is based on the format of – <Domain name><User name>
(To be more accurate only the left part of the internal Active Directory domain
name).
In case that the On-Premise Active Directory user account was configured also with
a public domain name suffix, the authentication can be performed by using the
UPN (User principal name) naming convention. For example – John@o365info.com
In our scenario we will use the standard naming convention – o365infojohn

3. Password – this is the “domain user password”, meaning the password that the
user use when he login to the corporate domain.
4. Approval for the Autodiscover test – choose the option of :
I understand that I must use the credentials of a working account from my
Exchange domain to be able to test connectivity with it remotely. I also
acknowledge that I am responsible for the management and security of this
account.
This is a mandatory requirement.
When choosing this option, we are approving that we “trust Microsoft” (we provide
the ExRCA server our “secret” the private domain user credentials).
5. Verification – we will need to complete the verification process by re-type the
letters that appear (this is how Microsoft verifies that we are a human factor and
not a malicious code).
To complete the process click on the verify button

In the next screenshot, we can see that the verification process was completed
successfully.
To start that Autodiscover test, click on the Next option

Analyzing the results from the – Outlook Autodiscover
test
This is that part in which the ExRCA “shine”.
I know that it may be sound “Geek” but, I think that the ExRCA is doing a wonderful
job in presenting the “findings” in a very clear a “human like” way.
For myself, I have solved many “Autodiscover problems” using these tools that
provide me a clear and informative information about the Autodiscover process.

RCA – Remote Connectivity Analyzer Tool results structure and
logic
At first glance, the result that provides by the – Remote Connectivity Analyzer Tool,
look a little messy.
For this reason, it’s important that we will understand the way that the ExRCA use
for displaying the results.
An Autodiscover process consists of several parts.
The results include a dedicated part for each of the “part” or the “step” that involved
in the Autodiscover process.
In the begging of each “section”, we can see the task and the result (success or
failure) and beneath the header, we can see a detailed description for each of the
“sub steps” that was implemented and the result (success or failure).

ExRCA Results interface
This part in which we review “how to read” the displayed results of the ExRCA
Autodiscover connectivity test, can seem “unnecessary” but despite the fact that
everyone knows to use the result, it’s important to spend a minute on
understanding the way that the ExRCA Results are displayed.
Because the Autodiscover process or flow can be relatively simple or contain an
enormous amount of information, the ExRCA uses the method of – “expand and
collapse”.
The logic is based on a “Hierarchy concept” starting with the “first level” of
information and the ability to view (expand) each of the sub processes or tests that
are implemented in the Autodiscover test.
A metaphor that we can use is the “Russian babushka”.
The first “babushka” can be open and inside, we can find another babushka, when
we open the babushka that is inside, we can find another babushka and so on.
The same logic is implemented on the ExRCA Autodiscover test result.

Each of the steps can be expanded so we can see the content of the additional
steps that were included in the “father step” and so on.
To demonstrate the “Hierarchy concept” of the ExRCA Results interface, let’s use an
example of ExRCA Autodiscover test results that simulate Autodiscover access to an
on-Premises, Public facing Exchange CAS server.
Level 1
At this level, we can see a “clear answer” for the ExRCA Results. In our example, the
test completes successfully.

Level 2
When choosing the option of -”expand” under the Test Steps, we can see
“additional level” of information.
In our example, we can see that the Autodiscover test was started by looking for
the host named o365info.com and, the result is – failure.
The next Autodiscover test, was performed using the host named
autodiscover.o365info.com and the result is – Success

Level 3
The next level (“Level 3”) is the level in which we can review all the steps that are
included in the Autodiscover flow.
In the following diagram, we can see the logic of the displayed results.
In the following screenshot, we can see a short description for each of the steps
that was included in the Autodiscover process.
Step 1: described as – Attempting to resolve the host names
autodiscover.o365info.com in DNS.
Step 2: described as – Testing TCP port 443 on host autodiscover.o365info.com to
ensure its listening and open”.

Step 3: described as – Testing the SSL certificate to make sure it’s valid.
Step 4: described as- Checking the IIS configuration for client certificate
authentication.
Step 5: described as – Attempting to send an Autodiscover POST request to
potential Autodiscover URLs.
Level 4
This is the “deepest level” of information that enables us to take a deeper look at
the specific Autodiscover step.
In the following example, we have expanded the “Name resolution” steps in which
the Autodiscover client accesses the DNS server and asks for the IP address of the
Autodiscover Endpoint.
In our scenario, we can see that the IP address that was returned to the client is:
212.25.80.239 and, the “round trip” time that took to complete the process is: 221
ms

An Autodiscover flow – mixture of events of success
and failure | Reviling the mystery
One of the most confusing issues in a standard Autodiscover flow, can be described
as – the mixture of events of success and failure.
An additional confusing issue is – the ExRCA result which can be described as –
“Connectivity Test Successful with Warnings”
The “confusion” is that it’s not clear if the test was completed successfully or not. In
other words, no option of getting a clear whiteblack answer.

When looking at the screenshot, we can see that the icon of the test result is green,
but at the same time we can see that we see a yellow icon with an exclamation
mark.
So the most obvious question is – is it good or bad?
Can we understand that our Autodiscover infrastructure was configured correctly
or, we need to fix some issues?
The simple answer is – “Yes, this is good”.
The reason for the notification of – “Test Successful with Warnings” is that the
Autodiscover process is based on a concept of trial and error.

While looking for the “final result”, the Autodiscover client is programed to execute
a couple of methods and 99% of the time, some of this “methods” or tests will fail.
What matter is the “end result” that answers the question – did the client was able
or not able to find the “answer”, meaning – the Autodiscover response.
The reason for the yellow icon with an exclamation mark are as follows:
1. Root domain
The most popular cause for the result – “Test Successful with Warnings” is, that be
default, the Autodiscover client is programed to look for the Autodiscover Endpoint
by “extracting” the domain name from the recipient E-mail address (the “right part”
that includes the recipient SMTP domain name) and create a DNS query using the
“domain name” as the Host name.
For example, in the case that the recipient name is – John@o365info.com , the
Autodiscover client such as Outlook, will create a DNS query looking for the
hostname – o365info.com
Most of the time, this method will fail, because it’s a very rare scenario in which the
organization public domain name is “mapped” in the DNS for the IP address of the
Exchange server.
The outcome is the most of the time the first step in the Autodiscover process will
appear as “failed”.

Generally speaking, the method of – “looking for the hostname of the Autodiscover
Endpoint using the root domain name” can even cause minor or major problem.
In case that the organization uses a public website and additionally maps the
address of the domain name of the website, the Autodiscover client will get a
“positive answer” from the DNS regarding the IP address of the Root domain name
but when he tries to communicate with the “Apparent Autodiscover Endpoint” using
HTTPS, the communication will fail.
So, besides of the time that was spent in implementing this method, there’s no
harm.
In fewer good scenarios, in case that the “destination host” (the website) has a
problematic certificate such as a certificate that her date was expired and so on, the
Autodiscover client will stop the Autodiscover process because, the Autodiscover
client “understand” that there is a problem with the Autodiscover Endpoint.

To be honest, I think that the Autodiscover method of – “looking for the hostname
of the Autodiscover Endpoint using the root domain name” should be removed
because, for myself, I cannot see any advantage to using this method.
An example of looking for the hostname of the Autodiscover Endpoint
using the root domain name
In the following screenshot, we can see an example of the ExRCA test results:
The Autodiscover client connects the DNS server looking for the IP address of the
root domain name (o365info.com in our example), get the IP address of the host
name-
Attempting to resolve the host name o365info.com in DNS. The host name resolved
successfully. IP addresses returned: 104.28.12.85, 104.28.13.85
When the Autodiscover client tries to check if the host is “listing” to HTTPS
communication, the test fails, because the destination host, cannot communicate
using HTTPS.
The results in the ExRCA appear as-

Testing TCP port 443 on host o365info.com to ensure it’s listening and open. The
specified port is either blocked, not listening, or not producing the expected
response.
2. Certificate chains
An additional reason for the result of – “Test Successful with Warnings” is the
process that described as – ”testing the Certificate chains”
The Autodiscover client, request from the Autodiscover Endpoint to prove his
identity, by providing a certificate.
The public certificate infrastructure, is built upon a hierarchical concept.
The public server certificate is provided by a “higher authority” and, many times, the
“higher authority” is a subordinate of additional “higher authority”.
In this scenario, there at least “two elements” that are involved – the element that
provides the certificate (described as CA- Certificate Authority) and the “client that
uses the certificate” (Exchange server for example).

Part of the security test that Autodiscover client will perform is – check the
“element” which provides the certificate meaning the CA and the CA certificate.
The ability of the Autodiscover client of – verifying the CA certificate, is based on the
assumption that the CA is “well know” and that the client (the Autodiscover client)
has the CA certificate in his certificate store.
When we perform the Autodiscover test by using the ExRCA tool, even when the
phase of – “testing the Certificate chains” is completed successfully, the ExRCA tool
notifies us that the fact the “he” (the ExRCA), manage to verify the certificate chains,
doesn’t mean that a “user desktop” will also manage to complete successfully the
certificate chains test because these depend on the specific desktop certificate
store.
When looking at the ExRCA test results, we can see this type of notification:
Analyzing the certificate chains for compatibility problems with versions of
Windows. Potential compatibility problems were identified with some versions of
Windows. Additional Details
The Microsoft Connectivity Analyzer can only validate the certificate chain using the
Root Certificate Update functionality from Windows Update. Your certificate may
not be trusted on Windows if the “Update Root Certificates” feature isn’t enabled.
Just to recap, despite the fact that the Autodiscover phase of testing the certificate
chains appears with a yellow exclamation mark, the issue is not a problem and
there is nothing that we can do to avoid from this information to appear in the
Autodiscover test results.
Saving the ExRCA test results for further Analysis
The test result that we get from using the ExRCA tool, can be used for real-time
analyses or, for sending the data to a technical support team that (such as the
Office 365 support team) for continued analysis.

The ExRCA tool, enable us to save the result from the Autodiscover test, using three
different options:
1. Copy to clipboard
This option will copy the ExRCA test result to the local desktop clipboard using an
XML format. Personally, I prefer the other method such as – saving the
Autodiscover test result, to an HTML format because the reading of the result is
much clearer.
2. Save the result to HTML file

This is my prefer method. The option of saving the ExRCA test result HTML file is
identical to the result that appears on the screen. The use of the green and red
icons, unable to find “area of problems” very easily and additionally, the option of
“expand and collapse” enable us to navigate through the data very easily.
3. Save the result to XML file
The option of saving the data into an XML format is interesting because when using
the option of XML, we can use tolls such as Microsoft Excel for “presenting” the data
in a custom format.
In case that we save the ExRCA Autodiscover test result in an XML file format, and
we use Excel for opening the XML file, the following message will appear – “please
select how you would like to open this file”
We will choose the option of – As an XML table

In the next popout window click OK

In the following screenshot, we can see the results.
Excel “know” how to put the XML data in a table format, and, we can use Excel
option such as Filter for showing or hiding specific “data”.

An additional option is to open the XML file using an advanced text editor such as:
Notepad++
In the following screenshot, we can see the result of opening an XML file with
Notepad++. We can see that the Text editor “understand” the special XML format
and display the data using a color, Hierarchy of XML tags etc.

Microsoft Remote Connectivity Analyzer (ExRCA) | Error
messages
In the following section, I have added a link list that relates to each of the posable
errors that can appear in the Microsoft Remote Connectivity Analyzer (ExRCA) test
results.
 Microsoft Connectivity Analyzer Tool
 RPC Server Unavailable Error was Thrown by the RPC Runtime
 Could Not Find MS-Server-ActiveSync Header in OPTIONS Response
 Could Not Negotiate an Appropriate Airsync Version with Server
 An Unexpected Redirect Response was Received
 A Positive HTTP Response Other than a Redirect Response was Received
 Could Not Find Autodiscover Service Location (SRV) Record in DNS
 The MobileSync Autodiscover Provider Returned an Error Status in the XML
Response
 The Outlook Autodiscover Provider Returned an Error Status in the XML
Response
 Missing EXPR Element in Autodiscover XML Response
 Missing AuthPackage Element in Autodiscover XML Response
 Anonymous Authentication Enabled for Virtual Directory
 No Supported Authentication Methods Found in Response
 An Unsupported Authentication Method was Found
 All Required Authentication Methods Could Not be Found
 The Host Name Could Not be Resolved in DNS
 SSL Certificate Name Mismatch
 SSL Certificate Trust Failure
 Expected Service Banner was not Received when Connecting
 A Network Error Occurred while Communicating with Remote Host
 Name Could Not be Matched to a Name in the Address List
 Mutual Authentication Could Not be Established
 RPC Encryption Required
 The Client and Server Versions are Not Compatible
 Cached Mode is Required for this Mailbox
 RPC over HTTP Connection is Not Allowed
 MAPI Connections are Not Allowed
 No MX Records were Found for the Specified SMTP Domain
 Open Relay Detected
 An HTTP 403 was Received Because ISA Denied the Specified URL

 An HTTP 403.4 was Returned Because SSL was Required on the Virtual
Directory
 An HTTP 500 was Returned to ISA Because the Certificate on the Published
Server Doesn’t Match the Name in the Publishing Rule
 Access is Denied Error was Thrown by the RPC Runtime
 Exchange ActiveSync Returned an HTTP 500 Error
 ActiveSync ExternalUrl is Not in the Expected Format
 Windows Mobile Root Certificates
 Missing Intermediate Certificates in Chain
 The Act As Account Does Not Have Permissions to Create Items in this Folder
 The Act As Account May Not Have Permission to Delete Items in this Folder
 The Act As Account May Not Have Permissions to Access this Folder
 The Service Account Specified Does Not Have Impersonation Rights on Client
Access Server
 The Service Account Specified Does Not Have Impersonation Rights on the
Act As Account Specified
 Invalid XML Response Unable to Retrieve Availability or OOF Settings
 IP Address does not have a PTR record in DNS
 IP Address Found on RBL
 Name Space is not Federated
 The domain is a federated domain but the user <User>@contoso.com is not
known by Office 365
 Active Directory Federated Services (AD FS) HTTPS endpoint name could not
be resolved
 Active Directory Federated Services (AD FS) server is down or unreachable
 ADFS SSL Certificate Name Mismatch
 ADFS SSL Certificate Trust
 ADFS SSL Certificate Expired
 Token Signing Certificate Expired
 ADFS token not accepted by Authentication Platform (for later version of
RCA)
 Unknown Username or bad password
 General issues that may occur for one or all users
 UPN issues when authenticating
 You must uninstall all interim updates before you install Exchange Server
2010 Service Pack 2
 Missing EXCH Element in Autodiscover XML Response

 Mutual Authentication Established by Subject Alternative Name
 Error with System Time
 Firewall Pre-Authentication Check
 EWS Endpoint Directed to On-Premises Legacy Server
 Error when you run the Exchange Remote Connectivity Analyzer tool to test
connectivity to Office 365: “To authenticate to Office 365, you must enter
your Microsoft account”
 The user name provided could not be matched to a name in the email
server’s address list
 The email server is not available
 MCA test: I can’t log on with Office Outlook
 MCA test: I can’t send or receive email on my mobile device
 Additional help resources for MCA
 The ActiveSync OPTIONS command returned an HTTP 401 Error
 MCA test: I can’t view the free/busy information of another user
 MCA test: I can’t send or receive email from Outlook (Office 365 only)
 MCA test: I can’t log on to Lync on my mobile device or the Lync Windows
Store App
 Message Header Analyzer
Additional reading
 What’s new with Microsoft Remote Connectivity Analyzer? A lot!
 New Remote Connectivity Analyzer Tests for Mail Flow
 How to use Remote Connectivity Analyzer to troubleshoot single sign-on
issues for Office 365, Azure, or Intune
Video links
 Using Microsoft Remote Connectivity Analyzer in Exchange 2013

Microsoft remote connectivity analyzer (ex rca) autodiscover troubleshooting tools part 2#4 part 22#36

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

Similar to Microsoft remote connectivity analyzer (ex rca) autodiscover troubleshooting tools part 2#4 part 22#36

Similar to Microsoft remote connectivity analyzer (ex rca) autodiscover troubleshooting tools part 2#4 part 22#36 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Microsoft remote connectivity analyzer (ex rca) autodiscover troubleshooting tools part 2#4 part 22#36