Frequently Asked Questions

Please note: The approach described in this document was added in v. 4.2.

User debugging consists of two elements:

1. API logging to see what traffic is being sent between the OnTime Group Calendar clients (or API) and the OnTime Group Calendar server.
2. Extended synchronization logging that  enabled to the user in question to help diagnose specific sychronization issues for a particular user. This is similar to enabling extended log in an OnTime Server Document for only for specific users and is hence much more lightweight.

Prior to v. 4.2 user synchronization logging and API logging was enabled separately and in different ways. This is now much easier to enable.

Enabling user debug for one or more users are done as follows:

1. Open the OnTime Group Calendar Configuration database.
2. Go to the "Users" view in the left hand navigator.
3. Select the user(s) to enable/disable user logging for.
4. From the action bar select "Selected/Debug/Enabled" to enable debugging and "Selected/Debug/Disable" to disable debugging.
5. A magnifying glass is shown to the right of the names where user debugging is enabled.
6. Now reproduce the issue and send the OnTime Group Calendar log database to OnTime support as arranged with us.

Remember to disable user debugging once the issue has been reproduced.

No, the OnTime Group Calendar 9 series and the OnTime Group Calendar version 7 / 8 are two totally different products and therefore also have seperate license keys.

Please contact your prefered OnTime partner or IntraVision in order to retreive a new license key.

OnTime Group Calendar is fault tolerant and support clustering on Domino but please note that not all databases in the OnTime Group Calendar installation should be clustered. The API database and the Web database are only used to serve up the Web and Mobile interfaces and to temporarily store documents related to the OnTime Group Calendar API. These two databases are not designed for clustering and hence should not be clustered as it may cause the clients to fail. Whether you choose to cluster the log database is up to the customer.

You may run OnTime Group Calendar even though you are running multiple domains in your Domino environment but it does pose some additional challenges when names and groups need to be resolved. In general the only requirement that OnTime Group Calendar imposes when running in multi-domain configuration is that all the Domino Directories from the other Domino domains must be replicated to the Domino server running the admin-task. OnTime Group Calendar does not however require Directory Assistance or similar to be configured.

Configuring the multi-domain option is very simple and generally only consists of adding references to the various Domino Directory databases and mapping each to a Domino domain. This is very clearly described in the OnTime Group Calendar Installation manual.

Resolving groups

When using the multi-domain option special care needs to be taken when group names are specified. All group names may have the domain name appended to explicitly tell OnTime Group Calendar which Domino Directory to use when resolving the group. If nested groups are used they are resolved against the same Domino Directory as the parent group. If no domain is specified for a group OnTime Group Calendar will look to the group in allconfigured Domino Directory databases and resolve the group as being the combination of users from across directories.

Configuration example

Consider an Domino environment with three domains called US, EU and JP and an organizational certifier called /ACME. The OnTime Group Calendar admin-task is designated to run on the OnTimeServer/ACME server in the EU domain. To enable the multi-domain option the administrator would perform the following steps:

1. Replicate the Domino Directory for the US and JP domains to the OnTimeServer/ACME server in the EU domain.
2. In the OnTime Group Calendar configuration database enable the multi-domain option mapping each Domino Directory to the corresponding domain.
3. Make sure all groups used in the OnTime Group Calendar configuration is qualified with a domain name. E.g. the group SalesEurope from the EU Domino Directory should be SalesEurope@EU to explicitly tell OnTime how to resolve the group.

Group resolving example

Imagine the following groups from the Domino Directories mentioned above.

EU domain

• SalesEurope (members: Jane Ellen/ACME@EU, Marc Rogers/ACME@EU)
• Administrators (members: Pete Sams/ACME@EU)

US domain

• SalesUS (members: Sales@US)
• Sales (members: John Ops/ACME@US, Eileen Hums/ACME@US)
• Administrators (members: Marc Willis/ACME@US)

JP domain

• SalesJP (members: Sales@JP)
• Sales (members: Jiro Tokyo/ACME@JP, Masuru Heiku/ACME@JP)
• Administrators (members: Jiro Tokyo/ACME@JP)

Below are examples from resolving the specified group names using the Domino Directories above.

