Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide

Part III Deploying Calendar Server

This part contains the following chapters:

Chapter 16 Introduction to Calendar Server Software

This chapter provides an overview of Sun Java System Calendar Server, the business reasoning behind deploying Calendar Server, and the deployment process itself.

This chapter contains the following sections:

Calendar Server Overview

Sun Java System Calendar Server (formerly Sun^TM ONE Calendar Server) is a high-performance, Internet standards-based calendar server designed with the scalability to meet the needs of customers ranging from medium- and large-sized enterprises to even the largest telecommunication and Internet service providers. Through a native Web browser interface or connectors to other calendar clients, including Microsoft Outlook, Calendar Server provides group scheduling and personal calendaring to consumers at home or at work, while enabling them to share calendar information with others over the Internet. The user interface (UI) can be customized to include Web links for e-commerce, banner ads, logo, or brand of the calendar server customer, and more.

Calendar Server provides one of the industry’s most open, interoperable, and high-performance time and resource management solutions. Through its scalability, performance, and reliability, it provides the features you require at a lower total cost of ownership than alternative solutions. Native support for iCalendar standards enables users to schedule events in a format that is easily shared across the Internet. Calendar Server employs standards and protocols such as:

Internet Calendaring (iCalendar)
iCalendar Transport-Independent Interoperability Protocol (iTIP)
iCalendar Message-based Interoperability Protocol (iMIP)
eXtensible Markup Language (XML)
Lightweight Directory Access Protocol (LDAP)
HyperText Transport Protocol (HTTP)

The Calendar Server architecture is flexible, extensible, and scalable both vertically (by increasing the number of CPUs per system) and horizontally (by introducing additional servers into the network). As a result, Calendar Server can be thought of as a system of servers that can be configured to fit a variety of needs. It can remain in isolation as a standalone calendar server, or it can be configured with many instances, having the various services duplicated or split between them.

Calendar Server makes use of plugins to obtain external services. Calendar Server also supports both LDAP- and identity-based deployments, and integrates with Sun Java System Access Manager (formerly Identity Server), Sun Java System Portal Server (formerly Sun ONE Portal Server), and Sun Java System Instant Messaging (formerly Sun ONE Instant Messaging) to provide additional functionality.

Calendar Server provides the following benefits:

Web-based group scheduling, free-busy lookup, and corporate directory lookup
Web-based resource scheduling for conference rooms, projectors, and other resources
XML-based customization (color, login, user interface, logo, branding, and so on)
Support for standards-based event and calendar data feeds published in XML or iCalendar formats, which improves communication and can offer new revenue opportunities through commerce links and banner ads
Native LDAP support, with an API for other directory services
Connectors to additional calendar clients, such as Microsoft Outlook, enabling these clients to perform scheduling on Calendar Server
Support for hosted domains
Simplified system management, online backup and restore, and entire database backup and restore
Support for multiple calendars, such as work, family, friends, and more
Support for public and private calendars, as well as public, private, and confidential individual events
Support for layered calendar views, which enables users to combine two or more calendars into a single view, providing improved communication and productivity
Automatic e-mail notification of appointments, invitations, and reminders sent to selected recipients; integrates with Sun Java System Instant Messaging to provide automatic pop-up reminders
Support for multiple owners of each calendar, to facilitate communication and productivity with project teams and community groups
Ability to delegate calendar ownership to others who may act on behalf of the primary owner
Daily, weekly, monthly, yearly, and comparison views
Supports hundreds of thousands of users through a scalable, networked, server-to-server, client- server architecture
Supports Secure Sockets Layer (SSL) encryption, LDAP authentication, authentication plugins, and identity-enabled single sign-on (SSO) through Access Manager

For more information on Calendar Server concepts, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Designing Your Calendar Server Deployment

The deployment process consists of the following general phases, referred to as the Solution Life Cycle:

Analyzing business requirements
Analyzing technical requirements
Designing the logical architecture
Designing the deployment architecture
Implementing the deployment
Operating the deployment

The deployment phases are not rigid: the deployment process is iterative in nature.

For detailed information on the deployment process for Calendar Server, and other Java Enterprise System components, see the Sun Java Enterprise System 2005Q4 Deployment Planning Guide.

Objectives of Your Calendar Server Deployment

Before you begin your Calendar Server deployment planning, a good question to ask is:

Why is my organization deploying Calendar Server?

Several reasons to consider are:

Cost savings. The total cost of ownership per user is lower than using other calendar products on the market.
Increased productivity. Your calendar users can manage their events and tasks as well as schedule meetings and appointments with others in the organization. Your users can also manage calendar groups and resources such as meeting rooms and equipment. They can also synchronize their calendars with mobile devices (PDAs) and Microsoft Outlook.
Improved scalability and availability. Calendar Server scales both horizontally and vertically. If your organization grows, you can easily upgrade your configuration by upgrading a server or add more servers.
Improved security. If you deploy Calendar Server on a Solaris system, your organization can avoid many viruses and other security threats that are common in Windows environments.
High availability (HA) configuration. Integration with e Sun Cluster software enables you to configure Calendar Server as a highly available service. If you experience a software or hardware failure, Calendar Server fails over to a secondary server.

Calendar Server Deployment Team

Deploying Calendar Server usually involves a number of people, each with different roles and responsibilities. In a small organization, one person might perform several roles. Some of the roles to consider are:

Program Manager oversees the overall Calendar Server deployment and is responsible for its success or failure.
Calendar Server Administrator performs day-to-day administrative tasks to manage Calendar Server and might also be responsible for installing and upgrading Calendar Server.
Performance Engineer tests and monitors the Calendar Server performance for the trial and production deployments to see if the deployment criteria is met.
Development Engineering writes Calendar Server applications or plugins, or customizes the Calendar Server user interface (UI), if required.
Documentation Specialist writes any customized documentation for administrators and end users.
Education/Training develops training classes and material.
Support Specialists, who support both the trial and production deployments.

Calendar Server End Users

End users can connect to Calendar Server by using the Calendar Express Web client, Communications Express web client, or Sun Java System Connector for Microsoft Outlook.

Questions about end users at your site include:

How many total Calendar Server end users will your site have?
How will your end users connect to Calendar Server? Calendar Express? Communications Express? Microsoft Outlook? A combination of clients?
How many geographic locations are involved? Are your end users all in the same or different time zones?
Will your end users log into Calendar Server at the same time each day?
How many active end users will your deployment have during peak use?
How fast will your end user base grow?
What are your specific performance requirements for Calendar Server end users?
What are your single sign-on (SSO) requirements?
Are any of your users migrating from Netscape^TM Calendar 4.x?
Are your end users planning to use Sun ONE Synchronization?
Are you planning to customize the Calendar Server UI for your end users?
Does your site plan to use a proxy server?
Does your site plan to use load balancing?

Expected Calendar Server End User Performance

What are your specific performance requirements for your end users? For example:

What end user response times are acceptable?
Can you tolerate a possible degradation in performance during peak load times?

What configuration do you plan to use for your deployment? Calendar Server configuration scenarios include:

Single Calendar Server instance
Single front-end server with single back-end database server
Multiple front-end servers with multiple back-end database servers using LDAP CLD plugin
Multiple front-end/back-end servers using LDAP CLD plugin
High Availability (HA) configuration

If you plan to configure multiple front-end servers, how do you plan to distribute your end users?

If you plan to configure multiple back-end database servers, how do you plan to distribute your database? For example, you could distribute servers geographically.

What plans to you have for growth? For both front-end and back-end servers?

Chapter 17 Developing a Calendar Server Architecture

This chapter describes three basic Calendar Server deployment architectures, which can vary depending on your site’s specific requirements.

This chapter contains the following sections:

Single-Server Calendar Server Architecture

Figure 17–1 shows a single-server architecture. In this deployment, all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The Directory Server and Access Manager processes can run on the same server or on different servers.

Figure 17–1 Single-Server Calendar Server Architecture

This diagram shows a minimal, single-server Calendar Server deployment.

A Calendar Server instance on a single server includes the following services:

