Calendar Server 7 Administration Guide

Skip to end of metadata
Go to start of metadata

Oracle Communications Calendar Server Administration Guide

This guide explains how to administer Oracle Communications Calendar Server (also referred to as Calendar Server 7) and its accompanying software components.

Installing Calendar Server
If you need to install and perform an initial configuration of Calendar Server 7, see Installation Scenario - Oracle Communications Calendar Server 7.0.4.14.0.

Topics:

Setting up Your Initial Calendar Server 7 Deployment

The following tasks are meant to be of use in planning and setting up your initial deployment. After your deployment has gone live, you might also find it useful to revisit these tasks to make additional changes.

Provisioning Calendar Server Users

Topics in this section:

Provisioning Calendar Server Overview

Calendar Server uses Directory Server to store and retrieve user and resource information and to perform authentication. Before you can store Calendar Server information in Directory Server, you need to prepare Directory Server by running the comm_dssetup script, as described in the installation documentation.

You can provision Calendar users and resources in Directory Server either by using Delegated Administrator or LDAP tools. Calendar Server 7 supports the same LDAP schema used by Calendar Server 6. Some additional object classes and attributes were added for Calendar Server 7, as described in Messaging Server and Calendar Server LDAP Object Classes and Attributes. Currently, only the davStore and icsDomainacl attributes are used. Also, some attributes that were used in Calendar Server 6 are no longer used in Calendar Server 7. See Calendar Server and Directory Server Integration and LDAP Schema Changes for more information.

A Calendar Server deployment must have the following attributes defined:

  • mail
  • A unique ID attribute corresponding to the value for the server configuration parameter davcore.uriinfo.permanentuniqueid (see Calendar Server Unique Identifier for more information)

Be sure to also index the attribute used for davcore.uriinfo.permanentuniqueid, as Calendar Server performs searches on it.

To Define Valid Calendar Users

The davcore.ldapattr.userobject configuration parameter was introduced in Calendar Server 7 Update 2 Patch 5.

The davcore.ldapattr.userobject configuration parameter defines what LDAP object class is required to consider an entry as a valid calendar user entry. By default, davcore.ldapattr.userobject is empty. A value that would make sense is icsCalendarUser, however, if you use custom provisioning, you can define your own object class instead.

  • To define a valid calendar user, set the davcore.ldapattr.userobject configuration parameter to a valid LDAP object class.
    For example:

Setting davcore.ldapattr.userobject to the LDAP attribute icsCalendarUser would consider users without that object class in their LDAP entries as invalid calendar users, therefore no auto-provisioning would take place for them in the calendar store.

To Create Calendar Account with Default Calendar Automatically Upon Login

  1. Create users by provisioning them in LDAP.
  2. Provide users instructions for logging in to Calendar Server.
    The auto-creation of the calendar accounts happens when users log in to Calendar Server. By default, the davcore.autocreate.enableautocreate parameter, which permits the auto-creation, is enabled. Disable this parameter if you do not want to automatically create calendar accounts upon login.
  3. Use the davadmin command to set any of the davcore.autocreate.* parameters to customize your deployment:
    For more information on these parameters, see Calendar Server 7 Configuration Parameters.

To Enable and Disable Account Autocreation

This feature is available starting in Calendar Server 7 Update 3.

You can enable or disable, on a system-wide basis, calendar account autocreation, either on login or invite.

  • To enable calendar accounts autocreation:
  • To disable calendar accounts autocreation:

For more information, see the davcore.autocreate.enableautocreate parameter in Calendar Server 7 Configuration Parameters.

To Provision Calendar Users by Using Delegated Administrator

Delegated Administrator 7 supports Calendar Server 7 provisioning. Calendar Server 7 makes use of the davStore attribute and not icsdwphost (which is used in Calendar Server 6) to assign a specific back-end in a multiple back-end scenario. You can add the davStore LDAP attribute to users' and resources' subject entries to associate those users and resources with a particular back-end Calendar Server store. The value of the davStore attribute is equal to one of the davStore IDs defined in the server configuration. davStore is single valued. When not present, a server configurable default davStore ID is used.

When a user or group is assigned a calendar service, the davEntity objectclass is added along with icscalendaruser or icscalendargroup objectclass, enabling you to provision the user or the group with a davStore attribute.

The new user wizard with the Calendar Service Details consists of the following fields:

  • Calendar Host:
  • Calendar Store:
  • Timezone:

where the Calendar Host and Timezone are applicable to Calendar Server 6.x and Calendar Store is applicable to Calendar Server 7.

The user properties section in the Calendar Service Details consists of the following fields:

  • Calendar Host: (icsdwphost)
  • Calendar Store: (davstore)
  • Email Address: (mail)
  • Default Calendar: (icscalendar)
  • Owned Calendar: (icscalendarowned)
  • Subscribed Calendar: (icssubscribed)
  • Timezone: (icstimezone)
  • Calendar Service Status: (icsstatus)

where the Calendar Host, Default Calendar, Timezone, Owned Calendar, Subscribed Calendar are applicable to Calendar Server 6 and Calendar Store is applicable to Calendar Server 7. Email Address and Calendar Service Status are applicable to both servers.

A new field called Calendar Store is added for Calendar Server 7 users. When configuring a user in Delegated Administrator with Calendar services, a valid davstore ID has to be entered in the Calendar Store field instead of hostname.

To Provision Calendar Users Across Virtual Domains

Calendar Server supports hosted (or virtual) domains. In a hosted domain installation, each domain shares the same instance of Calendar Server, which enables multiple domains to exist on a single server. Each domain defines a name space within which all users, groups, and resources are unique. Each domain also has a set of attributes and preferences that you specifically set.

When installing and configuring hosted domains, use Schema 2 only.

Installing and configuring hosted domains on a server involves these high-level steps:

  1. Installing and configuring Calendar Server and Delegated Administrator
    For more information, see Installation Scenario - Calendar Server and Installation Scenario - Delegated Administrator.
  2. Using Delegated Administrator to create the hosted domain, and users, resources, and groups in that hosted domain.
    For more information, see Delegated Administrator Administration Guide.
  3. Setting domain ACLs
    For more information, see Managing Domain Access Controls.
    Note
    Always perform your provisioning for Schema 2 with Delegated Administrator. Schema 1 provisioning tools do not support hosted domains.

To Prevent a User or Resource From Accessing Calendar Server

To prevent a particular user from accessing Calendar Server 7, set the icsStatus attribute to inactive. As of Calendar Server 7 Update 2, this can be done on both a per user or resource, or domain basis. For more information, see icsStatus.

To Check for Active Calendar Users

Starting with Calendar Server 7 Update 2 Patch 5, you can use the commands log to check for which users have been querying their calendars. Thus, you can use that information to determine which users are active. For more information, see Using the commands Log.

Tip
Use a cron job script to automatically scan the commands log file and generate this kind of report.

To Remove Calendar Users

Completely removing a calendar user involves deleting it from the Calendar Server database and the LDAP directory.

  1. Run the davadmin account delete command to delete the user account and calendars from the Calendar Server back-end database.
  2. Set the icsStatus attribute for users being deleted to "removed."
    You need to do this so that the last step of deleting from LDAP by using the commadmin command is successful. Even when you delete the user account in Step 2, the LDAP entry for the user remains with the icsStatus attribute unchanged. Thus, you need to manually set the icsStatus attribute to "removed" so that running the Delegated Administrator commadmin domain purge command removes the user's LDAP entry.
  3. Run the Delegated Administrator commadmin domain purge command to remove the user's LDAP entry.
Note
The commadmin domain purge command does not, however, remove the user as a member from any groups of which the user is a member. To completely remove a user’s entry from the directory you must enable the Referential Integrity plug-in, see: Maintaining Referential Integrity in the Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition 11.

When you remove a calendar user by running the davadmin account delete command, the back-end resources for the user are deleted, and then purged according to the value of the store.dav.defaultbackend.purgedelay configuration parameter. See Removing Unwanted Calendar Data to Reclaim Space for more information.

Note
Beginning with Calendar Server 7 Update 2 Patch 5, the search_calprops.wcap command does not return calendars belonging to accounts which have a status of 'inactive,' 'removed,' or 'deleted.'

To Remove a Calendar User (Example)

These steps show how to use the command-line to remove a calendar user. In this example, the user is:

dn: uid=jsmith,ou=People,o=us.example.com,o=isp

These steps use the ldapmodify command to make changes to the Directory Server LDAP. Other LDAP tools are also available.

  1. In LDAP, search for the user(s) to be removed.
    For example:
  2. Run the davadmin command to remove the calendar account and its calendars from the Calendar Server back-end database:
  3. Verify that the calendar account has been removed from the Calendar Server back-end database:
  4. Run the ldapmodify command to change the user's status to removed in LDAP:

    Alternately, you can run the following commadmin command:

  5. (Optional) If user account is configured for mail service, remove the service for the user and run the msuserpurge command to purge the account from the Messaging Server message store.
    For example:

    The -g 0 option performs an immediate purge.

  6. Run the commadmin command to purge the account:

    The -g 0 option performs an immediate purge.

  7. Verify that the user has been removed from LDAP:

