CONFIGURING

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. IBM® 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 server's 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 user's 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 scheduling

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 users' 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 a user's home server is down. With non-clustered scheduling, if a home server is not available, its users are unable to access the Free Time database 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 user's query does not have to search another server's Free Time database for schedule information about a user whose mail server is in the cluster.

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.

Users in the same domain

1. Kathy creates a meeting invitation and chooses to search for Bob's free time.

2. A free time query is sent to Kathy's mail server.

3. The Free Time system looks for Bob's name in the Free Time database (BUSYTIME.NSF or CLUBUSY.NSF) on Kathy's mail server.

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

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

Users in different domains

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

2. A query is sent to Kathy's mail server.

3. The Free Time system looks for Robin's name in the Free Time database on Kathy's mail server. It determines Robin's mail server is in a different domain.

4. Kathy's Domino Directory is searched for a document that matches Robin's domain.

Users in other calendar domains

1. Kathy creates a meeting invitation and chooses to search for Susan's free time.

2. A query is sent to Kathy's mail server.

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

4. Kathy's Domino Directory is searched for Susan's Person document.

5. The Free Time system looks in Susan's 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 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 Susan's calendar domain. The Calendar server field in the Foreign Domain document identifies the name of the server that accepts queries for Susan's domain; the Calendar system field identifies the name of the add-in program -- for example, Organizer or IBM OfficeVision® -- that actually does the free-time lookup on Susan's 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 doesn't find a Foreign Domain document, the query fails; and the Find Time dialog box indicates that Susan's information is unavailable.

Related tasks
Setting up scheduling
Setting up the Resource Reservations database
Creating Holiday documents

Related reference
Schedule Manager Tell commands