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 .
The script is able to extract some EAS relevant details across the different Exchange and protocol versions. The way those data get logged in the IIS logs changed and this needed to be addressed. As a result, the output and additional switches were added. For more information read the previous posts:
- Troubleshooting Exchange with LogParser:IIS logs #1
- Troubleshooting Exchange with LogParser:IIS logs #2
The script can be downloaded from the Script Center here:
The switch -EASDetails forced the script to extract EAS relevant data, if available:
|EASCmd||The issued command.|
|EASError||The error, if occurred.|
|EASSyncType||The type of sync: “First Sync”, “Subsequent Sync”, “Recovery Sync” or “Invalid Sync”|
|EASStatus||The response status to the command.|
|EASClientSyncKey||Client side SyncKey|
|EASServerSyncKey||Server side SyncKey|
|EASFolderType||Type of folder (e.g.: EM, CO)|
|EASFilter||Filter in terms of time (No Filter, 1 day, 3 days, 1 week, 2 weeks, 1/3/6 months, Incomplete Tasks|
|EASServerChanges||Changes on server-side.|
|EASClientChanges||Changes on client-side.|
|EASPolicyKey||Negotiated policy key|
|EASCAFEServer||CAFE server, which is the front-end server|
|EASMBXServer||MB server, where the active database was currently mounted|
|EASHeartBeat||EAS current heartbeat interval|
|EASFolderCount||How many folders were synced during this command|
|EASFolderId||The first FolderID found in this command.|
|EASDevOS||The device reported OS.|
|EASLog||The complete URLDecoded part of the EAS relevant logged part in the IIS logs|
|EASActivity||The ActivityContextData from the EASLog|
If you parse the IIS logs for -DeviceID or -DeviceIDs, this switch is set to $true automatically.
These fields come into play, when you’re debugging Exchange ActiveSync related issues like the ones I described here.
Another example would be that devices are in a loop and requesting a “Recovery Sync” over and over again. For the end-user it looks like nothing is download as no mails or calendar items will be shown on the devices. Under the hood something went wrong and a full sync is triggered over and over again. We have seen this behaviour across different vendors, when the EASFilter was set too high and the local store (on the device) got corrupted.
The script used to have 2 Exchange ActiveSync related reports:
This report is based on the one provided by Exchange PG, which could be found here, but with some minor changes. One change for example is that I added the EASSyncType.
This report will give you a list of Server, DeviceID, EASError and Hits. Could be helpful to find a rogue server or to rule out a server issue.
The updated script has 2 additional ones:
This will generate a report with DeviceType and Hits. The field DeviceType is preliminary extracted from the IIS log field cs(user-agent). The field is split by ‘/’ and if $null the value of the EAS reported field DeviceType is taken. Actually you will receive a list of vendors and the number of occurrences.
This report is similar as EASReportByDeviceType, but it returns only devices, which have thrown an error. The output contains DeviceType, EASError and Hits.
With those reports you can create some interesting graphics.
This shows the number of requests generated by DeviceType:
Exchange ActiveSync errors sort descending by number:
Exchange ActiveSync errors grouped by DeviceType, sorted descending by number:
The most popular Exchange ActiveSync error (NMStolen) per DeviceType:
The reports above shows that the major number of requests are made by iOS devices (91%). The most logged error is NMStolen. When I filter for this error and then group by devicetype, we can see that 96% of this error is generated by iOS devices. 5% more than the overall requests. Or you can see it from a different angle:
24,8% of all iOS and 11,45% Android requests have the error NMStolen. Interesting fact, isn’t it?
NMStolen is the brief log information for Network Manager Stolen. When you turn on debug logging and analyze the logs with Mailbox Log Parser you can see that it reports
The heartbeat interval expired before any changes occurred in the folders being monitored.
In the IIS logs you will see a status with value 1 for a Ping request. You can read more about this in the MS-ASCMD documentation.
In short: The device is issuing the next request before the heartbeat interval has expired.
I hope the new script helps you to collect some more details and look behind the curtain in your organization.
Any feedback is more than welcome!