To Move Calendar Users to a New Back-End Database

  1. Take the user offline by using the ldapmodify command to set the LDAP attribute icsstatus to inactive.
  2. Back up the user's data by using the davadmin db backup command.
  3. Delete the user's data from the old back-end database by using the davadmin account delete command.
  4. Update the user's davStore attribute to the new back-end database by using the ldapmodify command.
  5. Restore the user's data to the new back-end database by using the davadmin db restore command.
  6. Re-activate the user by setting the LDAP attribute icsstatus to active.
  7. Restart GlassFish Server.
  8. Verify that the data has been successfully moved by having the user log in and view calendar data.

The following example shows how to move user caltest1@backend1.com from backend1 to the default back-end host1. In this example:

  • The default back end is on host host1 and the database name on the default back end is caldav.
  • The other back end is on host backend1 and the database name on backend1 is caldav_backend1.
  • The user caltest1@backend1.com has data located on backend1.
  1. Take the user offline by using the ldapmodify command to set the LDAP attribute icsstatus to inactive.
    # ./ldapmodify -D "cn=Directory Manager" -w password
    dn: uid=caltest1, ou=People, o=backend1.com, o=dav
    changetype: modify
    replace: icsStatus
    icsStatus:inactive
    
  2. Back up the user's data by using the davadmin db backup command.
    # ./davadmin db backup -u database_user -a caltest1@backend1.com -H backend1 -d caldav_backend1 -k caltest1.bak
    
  3. Delete the user's data from the old back-end database by using the davadmin account delete command.
    ./davadmin account delete -u admin_user -a caltest1@backend1.com
    
  4. Update the user's davStore attribute to the new back-end database by using the ldapmodify command.
    # ./ldapmodify -D "cn=Directory Manager" -w password
    dn: uid=caltest1, ou=People, o=backend1.com, o=dav
    changetype: modify
    replace: davStore:
    davStore: defaultbackend
    
  5. Restore the user's data to the new back-end database by using the davadmin db restore command.
    ./davadmin db restore -H host1 -u database_user -d caldav -k caltest1.bak
    
  6. Re-activate the user by setting the LDAP attribute icsstatus to active.
    # ./ldapmodify -D "cn=Directory Manager" -w password
    dn: uid=caltest1, ou=People, o=backend1.com, o=dav
    changetype: modify
    replace: icsStatus
    icsStatus: active
    
  7. Restart GlassFish Server.
    # ./asadmin stop-domain domain1;./asadmin start-domain domain1
    

To Change a User's Email Address in the Calendar Server Database

The davadmin command was enhanced in Calendar Server 7 Update 2 Patch 5 to perform the repair operation.

When a user undergoes an email address change, use this procedure to fix notification addresses, organizer addresses, attendee addresses, and alarm addresses in the Calendar Server database.

  1. Add the previous email address value to the LDAP attribute defined as mailAlternateAddress, that is, the attribute defined by the davcore.ldapattr.mailalternateaddress configuration parameter.
  2. Replace the the value for the user's mail attribute in LDAP with the new email address.
  3. Run the davadmin account repair -a command.
    For more information on this command, see davadmin account.
  4. (Optional) Remove the previous email value from the mailAlternateAddress values.

To Subscribe or Unsubscribe Calendars

This feature is available starting in Calendar Server 7.0.4.14.0.

Calendar Server administrators can subscribe or unsubscribe calendars for a user by using the davadmin account command with subscribe or unsubscribe actions.

  • To subscribe a user to another user's calendar:
    1. User A gives user B read, write, or all rights to User A's calendar.
    2. User B is subscribed to User A's calendar:
      davadmin account subscribe -a <User B> -c <User A's calendar>
      

      For example:

  • To unsubscribe a user from another user's calendar:
    davadmin account unsubscribe -a <User B> -c <User A's calendar>
    

    For example:

  • To subscribe using a collection file:
    1. Create a file such as /tmp/list_of_collections with the following content:
      /home/usera@example.com/calendar/
      /home/userc@example.com/cal1/
      /home/userd@example.com/personal/
      
    2. Run the following command:

For more information, see account Operation.

Setting up CalDAV and CardDAV Autodiscovery

This feature is available starting in Calendar Server 7 Update 1.

Calendar Server supports the .well-known URI concept as defined in Locating CalDAV and CardDAV services for CalDAV clients to access the Principal URI without having to specify the entire URI. That is, access to / (root) or /.well-known/caldav/ is redirected to the /dav/principals/ URI.

To take full advantage of this functionality, administrators should configure a corresponding DNS record as described in Locating CalDAV and CardDAV services.

Configuring External Authentication

This feature is available starting in Calendar Server 7 Update 3.

Calendar Server enables authentication against a separate, LDAP directory external to the Calendar server environment. Such a configuration is useful in hosted environments for delegating one administrative aspect to a provider (managing the Calendar Server front- and back-end hosts and LDAP directory with non-sensitive data), while maintaining control over the LDAP user passwords in the internal, corporate network. In this setup, Calendar Server would use the external directory for authentication.

Configuring Calendar Server for external authentication consists of the following high-level steps:

  1. Creating the LDAP pool for the external authentication directory
  2. Specifying how to search for users in that directory
  3. Specifying how to map the external user entry back into a Communications Suite directory user entry

Topics in this section:

To Configure Calendar Server for External Authentication

  1. Use the davadmin ldappool command to create then verify an LDAP pool for the external authentication directory.
    For example:

    You can also set other parameters, such as ldappoolsize and ldaptimeout. See the davadmin ldappool command for more information.

  2. Define how to search for users in that directory by adding the externalAuthPreUrlTemplate LDAP attribute to each of the domain entries associated with that external directory.
    The attribute value is an LDAP URL (http://tools.ietf.org/html/rfc4516) of the following form:
    ldap://<server name>/<search base DN>?<attributes>?<scope>?<search filter>

    where:
    server name must correspond to a defined LDAP pool.
    search base DN and search filter can contain the following patterns:

    • %o (original login ID, as provided by the user over protocol)
    • %U (user part of login ID)
    • %V (domain part of login ID)
      The % character in %o, %U, and %V needs to be encoded as per the general URI definition. That is, the % character becomes %25. See externalAuthPreUrlTemplate for more information.
  3. Define how to map the external user entry back into a UCS directory user entry.
    Do the external directory user entries have a mail attribute value corresponding to their internal Communications Suite directory attribute value?
    • If yes, no further configuration is required. (In Step 2, the list of attributes to retrieve should simply include the mail attribute.)
    • If no, define a search to be issued against the Communications Suite directory by using the externalAuthPostUrlTemplate domain entry attribute. As with the the externalAuthPreUrlTemplate attribute, the externalAuthPostUrlTemplate value is an LDAP URL of the following form:
      ldap://<server name>/<search base DN>?<attributes>?<scope>?<search filter>

      See externalAuthPostUrlTemplate for more information. Note the following:

      • The server name is ignored and should be empty because the lookup is performed against the internal Communications Suite directory.
      • The attributes to be retrieved must include the mail attribute.

Example: External Authentication by Using cn

In this external authentication scenario, example.com is the default domain and uses the cn attribute as the login ID. Each user entry in the external authentication directory contains a ucsUid attribute value that corresponds to the internal Communications Suite directory uid attribute value (in the Communications Suite user entry). The LDAP pool is myldap and the following two attributes have been added to the example.com domain entry:

externalAuthPreUrlTemplate: ldap://myldap/dc=example,dc=com?ucsUid?sub?(cn=%25U)
externalAuthPostUrlTemplate: ldap:///uid=%25A[ucsUid],ou=people,o=example.com?mail?base?(objectclass=*)

The LDAP entry in the external directory for a sample user, John Doe, looks like the following:

dn:cn=John Doe,ou=people,o=marketing,dc=example,dc=com
cn:John Doe
ucsUid:jdoe
...

The LDAP entry in the internal Communications Suite directory for John Doe looks like the following:

dn:uid=jdoe,ou=people,o=example.com
cn:Doe, John
uid:jdoe
mail:john.doe@example.com
...

The user authenticates by using the login ID John Doe. Given that this login ID has no domain part, the default domain (example.com) is assumed and the externalAuthPreUrlTemplate attribute of that domain entry is used to construct the following search against the server defined by authPool:

  • base DN: dc=example,dc=com
  • scope: subtree search
  • filter: (cn=John Doe)
  • attributes to retrieve: ucsUid

The entry dn:cn=John Doe,ou=people,o=marketing,dc=example,dc=com is returned and that dn is used to issue an LDAP bind request to verify the user's password.

That same entry (containing the ucsUid attribute) is used to construct a second search, against the Communications Suite user/group directory:

  • base DN: uid=jdoe,ou=people,o=example.com
  • scope: base search
  • filter: (objectClass=*)
  • attributes to retrieve: mail

The correct entry is found and the authentication is considered successful.

Creating Additional Back-end Calendar Server Stores

If you need to create a back-end calendar store after initial installation, see Configuring Multiple Calendar Server Back-end Hosts.

Making Calendar Server Secure

This information describes how to implement security for Calendar Server 7. It also provides links to security topics that provide more indepth information for configuring and administering Calendar Server security.

Topics in this section:

Securing Communications to Calendar Server Back Ends

This capability is available starting in Calendar Server 7.0.4.14.0.

You can enhance your security by configuring SSL communication between the Calendar Server front ends and back ends. First enable the back-end database servers for SSL, setting up either the required trustStore files or wallets. Then configure the Calendar Server front ends to connect over SSL by making use of the stored certificates. To configure a MySQL back end, see Configuring SSL for the Calendar Server MySQL Back End. To configure an OracleDB back end, see Configuring SSL for the Calendar Server OracleDB Back End.

You can also configure SSL communication between the Calendar Server front ends and the remote document stores. See To Configure Remote Document Store SSL.

Securing iSchedule Port

This capability is available starting in Calendar Server 7.0.4.14.0.

You can use the service.dav.ischedulewhitelist configuration parameter to specify the hosts that are allowed to send iSchedule POST requests. You can even limit the hosts to just the SMTP server that uses iSchedule for automatic iMIP handling. Additionally, you can change the maximum content length of requests POSTed to the iSchedule port by setting the value for the davcore.serverlimits.maxischedulecontentlength configuration parameter (the default is set to 10000000 bytes). This blocks very large freebusy or invitation requests at the iSchedule port itself.

  • To specify a list of hosts that are allowed to send iSchedule POST requests, use the davadmin config command:

    where hosts can be:

  • A space-separated list of single host IP addresses and/or Classless Inter-Domain Routing (CIDR) entries (a base IP address followed by a number indicating how many upper bits to mask. For example, 10.20.30.0/24 matches all addresses in the range 10.20.30.0 to 10.20.30.255.
  • 0.0.0.0/0, to allow all requests.
  • An empty list, which denies all requests except for those from "localhost."
  • To change the maximum size of iSchedule data that a client can POST, use the davadmin config command:

Creating Secure Communications Between davadmin and Calendar Server

This capability is available starting in Calendar Server 7.0.4.14.0.

The davadmin command uses the JMX protocol to connect to GlassFish Server. This section describes how to create secure communications between the davadmin command and the Calendar Server over SSL. To do so, you need to create a trustStore file for davadmin. If you are using SSL for communicating with GlassFish Server, it is mandatory to also configure JMX to use SSL.

To Create Secure Communications Between davadmin and Calendar Server

  1. Export the server certificate that GlassFish Server is using for SSL.
    Depending on the GlassFish Server version, you might use the Java keytool command or the NSS certutil command to export the certificate.
    • Example keytool command:
    • Example certutil command:

      In these examples, the current directory is the GlassFish Server configuration directory and the certificate is named s1as.

  2. Import the GlassFish Server certificate into a Java keystore for use by the davadmin command with the -s option.
    For example:
  3. Modify the /var/opt/sun/comms/davserver/config/davadmin.properties file to reflect the new trustStore file created in the previous step.
    Add the following line:
    secure=/var/opt/sun/comms/davserver/config/davtruststore
    

    Alternately, you could specify the explicit path to the trustStore file in the davadmin command with the -s option.
    For example:

  4. In the GlassFish Server 3 Administration Console, enable secure JMX.
    1. Navigate to Configurations.
    2. Navigate to server-config.
    3. Navigate to Admin Service.
    4. On the JMX Connector tab, select the Enabled box for Security.

Configuring GlassFish Server 3 Denial of Service Prevention

This capability is available starting in Calendar Server 7.0.4.14.0.

GlassFish Server 3 provides the following ways to help prevent a Denial of Service (DoS) attack:

  • Limit the size of a POST request
  • Specify a request timeout value
  • Create a blacklist of host names and/or IP addresses

You can configure additional DoS prevention at the Calendar Server level by using configuration parameters such as davcore.serverlimits.maxcontentlength, service.dav.blacklist, service.wcap.blacklist, service.dav.ischedulewhitelist, and davcore.serverlimits.maxischedulecontentlength. For a complete list of configuration parameters, see Calendar Server 7 Configuration Parameters.

To Limit the Size of a POST Request

To limit the size of a POST request, set the Max Post Size field in the GlassFish Server Administration Console:

  1. Choose Configurations.
  2. Choose server-config.
  3. Choose Network Config.
  4. Choose Protocols.
  5. Choose http-listener*.
  6. Choose HTTP.
  7. Edit the Max Post Size field.

On this same page, you can also set the Request Timeout field so that a request fails if it takes longer than the specified time to complete.

Alternately, you can use the asadmin command to set the Max Post Size, for example:

To Create a Blacklist

To create a blacklist of host names and/or IP address, use the GlassFish Server Administration Console to navigate to the server page:

  1. Choose Configurations.
  2. Choose server-config.
  3. Choose Virtual Servers.
  4. Choose server.
    Add properties to indicate which hosts or IP addresses you want to blocked. Use the allowRemoteHost or allowRemoteAddress property names to whitelist hosts, and use the denyRemoteHost or denyRemoteAddress property names to block a host or IP address. Separate multiple host names or IP addresses by commas.

Alternately, you can use the assadmin command to create a whitelist or blacklist of hosts.

  • For example, to create a whitelist:
  • For example, to create a blacklist:

Blocking CalDAV and WCAP Clients

This feature is available starting in Calendar Server 7 Update 2.

Calendar Server can block requests from certain versions of CalDAV clients and WCAP clients that are known to be problematic. Blocked clients receive an error, HTTP 403 status, which indicates that the server can be reached, but the server declined to allow access to the page. By using this capability, you can help to prevent denial of service attacks by blocking rogue clients that can inundate the server with requests.

Topics in this section:

To Block CalDAV Client Requests

  1. Look at the HTTP user-agent request header that contains the client information to determine which client to add to the reject list.
    Here are some user-agent examples:
    user-agent: DAVKit/3.0.6 (661); CalendarStore/3.0.8 (860); iCal/3.0.8 (1287); Mac OS X/10.5.8 (9L31a)
    user-agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (976); iCal/4.0.2 (1379); Mac OS X/10.6.3 (10D573)
    user-agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (976); iCal/4.0.2 (1379); Mac OS X/10.6.3 (10D578)
    user-agent: DAVKit/4.0.3 (732); CalendarStore/4.0.3 (991); iCal/4.0.3 (1388); Mac OS X/10.6.4 (10F569)
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.5pre) Gecko/20100430 Lightning/1.0b2pre OracleBeehiveExtension/1.0.0.0pre6 Thunderbird/3.1b2
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
    user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9.7.4-Oracle Thunderbird/2.0.0.24
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 ( .NET CLR 3.5.30729)
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.5
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.6
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.0 (KHTML, like Gecko) Chrome/6.0.408.1 Safari/534.0
    user-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
    user-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
    user-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12
    user-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.21) Gecko/20090323 Lightning/0.9 Thunderbird/2.0.0.21
    user-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100226 Firefox/3.5.8
    user-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.3
    user-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 Lightning/1.0b2 Thunderbird/3.1
    user-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.0.17) Gecko/2009122317 Firefox/3.0.17
    user-agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.8.1.23) Gecko/20090910 Lightning/0.9 Thunderbird/2.0.0.23
    
  2. Specify a client or list of clients to be rejected for the DAV protocol by using the service.dav.blacklist parameter.
    This parameter takes a a single client/version pair, or list of space-delimited client/version pairs. For example, to cause Calendar Server to reject client requests from Lightning 1.0 Beta 1 and iCal version 3.0.8, use the following command:

    This example causes Calendar Server to reject requests from a client when the exact string "Ligntning/1.0b1" or "iCal/3.0.8" appears in the client's user-agent header. A variation of the client/version pair is when the version part is expressed as a regular expression.

See Calendar Server 7 Configuration Parameters for more information on the service.dav.blacklist parameter.

To Block WCAPbis Clients

  1. Look at a WCAP client's HTTP user-agent request header that contains the client information (regular expression) to use to deny client access.
  2. Use the service.wcap.blacklist configuration parameter to specify a space separated list of regular expressions.

See Calendar Server 7 Configuration Parameters for more information on the service.wcap.blacklist parameter.

Configuring a Secure LDAP Connection

Like other applications, Calendar Server and GlassFish Server use the LDAP protocol to read from and write to Directory Server. The default is to communicate LDAP data by "unsecured" transmission. You can configure your Calendar Server deployment to use Secure Sockets Layer (SSL) for secured transmission of data. You do so by installing a Certificate Authority (CA) certificate on the GlassFish Server then configuring Calendar Server to use LDAP for SSL.