• SalesEurope (result: Jane Ellen/ACME@EU, Marc Rogers/ACME@EU)
• SalesEurope@EU (result: Jane Ellen/ACME@EU, Marc Rogers/ACME@EU)
• Administrators@JP (result: Jiro Tokyo/ACME@JP)
• Administrators@US (result: Marc Willis/ACME@US)
• Administrators (result: Pete Sams/ACME@EU, Marc Willis/ACME@US, Jiro Tokyo/ACME@JP)
  Please note: Resolved against all directories as no domain name is specified for the group and the group exists in all directories)
• Sales@US (result: John Ops/ACME@US, Eileen Hums/ACME@US)
• Sales (result: John Ops/ACME@US, Eileen Hums/ACME@US, Jiro Tokyo/ACME@JP, Masuru Heiku/ACME@JP)
  Please note: Resolved against US and JP directories as no domain name is specified for the group name was found in both the US and JP directories.

Runs at midnight.

To run manually: Server Settings view, "Servlet Commands" / "Main Servlet" / "Cleanup log"

By default the OnTime Group Calendar Administration task ("admin") runs every night at 2am on the OnTime Group Calendar Administration Server. The admin-task can also be initiated on demand from the OnTime Group Calendar Config database or from the Domino Server console using "tell ontimegc admin". 

One of the purposes of the admin-task is to process information read by the synchronization process from mail files into the Configuration database such as mail file Access Control List (ACL), calendar settings profile document (work hours etc.) In OnTime Group Calendar each user has 3 documents:

• User document (maintained by the admin-task)
• Calendar document (maintained by the synchronization task, created on first synchronization of a user)
• Settings document

It's important to know that all user based calls to OnTime Group Calendar is processed from the "user document" and hence the admin-task is required to run to "bring in" information read from the mail file. For instance if a user changes his/her work hours in the mail file OnTime Group Calendar will first need to synchronize the user (reads information from the mail file into into the "calendar document") and then run the admin-task to transfer the information from the "calendar document" to the "user document". OnTime Group Calendar maintains a very strict separation between which tasks may write to which documents to avoid data corruption and save/replica conflicts.

Sometimes the admin-task will take a while to run - sometimes even a long time if you have many thousands of users in OnTime Group Calendar. This is of course because the admin-task does a lot of things from maintaning users from associated directories to maintaining groups and groups membership. That doesn't mean that moving the admin-task to a separate server cannot be a good idea as it certainly will optimize I/O but it describes why the task may take a while to run.

Please note:  For most organisations there should be no need to run admin during the day or even multiple times a day. It runs daily at 2am.

If you need to run the admin-task during the day consider using one of the sub-commands to tell the admin-task exactly what you would like it to do. If you only want to process static groups i.e. update group membership you could run "tell ontimegc admin gs" from the Domino Server console. 

All of the "sub commands" from the admin-task is available to be run separately as shown in the below table. The sub-commands are listed in the actual sequence they are run.

* When task loads on OnTime GC admin server
** Daily job that runs at 2am
*** Job that runs every hour

Please note: Starting from version 4.2.2 you can now control which admin sub-commands run on which days and on load in Global Settings. You also have the option of terminating a running admin-task by issuing the follow command on the IBM Domino Server console.

Set Config OnTimeGCAdmin=Quit

Internally in OnTime Group Calendar users are identified by a socalled OnTime ID which is a short, unique, ID. The OnTime ID first created for a user when he/she is brought into OnTime Group Calendar and is thereafter maintained by the administration task.

For each user OnTime records the fully distinguished name (DN, e.g. CN=John Doe/OU=Sales/O=Acme) as well as the UnID of the person document. Whenever a user is processed as part of the administration task the user in OnTime can be found using either the DN or the UnID. This means that a user in OnTime will keep their OnTime ID even though that are recertified (get new name, new organisational hierarchy) or a new person document is created for the same user (same DN). Since the OnTime ID stays the same the user also keeps their private groups.

It follows from the above, that a user cannot change both DN and Domino Directory UnID at the same time while keeping their OnTime ID.

Starting with OnTime Group Calendar v. 4.2, for each user connecting to OnTime Group Calendar, we log the client name (Application ID, ApplID) and the client version (Application Version, ApplVer). The information is logged automatically and saved to the user setting document for each user. To see the actual user settings documents do the following:

