Calendar Data Source FAQ

How to Choose the Right Calendar Data Source?

SyncSign supports multiple calendar data sources. You can choose the appropriate one based on your environment and requirements:

Calendar Data Sources

Data Source Type	Use Case	Deployment Method	Notes
Google Calendar	Personal or small teams	Cloud (SaaS) / On-Premise (SOPS)	Easy to configure
Google Workspace	Enterprise Google Workspace	Cloud (SaaS) / On-Premise (SOPS)	Supports organization management & resources
Office 365	Microsoft 365 users	Cloud (SaaS) / On-Premise (SOPS)	Supports organization management & resources (Delegated & App auth)
Exchange Server	On-premise Exchange deployment	On-Premise (SOPS)	Requires SOPS server
NextCloud	Self-hosted CalDAV server	On-Premise (SOPS)	Requires SOPS server
CSV URL	Custom data source	On-Premise (SOPS)	Requires SOPS server

Note

• Cloud deployment (SaaS): Suitable for most users, simple configuration, no local server required

• On-premise deployment (SOPS): Suitable for enterprises with special data security requirements, all data stays within the corporate network

Cloud Calendar Webhook Endpoint for SOPS Must Be Publicly Reachable

Does privately deployed SOPS need a public endpoint for cloud calendars?

Yes, if you enable real-time calendar synchronization with cloud calendar providers such as Microsoft 365 / Exchange Online or Google Calendar / Google Workspace.

SOPS can be deployed inside the customer’s private network. However, cloud calendar providers send calendar change notifications to SOPS through a webhook / push notification mechanism. For this to work, the provider must be able to reach the SOPS webhook notification URL from the public Internet over HTTPS.

Typical symptom:

• Microsoft Graph returns HTTP 400 while registering an Office 365 calendar watch / webhook subscription.

• The error indicates that the notification URL resolves to an unsafe, private, or non-public IP address.

• The configured SOPS domain resolves to a private address such as 10.x.x.x, 172.16.x.x - 172.31.x.x, or 192.168.x.x.

In this case, the issue is usually not the Azure Redirect URI, Google OAuth redirect URI, or the webhook URL string format. The root cause is that the cloud provider cannot access the SOPS webhook endpoint from the public Internet.

Why this is required:

• For Microsoft 365 / Exchange Online, Microsoft Graph must validate and call the SOPS notificationUrl when a calendar subscription is created and when calendar changes occur.

• For Google Calendar / Google Workspace, Google Calendar push notifications must be delivered to the webhook callback URL configured for the watch channel.

• If the domain resolves only to an internal IP address, cloud services cannot complete the subscription validation or send change notifications.

Required configuration:

1. Configure the SOPS domain, for example syncsign.example.com, to resolve publicly to a public IP address, public load balancer, or public reverse proxy.

2. Ensure the public endpoint can forward HTTPS / TCP 443 traffic to the SOPS webhook service.

3. Install a valid SSL certificate issued by a trusted public certificate authority.

4. Restrict inbound access with firewall or WAF rules where possible, for example by allowing only the calendar provider’s webhook notification traffic.

5. Expose only the webhook path if your security policy does not allow exposing the full SOPS management portal.

6. After DNS, HTTPS, and firewall changes are complete, trigger the calendar watch / webhook registration again.

Note

Private deployment can still be retained. The requirement is only that the cloud calendar webhook notification endpoint has a controlled public HTTPS entry point.

See also: From Internet to SOPS (Inbound, for Data Source)

Office 365 Related Issues

Which Microsoft Graph Permission Type Should I Configure?

The permission type depends on the SyncSign deployment:

• SyncSign Cloud (SaaS) uses Microsoft Graph Application permissions for its application authorization flow. Configure Calendars.Read and User.Read.All as Application permissions and grant tenant administrator consent.

• SyncSign On-Premise Server (SOPS) supports Delegated OAuth only and accesses calendars on behalf of the signed-in user. SOPS does not use Application permissions or Global Admin authorization mode.

For SOPS, configure the Microsoft Entra app as follows:

1. Set Supported account types to Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant).

2. Open https://<Your-SOPS-Domain>/o365 and copy the complete Authorized Redirect URI into the app registration’s Web redirect URIs.

3. Add User.Read, Calendars.Read, and offline_access as Delegated permissions.

4. Add delegated Calendars.Read.Shared when SOPS must access shared calendars or room resources.

5. If meeting write operations are enabled, also add delegated Calendars.ReadWrite and Calendars.ReadWrite.Shared.

Do not copy the Cloud Application-permission configuration into the SOPS app registration. SOPS cannot switch to Application permissions as an alternative authorization or troubleshooting mode.

For the complete SOPS setup, see Using Microsoft 365.

Microsoft 365 Compatibility

Which Microsoft 365 licenses are supported?

SyncSign is designed to integrate seamlessly with standard Microsoft Business solutions. We support most commercial plans, including but not limited to:

• Microsoft 365 Business Basic

• Microsoft 365 Business Standard

• Microsoft 365 Business Premium

As long as your organization uses a standard commercial environment, SyncSign can integrate with your Exchange Online calendars.

Note

In general, any commercial Microsoft 365 plan that includes an Exchange Online mailbox and provides Outlook Web access can, in principle, be used as the authorized login account for integrating SyncSign with Microsoft 365 / Exchange Online. Since SyncSign connects to Microsoft 365 through Microsoft Graph, the integration is not bound to a specific commercial plan tier (such as Business, Enterprise, Education, or Frontline); it only requires that the assigned license grant the user an Exchange Online mailbox.

Does SyncSign support Microsoft GCC or GCC High?

SOPS supports Microsoft 365 GCC High. When entering the Microsoft Entra application credentials in the SOPS Portal, select the GCC High Plan so SOPS uses the US Government .us endpoints. Select Business for standard commercial Microsoft 365 tenants.