To Configure Calendar Server for Secure LDAP

  1. Configure GlassFish Enterprise Server to use a CA signed certificate for SSL.
  2. When performing this task, note the following.
    • Not all GlassFish Server domains use the same security key store.
      GlassFish Server may end up using either the NSS security library and associated key store for certificates, or it may use the Java Key Store instead. The keystore that GlassFish Server uses is initially determined by the GlassFish Server "Profile:" Enterprise, Developer, or Cluster. The Enterprise profile uses NSS, while the Developer and Cluster use Java Key Store.

      You can specify the profile when you create a new domain. However, the initial domain defaults to a profile depending on the version of GlassFish Server installed along with possible configuration specifications.

      The To Configure GlassFish Enterprise Server to Use a CA Signed Certificate for SSL procedure assumes the Enterprise version of GlassFish Server, which uses the NSS security library and includes the certutil utility.

      If you want to use a profile with Java Key Store, review the Java Key Store documentation on the tool "keytool." Use a newer version of keytool from Java 6.

      The key store is configured during creation of the domain. Although both sets of key store files may be present in the config directory, only the chosen key store is configured with common CA certificates and the GlassFish Server password. Thus, for example, if Java Key Store is configured, and you try to generate a certificate request with certutil, you may get an I/O error because the NSS database is not initialized with the GlassFish Server password.

      Though it should not be necessary, if you need to change the key store password, use the asadmin command, not the certutil utility.
    • Certificate request generation depends on generating the request with the key store database in the domain's config directory.
    • GlassFish Server installs with a default self-signed certficate named s1as. This should already be configured for SSL, and so SSL can be tested before adding a valid certificate. However, many clients warn that the SSL certificate cannot be trusted, and other clients may simply not work.

      Some older versions of FireFox report a "connection was interrupted" error when the certificate is self-signed or otherwise not valid.
  3. Configure Calendar Server to use LDAP for SSL.
    • In step #2, while running davadmin config to process the davadmin commands:
      Processing the configuration file can take time and can result in multiple messages to restart GlassFish Server. Wait until all the commands are finished processing before restarting GlassFish Server. Otherwise, some configuration parameters might not be processed, leaving SSL partially configured.

Configuring Calendar Server for Virus Scanning

This feature is available starting in Calendar Server 7 Update 2.

Calendar Server 7 enables attachments virus scanning by making use of the Messaging Server MTA and its capability to interface to many different AVS systems. Calendar Server packages the calendar event and attachment and sends it by using SMTP to the Messaging Server MTA, where the scanning takes place on the configured AVS system. Messaging Server relays the result of the scan to Calendar Server. Calendar Server can be configured to test and optionally reject incoming data, as well as scan existing data (and optionally delete) by using the davadmin vscan utility.

See Configuring and Administering Virus Scanning in Calendar Server for details.

Where to Find Additional Security Related Information

For more information on making your Calendar Server deployment secure, see Setting Up and Managing Calendar Server Security.

Enabling Calendar Server 7 Advanced Features

Topics in this section:

Enabling Attachments

Starting with Calendar Server 7 Update 2, the davcore.attachment.enable configuration parameter determines whether a deployment is using attachments.

To enable or disable attachments:

  1. List the davcore.attachment.enable parameter value:
  2. Modify the parameter value:
    1. To enable attachments:
    2. To disable attachments:

You do not need to restart the Calendar Server process for a change in the davcore.attachment.enable parameter to take effect.

Enabling Apple iCal Private/Confidential Support

  • To enable Apple iCal private/confidential support, set the davcore.acl.appleprivateevent to true.
    For example:

This triggers the sending of the DAV header with the value calendarserver-private-events to the iCal client. As a result, the iCal client includes a check box labeled "private" in the event creation and modification UI. When the private check box is checked, the iCal property X-CALENDARSERVER-ACCESS is set to CONFIDENTIAL. If the check box is unchecked, the X-CALENDARSERVER-ACCESS is set to PUBLIC. Apple iCal currently supports only these two values.

Enabling SMS Calendar Notifications in Convergence

You can enable SMS notifications for calendar event reminders (but not for calendar invitations) in Convergence. See How Do I Turn on SMS Notifications for Calendar Event Reminders in Convergence?

Enabling the iSchedule Channel to Handle iMIP Messages

The iSchedule database is used to manage external calendar invitations. The established standard for scheduling between two separate calendar servers is still only through iMIP, which sends calendar data over email. Previously, end users had to manually import such invitations and responses that arrived in email into their calendars. Starting with Messaging Server 7 Update 5, you can use an iSchedule channel that interprets such mail messages and posts them to the Calendar server directly. Thus, external invitations and responses get into users' calendars without any user intervention. See Using the iSchedule Channel to Handle iMIP Messages for instructions on how to set up Messaging Server. No special setup is required for Calendar server.

Starting with Calendar Server 7.0.4.14.0, you can use the service.dav.ischedulewhitelist configuration parameter to prevent denial of service attacks on the iSchedule port. The service.dav.ischedulewhitelist parameter lists the hosts from which iSchedule POST requests are allowed. The parameter takes a space separated list of single host IP addresses and/or Classless Inter-Domain Routing (CIDR) entries. A CIDR entry is a base IP address followed by a number indicating how many upper bits to mask. For example, specifying a CIDR of 10.20.30.0/24 matches all addresses from the IP address 10.20.30.0 to the IP address 10.20.30.255. An entry of 0.0.0.0/0 allows all requests. The default setting for the parameter is an empty list, which denies all requests except for those from localhost.

You can also secure the iSchedule port. For more information, see Securing iSchedule Port.

Stopping and Starting Calendar Server 7 Services

Topics in this section:

Stopping and Starting Calendar Server

To stop and start the Calendar Server process, you use the asadmin stop-domain and asadmin start-domain commands to stop and start the GlassFish Server container in which Calendar Server is deployed. The following examples assume a default GlassFish Server installation with Calendar Server deployed in domain1.

  • To stop Calendar Server:
  • To start Calendar Server:

Starting and Stopping the Document Store

The document store was introduced in Calendar Server 7 Update 1. For more information, see Planning the Document Store.

  • To start the document store server:
  • To stop the document store server:

Administering a Calendar Server 7 Deployment

Topics in this section:

Administering GlassFish Server

Calendar Server 7 depends on Sun GlassFish Server as a web container. See the Oracle GlassFish Server Product Documentation for details on administering Glassfish Server. Starting with version 7.0.4.14.0, Calendar Server supports GlassFish Server 3.

The following Glassfish Server documentation links are also provided to help you get started:

Administering the Document Store

The document store was introduced in Calendar Server 7 Update 1.

Topics in this section:

Document Store Overview

The Calendar Server document store is used to store and retrieve "large data," such as calendar events with many invitees, and todos with large attachments. Normally, you configure the document store as part of the Calendar Server installation process. You set up one document store per configured Calendar Server back end. You do so by specifying the location of the document store directory for Calendar Server to use in the store.dav..dbdir configuration parameter, if the store is local, and the store.dav..attachstorehost configuration parameter, if the store is remote. For more information, see Configuring the Calendar Server Document Store.

To start and stop the document store process, see Starting and Stopping the Document Store.

To Change the Password Used for Remote Document Store Authentication

This feature is available starting with Calendar Server 7 Update 3.

When changing passwords used for remote document store authentication, you must change them on both the local Calendar Server host and on each remote document store host to keep them in sync.

  1. Use the following davadmin command to change the password on each remote document store host.

    Respond to the prompts.

  2. Stop then restart the document store server for the password change to take effect.
  3. Use the following davadmin command to change the password on the local Calendar Server host.

    Respond to the prompts.

Note on Backing up the Document Store

The davadmin db backup command prompts for the document store password starting with Calendar Server 7 Update 3.

When you run the davadmin db backup command, you are prompted for the document store password. To avoid having to enter a password every time when running this command, you can create a password file by running the davadmin passfile command.

Using Calendar Server 7 Administration Utilities

Calendar Server provides a number of command-line utilities for server administration. These utilities run under the umbrella command, davadmin, which is a simple shell script. By default, the davadmin utility is installed in the cal-svr-base/sbin directory with user or group bin/bin permissions. See Calendar Server Command-Line Utilities.

Administering Calendar Server 7 Logging

Topics in this section:

Calendar Server 7 Logging Overview

Calendar Server 7 maintains four types of log files:

  • commands - Stores information about requests that are sent to the server and information related to each operation performed to satisfy those requests. The commands log contains servlet and core operation classes entries that are designed to help you monitor requests to the server and help diagnose problems. For more information on the commands log, see Using the commands Log.
  • errors - Stores error and debug-level information that is supplied by the server for use in diagnosing problems.
  • scheduling - Stores information on scheduling actions, showing when invitations are enqueued and dequeued.
  • telemetry - Stores entire Calendar Server servlet request and response transcripts.
  • scan - Beginning with Calendar Server 7 Update 2, stores information on virus scanning actions.

Each of these files has a suffix of .#, which is a rollover number indicating that the log file was filled to its maximum capacity and was rolled over to another file. The lowest numbered log file is the newest.

Each log file has its own configuration attribute that controls the log file location, maximum size, and log level.

The Calendar Server log files are kept separate from the GlassFish Enterprise Server log files. The GlassFish Server log files are maintained in the ${APPSERVER_DOMAIN}/logs directory, where ${APPSERVER_DOMAIN} is the path to the respective container's base directory, for example, /opt/SUNWappserver/domains/domain1/. Even though the container's log file is the root log file, by default, information that is logged to the Calendar Server's log files is not logged to the container's log file.

To Log Calendar Server Information to Application Server Log File

Calendar Server sets its logToParent flag to false by default, preventing logging of information to the Application Server log file.

