Sun Java Communications Suite 5 Deployment Planning Guide

Part III Deploying Calendar Server

This part contains the following chapters:

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

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:

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, Sun Java System Portal Server, and Sun Java System Instant Messaging to provide additional functionality.

Calendar Server provides the following benefits:

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

Designing Your Calendar Server Deployment

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

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

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:

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:

Calendar Server End Users

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

Questions about end users at your site include:

Expected Calendar Server End User Performance

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

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

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 do you have for growth? For both front-end and back-end servers?

Chapter 16 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 16–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 16–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:

For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 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.3 WCAP Developer’s Guide.

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

The tool Calendar Server uses for administration of users, groups, resources, domains, and roles for Schema 2 deployments is Delegated Administrator, which must be installed and configured separately. The Delegated Administrator has both a graphical user interface console, and a command line utility (commadmin). For information about the Delegated Administrator utility, see the Sun Java System Delegated Administrator 6.4 Administration Guide.

For Schema 1 deployments, Calendar Server has its own bundled set of utilities for administration.

You can implement SSO for Communications Suite products using Access Manager, or using trusted circle technology among the Communications Suite products. Users log in to Access Manager and then can access other the servers, as long as all servers are configured properly for SSO. For the trusted circle technology, a user logging into Messaging Server would also have access to Calendar Server and Instant Messaging without having to login again. For more information on SSO trusted circle implementation, see the Sun Java System Calendar Server 6.3 Administration Guide.

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. Though not shown in this figure, the front-end hosts need access to the LDAP directory.

Figure 16–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:

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.3 Administration Guide.

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

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 16–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 16–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), Database Wire Protocol (DWP) Service (csdwpd process), and Backup Service (csstored).

For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 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.3 Administration Guide.

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

Chapter 17 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 Directory Server documentation:

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.3 Administration Guide.

Chapter 18 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:

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. The calendar databases can be distributed over one or more back-end machines. These back-end machines can be associated with one front-end machine.

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 the number of CPUs as the front-ends.

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. Communications Express deployments with Calendar Server have different characteristics. See the Communications Express documentation for more information.

Note –

The only configuration for Calendar front ends that might warrant a true HA solution is one where the Calendar front end is deployed 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. In this case, you 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, deploy the Calendar Server back end with Sun Cluster, as the back end contains persistent data.

Note –

In a configuration with both front-end and back-end Calender Server hosts, all hosts must be running 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 LDAP, 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.

The LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data, but can introduce a delay in the availability of committed LDAP data. For example, if your site has deployed a master/slave LDAP configuration, with Calendar Server accessing the master LDAP directory through a slave LDAP directory server, it introduces a delay.

This section covers the following topics:

Considerations for

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

Using the LDAP Data Cache in a 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:

LDAP Attributes Affected by Delays

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 18–1 Calendar Server LDAP Attributes Affected by Delays


LDAP Attributes Affected  

Auto provisioning 

icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost

Calendar groups 


Calendar creation 

icsCalendarOwned, icsSubscribed

Calendar subscription 


User options 

icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy

Calendar searches 


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:

Thus, the LDAP data cache database provides for:

Limitations to the LDAP Data Cache Solution

The LDAP data cache does not provide for:

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.3 Administration Guide for more information.

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

Planning Calendar Server Domains

For new Calendar Server installations, you must first create a default domain before running the Calendar Server configuration script. To create a default domain, use Delegated Administrator. This means that Delegated Administrator must be installed and configured before Calendar Server is configured.