Installation
     Instructions for RPM

Users and Groups
     Designating Non-Human Resources
     Modifying User Accounts
     Disabling User Accounts
     Deleting User Accounts
     Designating a CyberScheduler Administrator
     CyberScheduler Passwords
     Hierarchical User Groups

Database Administration
     Backing up the Database
     Restoring the Database

Calendar Server Configuration
     Configuring E-mail Delivery
     Enabling/Disabling E-mail Notification
     Editing the Holidays File
     Obtaining License Information

Designating Non-Human Resources

Resources such as conference rooms and slide projectors can be listed in the db/users file. Users running CyberScheduler can then specify not only which users they would like to attend a meeting, but what resources they would like to reserve as well. Note that resource entries do not include a login_name. These entries are designated by the lack of a login_name. They are treated by CyberScheduler in much the same manner as other users, with the following exceptions:

• Schedules for resource entries can always be opened by users, although individual items on the resource’s calendar may not be readable.
• CyberScheduler administrators (see below) automatically obtain agency status for resources so that calendar permissions can be set easily for the resources.

Modifying User Accounts

There will commonly be times when a user’s entry in db/users must be modified. Any of the last three fields for an entry can be modified without loss of data for that account. Please remember, the first field for a user’s entry CyberScheduler_name must not be changed unless you wish to remove the data for the original entry. For example, if a user changes his or her name, or is replaced by a different person, this change can be applied to the CyberScheduler_alias field in that user’s entry. If a user’s login_name must be changed, simply change that field. The e-mail_address field can be also be changed in this fashion. If you need to have a new user inherit data from another user’s calendar, consider simply changing all fields except the CyberScheduler_name. 

Disabling User Accounts

You can disable a CyberScheduler account without removing the calendar data associated with it. You can use any of the following techniques depending on your needs:

• Clear or change the login_name to prevent anyone from logging into that account.
• Change the CyberScheduler_alias to something (e.g., "disabled account") that will dissuade others from scheduling this account.
• Prevent others from scheduling this account through restrictive settings in the Calendar Permissions dialog tab which is accessed by clicking on the Seurity icon.

Deleting User Accounts

To delete a user account, you can either remove the user’s entry from the db/users file or change the CyberScheduler_name field. Please note: Deleting an account will automatically delete all calendar items originated by that user and removes that user from the invitee list of all calendar items to which he/she was invited. Extreme caution should be used when performing this type of maintenance. 

Designating a CyberScheduler Administrator

CyberScheduler administrators can be designated by an optional "+" entered just before the CyberScheduler_name (see example above). The "+" is not part of the user’s name. One or more administrators may be designated for a database. Administrative capabilities apply only to the local database, not to remote ones. Administrators have the following capabilities:
Automatic agency status for resources: This facilitates the setting of calendar permissions for resources. For example, if you wish to designate Joe as the only person who can schedule a conference room, make sure that you are a CyberScheduler administrator, become the agent for that conference room and designate Joe as the only "Scheduler" for the conference room. 

CyberScheduler Passwords

In some cases, it may be necessary to reset a password if, for example, a user forgets his or her password. To reset a password, the user’s password entry must be deleted from the db/database/userinfo file. There may be more than one line corresponding to the same user in this file. Only the line containing the encrypted password entry should be deleted. The entire line must be deleted. 

Hierarchical User Groups

As the number of CyberScheduler users grows, a linear set of names becomes insufficient to allow quick access to users. To deal with this issue, the ability to display a hierarchy of user groups is provided. The db/groups subdirectory can contain files and directories that define the group structure. Files are used to designate group names and directories are used to designate group hierarchies. Group names must be unique within a particular database. This applies to both file and directory names. For example, you cannot have a group named "staff" under both Engineering and Administration (rather you could use "Engineering_staff" and "Administrative_staff"). Behavior is unpredictable if this rule is not met. The following example shows a possible layout for a groups hierarchy under db/groups:

     Building-1 (subdirectory)
          Engineering (subdirectory)
               Development (file)
               Pubs (file)
          Manufacturing (file)
     Building-2 (subdirectory)
          Administration (file)
          Marketing (file)
          Sales (file)

A group file lists either the CyberScheduler_alias or CyberScheduler_name of users in the group, one per line. For example, consider the following lines from a db/users file:

     Joe, jclark, , Joey
     +Larry,lsmith,lsmithmantle,
     Rhonda, rjones, , Rhonda Jones
     "Karlsen, Jim", jkarlsen,,Jim
     Joseph, joe,, Joe
     Conference Room A, , ,
     Slide Projector

If Joe, Jim and Rhonda work in the Manufacturing group in Building-1, then the file db/groups/Building-1/Manufacturing might contain the following entries:

     Joe
     Karlsen, Jim
     Rhonda Jones

Note that it is not necessary to surround Jim’s name by double quotation marks as in the users file. Also note that a group file entry will always refer to a matching CyberScheduler_alias before a matching CyberScheduler_name. For example, "Joe" in the above group file refers to the user whose login is "joe", not "jclark".