Administration service (csadmind process) provides support for administration functions such as commands to start or stop Calendar Server, create or delete calendar users or resources, or fetch and store calendars.
HTTP service (cshttpd process) handles incoming SHTML and WCAP requests.
Event Notification Service (enpd) acts as the broker for event and alarm notifications.
Backup service (csstored) implements automatic backups, both archival backups and hot backups.

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

The Database Wire Protocol (DWP) service (csdwpd process), which provides networking capability when the calendar database is on another server, is not required for a minimal configuration because the database is on the same server.

Calendar Server requires a directory server to authenticate users and to store user preferences. Usually, the directory server is an LDAP directory server, such as Sun Java System Directory Server. However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plugin to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server 6 2005Q4 Developer’s Guide.

The directory server can run on the same server where Calendar Server is running or on a remote server.

Sun Java System Access Manager (release 2003Q4 (6.1) or later) provides the following functionality:

Communications Services Delegated Administrator utility. Use the CLI utility (commadmin) to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles for Sun Java System communications servers, including Calendar Server.

For information about the Communications Services Delegated Administrator utility, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
Single Sign-on (SSO). You can implement SSO for Sun Java Enterprise System servers, including Calendar Server and Messaging Server, using Access Manager, or through trusted circle technology. Access Manager serves as the SSO gateway for Java Enterprise System servers. Users log in to Access Manager and then can access other the servers, as long as all servers are configured properly for SSO.
Sun Java System LDAP Schema 2. Access Manager (release 2003Q4 or later) is required if you want to use this version of the schema.

For more information on these topics, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Access Manager can run on the same server where Calendar Server is running or on a remote server.

End users connect to Calendar Server from client machines by using one of two Web user interfaces (UIs), either Sun Java System Calendar Express, or Sun Java System Communications Express. For information using these interfaces, see the respective interface’s online Help.

Two-tiered Calendar Server Architecture

Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services can also be distributed across multiple CPUs.

In a two-tiered architecture, sometimes referred to as network front-end/database back-end configuration (shown in the following figure), users log in to a front-end server and connect to a back-end server using the Database Wire Protocol (DWP) service (csdwpd process). The calendar database is connected only to the back-end servers.

Figure 17–2 Two-tiered Calendar Server Architecture

This diagram shows a scalable Calendar Server deployment.

Calendar Server processes run on both the front-end and back-end servers as follows:

Users are directed by load balancers to a front-end server, where they log in. Each front-end server requires these services:
- Administration Service (csadmind process)
- HTTP Service (cshttpd process)
Each back-end server is connected to a calendar database, so each back-end server requires these services:
- Administration Service (csadmind process)
- Backup service (csstored)
- Event Notification Service (enpd and csnotifyd processes)
- Database Wire Protocol (DWP) Service (csdwpd process) to provide networking capability to the front-end servers for the calendar database

In this configuration, users do not log in to the back-end servers, so the HTTP service (cshttpd process) is not required.

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

A scalable Calendar Server configuration requires a directory server to authenticate users and to store user preferences.

You can use Access Manager (release 6.1 (release 6 2003Q4) or later) to implement Single Sign-on (SSO), to use Sun Java Enterprise System LDAP Schema 2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

Two-tiered, Multiple Server Calendar Server Architecture

In a two-tiered Calendar Server architecture with multiple front-end and back-end servers (shown in Figure 17–3), users log in to a specific server, and each server is connected to a calendar database. This configuration enables calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.

Figure 17–3 Two-tiered, Multiple Server Calendar Server Architecture

This diagram shows a Calendar Server configuration for multiple
front-end and back-end servers.

In this architecture, each server functions as both a front end and back end, and requires all Calendar Server services: Administration Service (csadmind process), HTTP Service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), and Database Wire Protocol (DWP) Service (csdwpd process).

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Note –

In this architecture, you could also separate the front end services from the back end services onto separate machines, and use the LDAP Calendar Lookup Database (CLD) to determine which back end a front end needs to get data from. For more information, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

A multiple front-end/back-end server deployment requires a directory server to authenticate users and to store user preferences.

Chapter 18 Planning Calendar Server Security

This chapter describes how to plan for and protect the various components of your Calendar Server deployment.

This chapter contains the following sections:

Calendar Server Security Overview