1. Assign the [Developer] role to your self in OnTime Group Calendar Configuration database.
2. Open the OnTime Group Calendar Configuration database.
3. In the "Developer" section on the left open the "Users Settings" view.

This view contains all the user setting documents. These documents has a number of backend fields - two fields per client (more specifically Application ID) as follows:

SettingsRead_<Application ID>_Ver
SettingsRead_<Application ID>_Time

For instance a user accessing OnTime Group Calendar using the OnTime GC Notes client (Application ID: Notes2011), Team-At-A-Glance sidebar component (Application ID: TAAG2011) and OnTime Group Calendar Mobile (Application ID: Mobile2011) will have the following 6 fields:

SettingsRead_Notes2011_Ver = "4.3.0.201507231633"
SettingsRead_Notes2011_Time = "03/08/2015 10:19:43 CEDT"
SettingsRead_TAAG2011_Ver = "4.3.0.201507231633"
SettingsRead_TAAG2011_Time = "31/07/2015 17:19:43 CEDT"
SettingsRead_Mobile2011_Ver = "4.2.2a"
SettingsRead_Mobile2011_Time = "12/07/2015 00:38:54 CEDT"

At the time of this writing this information is not surfaced in the user interface but is accessible using agents or manual access using the Document Property Explorer in Notes.

The below information must be set on the person document in Domino Directory for a person to be considered for import into OnTime Group Calendar. Please note that the user must also be included by the filter in Global Settings.

• User must have a mail server (field "MailServer" in Domino Directory)
• User must have a mail file (field "MailFile" in Domino Directory)
• User must have a fullname (field "FullName" in Domino Directory)
• User must have Mail System set to one of the following values:
  • "Notes mail" (field "MailSystem" set to "1" in Domino Directory)
  • "POP or IMAP mail" (field "MailSystem" set to "6" in Domino Directory)

If you use OnTime Group Calendar for Domino in a hybrid scenario where OnTime Group Calendar for Domino contains both Domino and Microsoft Exchange users the Microsoft Exchange users must be defined in Domino Directory. The person documents must also have the following fields set:

• User must have Mail System set to  something else than one of the following values:
  • "Notes mail" (field "MailSystem" set to "1" in Domino Directory)
  • "POP or IMAP mail" (field "MailSystem" set to "6" in Domino Directory)
• User must have an email address set (field "InternetAddress" in Domino Directory)

Please note: The email address is used to map from the users in OnTime Group Calendars to users in Microsoft Exchange.

The OnTime Group Calendar server task listens to events on the Domino servers being monitored in order for OnTime Group Calendar to synchronize calendar entries from mail files. Part of this process is discovering the replica ID of the databases to support OnTime clustering among other things. To discover the replica ID the OnTime Group Calendar server require access to the databases even though they may not be a mail database or an OnTime Group Calendar system database.

See a message similar to the following means that the OnTime Group Calendar server does not have access to the listed database:
OnTime-server01: WARNING: CN=Server01/O=OnTime!!IBM_ID_VAULT\MyIDVault.nsf: You are not authorized perform that operation

To not see the message the OnTime Group Calendar should have at least "No access w/ read public documents" access to the database. With this low access OnTime Group Calendar can discover the replica ID without having access to contained data.

Do you have problems launching OnTime GC Web after installing and setting up, then you can try to open the test page.

The test page can be found if you add "/test" after the normal path to the web database. http://<path>/<ontimeclient database (.nsf)>/test

Here you can, amongst others, validate if the path to the config database is correct. 

There can be 2 reasons to why you have to login every time:

1. Your administrator has not set the correct Acces Control on the web database regarding Anonymous access. Described in the Installation manual
2. You Domino environment use SSL and TCP Authentication for Anonymous is set to "No". Contact your Domino administrator

Cookies can be blocked by the browser, therefore check the security settings to set allow cookies for the website.

Please note: The below information pertains to HTTP based access to the OnTime Group Calendar API that is for OnTime Group Calendar Web, Mobile and Social. It also pertains to Notes and Team-At-A-Glance if these are configured for HTTP access. If native IBM Notes API (NRPC) access is used for the latter two clients an OnTime Access Token is not used.