To log calendar information to both the Application Server log file (server.log) and the Calendar Server log file (calendar.0)):

  • Set the log.dav.commands.logtoparent parameter to true:

To Configure Calendar 7 Log Files

The following table shows the log file parameters.

Calendar Server Log File Parameters

Parameter Description
log.dav.name.logdir Specifies the log file directory path
log.dav.name.loglevel Specifies the log level:
  • SEVERE: Logs catastrophic errors.
  • WARNING: Logs major errors or exceptions with the system.
  • INFO: Logs general informational messages. This is the default level. Any information logged at this level is placed in the log file.
  • FINE: Logs general debugging and tracing information to show the higher level flow through the code or more detailed information about a problem.
  • FINER: Logs finer grain details than FINE.
  • FINEST: Logs the finest grain details of code flow or problem information. Turning on logging at this level could cause massive amounts of data to be put into the log file, making it hard to parse.
log.dav.name.logtoparent Sets a flag to enable logging to the GlassFish Enterprise Server log file, in addition to the Calendar Server logs
log.dav.name.maxlogfiles Specifies the maximum number of log files
log.dav.name.maxlogfilesize Specifies the log file's maximum size

Where name can be commands, errors, scheduling, telemetry, or scan, depending on which log file type you want to configure. The name to use to get the Calendar Server logs is errors.

To View the Document Store Logs

  • The document store logs are located in the datadir/logs directory. Change to this directory to view the log files.

To Set the Logging Level for Calendar Server 7 Logs in GlassFish Enterprise Server

You can set the logging level for Calendar Server logs in the GlassFish Enterprise Server logs, using the Admin Console.

  1. In a browser, access the Admin Console, for example:
  2. Type the administration user name and password, specified when you installed the product, and click Log In.
  3. In the Admin Console, click the Logging tab.
  4. Click the Logging Settings tab.
  5. At the bottom of the page add a logger and set its level by clicking the Add Properties button.
    For the Name, the logger should have the root logger name, com.sun.comms, or a package name, such as com.sun.comms.davserver.core. For the Value, type any of the following values (listed from highest to lowest):
    • SEVERE
    • WARNING
    • INFO
    • CONFIG
    • FINE
    • FINER
    • FINEST
    • OFF
      Messages at the selected level or higher appear in the log. The default level is INFO, so the log will contain messages of INFO, WARNING, or SEVERE levels.
  6. When done, click Save.

Using the scheduling Log

The following table explains the scheduling codes in the scheduling log file.

Codes Used in Scheduling Log Files

Code Log Level Needed Description
E INFO Enqueuing of an inbound scheduling message
J INFO Rejection of attempted enqueue
DL FINE Successful dequeue for a local recipient
DE FINE Successful dequeue for an external (iSchedule) recipient
DM FINE Successful dequeue for an iMIP recipient
QE INFO Temporary failure to dequeue for an external (iSchedule) recipient
QM INFO Temporary failure to dequeue for an iMIP recipient.
R INFO Permanent failure to dequeue

By default, enqueues are logged, as well as unsuccessful dequeues, such as wrong user, temporary errors, and so on. To see successful dequeues in the log, you need to set the scheduling log level to at least FINE.

The following log sample shows sample dequeues and enqueues.

[2012-06-01T16:26:56.018+0200] E "a11bdb82-422a11dd-8002d2ed-c263972e@example.com/calendar-outbox/REQUEST-1338560816008-3-.ics" 6954475.scen REQUEST mailto:james.smith@example.com mailto:ron.white@example.com "1.2;Delivered"
[2012-06-01T16:26:56.019+0200] E "a11bdb82-422a11dd-8002d2ed-c263972e@example.com/calendar-outbox/REQUEST-1338560816008-3-.ics" 6954475.scen REQUEST mailto:james.smith@example.com mailto:mary.jones@example.com "1.2;Delivered"
[2012-06-01T16:26:56.083+0200] DL "a11bdb82-422a11dd-8002d2ed-c263972e@example.com/calendar-outbox/REQUEST-1338560816008-3-.ics" 6954475.scen REQUEST mailto:james.smith@example.com mailto:ron.white@example.com "Success"
[2012-06-01T16:26:56.239+0200] DL "a11bdb82-422a11dd-8002d2ed-c263972e@example.com/calendar-outbox/REQUEST-1338560816008-3-.ics" 6954475.scen REQUEST mailto:james.smith@example.com mailto:mary.jones@example.com "Success"

invitation from james to ron and mary with UID "6954475.scen" was submitted (E) at "2012-06-01T16:26:56.018+0200" and delivered at 2012-06-01T16:26:56.083 to ron and at 2012-06-01T16:26:56.239 to mary

This example shows the following information:

  1. Timestamp
  2. Scheduling codes (E,DL)
  3. Relative URI of scheduling message being processed
  4. iCalendar UID of the event/tasks
  5. Type of message (iTIP REQUEST, REPLY)
  6. Originator
  7. Recipient
  8. iTIP detailed status code

Using the commands Log

The following functionality documented in this section was introduced in Calendar Server 7 Update 2 Patch 5.

The Calendar Server commands log contains per servlet entries that are designed to help monitor requests to the server and help diagnose problems. Starting with Calendar Server 7 Update 2 Patch 5, the commands log is enhanced to pass additional information, including the principal account that logged in and what operations were done from that account.

The commands log records contain three set fields and one variable field:

commands Log Fields

Field Description
Time stamp Identifies when the log entry is created.
Sequence Unique number for each request.
Servlet Name of the Calendar Server servlet that handles the request.
Variable Logs information about the start and end of specific internal server operations..
For HTTP commands that are logged from the servlet layers, this field also logs the HTTP request coming in with a [REQ], the HTTP method, URI information, IP address, host name, and port, as well as the user principal information for that request. The corresponding response is marked as [RES], followed by an HTTP status.

The following log entries are for a simple CalDAV query of a calendar event performed by caluser8@example.com:

[2011-11-16T11:50:21.512-0700] <22> DavServlet[REQ] GET /davserver/dav/home/caluser8@example.com/calendar/test.ics 127.0.0.1 localhost:8080{principal: caluser8@example.com}
[2011-11-16T11:50:21.512-0700] <22> DavServlet----- {authenticated principal: caluser8@example.com}
[2011-11-16T11:50:21.512-0700] <22> DavServlet----- Authentication: caluser8@example.com login_time=0.0 secs,start_service_time=0.0 secs.
[2011-11-16T11:50:21.513-0700] <22> DavServlet----- Get /davserver/dav/home/caluser8@example.com/calendar/test.ics start.
[2011-11-16T11:50:21.517-0700] <22> DavServlet----- Get end. Processing time=0.0040 secs.
[2011-11-16T11:50:21.517-0700] <22> DavServlet----- Get /davserver/dav/home/caluser8@example.com/calendar/test.ics start.
[2011-11-16T11:50:21.521-0700] <22> DavServlet----- Get end. Processing time=0.0040 secs.
[2011-11-16T11:50:21.526-0700] <22> DavServlet[RES] [200] Command execution time: 0.014 secs

The following log entries are from a list_subscribed.wcap command executed by user arnaud@example.com.

