Troubleshooting Exchange with LogParser: EWS logs

When it comes to the point to troubleshoot Exchange Web Services related issues, where do you start? When it’s related to F/B requests of Outlook there used to be some client-side logs available. Since Office 2013 not anymore, as these data are all moved into ETL files, which are encrypted. It can be also hard to troubleshoot a Mac client or even cross-org or Hybrid scenarios.

So how can you start troubleshooting?

Starting with Exchange 2010 you will find EWS related logs on the servers and you can easily parse them. The newer the Exchange version is the more information is logged.

Where do I find the logs?

By default the logs are stored in the folder $exinstall\Logging\Ews:

How to analyze?

If you have only a few servers, you can use your favorite editor or parse the logs using PowerShell. I love LogParser and as I have multiple servers, I wrote a script for this task.

How it works?

As the other scripts you need to fullfil the following prerequisites:

• LogParser
• a server from where you will run the script. This server needs SMB access to all Exchange servers as we will access the EWS logs via UNC path
• adjust the execution policy. Here is an example, which bypass the policy only for the running process:

  Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

• the script itself, which you can download here

The script will search for Exchange server within given AD sites, determines the installation path and search then in those paths for log files. There are several possibilities you can filter for (e.g.: servers, AD sites, dates, users).

The full list of parameters:

Parameter	Description
Emailaddress	Normally the users are logged with their PrimarySmtpAddress. But the SamAccountName is also used.
Emailaddresses	same as Emailaddress, but it allows you to define multiple users comma seperated
StartDate	this is used for filtering the logfiles to be parsed. The default format is yyMMdd, but you can also use yyMMddHH.Default: Current day
EndDate	this is used for filtering the logfiles to be parsed. The default format is yyMMdd, but you can also use yyMMddHH.Default: Current day
LogParser	Define path to LogParser.exe.Default: “${env:ProgramFiles(x86)}\Log Parser 2.2\LogParser.exe”
ADsite	Search for Exchange servers in one or multiple sites. The default is the current site from the the script is running. You can define multiple sites comma seperated.Default: The site of the machine you are running the script
Outpath	Define where the CSV files will be stored. Default:”$env:temp”
SpecifiedServers	Comma seperated filter for only specified servers in an AD site
Localpath	if you have log files in a local folder. There is no filtering by date! All files will be analyzed
Exchange2013	This switch controlls, which version of Exchange should be searched. By default it’s set to $true, which means the script search for Exchange 2013 and newer versions.
OneFile	By default the script generates for each day a seperate file. If this switch is used, the output will be only one file.

Note: As mentioned in the description of the parameters Emailaddress, the applications can use multiple names for a user. This also depends on the authentication. I recommend to use PrimarySmtpAddress of the user. If you don’t get the expected result, use Emailaddresses and PrimarySmtpAddress and SamAccountName for the user you are troubleshooting.

How does it looks like?

In this example I parsed the logs for the user ingo@fabrikam.local and specified the path to LogParser.exe

.\Get-EWSStats.ps1 -Emailaddress ingo@fabrikam.local -Logparser C:\Temp\LogParser.exe

The script list the server and the logs, which could be found and are accessible. I omitted to specify a StartDate and EndDate and therefore the script used the current day. If you want you can filter also on hourly base

.\Get-EWSStats.ps1 -Emailaddress ingo@fabrikam.local -Logparser C:\Temp\LogParser.exe -StartDate 17011206

As you can see there are now less logs to be parsed, which improves performance!

Note: You will find entries for users ONLY on those server, where the database was currently mounted. That means you can improve the script’s performance, when you filter by hour and only to those server where the user’s  mailbox or the mailbox the user accessed was mounted.

What can you see?

In this example a misconfiguration of the AuthServer caused issues for F/B lookups, between On-Premises and EXO

To get this fixed read carefully Configure OAuth authentication between Exchange and Exchange Online organizations or even better run the Hybrid Configuration Wizard.

In the following example the servers were behind a proxy, but InternetWebProxy was not configured properly. The second error is expected as I tried to lookup availability for an unknown user.

And here are the GenericErrors for the previous requests

Conclusion

As you can see there are a lot of information available. You just have to know where to look at and how to parse. I hope this helps.