Advanced Calendar Integration Settings

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 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: 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: 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: 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: 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.

MS Exchange

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: 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: 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.

MS Office 365

The authentication protocol for Calendar Integration with Office365 can be either Open Standard for Authentication 2.0 (OAuth 2.0), OAuth 2.0 (Microsoft Graph) or Basic Authentication protocol.

A service account with a valid Office365 user license is required to enable the mailbox.

Basic Authentication mechanism is a process where the username and password are provided for authentication purposes, whereas in case of OAuth 2.0, tokens are being used for authorization.

OAuth 2.0 (Microsoft Graph) also uses the OAuth 2.0 tokens with difference being instead of Exchange it uses Microsoft Graph Server APIs to fetch the calendar details.

For initial details on configuration, refer to MiCollab Users and Services Provisioning > Configuration > Cloud Service Provider section.

Once the configuration under Cloud Service Provider is successful, the MiCollab Administrator can enable Calendar integration from MiCollab Client Services.

Perform the following steps under MiCollab Client Services:

Navigate to the Applications > MiCollab Client Services > Enterprise.
Under Calendar Integration, select the Calendar Type as MS Office365.
Select the Authentication Protocol for Office 365 as:
- Basic,
- OAuth 2.0, or
- OAuth 2.0 (Microsoft Graph)
  
  In order to enable OAuth 2.0 or OAuth 2.0 (Microsoft Graph), the administrator must select the respective Authentication Protocol's radio button.
Note:
The API permission for MS Graph must be given to app in Azure Active Directory.

Note: The administrator must test the connection to switch between OAuth 2.0 (Microsoft Graph) and OAuth 2.0

Note:
The Username field is mandatory to configure the calendar integration with Office 365 using OAuth 2.0 protocol.

The Username should be a primary SMTP address.
For Exchange Subscription Type, the default option selected is Impersonation if OAuth 2.0 (Microsoft Graph) is selected as Authentication Protocol. It will be applicable for all 9.6 servers including the new deployed and upgraded servers.

Note: After a backup restore, the client credentials will not be part of the MiCollab backup. Therefore, the admin must reconfigure OAuth 2.0 settings at the Cloud Service Provider section and then enable Calendar Integration.

Note: Default subscription type is not supported in Calendar Integration for Office 365 with OAuth 2.0 Authentication Protocol.

↑