[2011-11-14T13:48:36.504-0700] <2056> WCAPServlet [REQ] GET /davserver/wcap/login.wcap?user=arnaud&password=*****&fmt-out=text/xml 127.0.0.1 localhost:8080{principal: arnaud@example.com}
[2011-11-14T13:48:36.504-0700] <2056> WCAPServlet----- {authenticated principal: arnaud@example.com}
[2011-11-14T13:48:36.504-0700] <2056> WCAPServlet----- Authentication: arnaud@example.com login_time=0.0 secs,start_service_time=0.0 secs.
[2011-11-14T13:48:36.504-0700] <2056> WCAPServlet----- Search /home/arnaud@example.com/ start. scope=SCOPE_ONE filter={DAV:}resourcetype=DEFAULT_CALENDAR
[2011-11-14T13:48:36.507-0700] <2056> WCAPServlet----- Search end. Processing time=0.0030 secs. NbEvaluatedNodes=2,NbMatchingNodes=1
[2011-11-14T13:48:36.509-0700] <2056> WCAPServlet[RES] [200] Command execution time: 0.0060 secs
[2011-11-14T13:48:36.565-0700] <2057> WCAPServlet [REQ] GET /davserver/wcap/list_subscribed.wcap?id=W6a505a75-cf21-4d68-90b6-35095ad51ccb&fmt-out=text/xml 127.0.0.1 localhost:8080{authenticated principal: arnaud@example.com}
[2011-11-14T13:48:36.596-0700] <2056> WCAPServlet----- ListSubscribedCalendars /home/arnaud@example.com/calendar_subscribed_set start.
[2011-11-14T13:48:36.596-0700] <2056> WCAPServlet----- Get /home/arnaud@example.com/calendar_subscribed_set start.
[2011-11-14T13:48:36.598-0700] <2056> WCAPServlet----- Get end. Processing time=0.0020 secs.
[2011-11-14T13:48:36.600-0700] <2056> WCAPServlet----- ListSubscribedCalendars end. Processing time=0.0040 secs.
[2011-11-14T13:48:36.600-0700] <2056> WCAPServlet----- Search /home/arnaud@example.com/ start. scope=SCOPE_ONE filter=|({DAV:}resourcetype=CALENDAR)({DAV:}resourcetype=DEFAULT_CALENDAR)
[2011-11-14T13:48:36.612-0700] <2056> WCAPServlet----- Search end. Processing time=0.012 secs. NbEvaluatedNodes=10,NbMatchingNodes=5
...
[2011-11-14T13:48:36.613-0700] <2057> WCAPServlet[RES] [200] Command execution time: 0.049 secs
[2011-11-14T13:48:36.668-0700] <2058> WCAPServlet [REQ] GET /davserver/wcap/list_subscribed.wcap?id=W6a505a75-cf21-4d68-90b6-35095ad51ccb&fmt-out=text/xml 127.0.0.1 localhost:8080{authenticated principal: arnaud@example.com}
[2011-11-14T13:48:36.668-0700] <2056> WCAPServlet----- ListSubscribedCalendars /home/arnaud@example.com/calendar_subscribed_set start.
[2011-11-14T13:48:36.668-0700] <2056> WCAPServlet----- Get /home/arnaud@example.com/calendar_subscribed_set start.
[2011-11-14T13:48:36.670-0700] <2056> WCAPServlet----- Get end. Processing time=0.0020 secs.
[2011-11-14T13:48:36.672-0700] <2056> WCAPServlet----- ListSubscribedCalendars end. Processing time=0.0040 secs.
[2011-11-14T13:48:36.672-0700] <2056> WCAPServlet----- Search /home/arnaud@example.com/ start. scope=SCOPE_ONE filter=|({DAV:}resourcetype=CALENDAR)({DAV:}resourcetype=DEFAULT_CALENDAR)
[2011-11-14T13:48:36.691-0700] <2056> WCAPServlet----- Search end. Processing time=0.019 secs. NbEvaluatedNodes=9,NbMatchingNodes=4
[2011-11-14T13:48:36.692-0700] <2058> WCAPServlet[RES] [200] Command execution time: 0.025 secs

In this example, following the initial login.wcap command, the test issued multiple list_subscribed.wcap commands to the Calendar Server WCAP servlet by using the same session ID obtained from the login command. Starting in Calendar Server 7 Update 2 Patch 6, the email address of the user principal who issues the request is also included as part of the fourth field, between curly braces.

Administering Calendar Server Access

Calendar Server uses Access Control Lists (ACLs) to determine access control for calendars and scheduling.

The following features documented in this section were introduced in Calendar Server 7 Update 1.

Topics in this section:

Overview of ACLs

An Access Control List (ACL) consists of one or more Access Control Entries (ACEs), which are strings that grant a particular level of access. ACEs collectively apply to the same calendar or component, or in the case of scheduling, to an account. Each ACE in an ACL must be separated by a semicolon. Multiple ACE strings can apply to a single calendar or a single account.

ACLs are denied unless explicitly granted. Some control access is "built-in" to Calendar Server. For example, calendar owners have full access to their calendars. Granting of a particular ACE means implicitly granting anything considered a "lower" ACE.

ACEs are in the form, ace_principal:right, where ace_principal can be "@" for all, "@domain" for a domain, "user@domain" for a user and "group@domain" for a group. See Calendar Access Controls for ACE rights for calendars and scheduling.

ACEs function in the following way:

  • More specific access rights override other access rights.
  • Access rights granted to a specific user are more specific than rights granted to a user as member of a group.
  • Rights granted as part of the "all" users setting are considered least specific.
  • If a user is a member of multiple groups, the highest level of access granted individually by any one of the groups is the access level of the user.
  • Calendar Server access control does not take into consideration nesting levels within each group.

You set Calendar Server access controls by using either the davadmin command or WCAP commands. Calendar Server uses the acl parameter to facilitate storing of the ACE strings. The acl parameter is a semicolon-separated list of ACE strings.

Calendar Access Controls

You can set the following four levels of calendar access controls on each calendar collection:

  • none (level n)
  • read (level r)
  • read+write+delete (level w)
  • read+write+delete+manage (level a)

An ACE is granted to all (@), domain, user or group. Definition of "all" is made server-wide through the davcore.acl.calendaranonymousall configuration parameter. If set to false, "all" does not include unauthenticated users. Users and groups are represented by their mail address.

The following example shows an ACE in which all users get read access, userA@example.com gets read, write, delete, and manage access, and all members of groupA@example.com get read, write, and delete access.

The davcore.acl.defaultcalendaracl configuration parameter defines a default ACL for all calendar collections. You can change this value by using the davadmin config command. Calendar Server 7 uses default ACLs for all calendars for which ACLs are not explicitly set.

Scheduling Access Controls

You can set scheduling permissions for an account, which are used for checking a user's freebusy information, inviting a user, and inviting on behalf of a user. The four levels of scheduling access levels are as follows:

  • none (level n)
  • freebusy (level f)
  • freebusy+schedule_invite (level s)
  • freebusy+schedule_invite+manage (level m)

An ACE is granted to all (@), domain, user or group. Definition of "all" is made server-wide through the davcore.acl.schedulinganonymousall configuration parameter. If set to false, "all" does not include unauthenticated users.

You define a default ACL for scheduling by using the davcore.acl.defaultschedulingacl configuration parameter.

To invite someone else, you need to have a scheduling right of at least s for that user.

Setting Access Control for LDAP Groups

In addition to granting calendar and scheduling ACEs to users, you can grant them to LDAP groups. The group is represented by its mail address just like a user. An ACE granted to a group is effective for all members of the group. Any user-specific ACEs granted to a group member override the ACEs granted through group membership.

When evaluating group members for ACL evaluation, only internal group members are considered. That is, only members defined in LDAP by using their DN, directly using the uniquemember attribute, or indirectly as an LDAP URL that resolves to member DNs belonging to the group by using the memberurl attribute, are considered for ACL evaluation.

Retrieving Access Control Information

You use the davadmin command or WCAP commands get_calprops.wcap, search_calprops.wcap, and get_accountprops.wcap to retrieve the access control rights of a logged-in user to a particular calendar, or user. The ACL itself is viewable by owners, administrators, and those users with manage rights only. All other users can get their access rights through the X-S1CS-MYRIGHTS property that is returned by the get and search commands. The value of this property is either calendar-level rights (n, r, w, or a); or scheduling rights (n, f, s or m), depending on the WCAP call.

Configuration Parameters for Access Control

The following table describes the configuration parameters that Calendar Server uses for access control.

Access Control Configuration Parameters

Parameter Description
davcore.acl.defaultcalendaracl Specifies the default access control settings used when creating a new user calendar. The default is: ""
davcore.acl.defaultschedulingacl Specifies the default access control used for scheduling that is set on a scheduling inbox creation (from the server configuration parameter). The default is: @:s
davcore.acl.calendaranonymousall Determines if all (@) includes anonymous principals for user calendar access. The default is: true
davcore.acl.schedulinganonymousall Determines if all (@) includes anonymous principals for scheduling access. The default is: true
davcore.acl.defaultresourcecalendaracl Specifies the default access control settings used when creating a new resource calendar. The default is: @:r
davcore.acl.defaultresourceschedulingacl Specifies the default access control settings set on scheduling inboxes of resource calendars. The default is: @:s

See Calendar Server 7 Configuration Parameters for more information on these access control configuration parameters.

Command-Line Utilities for Access Control

Use the davadmin calendar to get or set calendar ACLs for calendars and the davadmin account command to get or set scheduling ACLs for access control.

WCAP Commands for Access Control

