Using fiddler for autodiscover troubleshooting scenarios part 4#4 part 24#36

of 16 | Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part
24#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Using Fiddler for Autodiscover
troubleshooting scenarios | Part 4#4 |
Part 24#36
The current article is the last article in the Autodiscover troubleshooting tools
article series.
In this article, we will review a very interesting tool named – Fiddler, that can help
us in our task of capturing and analyzing Autodiscover data that is passed between
the Autodiscover client and the Autodiscover Endpoint throughout the
Autodiscover communication channel.
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

24#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
The “Fiddler” tool
The “Fiddler” tool, can be classified as a “network sniffer” but the thing that makes it
“special tool”, is that the fiddler is an HTTP and HTTPS network sniffer tool.
In the current article, we will review how to use the fiddler tool for the purpose of
Autodiscover troubleshooting scenarios but, it’s important to mention that the
Fiddler can serve as a tool for many other scenarios, in which we need to get a
detailed view “inside” an HTTP or HTTPS session between two nodes (client and
server, for example).
The Fiddler concept

24#36
Generally speaking, there are a couple of tools that have the ability to capture
network traffic that flow in the communication channel between two nodes.
An example for such tools is:
 Microsoft Network Monitor
 Wireshark
The “thing” that distinguishes the Fiddler tool versus other network capture tools is
that a standard network monitor tool, cannot monitor the information that flows
when using HTTPS session because the data is encrypted.
The ability of the Fiddler tool to “look into” an encrypted HTTPS session, is a little
similar to a well-known attack named – a man in the middle.
In case we configure the Fiddler to inspect an HTTPS session, the Fiddle toll use his
own personal certificate.
When the “client” sends information to the server, the information is captured by
the Fiddler, Fiddler inspects the data, “repackage” the data and sends it back to the
server.
Download and install fiddler
Use the following link to download the Fiddler

24#36
Using Fiddler as an Autodiscover troubleshooting tool
advantage and disadvantages
Advantage
 The ability to inspect HTTP and HTTPS session from any type of clients – in the
current article, we demonstrate how to use Fiddler for inspecting an Outlook
session but, it’s important to mention that the Fiddler tool, can use to inspect
HTTP and HTTPS session of any type of client.
For example, we can use the Fiddler for the monitoring OWA session (Outlook
web client) and get a very detailed information about the information the “flow”
between the client and the server.
Disadvantages

24#36
 The Fiddler was not created as a “dedicated tool for troubleshooting Microsoft
Autodiscover client problems”. The information that we get from Fiddler is not
so clear and “understandable” as the information that we get when using
tools such as the ExRCA (Exchange remote connectivity analyzer).
 Disability of inspecting additional protocols beside HTTP and HTTPS.
For example, an Autodiscover process in Active Directory environments
includes additional protocol beside the HTTP and the HTTPS such as as-DNS
and LDAP.
When using the Fiddler, we will not be able to get any kind of information
about these “Autodiscover parts” that are implemented by the Autodiscover
client.
Configuring Fiddler to decrypt HTTPS traffic
Choose the Tools menu and then click on the Fiddler options

24#36
Click the HTTPS tab and choose the option box – Decrypt HTTPS traffic

24#36
A warranting or a notification window appears that notify us that Fiddler will
generate a unique root certificate. Click on the Yes button

24#36
On the last window approve the operation of the certificate installation on the local
desktop
Fiddler graphical interface
The Fiddler is a very sophisticated tool with many options.
At the current time, I will provide just a quick review for an example in which we use
Fiddler for inspecting an Autodiscover session between Autodiscover client and
Autodiscover Endpoint.
In the following screenshot, we can see the “structure” of the session screen.
 Row 1 – in this row we can see the icons that Fiddler use for representing a
specific event such as success, failure, encryption etc.
 Row 2 – the protocol that was used (HTTPS or HTTP)

24#36
 Row 3 – the hostname
 Row 4 – the URL address
 Row 5 – the “process” the meaning is the factor or the “client” that creates or
Initializes the session. In our example, we monitor an Outlook Autodiscover
process that tries to access his Autodiscover Endpoint.
The “Left part” of the Fiddler graphical interface, is dedicated to presenting the –
“Log rows”, the record of the HTTP or the HTTPS session that occurs.
The “Right part” of the Fiddler graphical interface, is dedicated to presenting the
content of a specific session.
Notice to “Tab” on the upper part and beneath the content. Each of this tab, enable
us to get a “differ view” of the information.
For example, SyntaxView, HexView, Image View, XML, Heeders etc.

