| Oracle® Communications Calendar Server System Administrator's Guide Release 7.0.5 E54935-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Calendar Server System Administrator's Guide Release 7.0.5 E54935-01 |
|
|
PDF · Mobi · ePub |
This chapter provides details on monitoring and managing Oracle Communications Calendar Server.
Calendar Server depends on Oracle GlassFish Server as a web container. See the Oracle GlassFish Server 3 documentation for details on administering GlassFish Server.
The following Glassfish Server documentation will help you get started:
"Certificates and SSL" in Glassfish Server Security Guide
"asadmin Utility" in Glassfish Server Administration Guide
"High Availability in GlassFish Server" in Glassfish Server High Availability Administration Guide
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.defaultbackend.dbdir configuration parameter, if the store is local, and the store.dav.backend_name.attachstorehost configuration parameter, if the store is remote. For more information, see the topic on configuring the document store in Calendar Server Installation and Configuration Guide.
Administering the document store involves:
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 synchronized.
To change the remote document store password:
Use the following davadmin command to change the password on each remote document store host.
cd CalendarServer_home/sbin
./davadmin passfile modify -O
Respond to the prompts.
Stop then restart the document store server for the password change to take effect.
cd CalendarServer_home/sbin
./stop-as
./start-as
Use the following davadmin command to change the password on the local Calendar Server host.
cd CalendarServer_home/sbin
./davadmin passfile modify
Respond to the prompts.
Note:
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, create a password file by running the davadmin passfile command.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 CalendarServer_home/sbin directory with user or group bin/bin permissions. See "Calendar Server Command-Line Utilities" for more information.
Managing logging includes:
Calendar Server 7 maintains the following 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. See "Using the commands Log" for more information on 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: Stores information on virus scanning actions.
Each log file has its own configuration parameters that control the log file location, maximum size, log level, and number of files allowed.
Log files are created with a suffix of .number, for example, commands.0, commands.1, and so on. The log file numbered .0 is the newest, the log file numbered .1 is next newest, and so on. When a log file is filled to its maximum configured size, the logging system increments each of the existing log file suffixes to the next higher number, starting with the highest. If the number of log files reaches the configured maximum, the highest numbered log file is deleted and the next higher takes its place.
For example, Calendar Server is started for the first time and you have configured the maximum number of log files at 10. The logging system begins writing messages to the log file with the .0 suffix. When the .0 log file is filled to capacity, the logging system increments its suffix to the next higher number and the file becomes .1. The logging system then creates a new .0 log file and begins writing messages to it. When the .0 file become full, the logging system increments the .1 file to .2, increments the .0 file to .1, and creates a a new .0 file. This process continues until the maximum number of configured log files is reached. When that happens, the logging system deletes the highest numbered (oldest) log file, .9, increments each of the lower numbered files' suffixes, and creates a new .0 log file.
The Calendar Server log files are kept separate from the GlassFish Server log files. The GlassFish Server log files are maintained in the GlassFish_home/domains/domain_name/logs directory, for example, /opt/glassfish3/glassfish/domains/domain1/logs. 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.
The Calendar Server logToParent flag is to false by default, preventing logging of information to the GlassFish Server log file.
To log calendar information to both the GlassFish Server log file (server.log) and the Calendar Server log file (commands.0), set the log.dav.commands.logtoparent parameter to true:
./davadmin config modify -u admin -o log.dav.commands.logtoparent -v true
Use the davadmin command to configure Calendar Server logging configuration parameters as shown in Table 3-1.
name can be commands, errors, scheduling, telemetry, or scan, depending on the type of logging you want to configure; use error to configure Calendar Server error logging. SEVERE and WARNING messages need immediate attention. FINE, FINER, and FINEST messages are usually informational only, but can provide more context for troubleshooting when accompanying SEVERE and WARNING messages.
For more information about the logging configuration parameters and their default values, see "Calendar Server Configuration Parameters."
Table 3-1 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:
|
|
log.dav.name.logtoparent |
Enables or disables logging to the GlassFish Server log file. When set to true, messages are logged to both the GlassFish Server log file and the Calendar Server log file. Set to false to disable logging to the GlassFish Server log file. |
|
log.dav.name.maxlogfiles |
Specifies the maximum number of log files |
|
log.dav.name.maxlogfilesize |
Specifies the log file's maximum size |
The document store logs are named astore.number and are located in the CalendarServer_home/logs directory. Change to this directory to view the log files.
The scheduling log file stores information on scheduling actions, showing when invitations are enqueued and dequeued Table 3-2 describes the scheduling codes in the scheduling log file.
Table 3-2 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 must 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:
Timestamp
Scheduling codes (E,DL)
Relative URI of scheduling message being processed
iCalendar UID of the event/tasks
Type of message (iTIP REQUEST, REPLY)
Originator
Recipient
iTIP detailed status code
The Calendar Server commands log file contains per servlet entries that are designed to help monitor requests to the server and help diagnose problems. The commands log file includes the principal account that logged in and what operations were done from that account.
Table 3-3 describes the command log fields. The commands log records contain three set fields and one variable field.
| 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. The email address of the user principal who issues the request is also included as part of the fourth field, between curly braces.
Calendar Server uses Access Control Lists (ACLs) to determine access control for calendars and scheduling.
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 for 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.
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. If you change the davcore.acl.calendaranonymousall parameter, the change does not affect ACLs that were previously configured. Changing davcore.acl.calendaranonymousall only affects new ACLs.
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.
@:r;userA@example.com:a;groupA@example.com:w
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 uses default ACLs for all calendars for which ACLs are not explicitly set.
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:
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 must have a scheduling right of at least s for that user.
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.
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.
See Calendar Server WCAP Developer's Guide for information on the get_calprops.wcap, search_calprops.wcap, and get_accountprops.wcap commands.
Table 3-4 describes the configuration parameters that Calendar Server uses for access control.
Table 3-4 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 Configuration Parameters" for more information on these access control configuration parameters.
Use the davadmin calendar command to get or set calendar ACLs for calendars and the davadmin account command to get or set scheduling ACLs for access control. See "Calendar Server Command-Line Utilities" for more information.
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).
For information on these commands, see the topic on Web Calendar Access Protocol overview in Calendar Server WCAP Developer's Guide.
Domain ACLs control calendar operations that span multiple domains. Calendar Server 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 the topic on managing domain access controls in Calendar Server Security Guide.
The group ACL feature 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.
This section describes how manage Calendar Server scheduling rules, booking window, and LDAP group invitation.
Administering scheduling options involves:
Controlling Double Booking When Creating Accounts Automatically
Modifying Configuration Parameters That Control Double Booking
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)
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 minbookingwindow 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 using the davcore.scheduling.minbookingwindow parameter and the davcore.scheduling.maxbookingwindow parameter. 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 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:
./davadmin account modify -a resource1@example.com -y minbookingwindow=10,maxbookingwindow=365
set_accountprops.wcap command:
$(wcapbase)/set_accountprops.wcap?account=$(resourceEmail)&minbookingwindow=10&maxbookingwindow=365&fmt-out=text/json
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.
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:
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.
Manually create accounts with the desired property flag setting.
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.Because automatic creation 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 "Creating Calendar Account with Default Calendar 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)
Table 3-5 describes the flag options. Both the davcore.autocreate.calattendantuserflags and davcore.autocreate.calattendantresourceflags configuration parameters take the options described in the table. Double booking is allowed on calendars when the value of these attendant flag options is 0, 1, 4, or 5.
| 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.Use the davadmin config modify command to change double booking behavior.
For example, the following command causes invitations for resources to be automatically accepted on invitation and declined on booking conflict or if outside the allowed booking window.
./davadmin config modify -u admin -o davcore.autocreate.calattendantresourceflags -v 3
The following command configures the system to not perform autoaccept, not check booking conflict, and not check recurrence on invitations for users:
./davadmin config modify -u admin -o davcore.autocreate.calattendantuserflags -v 0
You can use LDAP to override the double booking value that is set on individual accounts during autocreation.
Check the value of the davcore.ldapattr.icsdoublebooking configuration parameter and change it if necessary.
The value is an LDAP attribute that controls the double booking setting used during autocreation. By default, this attribute is icsDoublebooking.
./davadmin config list -o davcore.ldapattr.icsdoublebooking
Enter Admin password: password
davcore.ldapattr.icsdoublebooking: icsDoubleBooking
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.
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:
./davadmin account create -a "resource@example.com" -y "attendanceflag=0"
Note:
For accounts created through the davadmin command, the same defaults for autocreation are used if you do not specify a value.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:
./davadmin account modify -a "resource@example.com" -y "attendanceflag=2"
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 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, anddavcore.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 involves:
Entities that can be scheduled but that do not control their own attendance status are called resources. You provision resources in LDAP, either by using Delegated Administrator or LDAP tools. See "Messaging Server and Calendar Server LDAP Object Classes and Attributes" in Communications Suite Schema Reference 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. See "davadmin account" for details.
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.
An LDAP "mail" attribute (most often the mail 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 "Managing 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.When you have multiple back-end hosts, use -A davstore:backend -E email to provision the Calendar Server back-end host for the resource, where backend is the JBDC resource name without the JBDC prefix.
This is mandatory for:
Multiple Calendar Server 7 back-end hosts
Calendar Server 6 and 7 coexistent deployments
Example for one back-end host:
DelegatedAdmin_home/bin/commadmin resource create -D admin -c bigdipper -N "Big Dipper Conference Room" -E bigdipper@us.example.com -o calmaster
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:
DelegatedAdmin_home/bin/commadmin resource create -D calmaster -d demo.example.com -w password -u room1 -c room1 -N Room1 -A davstore:defaultbackend -E room1@demo.example.com
Notes:
For commadmin resource create, use 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 by using the Delegated Administrator console:
Log in to Delegated Administrator Console.
Select the organization in which to create the resource calendar.
Click the Calendar Resources tab.
Click New.
The New Calendar Resource page is displayed.
Type the required resource information, including Resource ID, Calendar Resource Name, and Resource Owner.
You cannot create a resource without a resource owner.
In a multiple back-end deployment, make sure that you type the correct calendar store.
Click Next.
The summary page is displayed.
Click Finish to create the resource.
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:
dn: uid=calresbitbucket,ou=People, o=exaample.com, o=dav uid: calresbitbucket cn: CalResBitBucket description: Conference Room mail: calresbitbucket@example.com icsStatus: active objectClass: top objectClass: inetresource objectClass: icscalendarresource objectClass: daventity objectClass: inetMailUser objectclass: inetlocalmailrecipient inetResourceStatus: active owner: uid=john, ou=People, o=example.com, o=dav mailDeliveryOption: forward mailForwardingAddress: calresbitbucket@[channel:bitbucket] mailhost: icsmail.example.com
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.
Time zones 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 time zone information. The timez one information is compiled and shipped along with Calendar Server. Each Calendar Server patch is updated to the latest available Time Zone Database. For more information on IANA, see the website at:
http://www.iana.org/time-zones
Administering time zones includes:
Calendar Server makes a subset of supported time zones available to WCAP clients. Calendar Server derives the supported WCAP time zones to match those that the Convergence client supports. If you modify the Convergence client to support a new time zone, you must also add the new time zone to Calendar Server's WCAP time zone list.
The list of WCAP time zones is derived from the list provided in the CalendarServer_home/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 time zone.
For more information on how this works with Convergence, see the topic on adding and modifying Calendar Server time zones in Convergence Customization Guide.
The following task applies to WCAP clients that use time zone aliases. Currently, the Convergence client does not support time zone aliases.
To add an alias to an existing time zone:
Edit the CalendarServer_home/config/timezoneids.txt file.
Find the corresponding time zone 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 time zone entry, change:
America/Los_Angeles:Pacific Standard Time:US/Pacific
to
America/Los_Angeles:Pacific Standard Time:US/Pacific:US West Coast
Restart Calendar Server.
See "Stopping and Starting Calendar Server" for details.
To add a new time zone:
Find the time zone or its equivalent in the "Time Zone Database" list supported by the server.
Edit the CalendarServer_home/config/timezoneids.txt file.
Add an entry for that time zone ID to the end of the file.
If you prefer a different name, add that name as an alias too, by adding a colon and the name following the time zone ID entry.
Restart Calendar Server.
See "Stopping and Starting Calendar Server" for details.
Calendar Server 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 Notifications" for details.
This section describes how to administer the Calendar Server back end databases.
The following links provide information about administering MySQL. For more information, consult the MySQL documentation directly.
"Starting and Stopping MySQL Automatically" in MySQL 5.5 Reference Manual
"MySQL Server and Server-Startup Programs" in MySQL 5.5 Reference Manual
"MySQL Administrative and Utility Programs" in MySQL 5.5 Reference Manual
Caution:
You can view contents of the back-end store by using standard MySQL tools. Do not use MySQL tools to modify your data.The following links provide information about administering Oracle Database. For more information, consult the Oracle Database documentation directly.
"Stopping and Starting Oracle Software" in Oracle Database Administrator's Reference 11g Release 1 (11.1) for Linux and UNIX-Based Operating Systems
"Administering Oracle Database" in Oracle Database Administrator's Reference 11g Release 1 (11.1) for Linux and UNIX-Based Operating Systems
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.See "Backing Up and Restoring Calendar Server Files and Data" for information.
To reclaim space in the Calendar Server database, you can purge deleted calendar entries and purge messages from the scheduling inbox and outbox.
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. See "Calendar Server Configuration Parameters" for more information on this parameter.
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. 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. See "Calendar Server Configuration Parameters" for more information on these options. 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 outboxor 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).
|
 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|