Users are solely authenticated to the OnTime Group Calendar API (the "service" that provides the data for the OnTime Group Calendar user interfaces such as Web, Mobile, Notes etc.) using an OnTime Access Token. An OnTime Access Token is an encrypted text token that identifies the user and has a point in time it expires encoded in it (among other things). In order to obtain an OnTime Access Token the user must be authenticated to IBM Domino in whatever way the organisation requires such as basic authentication, form based authentication (using LtpaToken), certificates based authentication etc. Once an OnTime Access Token has been obtained it is used on subsequent requests to the OnTime Group Calendar API and identifies the user to the OnTime Group Calendar API. Once an OnTime Access Token is issued it is valid until it expires. The expiration duration can be controlled in the OnTime Group Calendar server document(s) and may be set to a duration in hours. The OnTime Group Calendar API issues a new OnTime Access Token on each request so the expiration time set in the OnTime Group Calendar server document(s) should be considered an "Idle time between requests".

Please note: In the OnTime Group Calendar Configuration database the OnTime Access Token idle timeout is referred to as the "HTTP Token Timeout".

Once an OnTime Group Calendar client obtains an OnTime Access Token it is cached by the client (for Mobile and Web it is cached in a browser cookie) and attempted used on subsequent requests to the API. This means that a user may access OnTime Group Calendar Web or OnTime Group Calendar Mobile without reauthenticating to IBM Domino if a valid OnTime Access Token is available. It also means that a suitable idle time should be set that suits the organisations security policy. For example if permitted by the security policy an idle time of 24 hours allows a user to use OnTime Group Calendar Mobile or Web during the day and reopen the client next day without reauthentication to IBM Domino as the OnTime Access Token is still valid.

It follows from the above that all API requests following obtaining an OnTime Access Token may be unauthenticated ("anonymous") from an IBM Domino perspective. This is not a security hole but is simply because non-token requests are solely authenticated from the OnTime Access Token. It also means that the IBM Domino HTTP server must allow anonymous requests whether that be over HTTP or HTTPs.

Please note that an OnTime Access Token may be revoked from the OnTime Group Calendar Configuration database. This means that even though a user have obtained an OnTime Access Token valid a year into the future the administrator may revoke it requiring the user to reauthenticate to use OnTime Group Calendar. This is a security measure.

HOW LOGIN TO ONTIME GROUP CALENDAR WEB WORKS

Below we assume that your OnTime Group Calendar Client database (”Client database”) is called ”ontimegcclient.nsf” and is in the ”ontime” directory. To open OnTime Group Calendar Web you would redirect users to ”/ontime/ontimegcclient.nsf/web”.

The login process is as follows:

1. User navigate to ”/ontime/ontimegcclient.nsf/web”.
2. The code checks whether an OnTime Access Token is present as a browser cookie or in the URL if launched from the Notes workspace icon. If it is, access is attempted using it.
3. If that OnTime Access Token doesn’t work (i.e. is expired) any browser cookie is cleared and the login process restarts.
   1. If no OnTime Access Token is found an API call is performed to obtain an OnTime Access Token. If the user is not authenticated to IBM Domino the API tells the client that and the user is redirected to the IBM Domino login page (hard coded which is why we only support form based authentication for this process).
   2. If an OnTime Access Token is obtained is it stored in a browser cookie and the login process restarts.

HOW LOGIN TO ONTIME GROUP CALENDAR MOBILE WORKS

Below we assume that your OnTime Group Calendar Client database (”Client database”) is called ”ontimegcclient.nsf” and is in the ”ontime” directory. To open OnTime Group Calendar Mobile you would redirect users to ”/ontime/ontimegcclient.nsf/mobile”.

Besides the URL required the login process is the same as for OnTime Group Calendar Web.

HOW LOGIN TO ONTIME GROUP CALENDAR NOTES AND TEAM-AT-A-GLANCE WORKS

When the OnTime Group Calendar Notes and/or Team-At-A-Glance clients are launched they need information about how to access the OnTime Group Calendar API. This information is stored in the users mail file in a profile document maintained by the OnTime Group Calendar synchronisation process. This profile document is updated every time OnTime Group  Calendar reads in (”synchronises”) appointment data from the mail file.