Use get_accountprops.wcap and set_accountprops.wcap to access and set an account's scheduling rights. Use get_calprops.wcap and set_calprops.wcap to access and set the access rights to a calendar. Use search_calprops.wcap to view a user's "MYRIGHTS" (privilege level of access to other users' calendars).

Managing Domain ACLs

Starting with Calendar Server 7 Update 2, domain ACLs control calendar operations that span multiple domains. Calendar Server 7 combines domain ACLs with the calendar and scheduling ACLs to grant or deny levels of access to any calendaring or scheduling operation. All operations within a single domain rely strictly on the calendar and scheduling ACLs.

For more information, see Managing Domain Access Controls.

Managing Dynamic Group ACLs

Starting with Calendar Server 7 Update 2, the group ACL feature now supports the use of dynamic groups. A dynamic group in LDAP uses the member URL attribute to specify an LDAP filter for the membership of the group. For example, the following URL uses a "department=marketing" filter for group membership:

[ldap:///o=mcom.com??sub?(department=marketing)]

Users that are determined to be members through the search filter are granted whatever access is given to the group in the ACL.

Administering Scheduling Options

This section describes how manage Calendar Server scheduling rules, booking window, and LDAP group invitation.

Topics in this section:

Configuring Scheduling Options

Calendar Server processes incoming invitations and delivers them to recipients, including delivery to default calendars for internal recipients, without any extra client interaction. If you need Calendar Server to perform additional checks and processing during scheduling, configure the attendantflag of the recipient's inbox by using either the davadmin account command or the set_accountprops.wcap command.

The attendantflag properties are:

  • Auto Decline of Recurring Meetings. You can disallow recurring meetings for some resource calendars. Any invitation for a recurring meeting received on such a calendar is declined, regardless of its availability.
  • Auto Decline on Scheduling Conflict. Calendar Server performs an upfront freebusy check on internal recipients and rejects the invitation if the scheduling results in a conflict and the recipient is set up to auto decline on conflict.
  • Auto Accept of invitation. Calendar Server can automatically accept incoming invitations if the recipient is set up for it.

Default settings of the flag are determined by the following configuration parameters:

  • davcore.autocreate.calattendantuserflags: default value for users (0 = no auto accept, no auto decline booking conflict, no recurrence check on invitations)
  • davcore.autocreate.calattendantresourceflags: default value for resource calendars (3 = auto accept invitation and auto decline on booking conflict)

Modifying Calendar Booking Window

The davcore.scheduling.minbookingwindow configuration parameter was introduced in Calendar Server 7 Update 3.

Topics in this section:

Calendar Booking Window Overview

The booking window is the scheduling time frame that determines how far into the future a calendar or resource can be booked. The optional minbookingwindow setting calculates the earliest date and time when a reservation can be made on a calendar for an event starting on a specific date and time. The maxbookingwindow setting defines the latest date and time when a resource can be reserved for an event starting on a specific date and time.

If the minbookingwindow value is defined, scheduling for an event at a certain time can occur only if the current time is equal to or greater than the date and time calculated by subtracting this value from the event's proposed start time. If the minbookingwindow setting is not defined, then bookings can be made at any time before the end of the booking window. The minbookingwindow takes a value in the range of 0 to 2 Gbytes. A negative integer value indicates that the minbooking window is not honored during a freebusy check. The default value is -1.

The maxbookingwindow setting (the default value is 365 days) defines the latest date and time when a calendar or resource can be reserved for an event starting on a specific date and time. If the current time is equal to or before the value obtained by subtracting the maxbookingwindow value from the start date and time of the event, then the invitation is successful. If this setting is absent, then the scheduling can occur any time from minbookingwindow. The maxbookingwindow takes a value in the range of 0 to 2 Gbytes.

Taken together, the minbookingwindow and maxbookingwindow settings provide the window of time events can be scheduled on the calendar, relative to the scheduling time. If a single event's timing is outside that window or a recurring event's instances go beyond the window (either before the minimum bound or after the maximum bound), all instances of the event are declined. Otherwise, only instances that are in conflict with other events are declined, if double booking is disallowed. In the case when no minimum bound is set, the event is autodeclined only when any instance is beyond the upper bound specified by maxbookingwindow settings.

In the case when no minimum bound is set, the event is autodeclined only when any instance is beyond the upper bound specified by maxbookingwindow settings.

You set the global booking window settings by the davcore.scheduling.minbookingwindow parameter (introduced in Calendar Server 7 Update 3) and the davcore.scheduling.maxbookingwindow parameter. Starting with Calendar Server 7 Update 3, you can override the global minimum and maximum values by using account-specific settings. These account-level minimum and maximum booking window properties are stored as scheduling inbox collection properties.

In general, only use the davcore.scheduling.minbookingwindow parameter for specialized resources or ones that require upfront time to be readied. For example, you might have a conference room that needs to be configured for Internet connectivity and it normally takes a week to do so. In this case, you would set the davcore.scheduling.minbookingwindow parameter to 7 (days). The conference room resource calendar would then only be available for booking 7 days in advance.

Note
Calendar Server performs a booking window check only if the account is set up to decline on doublebooking or when outside of booking window, that is, if the attendant flag for the davcore.autocreate.calattendantuserflags or davcore.autocreate.calattendantresourceflags configuration parameters is set only to 2, 3, 6, or 7. For information on double booking, see Modifying Calendar Double Booking.
To Configure a Booking Window

To configure both the minimum and maximum booking windows for accounts, you can use either the davadmin command or the set_accountprops.wcap interface. In absence of an account property, Calendar Server defaults to using the corresponding system-wide booking window configuration. For example:

  • davadmin command:
  • set_accountprops.wcap command:

The minimum and maximum booking window settings are used only if the attendant flag is also set appropriately, that is, set to 2, 3, 6, or 7.

Modifying Calendar Double Booking

This feature is available starting in Calendar Server 7 Update 3.

Double booking is the ability to schedule and display two events on a calendar at the same time. Calendar Server keeps track of double booking based on a per-account property. You can use the following ways to control double booking:

  1. Use account autocreation to automatically assign the double-booking property flag. Additionally, you can control the value assigned during autocreation on a per-account basis by using specific LDAP values in the account's LDAP entry.
  2. Manually create accounts with the desired property flag setting.
  3. Modify the value of an existing account by using the davadmin account command or a client that uses the wcap_setaccountprops command.
Note
This feature concerns double booking by invitation only. It does not prevent users with write permission from double booking the calendar by directly creating events in it.

Topics in this section:

Controlling Double Booking When Creating Accounts Automatically

Because autocreation of calendar accounts happens when users log in to Calendar Server, you create users by provisioning the users in LDAP then providing instructions for logging in. For more information, see To Provision Calendar Users Automatically Upon Login.

The two Calendar Server "autocreate" configuration parameters that control double booking are:

  • For users: davcore.autocreate.calattendantuserflags (default is 0, no auto decline, no auto accept)
  • For resources: davcore.autocreate.calattendantresourceflags (default is 3, auto decline and auto accept)

Both configuration parameters take the options described in the following table. Double booking is allowed on calendars when the value of these
attendant flag options is 0, 1, 4, or 5.

Flag Options

Option Value Description
0 Does not perform autoaccept, does not check booking conflict, does not check recurrence on invitations
1 Automatically accepts invitations
2 Automatically declines if invitation results in booking conflict
3 Automatically accepts invitation and automatically declines on booking conflict
4 Automatically declines recurring meeting invitations
5 Automatically accepts invitations and automatically declines recurring meeting invitations
6 Automatically declines recurring invitations and invitations that cause a booking conflict
7 Automatically accepts invitations, automatically declines recurring invitations and invitations that cause a booking conflict

Note
At the system-wide level, if the davcore.scheduling.allowownerdoublebooking parameter is set to true (the default value is false), then resource calendar owners can double book the resource even if an attendant flag is set that prevents double booking.
To Modify Configuration Parameters That Control Double Booking
  • Use the davadmin config modify command to change double booking behavior.
    For example, this command causes invitations for resources to be automatically accepted on invitation and declined on booking conflict or if outside the allowed booking window.

    This command configures the system to not perform autoaccept, not check booking conflict, and not check recurrence on invitations for users:

To Override the Account Autocreation Through LDAP

You can use LDAP to override the double booking value that is set on individual accounts during autocreation.

  1. Check the value of the davcore.ldapattr.icsdoublebooking configuration parameter and change if necessary.
    The value is an LDAP attribute that controls the double booking setting used during autocreation. By default, this attribute is icsDoublebooking.
  2. Update the account's entry in LDAP.
    For example, if you use the icsDoublebooking attribute, a value of 1 enables double booking, and a value of 0 prohibits double-booking. The autoaccept behavior is also controlled similarly. The default attribute that controls autoaccept is icsAutoaccept}}and it is defined by the {{davcore.ldapattr.icsautoaccept configuration parameter.
Manually Creating Accounts

Instead of relying on account autocreation (when a user logs in for the first time or a user or resource is invited to an event for the first time), you can use the davadmin account create command to explicitly create the account with the desired double booking flag setting.

For example, the following command creates a resource calendar that allows double booking and no auto-accept:

Note
For accounts created through the davadmin command, the same defaults for autocreation are used if you do not specify a value.
To Modify Double Booking on Existing Accounts
  • You can use the davadmin account modify command to change the double booking behavior of any account at any time.
    For example, the following command modifies a resource calendar so that double booking is no longer allowed:

Inviting LDAP Groups

The following features documented in this section were introduced in Calendar Server 7 Update 1.

You can invite entire groups in the LDAP directory as one attendee. The group is maintained as one attendee in the organizer's calendar, but the Scheduling Service expands the group and adds each member as a recipient of the invitation. When storing the invitation in each recipients' calendar, that recipient is added as an ATTENDEE, which is referenced as a member of the group. When a recipient replies, that recipient is added as an individual ATTENDEE, also referenced as member of the initial group in the organizer's calendar. This feature can be used to invite both static and dynamic groups in LDAP.

The following configuration parameters control this feature:

  • davcore.serverlimits.maxgroupexpansion - Limits the the level of nested group expansion. By default, it is 3 (three levels deep)
  • davcore.serverlimits.maxattendeesperinstance - For scheduling, limits the number of members as a result of group expansion. The default is 1000.
  • davcore.ldapattr.dngroupmember=uniquemember, davcore.ldapattr.urlgroupmember=memberurl, and
    davcore.ldapattr.mailgroupmember=mgrprfc822mailmember - Specify the various type of LDAP group memberships. davcore.ldapattr.dngroupmember is used for group members specified as a DN, which denotes static membership. davcore.ldapattr.urlgroupmember is used for group members specified through an LDAP filter, which denotes dynamic membership. davcore.ldapattr.mailgroupmember is used for group members specified through an email address.

If you have your own schema elements that follow the semantics of the preceding default settings, you could add those attributes to the corresponding list by using a space delimited fashion.

Administering Resource Calendars

The following features documented in this section were introduced in Calendar Server 7 Update 1.

Topics in this section:

About Resource Calendars

Entities that can be scheduled but that do not control their own attendance status are called resources. You provision resources in LDAP, either with Delegated Administrator or LDAP tools. See Messaging Server and Calendar Server LDAP Object Classes and Attributes for object classes and attributes required or allowed by Calendar Server 7. Once provisioned, the actual calendars are automatically created on first invite, if auto-creation is enabled. You can also create the calendar account with the default calendar for the provisioned resource by using the davadmin account create command.

You can manage resource accounts and calendars just like user accounts and calendars. In addition, you can set the resource account owner by using either the davadmin account or set_accountprops.wcap commands.

The mail LDAP attribute is required to be present for resource entries. Though resources do not check email, Calendar Server uses this address value to identify and schedule the resource, and thus it must be unique to the resource. You do not need to specify other values, such as owner's email address. Depending on your site's requirements, you may choose to discard or manage the email that is sent to resource email addresses. See To Manage a Resource Calendar's Mailbox for more information.

Note
When sharing a resource calendar and you do not receive the email notification advising of the share in your local language then set the preferredLanguage attribute to be your local language in the resource LDAP.

To Provision Resource Calendars (commadmin)

Example for one back-end host:

The LDAP entry for this example resembles the following.

dn: uid=bigdipper,ou=People,o=us.example.com,o=isp
cn: Big Dipper Conference Room
davuniqueid: d256e98e-fb1c-470e-9f78-eb80bc5e5ee8
icscalendar: bigdipper@us.example.com
icsstatus: active
inetresourcestatus: active
mail: bigdipper@us.example.com
objectclass: daventity
objectclass: inetresource
objectclass: icscalendarresource
objectclass: top
owner: uid=calmaster, ou=People, o=us.example.com,o=isp
uid: bigdipper

Example for multiple back-end host deployment:

Notes:

  • When using commadmin resource create, specify a resource owner with the -o owner option, if you want a Convergence user to be able to subscribe to the calendar.
  • The -o owner option can only used be on a uid in the same domain as the resource.

To Provision Resource Calendars (Delegated Administrator Console)

  1. Log in to Delegated Administrator Console.
  2. Select the organization in which to create the resource calendar.
  3. Click the Calendar Resources tab.
  4. Click New.
    The New Calendar Resource page is displayed.
  5. Type the required resource information, including Resource ID, Calendar Resource Name, and Resource Owner.
    You cannot create a resource without a resource owner.
  6. In a multiple back-end deployment, make sure that you type the correct calendar store.
  7. Click Next.
    The summary page is displayed.
  8. Click Finish to create the resource.

To Manage a Resource Calendar's Mailbox

Use one of the following options for a resource calendar's mailbox:

  • In the resource's LDAP entry, set the mail delivery option to forward and set the forwarding address to the bitbucket channel.
    Here is sample LDIF:
  • Assign the resource a valid email address and manage its mailbox. Either assign the password and management of that mailbox to the owner of the resource, or expire and expunge the email account more aggressively, so that email does not build up.

Administering Timezones Support

Support for WCAP was introduced in Calendar Server 7 Update 1.

Topics in this section:

About Timezones

Timezones are an important part of any time and date based application like calendaring and scheduling. Calendar Server uses the standard Time Zone Database, which is maintained by IANA, for timezone information. The timezone information is compiled and shipped along with Calendar Server. Each Calendar Server patch is updated to the latest available Time zone Database.

Adding New WCAP Timezones

Calendar Server makes a subset of supported timezones available to WCAP clients. Calendar Server derives the supported WCAP timezones to match those that the Convergence client supports. If you modify the Convergence client to support a new timezone, you need to also add the new timezone to Calendar Server's WCAP timezone list.

The list of WCAP timezones is derived from the list provided in the cal-svr-base/config/timezoneids.txt file. The file consists of the supported Time Zone Database timezoneid strings followed by their aliases, if any. The alias names are separated by a colon character. The file has one line per supported timezone.

For more information on how this works with Convergence, see Customization Example - Adding and Modifying Calendar 7 Timezones in Convergence 2.

To Add an Alias to an Existing Timezone

The following task applies to WCAP clients that use timezone aliases. Currently, the Convergence client does not support timezone aliases.

  1. Edit the cal-svr-base/config/timezoneids.txt file.
  2. Find the corresponding timezone line and add a colon followed by the new alias name at the end of the line.
    For example, to add the alias US West Coast to the America/Los_Angeles timezone entry, change:
    America/Los_Angeles:Pacific Standard Time:US/Pacific
    

    to

    America/Los_Angeles:Pacific Standard Time:US/Pacific:US West Coast
    
  3. Restart Calendar Server.
    See Stopping and Starting Calendar Server.

To Add a New Timezone

  1. Find the timezone or its equivalent in the list of Time Zone Database supported by the server.
  2. Edit the cal-svr-base/config/timezoneids.txt file.
  3. Add an entry for that timezone ID to the end of the file.
  4. If you prefer a different name, add that name as an alias too, by adding a colon and the name following the timezone ID entry.
  5. Restart Calendar Server.
    See Stopping and Starting Calendar Server.

Customizing Calendar Notifications

Calendar Server 7 provides preformatted notification messages to be sent to calendar owners when changes occur in calendar resources and properties. You can customize these files for your own deployment. See Using Calendar Server 7 Notifications for details.

Administering the Calendar Server Back End Databases

Topics in this section:

Administering the MySQL Database

The following links provide information about administering MySQL. For more information, consult the MySQL documentation directly.

Caution
You can view contents of the back-end store by using standard MySQL tools. Do not use MySQL tools to modify your data.

Administering the Oracle Database

The following links provide information about administering Oracle Database. For more information, consult the Oracle Database documentation directly.

Caution
You can view contents of the back-end store by using standard Oracle Database tools. Do not use Oracle Database tools to modify your data.

Backing Up and Restoring Calendar Server Data

See Best Practices for Backing Up and Restoring Databases in Calendar Server Deployments.

Removing Unwanted Calendar Data to Reclaim Space

Topics in this section:

Purging Deleted Calendar Entries

When calendar data is deleted, either by users deleting events and tasks, or by using the davadmin account delete, the data is only marked for deletion. The data is actually purged from the calendar database when the expiry time is reached. The default expiry time is 30 days and is controlled by the store.dav.defaultbackend.purgedelay configuration parameter. For more information on this parameter, see Calendar Server 7 Configuration Parameters.

Purging Messages From the Scheduling Inbox and Outbox

The ability to purge messages from the scheduling inbox and outbox was introduced in Calendar Server 7 Update 1 Patch 3.

Oracle Communications Calendar Server 7 supports implicit scheduling. The actual scheduling process involves writing of the iTIP request to the sender's calendar outbox, then posting it to the recipients' inboxes, and eventually writing to the recipients' default calendars. The interim iTIP messages are stored as resources in the Calendar Server users' scheduling outbox and inbox. Prior to Calendar Server 7 Update 2 Patch3, these messages were deleted only if the end user or the end user's client explicitly deleted them. This could have lead to those collections growing indefinitely. Starting with Calendar Server 7 Update 1 Patch 3, you can automatically purge these resources in the outbox and inbox collections.

To set the interval to purge messages from the scheduling outbox and inbox, use the davcore.scheduling.calendaroutboxexpirytime and davcore.scheduling.calendarinboxexpirytime parameters. For more information on these options, see the Calendar Server 7 Configuration Parameters. These parameters enable you to set the expiration time for scheduling messages in all the users' outbox and inbox.

For each parameter, specify the number of seconds after which the resources in the outbox/inbox should be deleted. The default for davcore.scheduling.calendaroutboxexpirytime is 604800 seconds (7 days), and the default for davcore.scheduling.calendarinboxexpirytime is 2592000 seconds (30 days).

Troubleshooting Calendar Server 7

See Calendar Server 7 Troubleshooting.

Where to Go for More Information

See the following Calendar Server 7 reference information:

Labels:
guide guide Delete
caldavserver caldavserver Delete
update7u2 update7u2 Delete
administering administering Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 15, 2013

    Hi Joe,

    last update seems to contain a transposition error: preferredLangauge
    Cheers
    Jens

    1. Jul 15, 2013

      Thanks Jens, I fixed this.

      Joe

  2. Sep 11, 2013

    Hi,
    while DeprecatedAttributesandObjectClassesinCalendarServer7 marks icsTimezone as a 'not used by cal7' attribute, the example ldif in ToManageaResourceCalendar'sMailbox suggest that this might still make a difference.

    Cheers
    Jens

    1. Sep 11, 2013

      Hi Jens,

      Looks like that is a legacy attribute not used by CS 7. I have updated the document.

      Thanks,

      Joe

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.