Security plays a key role in the day-to-day operations of today’s businesses. Breaches in security can not only compromise trade secrets, but can also result in downtime, data corruption, and increased operation costs. Calendar Server provides a number of security levels to protect users against eavesdropping, unsanctioned usage, or external attack. The basic level of security is through authentication. Calendar Server uses LDAP authentication by default, but also supports the use of an authentication plugin for cases where an alternate means of authentication is desired. Furthermore, integration with Access Manager enables Calendar Server to take advantage of its single sign-on capability.

Security involves not only ensuring the integrity of users. It also means ensuring the confidentiality of data. To this end, Calendar Server supports the use of SSL encryption for login, or both login and data. In other words, only the login may be encrypted, or the entire session including the login may be encrypted, from the Web client to the server.

Integration with Secure Remote Access also provides SSL encryption, but through a proxy gateway. In addition, integration with the portal gateway provides a URL rewriting capability to further insulate Calendar Server from external entities. Calendar Server can be deployed with the portal gateway such that there is no direct connection to the Calendar Server without going through the gateway. In this case, every URL is rewritten, thus obfuscating the true URL of the Calendar Server. Even though a user is authenticated, that does not mean that the user should have access to other calendar users’ data.

Within a calendar domain exist other layers of security to prevent authenticated users from unauthorized access to other authenticated users’ calendar data. One security measure is through the Calendar Server access control entries. Access control enables calendar users to specify who can see their calendars, who can schedule events into their calendars, who can modify their calendars, and who can delete events from their calendars. Access control also enables users to select who can act on their behalf to respond to invitations, schedule or modify events, and delete events. Finally, access control can be used to span domains of users, thus preventing (or enabling) users in one domain from scheduling events with users of another domain.

In addition to access control, Calendar Server provides an additional level of security at the database protocol level for deployments that separate the calendar front end from the database back end. This level of security is referred to as Database Wire Protocol (DWP) authentication, and utilizes a user name/password pair to authenticate a DWP connection. The user name/password pairs on both the front end and database back end must be identical for a DWP connection to be authenticated.

Monitoring Your Security Strategy

Monitoring your server is an important part of your security strategy. To identify attacks on your system, monitor message queue size, CPU utilization, disk availability, and network utilization. Unusual growth in the message queue size or reduced server response time can identify some of these attacks. Also, investigate unusual system load patterns and unusual connections. Review logs on a daily basis for any unusual activity.

Planning Calendar User Authentication

User authentication enables your users to log in through their calendar clients to retrieve their calendar information. Methods for user authentication include:

Plain Text and Encrypted Password Login

User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Calendar Server administration. To understand directory server password policies, see the Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide.

Both plain text and encrypted password login can be used.

Certificate-based Authentication with Secure Sockets Layer (SSL)

Calendar Server uses the SSL protocol for encrypted communications and for certificate-based authentication of clients and servers. This section describes certificate-based SSL authentication.

SSL is based on the concepts of public-key cryptography. Although TLS (Transport Layer Security) is functionally a superset of SSL, the names are used interchangeably.

At a high-level, a server which supports SSL needs to have a certificate, a public key, a private key, certificate, key, and security databases. This helps assure message authentication, privacy, and integrity.

To authenticate with SSL, the calendar client establishes an SSL session with the server and submits the user’s certificate to the server. The server then evaluates if the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.

If you use SSL for authentication, you need to obtain a server certificate for your Calendar Server. The certificate identifies your server to clients and to other servers. Your server can have more than one server certificate with which it identifies itself. Your server can also have any number of certificates of trusted Certification Authorities (CAs) that it uses for client authentication.

For more information on SSL, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Chapter 19 Planning Calendar Server Services

This chapter describes the planning information for Calendar Server services.

This chapter contains the following sections:

Planning for Calendar Server Front-end and Back-end Services

Calendar Server consists of six major services:

HTTP Service (cshttpd) listens for HTTP requests. It receives user requests and returns data to the caller.
Administration Service (csadmind) is required for each instance of Calendar Server. It provides a single point of authentication and administration for the Calendar Servers and provides most of the administration tools.
Notification Service (csnotify) sends notifications of events and to-dos using either email or the Event Notification Service.
Event Notification Service (enpd) acts as the broker for event alarms.
Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
Backup Service (csstored) implements automatic backups, both archival backups and hot backups. The first backup is a snapshot with log files, the second is a snapshot with log files applied. This service is automatically started when you run the start-cal command. However, it is not enabled at installation time, so you must configure it to function. If left unconfigured, Backup Service sends out a message to the administrator every 24 hours, with the notification that the service is not configured.

In a scalable Calendar Server deployment, you would deploy front-end systems in conjunction with a back-end server. The front-end systems would contain one instance of the cshttpd daemon per processor and a single Administration Service. A back-end server would contain an instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service.

Authentication and XML /XSLT transformation are two Calendar Service activities that generate heavy load. Additional CPUs can be added to meet quality of service requirements. In a scalable environment, these heavy load activities take place on the front-end system(s), permitting more CPUs to be added to individual front-end systems, or more front-end systems to be added, to meet quality of service requirements.

Note –

The preceding paragraph is not applicable if the Communications Express Calendar client is used for calendar access. Communications Express uses the WCAP protocol to access Calendar Server data and therefore the Calendar Server infrastructure is not doing the XML/XSLT translations. See Part V, Deploying Communications Express for information on deploying Communications Express.

Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds of the front-end CPUs.

You will want to consider early on in a deployment separating the Calendar Service into front-end and back-end services. Assign a separate host name for the front-end services and back-end services so that when it comes time to separate the functionality onto different hosts, the changes are essentially internal and do not require users to change their methods of operation.

The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Account for peak calendar usage to provide enough front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Sun Cluster. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming.

Note –

The only configuration for Calendar front ends that might warrant a true HA solution is where you have deployed the Calendar front end on the same host that contains a Messaging Server MTA. Even in this configuration, however, the overhead of such a solution should be carefully weighed against the slight benefit.

A good choice of hardware for the Calendar Server front ends is a single or dual processor server. You would deploy one instance of the Calendar Server cshttpd daemon per processor. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.

When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.

The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.

If your requirements include high availability, it makes sense to deploy the Calendar Server back end with Sun Cluster, as the back end does contain persistent data.

Note –

In a configuration with both front-end and back-end Calender Server hosts, all hosts must be running:

The same operating system environment and version; that is, you cannot have a mixture of systems running Solaris SPARC, Solaris x86, Linux Red Hat, and so forth.
The same releases of Calendar Server, including patch or hotfix releases.

Planning for the Calendar Server LDAP Data Cache

The LDAP data cache option ensures that LDAP data is available immediately after it has been committed. In some configurations of the LDAP directory server an update might need to be referred to a (remote) master server from which the update is then replicated down to the local LDAP directory. These kinds of configurations can induce a delay in the availability of committed data on the local LDAP server.

For example, if your site has deployed a master/slave LDAP configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, the LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data.

This section covers the following topics:

Considerations for Using the LDAP Data Cache

Use these guidelines to determine if your site should configure the LDAP data cache:

If Calendar Server at your site accesses your master (or root) LDAP directory server directly with no delays in the availability of committed LDAP data, you don’t need to configure the LDAP data cache. Make sure that the local.ldap.cache.enable parameter is set to “no” (which is the default).
If your site has deployed a Master/Slave LDAP Configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, configure the LDAP data cache to ensure that your end users have the most recent data.

Master/Slave LDAP Configuration

A Master/Slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:

If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you do not need to configure the LDAP data cache.
If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written transparently via an LDAP referral to the master directory server, which in turn replicates the data back to each slave directory server.

In this second type of configuration, problems with inaccurate LDAP data can occur because of the delay in the availability of committed LDAP data to the slave directory servers.

For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.

If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.

The following table lists the LDAP attributes that are affected by a delay in a master/slave LDAP server configuration where Calendar Server accesses the master LDAP directory server through a slave LDAP directory server.

Table 19–1 Calendar Server LDAP Attributes Affected by Delays


Operation	LDAP Attributes Affected
Auto provisioning	`icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost`
Calendar groups	`icsSet`
Calendar creation	`icsCalendarOwned, icsSubscribed`
Calendar subscription	`icsSubscribed`
User options	`icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy`
Calendar searches	`icsCalendarOwned`