Backing Up the Database

CrossWind recommends that you back up your CyberScheduler database on a daily basis. Only the db subdirectory and its contents need to be backed up. Utilities such as tar or cpio are recommended and easy to use for this task under UNIX. Whichever tool you decide to use, make sure that it saves all files and directories including empty directories and zero-length files. As an example, if you have a special UNIX disk partition or file system called /backups from which the nightly backups are made, then you might execute the following script each night:

     #!/bin/sh

     BACKUP_DIR="/backups"
     SYNC_DIR="/usr/local/lib/synchronize"

     cd $SYNC_DIR
     tar cf - db | compress > ${BACKUP_DIR}/db.tar.Z

You do not need to stop the calendar server when backing up the database. When deciding what time the backup should occur, keep in mind that the calendar server propagates unfinished to-dos to the next day around midnight. The amount of time required to do this depends on the size of the database and the speed of your system. For this reason, when scheduling your backup, it’s probably a good idea to avoid the time between 12:00 a.m. and 1:00 a.m. 

Restoring the Database

There are three scenarios to consider when restoring the calendar database: A full restore, which will reset the state of the database to the time of the last backup. A partial restore of particular database files when data for only a particular range of time (e.g., "this week" or "last month") must be restored for all users. Restoring a particular user’s data for an arbitrary range of time.

When performing a full restore, you should carefully follow these steps:

1. Stop the calendar server.
2. Restore the db subdirectory and its contents from a previous backup into the appropriate location in the existing CyberScheduler hierarchy.
3. Make sure that the ownership of the db subdirectory and its contents is the same as it was before the restore. You can use the chown -R command to ensure this.
4. Restart the calendar server.

1. Stop the calendar server.
2. Restore the db subdirectory and its contents from a previous backup into a temporary location.
3. Use the http://www.crosswind.com/products/synchronize/docs/techpapers/calendar.txt document on CrossWind’s FTP server to locate the files of interest in the database.
4. You can either overwrite existing database files with files from your backup or you can merge them.

Instructions for each are as follows:

1. To overwrite your existing database files, simply copy the appropriate files from the temporary location into the existing CyberScheduler hierarchy.
2. To merge your backup data with the existing data, first remove the header lines (the two lines beginning with #B and #F at the very beginning of each file) in each backup file you will be restoring. Once completed, concatenate each file from your backup onto its counterpart in your existing database.
5. Make sure that the ownership and permissions of the restored files are consistent with what is already there. You can use the chown and chmod commands to ensure this.
6. If you merged your database files as specified in step 4b) above, then you must start the calendar server with the -filterDups command-line option. After it has finished filtering duplicate events, it will exit automatically.
7. Restart the calendar server as you normally would.

Calendar Server Configuration 

Configuring E-mail Delivery

If your mail server is on a different machine than your calendar server, use a text editor to add a line to your calendar server's db/database/server/server.opts file that reads
     mailerHost: hostname
where hostname is the name of the host to which the calendar server should connect via SMTP when sending email. The default for hostname is "localhost."

Enabling/Disabling E-mail Notification 

During the installation of CyberScheduler for NT, you have the opportunity to enable e-mail notification for all users. In order to enable e-mail notification after installation you must edit the db/database/notify.mail file (create it first, if it does not already exist) to contain the following single line:

 #R (tab) _ _ALL_ _    ( Note: two underbars with no spaces between them, before and after the ALL.)

To disable e-mail notification for all users, remove the above line, or simply rename the db/database/notify.mail file to db/database/notify.mail.sav.

Editing the Holidays File 

During the CyberScheduler installation, a sample holidays file is installed as db/database/holidays. This file is used by CyberScheduler to display holiday names on each user’s calendar. The sample file includes entries for common holidays in the United States. Using any text editor such as Notepad or WordPad, you can edit the holidays file to contain the holidays that are appropriate for your CyberScheduler users.

The format of the holidays file is:

     holiday_name*{workday|nonworkday}:(tab) start_date - end_date

We recommend that you maintain your holidays in chronological order, with a blank line separating each year. Some entry examples from the file are:

Christmas Eve*workday:      12/24/1998 - 12/24/1998
Christmas Day*nonworkday:   12/25/1998 - 12/25/1998
New Year’s Eve*workday:     12/31/1998 - 12/31/1998

New Year’s Day*nonworkday:  1/1/1999 - 1/1/1999
Valentine’s Day*workday:    2/14/1999 – 2/14/1999

Notice that the date format is M/D/YYYY. Holidays that are designated as “nonworkday” are seen as time that is not free to anyone who uses “Find Free Time” when scheduling a meeting on CyberScheduler.

Obtaining License Information

After installation, you can determine the amount of users your CyberScheduler license supports by using any text editor to view /db/database/server/server.log. Under the heading "License information" you will see the number of users supported. Following is an example server.log entry that shows support for 5 users: