The following issues are mostly due to buggy clients and/or variable implementation details between clients. In most cases there is nothing Horde can due to work around these issues.
To start with, not all devices support this. Of those that claim to, some do not implement it correctly. For example, Android clients send broken Autodiscover requests where they pass the full email address as the username in the HTTP Authorization data, and don't even bother with sending the XML request. We work around these issues where we can, but simply cannot work around every single possible device issue. If Autodiscover fails, you simply have to configure the client manually - usually not more than an additional one or two fields.
This occurs whenever the ActiveSync client issues a request, the server processes, but the client either never receives the response, or receives a response that it does not understand. The client then reissues the request (along with the same SyncKey). Since the server already processed the request for the specified SyncKey, it leads to a duplicate PRIMARY key error. Since this is expected from time to time, the ActiveSync library deletes the sync state tied to the key causing the error and tries again. If this happens too many times in a row, the client will usually throttle the connection and notify the user.
Bottom line, if you do not see any this often, and you notice no issues with synchronization, this is normal and nothing to worry about.
Outlook 2013 with EAS (OL2013) shows the permanent message "This folder hasn't yet been updated, connection attempt" even if the folder synchronization is OK.
The problem occurs when the "Outlook Mail Notifier" addin (c:\Program Files\Common Files\Apple\Mobile Device Support\OutlookChangeNotifierAddIn.dll) is enabled.
Disabling this addin in OL2013 will solve the problem.
Push email may fail completely in iOS6, requiring manual email checking. There are also issues with meeting requests and responses that can cause incorrect response/cancellation emails to be sent out.
Messages that are over a certain size will always display the This message was downloaded as plain text message along with a button to download the message. Attempting to download the message results in an error displaying the email. This is an issue (feature?) with iOS. Viewing the attachments by clicking the download link for each attachment works as expected.
iOS devices attempt to move the email to the Trash folder on the client side instead of sending a move command to the server as the protocol dictates. This means that if there is no configured Trash folder on the device, the deletion will fail. If using iOS, you MUST have IMP configured to use move messages to a Trash folder on deletion.
Some ActiveSync clients automatically append the citation line to outgoing reply text. Due to this, and the way Smart Reply works in ActiveSync this can lead to duplicate citation lines when replying to email on these clients.
ActiveSync will NOT work with the following IMAP servers due to bugs in the specified versions:
Cyrus IMAP 2.4.x < 2.4.17 - Due to a bug in the BINARY extension. See https://bugzilla.cyrusimap.org/show_bug.cgi?id=3718. Workaround: disable BINARY extension in IMP's backend configuration, e.g.: $servers['advanced']['capability_ignore'] = array('BINARY');.
Events that recur every X years, on the same day-of-year - the number of days into the year 1 - 365 (or 366 on leap years) are NOT supported in the ActiveSync protocol. The only yearly recurring events that are supported are events that recur on the same date every year, or occur on the same week-of-month/dayof-week combination (e.g., 3rd Saturday of March). Prior to Horde_ActiveSync 2.30.6 these events would appear on every day of the year in the client's calendar. This was fixed in 2.30.6 to show them only once every X years - but not necessarily on the correct day-of-year.
iOS 6.x through 7.x has major issues dealing with creating event exceptions on the device. Mostly due to using the internal GUID as the server id. Creating any exceptions on the device could completely replace/remove the original recurrence series. Syncing certain server changes to recurrence series can also cause the series to become corrupt on the device. See:
iOS requests truncated event description body content. However, iOS never requests the remaining body content before allowing the event to be edited. Therefore, when editing such an event, it's the truncated text of the description that is sent back to the server, overwriting the full description text. EAS 16.0 is was supposed to help prevent this by allowing ITEMOPERATION requests on calendar data, but as of yet, this part is not implemented in iOS' EAS 16.0 support.
In certain versions of iOS if a contact is edited on the iOS device, iOS may send an empty Picture element back to the server, thus causing the picture to be removed. There is no workaround for this other than updating to a more recent version of iOS. This was verified to have started sometime after 6.1.3 and to have been resolved to sometime before, or on, 8.1.3.
Update: Looks like this was broken again sometime around iOS 9.3.1. See Ticket: 14361.
iOS 4.2.1 behaves different: When a contact is edited, no Picture element is included if the picture is left unchanged. Since the device never announced it does incremental updates to contacts ("ghosted" elements), we must delete the contact picture on the server side.
This is a known issue with most ActiveSync clients. It's due to the fact that the specification does not indicate a standard time to represent birthdays at during the day. As a result, clients represent the birthday field in a number of different ways. Recent versions of Horde_ActiveSync attempt to detect the client in use and adjust the time accordingly, but there are still likely clients out there that this is broken on.