Please note: It follows from the above that while having multiple OnTime Group Calendar environments read appointment data from the same mail file it is important that only one environment is configured to write this profile document.

The launch process is as follows:

1. User clicks the icon to launch the client.
2. If access information is cached this information is attempted used to access the OnTime Group Calendar API. If this does not work (or any cached token has been explicitly revoked) this cached information is cleared the the launch process is restarted.
3. The users mail file is located using the information specified in the users location document. If the user cannot press Ctrl-M (Cmd-M on Mac) to compose a new email this process will fail.
4. The profile document is retrieved and access information is read.
   1. If OnTime Group Calendar is configured for HTTP access an OnTime Access Token is obtained using native IBM Notes API access using digital signatures to verify and identify the user. Once an OnTime Access Token has been obtained the API is accessed over HTTP identifying the user by the OnTime Access Token.
   2. If OnTime Group Calendar is configured for native Notes API access information is tranferred using the native IBM Notes API using digital signatures to verify and identify the user.

When using the native IBM Notes API and digital signatures to verify and identify the user both the OnTime Group Calendar client and the OnTime Group Calendar API participate in the cryptographic process.

SINGLE SIGN ON (SSO)

Often customers are looking to provide a Single Sign On solution to OnTime Group Calendar and its user interfaces. Choosing the correct solution depends on the security infrastructure in place but most times the user is authenticated by some other system and/or the user identity may not map to IBM Domino. It may also be the case that the user is authenticated to some other system but the credentials cannot be reused for IBM Domino. There are various ways to solve this as described below.

THE SIMPLE APPROACH

Use the OnTime Group Calendar security as-is but set a long idle time for the OnTime Access Token. While this strictly speaking does not provide Single Sign On it will only require the user to authenticate once as long as the idle time for the OnTime Access Token is long enough and the user access OnTime Group Calendar within the idle time period set. This option is available out-of-the-box.

THE API APPROACH

If you have purchased the OnTime Group Calendar Open API option (sold separately) you may also use the OnTime Group Calendar API to issue tokens to users. Using the OnTime Group Calendar API a system user may obtain an OnTime Access Token on behalf of other users and thus provide access to OnTime Group Calendar using an identity verified by some other system such as Microsoft Sharepoint, a CRM system or an MDM provider. We have previously created Single Sign On (SSO) solutions for customers wanting to provide SSO from non-IBM Domino platforms to OnTime Group Calendar running on IBM Domino.

For example we have a customer with an intranet based on Microsoft technologies where the user is automatically authenticated to the intranet using Windows Integrated Authentication (IWA). The customer wanted users to be able to open OnTime Group Calendar Web without having to re-authenticate which was tricky as the user was only authenticated to the Microsoft intranet and not IBM Domino. To solve this we employed the OnTime Group Calendar API.

We solved it by having the intranet, once the user had logged in to it, use the verified username to obtain an OnTime Access Token on behalf of the user (using the OnTime Group Calendar API). Once the intranet server obtained an OnTime Access Token for the user it set the correct browser cookie to complete the puzzle. Now when the user tries to access OnTime Group Calendar the browser automatically provides the obtained OnTime Access Token and the user may access OnTime Group Calendar without reauthentication thus achiving Single Sign On.

SPNEGO / KERBEROS (OR IF FORM BASED AUTHENTICATION CANNOT BE USED)

For customers using SPNEGO with IBM Domino the default access control list (ACL) setup of the OnTime Group Calendar Client database can cause problems. This is due to the fact that the Client database allows Anonymous access by default and hence the required HTTP 401 response code that cause the operating system to initialiate the authorization handshake is never sent. To solve this the Client database has a special page that does require the user to be authenticated. Instead of using the page called ”Web” you simply use the page called ”WebSSO”.

For example if your Client database is called ”ontimegcclient.nsf” and is in the ”ontime” directory you would normally redirect users to ”/ontime/ontimegcclient.nsf/web” to open the OnTime Group Calendar Web user interface. If using SPNEGO simply replace ”/web” with ”/websso” and redirect users to /ontime/ontimegcclient.nsf/websso”. Nothing more is required.

Please note: It’s very important that the ACL is configured correctly as described in the documentation for this to work.