Calendar synchronisation is unable to process changes quickly enough causing packets to be dropped and calendars to become out of sync permanently.
QCS calendar synchronisation process was designed to only handle less than 2300 individual calendar changes during a sync delta, once this number is exceeded QCS begins to queue data to process until a point is reached where queued data itself is deleted. Once this point is reached calendars become out of sync and never get back into sync.
Note: When a user sends a calendar invite to a user on Exchange 2010 the invite is automatically added to the users calendar as a tentative invite, this is seen by QCS as once change. This is also observed on Exchange 2013/2016. The user accepting the invite is another change and if the user then makes a further change to the invite that would be considered a further change. Typically a single calendar invite could lead to 3 or 4 changes that QCS would need to replicate. QCS is concerned with the number of calendar changes rather than number of users so even if the number of actual mailboxes in sync may be relatively low, the calendar activity for those mailboxes may be high and it is this that can cause the issues.
In order for QCS to handle large number of Calendar changes (>2300) per delta, Quest recommends that multiple instances of QCS be installed. The total number of mailboxes to be synchronized can then be split across multiple instances ensuring each instance can process all changes within a given delta sync.
In order to ensure group membership of groups including Query Based Distribution Groups are correctly populated all user objects and Groups must be published as part of the same instance.
For Calendar subscriptions to correctly match with the AD user stub objects it is strongly recommended all instance of QCS must use the same Quest Collaboration Services Objects container.
For further details on how to scale QCS correctly please contact Quest Professional Services:
