calendar_integration

The Advanced Calendar Integration settings enable you to adjust calendar integration settings specific to your network.

NOTE: The default calendar integration settings are optimal in most cases. You should only modify them if you have some special requirements, such as high network latency. These settings are applied globally, across all enterprises.

Google Calendar Settings:

Calendar duration per fetch: Determines how much calendar information is retrieved each time a fetch is performed. The recommended value is 24 hours worth of information - see Note 3.
Calendar onpeak fetch Interval: Determines how often the calendar information is fetched during the onpeak time period . The recommended value is to poll calendars every 45 minutes. The range is 5 to 480 minutes - see Note 4..
Calendar offpeak fetch interval: Determines how often the calendar information is fetched during the offpeak time period . The recommended value is to poll calendars every 240 minutes. The range is 5 to 1440 minutes - see Note 4.
Start peak time: Peak period start time, default is 0700 hours. The allowed range is 0000 to 2359 - see Note 4.
End peak time: Peak period end time, default is 1730 hours. The allowed range is 0000 to 2359 - see Note 4.
Request accumulation delay: Determines the delay to accumulate free/busy requests. The range is 1 to 300 seconds; the default is 30. Lower values may result in unnecessary duplicate event fetches from the Google server – as the server can send multiple event notifications for a single calendar event creation or deletion.
Maximum users per fetch: Fetch at most 20 calendars per poll request (recommended). The range 1 to 20. Higher values will result in fewer (but larger) network requests. Lower values will result in more (but smaller) network requests.

Common Settings:

Parallel connections: Determine the number of parallel connections to the server. The recommended value is 6. Higher values can be useful in the case of high network latency. Higher values also result in higher network loads.
Connection timeout: Determines how long the connection can be lost before a timeout is flagged. The recommended value is 30 seconds.
Error limit: Determines how many timeouts can occur while communicating with the Google server before the MiCollab Client Service temporarily suspends communication with the Google server. The recommended value is 5 timeouts. Higher values cause the MiCollab Client Service to tolerate more timeouts from the Google server - see Notes 1 and 2.
Error duration: Determines the time interval within which timeouts are considered. For example, if the Timeout Duration is 5 minutes (which is the recommended value), then timeouts that happened before 5 minutes are not considered when determining whether or not to temporarily suspend communication with the Google Server - see Notes 1 and 2.
Retry delay after errors: Determines how long MiCollab Client suspends communication with the Google server before retrying. This applies to most errors caused due to admin configuration, or some issue with MiCollab Client-Google server communication. The default value is 15 minutes - see Notes 1 and 2.

NOTE 1: The Error limit, Error duration, and Retry delay after errors parameters are used for timeout error throttling. In other words, when <Error Limit> timeouts happen within <Error Duration>, then the MiCollab Client Service waits for <Retry delay> before re-initiating communication with the Google server. Before MiCollab Client retries, the administrator can at any time test the connection with the Google server from the Enterprise tab, apply the settings, and cause MiCollab Client to immediately start communicating again.

NOTE 2: Similar to the above note, non-timeout errors (such as incorrect authentication credentials, network reachability issues, etc.) will cause the communication with the Google server to be disabled and retried after <Retry delay> interval. When the communication is disabled, the MiCollab Client administrator can change settings, apply the changes and cause MiCollab Client to immediately retry the communication again.

NOTE 3: By default, the Calendar Integration Module retrieves 24 hours of calendar information for a user, starting at the present time. Once the first 15 hours elapse, the Calendar Integration Module once again retrieves information for the next 24 hours. If, during those first 15 hours, any calendar events are created/delete/modified, then the Calendar Integration Module will again retrieve 24 hours of information starting at the current time.

NOTE 4: Google calendar imposes a daily limit (10,000 requests by default) on how many requests can be made to it. To conserve the number of Google requests, MiCollab Client allows the Administrator to setup an onPeak interval during which time, the polling is done frequently. Outside of this time (for example, outside of normal office hours), the polling frequency is reduced, thus reducing the number of requests. If you need a bigger quota (more than 10,000 requests per day), please login to the console at https://code.google.com/apis/console#access and request more Quota.

Exchange Calendar Settings:

Calendar duration per fetch: Determines how much calendar information is retrieved each time a fetch is performed. The recommended value is 24 hours worth of information - see Note 3.
Calendar fetch Interval: Determines how often the calendar information is fetched. The recommended value is 15 hours - see Note 3.
Event subscription notification frequency: Determines how often subscription information is sent. The recommended value is 90 minutes. Lower values result in more subscription traffic and processing. Higher values will reduce processing but delay the detection of possible subscription losses on the exchange server.
Subscription delay: Determines the delay after each subscription is performed. The recommended value is 50 milliseconds. Lower values result in spikes of traffic and CPU. Higher values increase the amount of time taken to subscribe all users.
Request accumulation delay: Determines the delay to accumulate free/busy requests. The range is 1 to 10 seconds; the default is 10. Lower values may result in unnecessary duplicate event fetches from exchange server – as the exchange server can send multiple event notifications for a single calendar event creation or deletion.
Maximum users per fetch: Fetch at most 100 calendars per poll request (recommended). The range 10 to 100. Higher values will result in fewer (but larger) network requests. Lower values will result in more (but smaller) network requests.

Common Settings:

Parallel connections: Determine the number of parallel connections to the server. The recommended value is 6. Higher values can be useful in the case of high network latency. Higher values also result in higher network loads.
Connection timeout: Determines how long the connection can be lost before a timeout is flagged. The recommended value is 30 seconds. Higher values will wait longer for the calendar server to respond, but can delay the detection of unresponsiveness.
Error limit: Determines how many timeouts can occur while communicating with the Exchange server before the MiCollab Client Service temporarily suspends communication with the Exchange server. The recommended value is 5 timeouts. Higher values cause the MiCollab Client Service to tolerate more timeouts from the Exchange server - see Notes 1 and 2.
Error duration: Determines the time interval within which timeouts are considered. For example, if the Timeout Duration is 5 minutes (which is the recommended value), then timeouts that happened before 5 minutes are not considered when determining whether or not to temporarily suspend communication with the Exchange Server - see Notes 1 and 2.
Retry delay after errors: Determines how long MiCollab Client suspends communication with the Exchange server before retrying. This applies to most errors caused due to admin configuration, or some issue with MiCollab Client-Exchange server communication. The default value is 15 minutes - see Notes 1 and 2.

NOTE 1: The Error limit, Error duration, and Retry delay after errors parameters are used for timeout error throttling. In other words, when <Timeout Limit> timeouts happen within <Timeout Duration>, then the MiCollab Client Service waits for <Retry delay> before re-initiating communication with the Exchange server. Before MiCollab Client retries, the administrator can at any time test the connection with the Exchange server from the Enterprise tab, apply the settings, and cause MiCollab Client to immediately start communicating again.

NOTE 2: Similar to the above note, non-timeout errors (such as incorrect authentication credentials, network reachability issues, etc.) will cause the communication with Exchange server to be disabled and retried after <Retry delay> interval. When the communication is disabled, the MiCollab Client administrator can change settings, apply the changes and cause MiCollab Client to immediately retry the communication again.

Advanced Calendar Integration Settings