The current article, is the continuation of the previous article, in which we will continue…
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 fascinating tool named – Fiddler, that can help us in our task of capturing and analyzing Autodiscover data that passed between the Autodiscover client and the Autodiscover Endpoint throughout the Autodiscover communication channel.
Table of contents
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. 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
Generally speaking, there are a couple of tools that have the ability to capture network traffic that flows in the communication channel between two nodes.
An example for such tools is:
The “thing” that distinguishes the Fiddler tool vs. 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 Fiddler.
Using Fiddler as an Autodiscover troubleshooting tool advantage and disadvantages
- The ability to inspect HTTP and HTTPS session from any 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 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.
- 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 MRCA (Microsoft Remote Connectivity Analyzer).
- Disability of inspecting additional protocols besides HTTP and HTTPS.
For example, an Autodiscover process in Active Directory environments includes additional protocol besides 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
Click the HTTPS tab and choose the option box – Decrypt HTTPS traffic
A warranting or a notification window appears that notify us that Fiddler will generate a unique root certificate. Click on the Yes button
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)
- 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.
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 implemented between the Outlook client and his “Autodiscover Endpoint” (Exchange Online).
In the following screenshot, we can see the “Autodiscover round trip” that 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.
Error: TimedOut (0x274c).
System.Net.Sockets.SocketException A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 184.108.40.206: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 “travels” 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
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).
In the following screenshot, we can see that Outlook (Autodiscover client) manage to reach his Autodiscover Endpoint – an Exchange Online CAS server named –
By using the Syntax View tab, we can see the content of the XML file that the Exchange server return as an Autodiscover response.
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.
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.
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.
This Post Has 0 Comments