USER AND SERVER CONFIGURATION

Calendars and scheduling
The calendar and scheduling features allow users to check the free time of other users, schedule meetings with them, and reserve resources, such as conference rooms and equipment. As an administrator, you can define holidays that are particular to your organization or country. Domino includes a set of default Holiday documents, which you can modify. Users import this information directly into their personal calendars.

The calendar and scheduling features use the Schedule Manager (Sched task), the Calendar Connector (Calconn task), and the Free Time system (a combination of Sched, Calconn, and nnotes tasks) to operate. When you install Domino on a server (any server except a directory server), the Sched and Calconn tasks are automatically added to the serverfs NOTES.INI file. When you start the server for the first time, the Schedule Manager creates a Free Time database (BUSYTIME.NSF for non-clustered mail servers and CLUBUSY.NSF for clustered mail servers) and creates an entry in the database for each user who has filled out a Calendar Profile and whose mail file is on that server or on one of the clustered servers.

Each user can keep a personal calendar and create a Calendar Profile that identifies who may access the userfs free time information and specifies when the user is available for meetings. When users invite other users to meetings, the Free Time system performs the free-time lookups. The Free Time system also searches for and returns information on the availability of resources. If the lookup involves searching in Free Time systems on different servers or scheduling applications, the Calendar Connector sends out the queries. When users schedule appointments in their calendars and reserve resources, the Schedule Manager task collects and updates that information in the Free Time database.

By default, the Schedule Manager has access to the Free Time database, so you do not have to define the ACL for this database.

Using clustered Free Time databases

For clustered mail servers, the Schedule Manager creates the clustered Free Time database (CLUBUSY.NSF) the first time a server starts. The clustered version of the Free Time database works the same as the Free Time database (BUSYTIME.NSF). Each clustered server has a replica of the clustered Free Time database, which stores information about users whose mail files exist on servers in the cluster.

If you add a previously non-clustered server to a cluster, the Schedule Manager deletes the BUSYTIME.NSF database on that server and creates CLUBUSY.NSF, which then replicates to all cluster members. If you remove a server from a cluster, the opposite occurs: Schedule Manager deletes CLUBUSY.NSF and creates BUSYTIME.NSF. Until the Schedule Manager validates the database by checking to see if the location of usersf mail files has changed, the clustered Free Time database contains information about users whose mail server you removed from the cluster. This validation also occurs once each day (at 2 AM) to update free-time information for users whose mail files have been added to or removed from a mail server. You can update the information at any time by entering the Tell Sched Validate command at the console.

A benefit of clustered scheduling is that schedule information is always available, even when usersf home servers are down. With non-clustered scheduling, if users' home servers are not available, the Free Time database is not available for searching.

Other advantages of using clustered scheduling include improved performance and reduced server traffic. Because the Free Time database is available from other members in a cluster, the server that receives a userfs query does not have to search another serverfs Free Time database for schedule information about a user whose mail server is in the cluster.

Example of scheduling a meeting

This section describes the process of scheduling a meeting when users share the same mail server and domain, have different domains, and use different scheduling applications.

In the following examples, Kathy wants to check the free time of and schedule a meeting with three users -- Bob, who is in the same domain as Kathy; Robin, who is in a different domain; and Susan, who uses a different scheduling application (Lotus OrganizerR).

Users in the same domain

1. Kathy creates a meeting invitation and chooses to search for Bobfs free time.

2. A free time query is sent to Kathyfs mail server.

3. The Free Time system looks for Bobfs name in the Free Time database (BUSYTIME.NSF or CLUBUSY.NSF) on Kathyfs mail server.

4. Kathyfs Domino Directory is checked for Bobfs Person document. When the Person document is found, the Calendar Connector sends the request to Bobfs mail server, the name of which is listed in Bobfs Person document.

5. The Free Time system on Bobfs mail server looks in its Free Time database and returns the information to Kathy via the Calendar Connector. If the Free Time system doesnft find any information, the query fails, and the Find Time dialog box indicates that Bobfs information is unavailable.

Users in different domains

1. Kathy creates a meeting invitation and chooses to search for Robinfs free time. In addressing the invitation, Kathy specifies Robinfs domain.

2. A query is sent to Kathyfs mail server.

3. The Free Time system looks for Robinfs name in the Free Time database on Kathyfs mail server. It determines Robinfs mail server is in a different domain.

4. Kathyfs Domino Directory is searched for a document that matches Robinfs domain.

Users in other calendar domains

1. Kathy creates a meeting invitation and chooses to search for Susanfs free time.

2. A query is sent to Kathyfs mail server.

3. The Free Time system looks for Susanfs name in its Free Time database. It does not find the information, so it converts Susanfs name into a fully qualified one.

4. Kathyfs Domino Directory is searched for Susanfs Person document.

5. The Free Time system looks in Susanfs Person document and locates the name of her mail server in the Mail server field and the name of her calendar domain in the Calendar Domain field.

6. Because Susan is using Lotus Organizer as her scheduling application, the Free Time system finds that her calendar domain does not match her mail server domain. The Free Time system then looks for a Domain document for the calendar domain.

7. The Free Time system finds a Foreign Domain document for Susanfs calendar domain. The Calendar server field in the Foreign Domain document identifies the name of the server that accepts queries for Susanfs domain; the "Calendar system" field identifies the name of the add-in program -- for example, Organizer or IBMR OfficeVisionR -- that actually does the free-time lookup on Susanfs server. The Free Time system forwards the query to the appropriate server (the server listed in the Calendar server field) for processing.

If the Free Time system doesnft find a Foreign Domain document, the query fails; and the Find Time dialog box indicates that Susanfs information is unavailable.

See also