Overview

This article explains how to troubleshoot issues with Shared Calendars. Common symptoms related to these issues are:

• Users report issues with Accessing or Editing a shared calendar that they could previously access.

Workflow

Instructions

Each blue rectangle represents a troubleshooting procedure and links to a section in this article:

1. Recreate the event and attempt to reproduce.
2. Verify the Delegate Access Rights.
3. Verify the Sharing Access Rights.
4. Review Calendar Status.fld file.
5. Backup and Rebuild the CalDav DBs.
6. Isolate Differences between Affected and Unaffected Events.
7. Investigate Calendar Synchronization to the affected client.

Recreate the event and attempt to reproduce.

When a single event is exhibiting unexpected behavior, such as users with sharing rights being unable to view or edit the event, the individual event may have become corrupted. It is suggested that you first recreate the event using the same settings initially used to verify whether or not the behavior reappears.

Verify the Delegate Access Rights.

Within Kerio Connect, when a Shared calendar event contains more than one attendee, it is expected that only the event owner will be able to make changes to the event. In these situations, you can instead use Delegation, a more advanced form of sharing that enables this functionality. 

You can reference Configuring Delegation (On Behalf of) in Kerio Connect Client for guidance on setting this up for your Shared Resource.

Verify the Sharing Access Rights.

When users report issues specifically with viewing the shared Calendar or its events, this can often be traced back to incorrectly configured sharing settings. You can reference how to share calendars to verify that the users affected have been provided with the necessary access rights. 

Note that if you use user groups to share, you will want to confirm that the expected individuals appear within these groups, as shown in Managing User Groups in Kerio Connect.

Review Calendar Status.fld File

If all of the expected Sharing and Delegation settings appear valid within the Kerio Connect Client UI, this may indicate an issue on the backend. To help isolate the behavior, you should collect and review the status.fld file from the mail store in the filesystem. The path will depend on your server's configuration and the affected shared Calendar. 

By default, for a user calendar, this will be similar to the following path:

• /store/mail/<domain>/<user>/<shared_calendar>/status.fld

The Calendar's status.fld file will contain all of the sharing details as shown within Shared Calendar is not visible. If you identify incorrectly defined or missing sharing details, resharing the affected Calendar with the steps within this article will force a rebuild of the sharing information.

If you identify that the sharing details appear valid or you have corrected the status file, and the issue persists, this may indicate that the CalDav DB has become corrupt.

Backup and Rebuild the CalDav DBs.

When the status.fld file sharing details are valid, but the expected sharing behavior continues to show issues, this often indicates that the CalDav DB may have become corrupt. You can reference the steps within Fixing corrupted Calendars and Contacts to recreate these.

If the issue persists, you should Recreate the Calendar and attempt to reproduce this behavior within Webmail directly.

Isolate Differences between Affected and Unaffected Events.

If you continue to see issues after rebuilding the CalDav DB, collect additional details about the affected Calendar, Events, and Users: 

• Screenshots of what the affected users see.
• Identify whether other users are seeing the expected behavior.
• Collect a copy of the affected Event's ICS file:
  1. Navigate to Webmail  > Right-Click the event > Select "Forward as Attachment":
     
  2. From the email that appears, you can click the Event ICS file to open the raw event content directly:
     

Check the raw event body for signs of malformed data that might be causing the behavior. When possible, collect the same for an unaffected event within the same Calendar to compare. If a clear pattern is identified, you can make the necessary changes to the events.

If no clear pattern is found, it can be helpful to further isolate this behavior by recreating the shared Calendar and testing the behavior directly within Webmail. If specific users or groups are affected, you can focus this test on sharing to their account:

1. Log in to your Webmail portal and verify the current Sharing settings of the affected Calendar by selecting Sharing from the Arrow menu next to the Calendar:
   
2. You can then use these to recreate a copy of the Shared Calendar, starting with the affected users:
   
3. Once recreated, generate a copy of the affected calendar events within the new Calendar copy and confirm whether the issue persists.
   1. If the issue does not appear within the recreated Calendar using the limited settings, you can add the remaining users until you have isolated the setting responsible for the behavior.

If no apparent cause for the issue is found using the test above, or you encounter any difficulties completing these steps, please open a Support Ticket and include the collected details for further review.

Investigate Calendar Synchronization to the affected client.

When you cannot reproduce the issue within WebMail, this is usually an indication that the Calendar client is experiencing a Synchronization issue, does not support the affected behavior, or is otherwise in need of review. 

You can review the articles below to help further isolate the issue within the client:

• Troubleshooting a Calendar that does not Synchronize Automatically (KOFF)
• Calendar Items Not Syncing in Outlook
• Some Calendar Items Are Not Syncing to the Samsung Device