After a resource calendar is created, administer it using the csresource utility. The following are procedures for administering resource calendars:
To display a resource calendar, use the csresource utility list command.
For example, to display a list of all Calendar Server resource calendars and their corresponding LDAP attributes:
To display a list of all LDAP attributes for a specific resource calendar named Auditorium:
csresource -v list Auditorium
To modify a resource calendar, use the cscal utility modify command (csresource does not have a modify command).
For example, to set the owner as tchang and add another owner named mwong to the resource calendar named Auditorium:
cscal -o tchang -y mwong modify aud100
In this example, the cscal utility requires the calid (aud100) rather than the calendar name (Auditorium).
You might need to disable a resource calendar to prevent users from scheduling events. For example, a conference room might be unavailable during remodeling, or an overhead project might be out for repair.
To disable or enable a resource calendar, use the csresource utility enable or disable command.
For example, to disable the resource calendar named Auditorium:
csresource disable Auditorium
Then, to enable the resource calendar later:
csresource enable Auditorium
To delete a resource calendar, use the csresource utility delete command.
For example, to delete the Auditorium resource calendar:
csresource delete Auditorium
Calendar Server displays the following message:
Do you really want to delete this resource (y/n)?
Enter “y” to delete the calendar or “n” to cancel the operation.
If you enter “y”, Calendar Server deletes the calendar and displays a message that it has been deleted.
To move a user or resource calendar from one back-end server to another back-end server, follow these steps:
On the original server, disable the calendar resource using the csresource utility. For example to disable the resource with the common name Auditorium:
csresource disable Auditorium
On the original server, export each of the resources calendars from the calendar database to a file using the csexport utility. For example:
csexport -c aud100 calendar aud100.ics
Copy the exported calendar (*.ics) files from the original server to the new server.
On the new server, for each calendar 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 resource using the csresource utility. For example:
csresource 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 and you have moved 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.