test

Sun Java System Calendar Server 6.3 Administration Guide

Chapter 15 Administering Calendars

This chapter contains topics with instructions on how to use Calendar Server command-line utilities to create and manage calendars.

This chapter contains the following topics:

15.1 Calendar Administration Overview for Calendar Server Version 6.3

The Delegated Administrator does not create or manage calendars. You must use the Calendar Server utilities described in Appendix D, Calendar Server Command-Line Utilities Reference.

Before creating calendars, you must know the following information:

To run cscal or csresource, you must log in as a user who has administrative rights to the system where Calendar Server is running. You must run these commands from the /opt/SUNWics5/cal/sbin directory. That is, you must change to the sbin directory; you can not run them from another directory by specifying the path.

15.2 Creating Calendar Unique Identifiers (calid's)

Each calendar in the Calendar Server database is identified by a unique calendar identifier (ID) or calid. When creating calendars, you are required to specify the calid.

This section contains the following topics:

15.2.1 Calid Syntax

Each calendar in the database is identified by a unique calendar ID (calid). The following calid syntax has three parts:

userid[@domain][:calendar-name]

The three parts are:

userid

A user ID that is unique for the domain in this Calendar Server instance.

domain

The name of the user’s domain.

With a single domain, the domain part is optional since there is no ambiguity about which domain the user is in.

With multiple domains, if the domain part is not specified, then Calendar Server uses the value specified in the ics.conf parameter service.defaultdomain for the domain. If the user is not in the default domain, the domain part must be specified.

For more information about multiple domain environments, see Chapter 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment and Chapter 13, Administering Calendar Server Domains.

calendar-name

An optional calendar name that is unique to the specific user. Although an owner has only one default calendar, it is possible to have other calendars for various purposes. Each of these non-default calendars is distinguished by its calendar name. For example, if user John Doe has a uid jdoe, his default calendar might be jdoe@sesta.com. An auxiliary calendar he uses to keep track of baseball games for the Little League team he coaches might be identified with the following calid: jdoe@sesta.com:baseball.

15.2.2 Calendar ID Creation Rules

This section describes the rules for creating a calendar ID (calid).

When creating a calid, keep in mind the following rules:

15.2.3 Converting Non-Domain calid's to Multiple Domain Format calid's

If you have calid's that were created before you had domains, and you now want to convert them to domain specific calid's, there is a utility, csvdmig, that can be used to add the domain part to your existing calid's. See 3.6 csvdmig for instructions on how to use the utility.

If you do not add domain names to the existing calid's, the system will assume they belong to the default domain.

15.3 Automatic Creation of Calendars

This section contains conceptual information and instructions for using the Calendar Server feature for automatically creating calendars upon a user's first login.

Automatic calendar creation is enabled by default. With it enabled, the system automatically creates calendars under two circumstances:

For the configuration information necessary to implement automatic creation of calendars in this circumstance, see To Configure Calendar Server for Groups.

This section covers the following topics:

15.3.1 Creating calids

Calendar Server creates the calendar ID (calid) for new default calendars from the user ID and the domain name.

For example, John Smith's user ID is jsmith, and his LDAP entry resides in the sesta.com domain. The first time he logs into Calendar Server, the system automatically creates a default calendar with jsmith@sesta.com as the calid. Each subsequent calendar John Smith creates has a calid with jsmith@sesta.com: prepended to the calendar name. For example, if John Smith later creates a new calendar named meetings, the calid for the new calendar is jsmith@sesta.com:meetings.

If a user, group, or resource without a default calendar is listed in the attendee list of an event, the system looks up the uid in LDAP in the event owner's domain as the event owner. If no domain is assigned to the owner, the default domain is assumed. The system constructs a calid by appending the domain to the uid.

If the system can't find the uid in the event owner's domain, it will search any other domains the event owner is allowed to search. For more information, see 11.2 Cross Domain Searching in Calendar Server 6.3 Systems.

ProcedureTo Enable Autoprovisioning of Calendars

The auto-creaton of calendars is enabled by default. However, if you need to turn it on again after disabling it, perform the steps that follow:

  1. Log in as an administrator with configuration privileges.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the following parameters in the Calendar Server configuration file, ics.conf, as shown in the following table:

    Parameters  

    Description and Default Value  

    local.autoprovision

    Set to “yes”, allows default calendar creation to occur automatically when the user logs in the first time. autoprovisioning is enabled by default. 

    To turn this feature off, set the value to “no”. 

  6. Verify that the user’s LDAP entry is enabled for calendar.

    The entry must contain the icsCalendarUser object class. Add the class to the user’s LDAP entry if it is not there.

  7. If your site is using multiple domains, the user’s domain must also be calendar enabled before autoprovisioning will work. The domain entry must contain the icsCalendarDomain object class.

  8. Save the file.

  9. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Disable Autoprovisioning of Calendars

  1. Log in as an administrator with configuration privileges.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the following parameters in the Calendar Server configuration file, ics.conf, as shown in the following table:

    Parameters  

    Description and Default Value  

    local.autoprovision

    Setting the parameter to no disables autoprovisioning of user calendars.

  6. Save the file.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    Note –

    If autoprovisioning is disabled, calendars must be explicitly created for users before they can successfully log in.

15.4 Calendar Access Control

Calendar Server uses Access Control Lists (ACLs) to determine the access control for calendars, calendar properties, and calendar components such as events and todos (tasks).

This section covers the following topics:

15.4.1 Configuration Parameters for Access Control

The following table describes the configuration parameters in the ics.conf file that Calendar Server uses for access control.

Table 15–1 Access Control Configuration Parameters

Parameter  

Description  

calstore.calendar.default.acl

Specifies the default access control settings used when a user creates a calendar. The default is: 

"@@o^a^r^g;@@o^c^wdeic^g;

@^a^fs^g;@^c^^g;@^p^r^g"

calstore.calendar.owner.acl

Specifies the default access control settings for owners of a calendar. The default is: 

"@@o^a^rsf^g;@@o^c^wdeic^g"

resource.default.acl

Specifies the default access control settings used when a resource calendar is created. The default is: 

"@@o^a^r^g;@@o^c^wdeic^g;

@^a^rsf^g"

15.4.2 Public and Private Events and Tasks Filter

When creating a new event or task, a user can specify whether the event or task is Public, Private, or Time and Date Only (confidential):

Public

Anyone with read permission to the user’s calendar can view the event or task.

Private

Only owners of the calendar can view the event or task.

Time and Date Only

These are confidential events and tasks. Owners of the calendar can view the event or task. Other users with read permission to the calendar can see only “Untitled Event” on the calendar, and the title is not an active link.

The calstore.filterprivateevents determines whether Calendar Server filters (recognizes) Private, and Time and Date Only (confidential) events and tasks. By default this parameter is set to "yes". If you set calstore.filterprivateevents to "no", Calendar Server treats Private and Time and Date Only events and tasks as if they are Public.

15.4.3 Command-Line Utilities for Access Control

The following table describes the Calendar Server command-line utilities that allow you to set or modify ACLs for access control.

Table 15–2 Command-Line Utilities for Access Control

Utility  

Description  

cscal

Use the create and modify commands with the -a option to set ACLs for specific user or resource calendars.

csresource

Use the csresource utility with the -a option to set ACLs for resource calendars.

commadmin user

csuser

For Schema version 2, use Delegated Administrator Console, or Delegated Administrator Utility, commadmin, to change the default ACL used when a user calendar is created.

For Schema version 1, use the csuser utility with the -a option to change the default ACL used when a user creates a calendar.

Note –

To set access rights in the Delegated Administrator Console, from the Organization Properties page (also from the Create New Organization wizard), click the Advanced Rights button to see the list of access rights that can be administered from the console.

15.5 Creating Calendars

This section contains conceptual information and instructions on how to create calendars.

This section contains the following topics:

15.5.1 Creating a User Calendar with the cscalUtility

This section contains the following topics and examples:

The following example creates a calendar similar to the previous example, but it also sets specific access control settings for group scheduling:

cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal

The string -a "@@o^a^sfr^g" grants other owners schedule, free/busy, and read access privileges to both the components and calendar properties of this calendar for group scheduling.

15.5.1.1 Overview of Creating a New Calendar

To create a new calendar, use the cscal utility with the create command. The user or resource entry must already exist in the LDAP directory. Refer to Chapter 14, Administering Users, Groups, and Resourcesfor information on adding users and resources to your LDAP directory.

If your site is using the LDAP Calendar Lookup Database (CLD) plug-in, you must create all of the calendars for a particular user or resource on the same back-end server, as indicated by the icsDWPHost LDAP attribute in the user or resource entry. If you try to create a calendar on a different back-end server, the cscal utility returns an error. For information about the LDAP CLD plug-in, see Chapter 5, Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3.

15.5.1.2 Creating New Calendars

To create a new calendar, the minimal command is the following:

cscal -o uid  create calid

For example, for the user John Smith with a unique ID and calendar ID of jsmith the command would look like the following:

cscal -o jsmith create jsmith

The command has the following parts:

cscal

The name of the utility.

-o

The unique ID (uid) of the primary owner for this calendar.

create

The command to create the new calendar.

calid

The calendar ID to be assigned to this calendar.

For more information about the cscal utility, see D.5 cscal also located in this guide.

Tip –

The default access control settings are defined by calstore.calendar.default.acl in the ics.conf file.

15.5.1.3 Creating Another Calendar for a User

You can create multiple calendars for any user. However, they are always identified as sub-calendars of the default calendar. The fully qualified name of the new calendar will have the default calendar name on the left of a colon separator and the new calendar's name on the right of the colon separator.

The following example demonstrates how to create another (non-default) calendar for a user, John Smith, with the name of the new calendar as Personal:

cscal -o jsmith@sesta.com create Personal

The parts of the command are as follows:

cscal

The name of the utility.

-o jsmith@sesta.com

The unique ID (uid) of the primary owner for this calendar.

create

The command to create the new calendar.

Personal

The second half of the calendar ID (calid) to be assigned to this calendar.

The fully qualified calendar ID is jsmith@sesta.com:Personal.

15.5.1.4 Creating a Calendar with a Viewable Name

This example shows how to give a separate viewable name, “Hobbies”, to the Personal non-default calendar created in the previous example.

cscal -o jsmith@sesta.com -n Hobbies create Personal

-o

jsmith@sesta.com Specifies the user ID of the primary owner.

-n

Hobbies Specifies the viewable name of the calendar.

Personal

The name of this new additional calendar for John Smith.

The entire calid becomes: jsmith@sesta.com:Personal.

15.5.1.5 Creating a Calendar with Other Properties

The following example creates a new calendar, Personal, similar to the previous example, but it also associates the calendar with the category named sports, enables double booking, and specifies Ron Jones as another owner:

cscal -n Hobbies -o jsmith -g sports -k yes -y rjones create Personal

The command has the following parts:

cscal

The name of the utility.

-o jamsith@sesta.com

The unique ID (uid) of the primary owner for this calendar.

-g sports

This option associates the calendar, Personal, with a category named sports.

-y

The value rjones@sestas.com specifies another owner of the calendar.

-k yes|no

This option enables or disables double booking of events in one time slot.

A value of yes enables double booking. A value of no would disable double booking.

create

The command to create the new calendar.

Personal

The calendar ID to be assigned to this calendar.

15.5.2 Configuring the Calendar Server for Resources

A resource calendar is associated with things that can be scheduled, such as meeting rooms, notebook computers, overhead projectors and other equipment. Resource calendars require access control lists.

As shown in table Table 15–3, two configuration parameters in the ics.conf file apply to resource calendars:

resource.default.acl

A default access control list.

resource.allow.doublebook

A parameter that allows or disallows doublebooking.

To change the default values for these parameters (shown in table Table 15–3), edit the ics.conf file. Changes to the default values will apply only to new resource calendars; it will not change the values for existing resources.

For Schema version 1, use the Calendar Server Utility cscal to change values for an existing resource calendar. The csresource utility does not have a modify command.

For Schema version 2, use the Delegated Administrator Utility command commadmin resource modify. The Delegated Administrator Console does not allow you to change these values for calendar resources.

Note –

The Calendar Server notification software is not programmed to send notifications to resources, only to users.

Table 15–3 Resource Calendar Configuration Parameters in the ics.conf file

Parameter  

Description and Default Value  

resource.default.acl

This parameter determines the default access control permissions used when a resource calendar is created. The default permissions are specified by the following Access Control List (ACL): 

"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

This ACL grants all calendar users read, schedule, and free/busy access to the calendar, including both components and properties. 

To change the permissions for a resource, use the-a option when you create the calendar using the csresource utility create command.

resource.allow.doublebook

This parameter determines if a resource calendar allows doublebooking. Doublebooking allows a resource calendar to have more than one event scheduled for the same time. 

The default value is "no"— Do not allow doublebooking.

To allow doublebooking for a resource calendar, use the -k option when you create the calendar using the csresource utility create command.

resource.invite.autoprovision

The default value is "yes".

resource.invite.autoaccept

The default value is "yes".

15.5.3 Creating Resources and Resource Calendars

Tip –

If the value of the ics.conf parameter resource.invite.autoprovision is "yes", the resource calendar will be created upon first invitation. That is, if this resource does not already have a default calendar, the first time its scheduled in an invitation, a resource calendar will be created.

To create a resource, use one of the following methods:

Calendar Server Utility (Schema version 1)

Use csresource create

This utility creates both the LDAP entry and the default calendar for the resource.

If there is an existing LDAP entry for the resource, csresource creates only the calendar. It will not create a duplicate LDAP entry.

For example, to create a resource LDAP entry and calendar with the calendar ID aud100, viewable name Auditoriumwith the default settings, use the following command:

csresource -m aud100@siroe.com -c aud100 create Auditorium

Delegated Administrator Utility and Calendar Server utility

Use a combination of two commands:

  • The Delegated Administrator Utility command commadmin resource create to create the LDAP entry.

  • The Calendar Server Utility command csresource create to create the default calendar.

Delegated Administrator Console

To create the LDAP resource with the Console, select the organization where this resource will reside from the Organizations List. From the Calendar Resources page for this organization, click New to bring up the Create New Calendar Resource Wizard.

For more information about the Delegated Administrator Utility, see Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

For more information about the Delegated Administrator Console, see the online help.

For more information about csresource, see Appendix D, Calendar Server Command-Line Utilities Reference.

15.5.4 Allowing Double Booking of Resource Calendars

By default, Calendar Server does not allow double booking for a resource calendar (resource.allow.doublebook parameter). This default prevents scheduling conflicts for resources such as rooms and equipment. However, if you want to allow double booking for a resource calendar, set the csresource -k option to “yes” when you create the calendar.

The following command creates a resource LDAP entry and calendar, but the -k option allows double booking on the calendar, the -o option specifies bkamdar as the owner of the calendar, and the -y option specifies jsmith@sesta.com as another owner:

csresource -m aud100@siroe.com -c aud100 -k yes
    -o bkamdar -y jsmith@sesta.com create Auditorium

15.5.5 Limiting Access to Resource Calendars

To control who can schedule a specific resource, consider limiting the users who have write access to the resource calendar. For example, you might want to allow only certain users to schedule meeting rooms or reserve equipment.

If you do not specify an owner for a resource calendar, the value is taken from the service.siteadmin.userid parameter in the ics.conf file.

15.6 Managing User Calendars

This section contains instructions on how to manage user calendars using the Calendar Server utility D.5 cscal.

This section covers the following administrative tasks:

15.6.1 To Display Calendars

To display all calendars, all calendars owned by a user, or the properties of a specific calendar, use the cscal utility list command.

The following examples demonstrate three different tasks using cscal.

15.6.2 To Delete a Calendar

To delete one or more calendars from Calendar Server, use the cscal utility delete command. This utility deletes the calendar, but it does not delete the user from the directory server.

The following two examples demonstrate different tasks you can accomplish with cscal delete:

Caution – Caution –

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.

15.6.3 To Remove Calendars of Deleted Users

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:

Calendar Server utility csuser

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 in Calendar Server Version 6.3.

Delegated Administrator Console and Utility

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.

ProcedureTo Remove All Calendars of a User Deleted with csuser in Calendar Server Version 6.3

  1. Run the cscal list command to find all of the calendars for the deleted owner’s uid.

    cscal -o owner list

  2. Use the cscal command to remove all the calendars for this owner.

    cscal -o owner delete

  3. Verify that all the calendars have been removed by running csuser list again.

    Note –

    Use this procedure if you used commadmin to mark the user as deleted, and the user’s LDAP entry has already been purged.

ProcedureTo Remove All Calendars for Users Deleted by Delegated Administrator

Delegated Administrator does not remove calendars. Use the csclean utility to remove all calendars for any users marked as deleted with Delegated Administrator.

  1. Use csclean to remove all calendars for users marked as deleted but not yet purged.

    For example, to remove all the calendars for users 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

  2. 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 in Calendar Server Version 6.3.

15.6.4 To Enable a Calendar

To allow users to access their calendars, you must first enable the calendars using the cscal enable command.

The following examples, demonstrate how to enable calendars:

15.6.5 To Disable a Calendar

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@sesta.com:meetings, use the following command:

cscal disable jsmith@sesta.com:meetings

15.6.6 To Modify Calendar Properties

To modify the properties of a calendar, use the cscal utility modify command.

For example, to change the group scheduling access control settings of AllAdmins and specify RJones@sesta.com as another owner:

cscal -a "@@o^c^wd^g" -y RJones@sesta.com modify AllAdmins

The following explains the two command variables used in the preceding example:

15.6.7 To Remove Properties From a Calendar

To remove a property value from a calendar, use the cscal modify command and specify the value of the option with two double quotes ("").

The three examples that follow show how to remove different properties:

15.6.8 To Recover a “Lost” Default Calendar

If a user’s default calendar is not visible to the Communications Express user interface client, but still exists in the database, you can recover the calendar and make it visible again by updating two attributes in the user’s LDAP entry.

To recover a calendar, make sure the value of the following attributes in the user's LDAP entry is the user's fully qualified calid:

For Schema version 2, use one of the following methods to update the attributes:

For Schema version 1, use the csattribute add command to update the attributes.

ProcedureTo Move a User Calendar to a Different Back-End Server

To move a user calendar from one back-end server to another back-end server, follow these steps:

  1. On the original server, disable the calendar user using the D.19 csuser utility. For example to disable the user with the user ID and calid bkamdar:

    csuser disable bkamdar

  2. On the original server, export each of the user’s calendars from the calendar database to a file using the D.10 csexport utility. For example:

    csexport -c bkamdar calendar bkamdar.ics

  3. Copy the exported calendar (*.ics) files from the original server to the new server.

  4. On the new server, for each of the calendars exported, import the calendar from the file to the calendar database using the D.11 csimport utility. For example:

    csimport -c bkamdar calendar bkamdar.ics

  5. On the LDAP directory server, update the calendar owner’s icsDWPHost LDAP attribute to point to the new back-end server using the D.3 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

  6. On the new server, enable the calendar user using the D.19 csuser utility for a user calendar. For example:

    csuser enable bkamdar

  7. 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

  8. 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.

    Note –

    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.

15.7 Administering Resource Calendars

This section describes how to administer resource calendars using the csresource utility.

The following are procedures for administering resource calendars:

15.7.1 To Display Resource Calendars and Attributes

To display a resource calendar, use the csresource utility list command.

For example, use the utility to perform the following tasks:

15.7.2 To Modify a Resource Calendar

This section describes how to modify a resource calendar. You must use the D.5 cscal utility command because the csresource utility does not have a modify command.

For example, the following command performs two tasks simultaneously:

cscal -o tchang -y mwong modify aud100

In this example, the cscal utility requires that resource's calid (aud100) is specified rather than the calendar name (Auditorium).

15.7.3 To Disable or Enable a Resource Calendar

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

15.7.4 To Delete a Resource Calendar

To delete a resource calendar, use the csresource utility delete command.

For example, to delete the Auditorium resource calendar, issue the following command:

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.

ProcedureTo Move a Resource Calendar to a Different Back-End Server

To move a user or resource calendar from one back-end server to another back-end server, follow these steps:

  1. On the original server, disable the calendar resource using the D.15 csresource utility. For example to disable the resource with the common name Auditorium:

    csresource disable Auditorium

  2. On the original server, export each of the resources calendars from the calendar database to a file using the D.10 csexport utility. For example:

    csexport -c aud100 calendar aud100.ics

  3. Copy the exported calendar (*.ics) files from the original server to the new server.

  4. On the new server, for each calendar exported, import the calendar from the file to the calendar database using the D.11 csimport utility. For example:

    csimport -c bkamdar calendar bkamdar.ics

  5. On the LDAP directory server, update the calendar owner’s icsDWPHost LDAP attribute to point to the new back-end server using the D.3 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

  6. On the new server, enable the calendar resource using the D.15 csresource utility. For example:

    csresource enable bkamdar

  7. 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

  8. 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.

    Note –

    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.

15.8 Linking to a Calendar

You can create a link to one or more user or resource calendars, as long as each calendar has the permissions set to allow read access. For example, you can embed a calendar link in a web page or email message. Other users can then view the calendar anonymously without having to log into Calendar Server.

To create a link to one or more user calendars, use this syntax:

http://CommunicationsExpresshostname:
CommunicationsExpressport/uwc/
   ?calid=calid-1[; ... ;calid-n]

For multiple calendars, separate each calendar ID (calid) with a semicolon (;).

For example, to link to the default calendar for jsmith@sesta.com, and jdoe@siroe.com, enter:

http://calendar.sesta.com:8080/uwc/?calid=jsmith@sesta;jdoe@siroe.com

To link to a resource calendar for an overhead projector with the calid overhead_projector10:

http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10

15.9 Importing and Exporting Calendar Data in Calendar Server 6.3 Databases

To export and import calendar data to and from a file, use the csexport and csimport utilities. The calendar data can be in either iCalendar (.ics) or XML (.xml) format.

You must run csexport and csimport locally on the machine where your Calendar Server is installed. Calendar Server can be either running or stopped.

15.9.1 Importing Calendar Data

To import calendar data from a file previously saved using the csexport utility, use csimport. The file name extension of the import file (.ics or .xml) indicates the format in which it was saved.

For example, to import calendar data to the calendar ID (calid) jsmithcal@sesta.com from the file jsmith.ics that was saved in iCalendar (text/calendar MIME) format:

csimport -c jsmithcal@sesta.com calendar jsmith.ics

To import data into the calendar jsmithcal@sesta.com from a file named jsmith.xml that was saved in XML (text/xml MIME) format:

csimport -c jsmithcal@sesta.com calendar jsmith.xml

15.9.2 Exporting Calendar Data

To export calendar data to a file, use csexport. The file name extension (.ics or .xml) that you specify for the output file determines which format is used.

The following examples show how to use the export utility: