Tales of the Weird: One User Not Able to use any ActiveSync Device or OWA will not work.
It's been a while, so here's another case from the "Tales of the Weird and Unusual" bin at Microsoft Exchange Support. I recently was working a case with a customer where they were having issues with one user syncing their ActiveSync device to Exchange. They were an environment which was primarily on Exchange 2010, however in our testing it would have affected Exchange 2013 or Exchange 2016 as well.
What we discovered about this user is that no matter what device they had for ActiveSync, they would be unable to get everything to their ActiveSync device. We also tried to connect to the Mailbox in OWA and we would get log in, but then the web page would just sit there and spin.
Normally when we have one user who cannot sync like this, two big items come to the forefront of what can cause it.
1. Issue with the load balancer
2. Corruption within the mailbox.
We then bypassed the load balancer, and we were getting the same results. Because no other users were reporting issues (for example, in a server performance case) we migrated the mailbox to a new database on a different server. When we move a mailbox we do a corruption check, and thus if we have any corrupted items those can be identified. However, after the mailbox move, we were still encountering the same issues - Active Sync would not complete, and we could not use the mailbox in OWA. However, Outlook in cached mode worked just fine.
At this point we enabled Active Sync Mailbox Logging which proved useful.
ActiveSync Mailbox Logging often times will scare people because of the verbosity and type of information we are able to get from it. However it can be very useful when troubleshooting sync issues such as these, as the Active Sync protocol is well documented and in some cases, we can see what happens from the mailbox side of things when gathering IIS logs is not prudent or useful.
When we reviewed the Active Sync logs, we kept seeing the following repeatedly:
RequestHeader :
POST /Microsoft-Server-ActiveSync/default.eas?User=User@Contoso.com&DeviceId=MYDEVICEIDISREMOVED&DeviceType=WindowsMail&Cmd=FolderSync HTTP/1.1
Connection: keep-alive
Content-Length: 13
Content-Type: application/vnd.ms-sync.wbxml
Accept: */*
Accept-Encoding: br, gzip, deflate
Accept-Language: en-us
Authorization: ********
Host: 192.168.0.10
User-Agent: MyDeviceID
MS-ASProtocolVersion: 14.1
X-MS-PolicyKey: 0
X-Forwarded-For: 192.168.0.1RequestBody :
<?xml version="1.0" encoding="utf-8" ?>
<FolderSync xmlns="FolderHierarchy:">
<SyncKey>0</SyncKey>
</FolderSync>
So, the key here I've highlighted above. What we kept doing was a folder sync repeatedly. When we look at our documentation for why we were seeing this, on https://msdn.microsoft.com/en-us/library/ee237648(v=exchg.80).aspx we state the following:
The FolderSync command synchronizes the collection hierarchy but does not synchronize the items in the collections themselves.
This command works similarly to the Sync command (section 2.2.1.21). An initial FolderSync command with a SyncKey element (section 2.2.3.181.2) value of 0 (zero) is required in order to obtain the list of folders and the synchronization key associated with that list. The synchronization key is returned in the SyncKeyelement of the response if the FolderSync command succeeds. This synchronization key is used in subsequent FolderSync commands to obtain folder hierarchy changes.
Unlike a Sync request, there is no GetChanges element (section 2.2.3.84) submitted in the FolderSync request (section 2.2.1.5) to get changes from the server. All folders MUST be returned to the client when initial folder synchronization is done with a synchronization key of 0 (zero).
The FolderHierarchy namespace is the primary namespace for this section. Elements referenced in this section that are not defined in the FolderHierarchynamespace use the namespace prefixes defined in section 2.2.4.
Simply put, we were not able to complete the FolderSync within the allowed time period.
We then went and revisited the user's mailbox to see if we can determine how many folders we were trying to sync. We did this via the Get-MailboxFolderStatistics -Identity user@contoso.com -FolderScope Inbox |Select Name,FolderSize,ItemsInFolder command, but there are a number of different ways you can do this.
You will see something similar to below:
In my test lab, we don't have many folders configured, however in our users case we found over 40,000 folders. This in almost all instances is going to cause performance issues when attempting to connect via ActiveSync or OWA, no matter our Exchange version.
We have some very well documented limits for Outlook, as available here. We know if we get above 500 folders, then we can have performance issues inside of the Outlook client. We also have limits for Exchange 2010/2013/2016 and Exchange Online. Note, our limits for Exchange 2010 are significantly different from Exchange 2013/2016/Exchange Online!
However, in our case for Exchange 2010, which is where this mailbox was hosted, we were significantly over the limits for Exchange 2010. Since Exchange 2010 is also at End of Life we will be migrating to a newer version of Exchange we know migrating a user with over 40,000 folders will be almost impossible.
Once we were able to get the user to our guidance and under 500 folders, the issue disappeared and the end user was able to sync again.