After your user calendars are created, use the cscal utility to perform the following administrative tasks:
For example, to list all calendars in the calendar database:
To list all calendars owned by jsmith:
cscal -o jsmith list
To list all the properties of a calendar with the calendar ID jsmith:meetings:
cscal -v list jsmith:meetings
The delete command removes all of the calendar information from the calendar database and cannot be undone. After you delete a calendar, you can recover the calendar data only if it was backed up. For more information, see Chapter 17, Backing Up and Restoring Calendar Server Data.
The cscal utility lets you delete a single calendar or multiple calendars.
For example, to delete a specific calendar with the calendar ID jsmith:meetings:
cscal delete jsmith:meetings
To delete all calendars whose primary owner is jsmith:
cscal -o jsmith delete
If you have deleted one or more users with the Calendar Server Utility command csuser delete, or with Delegated Administrator Console or Utility, calendars owned by that user might still be present in the database.
There are two ways to remove users’ calendars. The method to use depends on the tool you used to delete the user:
The csuser utility removes the user from the LDAP directory and removes the user’s default calendar, but not any other calendars the user might own. For instructions on how to use cscal to remove these calendars, see To Remove All Calendars of a User Deleted with csuser.
Delegated Administrator does not remove any calendars. Use Delegated Administrator to mark users for deletion and then use Calendar Server Utility csclean to remove calendars for user's marked for deletion.
For instructions on how to remove deleted users’ calendars using csclean, see To Remove All Calendars for Users Deleted by Delegated Administrator.
For instructions on using Delegated Administrator Utility, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
For instructions on using Delegated Administrator Console, see the online help.
Run cscal list to find all of the calendars for the deleted owner’s uid.
cscal -o owner list
Use cscal to remove all the calendars for this owner.
cscal -o owner delete
Verify that all the calendars have been removed by running csuser list again.
Use this procedure if you used commadmin to mark the user as deleted, and the user’s LDAP entry has already been purged.
Delegated Administrator does not remove calendars. Use the csclean utility to remove all calendars for any users marked as deleted with Delegated Administrator.
Use csclean to remove all calendar for user's marked as deleted but not yet purged.
For example, to remove all the calendars for user’s marked as deleted in the sesta.com domain in the last 10 days, the command would be as follows:
csclean -g 10 clean sesta.com
If the user has already been purged from the LDAP, then you must use cscal.
For instructions, see To Remove All Calendars of a User Deleted with csuser.
To enable a calendar to allow users to access the calendar, use the cscal utility enable command.
For example, to enable calendar jsmith:meetings using the default configuration settings:
cscal enable jsmith:meetings
To enable the calendar jsmith:meetings but not allow doublebooking:
cscal -k no enable jsmith:meetings
To prevent users from accessing a calendar, use the cscal utility disable command. The disable command prohibits users from accessing the calendar, but it does not remove the information from the calendar database.
For example, to prevent users from accessing jsmith:meetings:
cscal disable jsmith:meetings
cscal -a "@@o^c^wd^g" -y RJones modify AllAdmins
-a "@@o^c^wd^g" grants owners write and delete access to the components (events and tasks) of AllAdmins.
-y RJones specifies this user ID as another owner.
cscal -d "" modify jsmith:meetings
To remove all categories from jsmith:meetings:
cscal -g "" modify jsmith:meetings
cscal -y "" modify jsmith:meetings
If a user’s default calendar does not appear in the Communications Express Current Calendar drop down list, but still exists in the database, you can recover the calendar by updating the following attributes in the user’s LDAP entry:
where default_calid is the user’s default calendar ID (calid).
For Schema 2, use one of the following methods to update the attributes:
Use the ldapmodify Directory Server utility.
Use the Calendar Server Utility command csuser reset.
Use the Delegated Administrator Utility command commadmin user modify.
Use the Delegated Administrator Console to add the default calendar name by editing the User Properties page.
For Schema 1, use the csattribute add command to update the attributes.
To move a user calendar from one back-end server to another back-end server, follow these steps:
On the original server, disable the calendar user using the csuser utility. For example to disable the user with the user ID and calid bkamdar:
csuser disable bkamdar
On the original server, export each of the user’s calendars from the calendar database to a file using the csexport utility. For example:
csexport -c bkamdar calendar bkamdar.ics
Copy the exported calendar (*.ics) files from the original server to the new server.
On the new server, for each of the calendars exported, import the calendar from the file to the calendar database using the csimport utility. For example:
csimport -c bkamdar calendar bkamdar.ics
On the LDAP directory server, update the calendar owner’s icsDWPHost LDAP attribute to point to the new back-end server using the csattribute utility. To update an attribute, you must first delete the attribute and then add it with the new value. For example, to set the new server name to sesta.com:
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar
On the new server, enable the calendar user using the csuser utility for a user calendar. For example:
csuser enable bkamdar
On the new server, use the following commands to verify that the attributes are correct and that each calendar has been moved correctly. For example:
cscal -v -o bkamdar list bkamdar ... csattribute -v list bkamdar
On the original server, delete each calendar you just moved. For example:
cscal -o bkamdar delete bkamdar
The -o option deletes all calendars whose primary owner is bkamdar.
If you are using the CLD cache option, after moving a calendar to a different back-end server, you should clear the CLD cache to remove the server names. An out-of-date entry in the CLD cache can prevent a front-end server from finding a calendar after it has been moved. To clear the CLD cache, follow these steps:
Stop Calendar Server.
Remove all files in the /var/opt/SUNWics5/csdb/cld_cache directory, but do not remove the cld_cache directory itself.
Restart Calendar Server.