Office 365 Fiddler Extension

Office 365 Fiddler Extension

Exchange Online Fiddler Extension

General Information

The Office 365 Fiddler Extension can help to analyse Fiddler network traces, utilizing accumulated knowledge to resolve high impact & critical situation scenarios with Office 365 client applications.

It is an Office 365 centric parser for Fiddler network traces which gives you knowledge on what is normally expected to happen, identifies false positives, and highlights the most relevant information front and center to resolve issues as efficiently as possible.

The Office 365 version of the extension has its origins in the Exchange Online Fiddler Extension. It includes all of session processing logic in that tool, with a widened scope to assist with troubleshooting any Office 365 application.

Where to Download?

You can download the Office 365 Fiddler Extension here.
This is a link to the latest release available on Github.com, which is a .msi installer which currently requires administrator privileges to install.

Source Code

Whether you want to contribute to the project or simply review code, it is available here.
If you are looking to find out more about the types of issues the extension detects and reacts upon, the SessionProcessor.cs file will be of interest to look through. It is not a light read however, there is a large switch statement based on HTTP response codes. Each switch likely contains an if then else statement of varying complexity, depending on how many scenarios we have seen from previous support cases.

Project Wiki

You can get to the extension wiki pages here.
This website is used for late breaking information on the extension such as release notes. The wiki on the other hand is a repository for useful knowledge about the extension.

Issues / Concerns / Questions

If you have found a bug, have a question or concern on the extension please funnel this information through the Github.com project issues page.
We will respond to the issues raised with as much helpful information as we can provide.

What does the extension do?

At a high level the extension adds the following to the Fiddler GUI:

  • Colours sessions according to session severity.
  • Adds an inspector tab titled ‘Office 365’.
  • Adds a menu to control the extension.

What does the extension look like?

Menu Title

The extension adds a menu in the Fiddler GUI on the right hand side called ‘Office 365’.

The title of the menu changes according to whether the extension is enabled or not.

Office 365 Fiddler Extension Menu Enabled
Menu Disabled

Application Logging

Application Logging Enabled controls whether session events recorded by the extension are recorded into the Fiddler applications log. Check the log tab on the right hand side of Fiddler to see the information.

Highlight Outlook and OWA Only

Highlight Outlook and OWA Only – If enabled only traffic Outlook.exe and browser executibles is highlighted in the various colors. All other traffic is colored in grey.

Otherwise sessions from all processes are highlighted / colored.

Download Page

The link to download the latest available version of the extension.

Extension Wiki

The link to the project wiki page.

Report Issues

The link to the project issues page. Use this link to ask any questions, report any problems or concerns with the extension.

Check For Update

Click this option to check for any available update, or get feedback on the version you are using the latest available version.

Session Colourisation

With the extension enabled sessions are coloured according to the severity of any potential issues detected in the session.

Grey — Sessions not directly related to Outlook, OWA or Exchange.

Green — No known failure condition detected.

Blue — False positives. Typically these will be HTTP 5xx server responses which are expected with Exchange Online.

Orange — Warning on some event. May or may not be a critical issue. Typically HTTP 401 authentication challenges.

Yellow — Undefined session response code in the extension.

Red— Critical issue to pay attention to. Typically HTTP 403 Forbidden or HTTP 5xx server errors.

Black with red text — HTTP 200 OK server response with the keyword ‘error’, ‘failed’ or ‘exception’ found in the response body, or other critical condition found. Looking to find errors and failures lurking in HTTP 200 OK server responses.

Special note on HTTP 200’s highlighted with black on red text. It is fairly typical to find errors with in javascript in the response body. This may well give you some false positives.

Found a session not colourised? Open an issue here.


Office 365 Fiddler Extension Session Colourisation

Additional Columns

The extension adds custom columns to the Fiddler GUI:

  • Elapsed Time: The total time the sesson took. Useful when looking for an issue related to session latency or performance.
  • Host IP: The host IP address of the device or server which responded to the session request. It is particularly useful to know if the responding device or server is on the local network or is from an internet based location. In other terms, did the web proxy on your network respond, or did the destination server you expected to respond.
  • Session Type: The extension calculates what type of session this is. If it cannot it simply puts the process information in this column.
  • Authentication: A quick summary informing you on the presence of authentication headers.
  • Response Server: The type of server or device that responded to the client request in the session. This may be IIS for Windows, or maybe Apache etc.

Inspector Tab

The extension adds an ‘Office 365’ inspector tab, which contains a text view control to display relevant information to the session.

If the extension is disabled the inspector tab text displays minimal information.

Inspector Disabled

With the extension enabled much more information is available on the currently selected session.

Data sections in the inspector

Update Notifications

As any updates are made available, notifications will be displayed at the top of the inspector text control.

General Session Data

In this section you have the:

  • Session id.
  • HTTP response code.
  • Date information on when the data was captured.
  • The session type detected by the extension.
  • The process (.exe) which initiated the traffic.
  • the host IP which responded to the request.
  • The response server type.

All relevant infromation to quickly determine who, what, where, when.

Overall Session Timers

Data on when the session started, how much processing time occurred, and when the response was completed.

Further more detailed information can be found here.

Server Timers

Timers which show you how long the ‘Server Think Time’ was, and how long the ‘Transmit Time’ was.

This can be useful information for determining if the responding server took a long time within the overall elapsed session time or not.

Authentication

Any authentication information will be displayed in this section.

If there are no authentication headers in the session, this section will not be displayed at all.

If there are authentication headers, information specific to the authentication headers detected will be displayed. 

The information will indicate if the client application is declaring it back perform modern authentication or not, and whether the responding server / service can perform modern authentication or not.

Authentication SAML Parser

A SAML/Response parser is built into this section as well. If in a Fiddler trace from a modern authentication capable client a SAML token to captured the Authentication section will show the SAML parser.

The SAML parser displays the following information from the SAML token response:

  • The token issuer. Typically the federation service URL.
  • Attribute Name Immutable Id. The Base64 encoded object ID typically from the On-Premise user account.
  • Attribute Name UPN: User account UPN.
  • Name identifier Format. This should match the Base64 immutible ID above, though enclosed in some additional data.
  • Signing certificate: The certificate presented from the token signing (Federation) service. Data is presented in such a way so it can be copied into a .cer file for review as a certificate file.

Session Analysis

The final section in the inspector is analysis on the session, with feedback giving you further information on how to interpret the data.

Examples of session analysis:

  • Instructions on next steps to perform.
  • Troubleshooting approach.
  • Links to Microsoft support articles.
  • Additional analysis to perform.
  • Confirmation of a positive outcome on a session response.
  • Confirmation of a false positive on the session response.
  • Confirmation of critical issue on the session response.

The general rule of thumb would be to check this section in any sessions highlighted in red if you are unsure of what to do next.

Office 365 Fiddler Extension Inspector Enabled

Performance of the extension

How much overhead does the extension add to the regular usage of Fiddler? The answer depends on the size of your SAZ file. The overhead could be a little, or in the extreme it could be a lot.

To put this into perspective I’ll compare two traces.

A regular trace I use for testing is a recording of a FederatedSTSUnavailable scenario from my lab which contains 105 sessions.

  • Without the extension enabled the data in the trace is loaded within a fraction of a second.
  • With the extension enabled the data in the trace is loaded in a little over a second.

I have an abnormally large trace I use for the purpose of testing CPU and memory consumption which contains twenty thousand sessions.

  • Without the extension enabled the same SAZ file loads in 14 seconds.
  • With the extension enabled this SAZ file loads in 9 minutes and 36 seconds.

While that time of over 9 minutes sounds extreme, it is actually not slow. You have to take into account in the extension we are running each and every of those twenty thousand sessions through individual logic checking which of course slows down the process.

Couple that with the fact that most Fiddler traces you are looking at for troubleshooting purposes should be a less than 300 sessions.

Fiddler should be collecting data for as short a period as possible while an issue is reproduced.

The typical number of sessions in traces I see while troubleshooting is in the 100 – 150 range. In that range the overhead is minimal, especially when you consider all the extra analysis done automatically against the sessions.

I am more than happy waiting an extra second for that 150 session trace to load, so I get all that enhanced feedback. Hopefully you are too!