To ensure that your end uses have the most recent LDAP data, configure the LDAP data cache as described in the following section, Resolving the Master-Slave Delay Problem.

Resolving the Master-Slave Delay Problem

The LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.

If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the /var/opt/SUNWics5/csdb/ldap_cache directory, but you can configure a different location if you prefer.

When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database. This data retrieval applies to the following operations for a single user:

User’s attributes at login
User’s options (such as color scheme or time zone)
User’s calendar groups
User’s subscribed list of calendars

Thus, the LDAP data cache database provides for:

Data consistency across processes on a single system—The database is available to all Calendar Server processes on a multiprocessor system.
Data persistence across user sessions—The database is permanent and does not require refreshing. You can configure the time to live (TTL) for an LDAP data cache entry and the interval between each database cleanup.

Limitations to the LDAP Data Cache

The LDAP data cache does not provide for:

Reading the cache for searches where a list of entries is expected, for example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.
Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.
The capability to handle a user who doesn’t always log into the same server. Such a user will generate different LDAP data in the cache on each server.

Configuring the LDAP Data Cache

Configure the LDAP data cache by setting the appropriate parameters in the ics.conf file. See the Sun Java System Calendar Server 6 2005Q4 Administration Guide for more information.

Caution –

If Calendar Server or the server where Calendar Server is running is not properly shut down, manually delete all files in the ldap_cache directory to avoid any database corruption that might cause problems during a subsequent restart.

Chapter 20 Understanding Calendar Server Pre-Installation Considerations

This chapter describes considerations you need to think about before installing Calendar Server.

This chapter contains the following sections:

Calendar Server Installation Considerations

The installation and configuration of Calendar Server has significantly changed from earlier Calendar Server releases (pre-2003Q4 versions). There is no longer a standalone installer for Calendar Server.

If you do not already have Calendar Server installed, you must use the Sun Java Enterprise System installer to get the 2005Q4 version. With this installer, you can also install other Sun Java System component products and packages. For information about the Java Enterprise System installer, refer to the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

If you want to upgrade from Calendar Server 6 2003Q4 to Calendar Server 6 2005Q4, the upgrade process is described in “Upgrading from Java Enterprise System 2003Q4” in the Sun Java Enterprise System 2005Q4 Upgrade Guide.

For information about migrating from older versions of Calendar Server, up through version 5.x, see Chapter 4, Database Migration Utilities, in Sun Java System Calendar Server 6 2005Q4 Administration Guide.

For migrating from versions later than 5.x, contact your Sun support representative.

Which Calendar Server Components to Configure?

When you install Calendar Server software, the Java Enterprise System installer installs all the Calendar Server packages. You then configure the appropriate Calendar Server component on a Calendar host through the Calendar Server configurator program.

The following table shows which components you need to configure for each type of Calendar host.

Table 20–1 Which Calendar Server Components to Configure?


Type of Calendar Host Being Configured	Needs These Components Selected in the Configurator Program
Front end	HTTP service(s) and Administration service
Back end	Notification Service, Event Notification Service, Distributed Database Service and Administration Service

The Distributed Database Service (csdwpd) is required only on back-end servers, that is, a server that has a calendar database, but does not provide user access services (cshttpd). It is not required on front-end servers that do not have a calendar database. The csdwpd service enables you to link front-end and back-end servers within the same Calendar Server configuration to form a distributed calendar store.

Planning for Calendar Server Administrators

Administrators for Calendar Server include:

Calendar Server Administrator (calmaster)

The Calendar Server administrator is a specific user name with its associated password that can manage Calendar Server. For example, a Calendar Server administrator can start and stop Calendar Server services, add and delete users, create and delete calendars, and so on. This user has administrator privileges for Calendar Server but not necessarily for the directory server.

The default user ID for the Calendar Server administrator is calmaster, but you can specify a different user during Calendar Server configuration, if you prefer. After installation you can also specify a different user in the service.admin.calmaster.userid parameter in the ics.conf file.

The user ID you specify for the Calendar Server administrator must be a valid user account in your directory server. If the Calendar Server administrator user account does not exist in the directory server during configuration, the configuration program can create it for you.

