Analyzing the Get-MobileDeviceStatistics -GetMailboxLog to determine Sync Errors

Scenario:  You have already enabled ActiveSync Debug Logging  (Set-CASMailbox steve -ActiveSyncDebugLogging:$true) and now you want to collect and analyze the logs for errors.  ActiveSync is chatty so it creates a TON of logging data to sift through. So how do we know which log entries are good and which are bad? Here is the dirty way we sifted through it.

Pull the ActiveSync Debug Log:

$1 = Get-MobileDeviceStatistics -Mailbox steve -GetMailboxLog

Lets take a quick glance at the status provided for each ActiveSync transaction provided in the MailboxLogReport

$1.MailboxLogReport | Out-file C:tempmobiledevicedebuglog.txt
$Text = “<status>”
$statuscheck = Get-Content C:tempmobiledevicedebuglog.txt | Select-String -Pattern $Text
$statuscheck

This should provide a long list of StatusCodes.  Usually a status of 1 (<status>1</status>) down the list is great!

BUT if you receive other statuses, then we may have to dive deeper into figuring out what the status means related to the ActiveSync command which caused it.  To do this, you will need to do the following:

1. Navigate to the Microsoft document which provides a list of each ActiveSync Command and their status codes.  It can be found here.

2. Open the C:tempmobiledevicedebuglog.txt  which was created in previous steps and perform a find on that status code. In this example, we will use:  <status>2</status> as our questionable status.

3. Perform a search for that status and in the responsebody: found in the text file, that section should list the ActiveSync command that was attempted that produced a result.  For example our <status>2</status> was for the PING command.

Digging deeper, it appears the <status>2</status> for PING is fine because it just lets me know that: “Changes occurred in at least one of the monitored folders. The response specifies the changed folders.”  which is fine — no big deal. I found that status code  here.

BUT lets pretend I found a status 8 (<status>8</status>). This would be an issue that was caused/recognized by the Exchange  server.  Something like this could help in troubleshooting a server issue versus a client issue.