24#36
Monitoring and Autodiscover session using Fiddler
To demonstrate the use of Fiddler, we will use the following scenario:
John is an Office 365 users whom his mailbox is hosted at the Exchange Online
server.
We would like to use the Fiddler tool for monitoring a “standard Autodiscover
session” that is implemented between the Outlook client and his “Autodiscover
Endpoint” (Exchange Online).
In the following screenshot, we can see the “Autodiscover round trip” that was
accused when a mail client such as Outlook accesses his mailbox on the Exchange
Online server.
We can see that in the begging, the Autodiscover client is trying to access a host
named –o365info.com
using HTTP and the communication requires failed.
If we look at the content of the Log row, we can see some additional information
such as:
[Fiddler] The connection to ‘o365info.com’ failed. <br />Error: TimedOut (0x274c).
<br />System.Net.Sockets.SocketException A connection attempt failed because the

24#36
connected party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond 104.28.12.85:443
Another session such as the HTTPS communication with the “Exchange Online
server” (pod51049.outlook.com) was completed successfully.
General clarification – in Office 365 and Exchange Online environment, the mail
client doesn’t reach directly to his “final Autodiscover Endpoint”.
Instead, the Autodiscover client is going through a “journey” in which he “travel”
between couples of nodes until he reaches his destination.
For example, a “standard Autodiscover workflow” in an Office 365 environment will
start when the Autodiscover client tries to look for the host using the SMTP email
domain as the host name (o365info.com in our scenario), if he fails to find or
communicate with this Autodiscover Endpoint, the client will try to look for a host
using the Autodiscover as a prefix (autodiscover.o365info.com in our scenario).
Because in Office 365 there is not such Autodiscover Endpoint, the Autodiscover
client will be redirected to Potential Autodiscover Endpoint named – autodiscover-
s.outlook.com and, from there will be redirected again to his “final destination”, in
our scenario an Exchange Online CAS server named- pod51049.outlook.com
An example for the Autodiscover session
In the following screenshot, we can see that Outlook (Autodiscover client) tries to
access host named – autodiscover-s.outlook.com

24#36
If we look at the content of the log row, we can see the information that appears in
the server certificate (the certificate that the server sends to the Autodiscover
client).
In the following screenshot, we can see that Outlook (Autodiscover client) tries to
access host named – pod51049.outlook.com
If we look at the content of the log row, we can see the information that appears in
the server certificate (the certificate that the server sent to the Autodiscover client).

24#36
In the following screenshot, we can see that Outlook (Autodiscover client) manage
to reach his Autodiscover Endpoint – an Exchange Online CAS server named –
pod51049.outlook.com
By using the Syntax View tab, we can see the content of the XML file that the
Exchange server return as an Autodiscover response.

24#36
Another option for viewing the content of the Autodiscover response is by using the
XML tab.
The XML tab enables us to see the information (the XML file) by displaying the XML
Hierarchy.
Fiddler Miscellaneous
As mentioned, the fiddler is a very powerful tool that enables us to “do” many
things with the recorded data.
In the following screenshot, we can see an example of a nice option that enables us
to “replay” a specific HTTP or HTTPS session.
To be able to replay a session, we will need to right click on the required Log row,
and choose the replay menu.

24#36
Saving a fiddler session
The option of “Saving a fiddler session” is useful in a scenario in which we want to
save the data for further analysis or send the data to tech support, etc.
To save a recorded Fiddler session, click on the File menu and choose the Save – all
session menu.

24#36
Additional reading
 Using fiddler rule to get outlook to authenticate to the Microsoft online
discover service
 Get-FederationInformation Fails to onmicrosoft.com with Bad Gateway Error
 Announcing Fiddler Inspector for Exchange Server ActiveSync
 EAS Inspector for Fiddler
 Configure Fiddler to Decrypt HTTPS Traffic
 TechNet Radio: IT Time – Troubleshooting Office 365 Single Sign-On with
Fiddler2
 Office 365: New port/URL required for OWA in Exchange Online
 How to help the Outlook.com support team collect FiddlerCap traces

Using fiddler for autodiscover troubleshooting scenarios part 4#4 part 24#36

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Using fiddler for autodiscover troubleshooting scenarios part 4#4 part 24#36