Microsoft GCC, DoD, and other government cloud environments are not covered by this setup. Contact SyncSign Support before deploying to one of those environments.

Can I use a personal Microsoft account?

• SyncSign Cloud supports personal Outlook.com or Microsoft accounts where the selected Cloud integration flow allows them.

• SOPS requires a work or school account in a Microsoft Entra organization. The SOPS app registration uses Accounts in any organizational directory (Multitenant) and does not support personal Microsoft accounts for the Exchange Online integration.

Room/Calendar Not Appearing in SyncSign Client

If SyncSign displays some Microsoft 365 calendars but not all expected room resources, the Microsoft 365 authorization is usually active. The next step is to determine whether the missing room is absent from Microsoft Graph’s calendar list or is being omitted by SyncSign.

For SOPS, this authorization is always Delegated OAuth. The signed-in Microsoft 365 account must be able to discover and access every calendar or room resource that will be bound to a Display.

1. Preserve the Current Authorization Session

Before contacting SyncSign Support, do not unbind the current calendar, remove the Microsoft 365 integration, or re-authorize the Microsoft account. The current Display binding may be needed to obtain read-only Microsoft Graph evidence for the investigation.

2. Information to Provide

Please provide:

• The SN of any Display that is currently bound to a Microsoft 365 calendar

• The full display name and Primary SMTP Address of each missing room resource

• A screenshot of the calendar list in Outlook showing the missing entries

The Display SN allows SyncSign Support to identify the current authorization account, authorization route, bound calendar, and calendars returned by Microsoft Graph. Do not send Microsoft 365 passwords, access tokens, device keys, or client secrets.

3. Verify the Missing Resource and Delegate Permission

Ask a Microsoft 365 administrator to connect to Exchange Online PowerShell and run the following commands for each missing room.

Confirm the mailbox type:

Get-EXOMailbox -Identity "<room email>" |
  Select-Object DisplayName, PrimarySmtpAddress, RecipientTypeDetails

For a room resource, RecipientTypeDetails should normally be RoomMailbox.

For SOPS or SyncSign Cloud Delegated User mode, confirm the calendar-folder permission:

Get-EXOMailboxFolderPermission `
  -Identity "<room email>:\Calendar" `
  -User "<delegated user email>" |
  Select-Object User, AccessRights, SharingPermissionFlags

The delegated SyncSign account should normally have at least Editor access; delegated room configurations may also show the Delegate sharing flag.

Note

SOPS does not provide Application permissions or Global Admin authorization mode. Do not change the SOPS Microsoft Entra app to Application permissions while troubleshooting a missing calendar. Application-permission troubleshooting applies only to a SyncSign Cloud integration configured for that authorization mode.

4. Outlook Grouping Is Not Conclusive

Outlook’s My Calendars, Other Calendars, and similar sections are user-interface groupings. A room shown under My Calendars is not guaranteed to be returned by the Microsoft Graph /me/calendars collection used for delegated calendar discovery.

Adding a room through Add calendar → Add from directory or moving it to My Calendars may be tried later as a workaround, but its Outlook location does not prove that SyncSign can enumerate it.

5. How SyncSign Support Distinguishes the Cause

Using the current authorization session, SyncSign Support can compare the calendars returned by Microsoft Graph with the calendars shown in SyncSign and directly test the missing room mailbox.

• If the room is absent from the delegated account’s calendar list but direct room access succeeds, the account has access and the issue is a calendar discovery/enumeration limitation, not a missing Exchange permission.

• If Microsoft Graph lists the room but SyncSign does not, the issue is within SyncSign’s calendar-list processing.

• If direct room access is denied or the mailbox is not found, recheck the room email address, mailbox type, and Exchange permission.

After this evidence is collected, SyncSign Support may ask a SOPS user to re-authorize the delegated Microsoft 365 account or correct its calendar-folder access. SOPS should not be switched to Application permissions. For SyncSign Cloud, follow the troubleshooting steps for the authorization mode configured in that deployment. Do not change the current integration before Support has collected the evidence above.

Display Synchronization Refresh Failure

1. Check Microsoft 365 Account Permissions

The Microsoft 365 account used to authorize login in the SyncSign client may have lost management permissions for the calendar (room resource) bound to the Display.

Troubleshooting steps:

1. Go to the SyncSign client and navigate to the Display configuration page

2. Unbind the Display from the calendar

3. Re-bind the Display to the calendar

Expected results:

• If binding succeeds: Observe whether the Display can synchronize and refresh the calendar information

• If binding fails: Please contact us and provide error screenshots for further troubleshooting and analysis

2. Integration Failure Due to Client Secret Expiration (SOPS Deployment)

The most common reason is that the Client Secret for the Azure App has expired. Once this date is reached, Microsoft rejects connection requests from SyncSign, causing the synchronization to fail.

Fix (typically takes only 5 minutes):

1. Log in to the Azure Portal and locate the specific App

2. Generate a new Client Secret

3. Immediately copy the new Secret Value and update it in your SOPS system configuration settings

4. Once saved, the integration will be restored immediately

Event Title Shows Organizer Name Instead of Event Subject

By default, Office 365 room resources are configured to display the organizer’s name instead of the actual event title. This means SyncSign displays may show the organizer’s name rather than the meeting subject.

Solution:

Please refer to: Modify the Settings of the New Room Resource

This document provides step-by-step instructions on how to modify the room resource settings using PowerShell or Azure Cloud Shell to ensure event titles are preserved and displayed correctly on SyncSign displays.

Other Issues

If the above solutions do not resolve your issue, or if you need additional assistance, please feel free to contact us:

• Website: https://help.sync-sign.com

• Email: help@sync-sign.com