See the Sun Java System Calendar Server 6 2005Q4 Administration Guide for the complete list of Calendar Server administrator configuration parameters in the ics.conf file.

Calendar Server User and Group

On Solaris systems, these special accounts are the user ID and group ID under which Calendar Server runs. Use the default values, icsuser and icsgroup, which are automatically created by the configuration program, if they do not exist. If you prefer, however, you can specify values other than icsuser and icsgroup when you run the Calendar Server configuration program. These values are stored in the local.serveruid and local.servergid parameters, respectively, in the ics.conf file.

Superuser (root)

On machines running Solaris software, you must log in as or become superuser (root) to install Calendar Server. You can also run as superuser to manage Calendar Server using the command-line utilities. For some tasks, however, you should run as icsuser and icsgroup (or the values you have selected) rather than superuser to avoid access problems for Calendar Server files.

Planning for Calendar Server Hosted 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:

Installing and configuring Directory Server
Installing and configuring Web Server or Application Server
Installing and configuring Access Manager

The Delegated Administrator is installed with Access Manager.
Installing Calendar Server
Running the comm_dssetup.pl script

For instructions on running this script, see Chapter 2, Directory Preparation Script (comm_dssetup.pl), in Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Configuring Communications Services Delegated Administrator

For instructions on configuring and using the Communications Services Delegated Administrator utility, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
Creating default domain and site administrator (calmaster)

The default domain is created when commadmin is configured, but the domain entry must be modified to add Calendar (or Mail) services. Also, the site calendar administrator (calmaster) must be set up. For instructions on how to perform these two tasks, see Part II, Postinstallation Configuration, in Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Configuring Calendar Server

For instructions on running the csconfiguratior.sh program, see Chapter 3, Calendar Server Configuration Program (csconfigurator.sh), in Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Setting hosted domain configuration parameters for Calendar Server

For a list of the configuration parameters and their values, see Hosted Domain Configuration in Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Creating the hosted domains for your site by using the commadmin utility
Populating your hosted domains with users and resources by using the commadmin utility
Starting Calendar Server services

For instructions, see Starting and Stopping Calendar Server in Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Note –
Always perform your provisioning for Schema 2 with the Communications Services Delegated Administrator interface.

Schema 1 provisioning tools do not support hosted domains.

Post-Installation Calendar Server Configuration

After you install the Calendar Server software, you must configure it. This step was previously performed as part of the installation process, but has now been separated out of the installer.

After you install Calendar Server, you must configure Calendar Server as follows:

Run the Directory Server Setup script (comm_dssetup.pl) to configure Sun Java System Directory Server.
Run the Calendar Server configuration program (csconfigurator.sh) to configure your site’s specific requirements and to create a new ics.conf configuration file. For a description of the parameters in the ics.conf file, see Configuration Parameters (ics.conf) File in Sun Java System Calendar Server 6 2005Q4 Administration Guide.

The comm_dssetup.pl script is located in the /opt/SUNWcomds/sbin directory, and the csconfigurator.sh utility is located in the /opt/SUNWics5/cal/sbin directory.

There are some configuration settings and changes that the Java Enterprise System installer and Calendar Server configuration utility (csconfigurator.sh) do not make. You must manually make changes to the following items:
- DWP and CLD Configurations. Edit the ics.conf file so that the CLD cache option is enabled. This cache stores the DWP host server information for calendar users and thus reduces calls to the LDAP directory server.
- Default Time Zone. If your default time zone is not Americas/New York, change it by editing the ics.conf file. You also need to change it in the /opt/SUNWics5/cal/bin/html/default_user_prefs.xml file so that it is in sync with the ics.conf file.
- Client-side Rendering. Calendar Server performs client-side rendering by downloading the XSLT processing to the end user’s browser, which in turn reduces the processing that must be done by Calendar Server. Calendar Server downloads the XSLT processing only if the browser is capable of rendering the XSLT processing. In the current release, this applies only to Internet Explorer 6.0. Edit the ics.conf file to make this performance improvement to client-side rendering.
- Setting for tmpfs. Edit the tmpfs setting for performance enhancement.
For more information on these changes, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.