Over the last months a lot of changes needed to be addressed. The script was intended to extract data from the IIS logs. With PowerShell in combination with LogParser it did a great job. But different versions of Exchange, changed infrastructure and multiple versions of Exchange ActiveSync protocol demanded an update to fulfill these needs.
The latest version focused on code improvement and added support for the new version of Exchange ActiveSync protocol v16.1 .
In the past month I had to troubleshoot a lot of EAS related issues. This is always a complex process and you as an administrator have to collect a lot of data and provide them to your vendors. After providing these, you often feels like a ping-pong ball. Especially when multiple vendors are involved.
Based on two examples I want to explain, how I was able to proof some misbehaviour of EAS clients. Meanwhile both have been acknowledged by the vendor as a bug:
With iOS 10 this feature can trigger a meeting forward to multiple recipients using SmartForward command.
When a user marks an item read or unread, the flag does not get synced to the mailbox.
Update 27.06.2017: There is also a fix in KB4012108 related to this issue. It’s not exactly the issue I’ve found, but a similar one. The details can be found in KB4024649.
For troubleshooting I used the following tools:
During a migration to Exchange 2013 several users started complaining about intermediate connectivity issues.
After some investigation I still had no clear picture of the issue. The users had in general no connectivity problems, but they got sometimes errors (e.g.: failed authentication, request could not be completed). And this not in a consistent way.
Some reported issues in Outlook and some on a mobile device using an app. When I heard about the mobile apps, my first thought was maybe an Exchange ActiveSync issue. But the apps on the mobile devices were using EWS.
In my previous post I described how to extract data from the IIS logs for one or multiple user/users or device/devices. This post is more about analytic or statistic tasks you can perform with this script.
There are the following reports available:
This is the first part of a serie about troubleshooting Exchange using LogParser. I bet all of you know the situation, where users complain about connectivity issue. But how do you troubleshoot?
In this post I will cover how to parse IIS logs. There are a few great tools out there to parse those logs:
But they have one big drawback in common:
You need to collect the logs from all servers into one place in order to parse them. If you have only 2-3 server that might me okay, but what when you have more than 10, 20 or 30 server? It also takes time to copy the logs depending on your settings what you are logging. Easily a log could be larger than 1GB.
Wouldn’t it be great to be able to parse the logs without the need of copying them?
Well here is the solution:
The clueless guy 