Part II Postinstallation Configuration

The chapters in this part describe the configuration and migration steps you must perform, after installation, before you can use Calendar Server.

• Chapter 2, Directory Preparation Script (comm_dssetup.pl)

• Chapter 3, Calendar Server Configuration Program (csconfigurator.sh)

• Chapter 4, Database Migration Utilities

Chapter 2 Directory Preparation Script (comm_dssetup.pl)

After you install Calendar Server, and before starting Calendar Server services, you must configure it. It is important that you run the two configuration programs in the following order:

1. Directory Preparation Script (comm_dssetup.pl)Directory Preparation Script configures Directory Server for Calendar Server 6 and

   The Messaging Server 6. It prepares the Directory Server by setting up new LDAP schema, index, and configuration data.

2. Calendar Server Configuration Program (csconfigurator.sh)

   The Calendar Server Configuration Program configures Calendar Server. It is described in Chapter 3, Calendar Server Configuration Program (csconfigurator.sh).

This chapter covers the Directory Preparation Script and contains the following topics:

• Installing the Directory Preparation Script

• Before You Run the Directory Preparation Script

• Running the Directory Preparation Script

• Manually Updating Schema Files

• Resolving Conflicting OID's in the LDAP Schema Directory

If you had an earlier version of Calendar Server or Messaging Server installed, you might need to migrate your LDAP directory entries from Schema 1 to Schema 2.

Do not run the configuration utility described in this chapter until you have read theSun Java System Communications Services 6 2005Q4 Schema Migration Guide. It instructs you on the timing and options for running the configuration utilities.

Installing the Directory Preparation Script

In earlier versions of Java Enterprise System, this utility was bundled with Messaging Server and Calendar Server and did not have to be separately installed. However, starting with Java Enterprise System 2005Q1, the script became a separately installable shared component.

To install the Directory Preparation Script, choose one of the following methods:

• Java Enterprise System installer–At the component selection panel, select the Directory Preparation Script. (Selecting Directory Server automatically selects the Directory Preparation Script, too.)

• If you are upgrading from an earlier version of Java Enterprise System and are not using the Java Enterprise System installation program, download the following patches:

As installed, the Directory Preparation Script is found in the following directory:

Before You Run the Directory Preparation Script

This section covers information you need to understand before running the Directory Preparation Script, and contains the following topics:

• What the Directory Preparation Script Does

• Directory Server Considerations

• Information You Need to Gather

• About the Schema Choices

• Access Manager Considerations

• Attribute Indexes

What the Directory Preparation Script Does

The Directory Preparation Script proceeds through three steps, as follows:

High Level Steps of the Directory Preparation Script

1. Collects your choices for utility options.

   For a list of the specific information this step requests, see Information You Need to Gather.

2. Generates a shell script and LDIF file from your options choices that will be used to modify the LDAP directory. If you are not using a Sun product for your directory server, or have customized your Directory Server, stop the process here without running the shell script. For further information, see Directory Server Considerations that follows.

3. Runs the shell script created from your options choices. Your LDAP is modified accordingly.

   At the end of each step, the utility asks you if you want to continue. No changes are made to the LDAP directory until the third step.

Directory Server Considerations

The following is a list of the considerations for your LDAP directory:

• A directory server must be installed, configured and running before you run the Directory Preparation Script.

• You must run the Directory Preparation Script on the same machine as your directory server.

• You must run the Directory Preparation Script on every machine on which a directory server resides.

• If you add an additional machine (such as a replica) at a future date, run the Directory Preparation Script against it, too.

• For a list of the LDAP directory servers supported by Calendar Server 62005Q4, refer to Chapter 1, Sun Java System Calendar Server 6 2005Q4 Release Notes, in Sun Java System Communications Services 2005Q4 Release Notes.

• If you have customized your LDAP directory, the following considerations may apply:

  • If you have indexed some attributes, you may have to reindex those attributes after the Directory Preparation Script runs.

  • If you have added other .ldif files (schema definitions), they should not be affected, so no action should be necessary. However, back up your custom schema definition files before running the Directory Preparation Script.

  • For all customizations, including the first two just listed, stop the Directory Preparation Script after it generates the script and before it actually updates the LDAP directory. Then inspect the script to evaluate how its proposed actions will affect your LDAP directory. Take whatever actions you think necessary to protect your customizations before running the script against your LDAP.

• If you are not using a Sun product for your directory server, the simplest solution for deploying the Calendar Server is to upgrade your directory server to the Sun Java System Directory Server.

  For information about installing and configuring a Directory Server, see http://docs.sun.com/coll/1316.1.

  Alternately, you can use the script generated by the Directory Preparation Script (without actually running the script) to understand the updates you need to make to your non-Sun LDAP directory.

Information You Need to Gather

During the first step of the Directory Preparation Script, it requests information about your Directory Server. Prepare for this by gathering the information shown in The following table. (To help you keep track of this information, use Appendix A, Directory Configuration Worksheet.

About the Schema Choices

Calendar Server supports the following schema choices:

• Sun LDAP Schema 1

  Corresponds to the Directory Preparation Script schema version choice 1.

• Sun LDAP Schema 2 compatibility mode

  Corresponds to schema version choice 1.5.

• Sun LDAP Schema 2 native mode

  Corresponds to schema version choice 2.

If you are still trying to decide which schema to use, for further explanation, see the Sun Java Enterprise System Technical Overview, the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX, and theSun Java System Communications Services 6 2005Q4 Schema Migration Guide.

The following table lists simplified guidelines which summarize why you might choose each of the schema versions for your installation.

Access Manager Considerations

If you are using Schema 2, Access Manager must be installed and configured.

Do not use the Access Manager console to administer users. For information on how to administer users, see Chapter 14, Administering Users and Resources.

Attribute Indexes

Attribute indexes improve the performance of search algorithms. The script offers to index attributes. If you choose to do so, it will add indexes not only for Calendar Server, but also for Messaging Server and Communications Express. Therefore, once you have run the indexing for one product, you do not need to reindex for the other product. In deed, if you try to index the same attributes again, nothing happens. The script calls db2index for each attribute being indexed, but only if the index does not already exist.

The following table lists all the attributes the Directory Preparation Script indexes, grouped by suffix category. It also lists the type of indexes created for each attribute. For more information about Directory Server indexing, see http://docs.sun.com/coll/1316.1.

Should you decide to add further indexes on your own, instructions for adding indexes can be found in the Directory Server documentation.

Running the Directory Preparation Script

This section covers the following topics:

• To Run the Directory Preparation Script

• To Run in Silent Mode

• To Run in Interactive Mode

To Run the Directory Preparation Script

1. On the server where Directory Server is installed, login as or become superuser (root).

2. Start Directory Server, if necessary.

3. Change to the /opt/SUNWcomds/sbin directory.

   Or, if you need it, a .zip file is available at /opt/SUNWcomds/lib

4. Run the Directory Preparation Script in either silent mode or in interactive mode. For further steps, see Running the Directory Preparation Script or Running the Directory Preparation Script.

   To run this script, use the version of Perl included as a shared component automatically installed with the Java Enterprise System installer. After installation, it can be found at the following directory:

   ds_svr_base/bin/slapd/admin/bin/perl

To Run in Silent Mode

To run the Directory Preparation Script in silent mode, issue the Perl command followed by a string of options using the syntax shown in comm_dssetup.pl Syntax. All of the option arguments are required. Table 2–1describes the options.

The utility creates the following LDIF file and shell script to update the LDAP directory indexes and schema:

/var/tmp/dssetup_timestamp.ldif 
/var/tmp/dssetup_timestamp.sh

Depending on the option values you pass in, the utility will either proceed to update the Directory Server by executing the new script, or not. If you have chosen not to proceed with the update, you can check the script and make any desired modifications before running the actual update at a later time.

comm_dssetup.pl Syntax

The following are all the options for running in the silent state:

perl comm_dssetup.pl
    -i yes|no
    -R yes|no
    -c DirectoryServerRoot
    -d DirectoryInstance
    -r DCTreeSuffix
    -u UserGroupSuffix
    -s yes|no
    -D DirectoryManagerDN
    -w DirectoryManagerPassword
    -b yes|no -t 1|1.5|2
    -m yes|no
   [-S PathtoSchemaFiles]
               

To Run in Interactive Mode

To run the Directory Preparation Script in interactive mode, run the script without any arguments and then enter your choices for the questions asked.

The following numbered list gives panel by panel instructions on how to use the interactive mode script.

1. Welcome and Introduction Panel

   # cd /opt/SUNWcomds/sbin # ./comm_dssetup.pl Welcome to the Directory Server preparation tool for Sun Java System Communications Services. (Version 6.3 Revision 0.1) This tool prepares your directory server for use by the communications services which include Messaging, Calendar and their components. The logfile is /var/tmp/dssetup_YYYYMMDDHHSS Do you want to continue [y]:

   Press Enter to continue, or type no and then press Enter to exit.

2. Installation Root of Directory Server Panel

   Please enter the full path to the directory where the Sun Java System Directory Server was installed. Directory server root [/var/opt/mps/serverroot]

   Specify the location of the installation root of the Directory Server, or press Enter to accept the default.

3. Directory Server Instance Panel

   If multiple instances of the Directory Server reside on this machine, the program lists them and asks you to choose one.

   Please select a directory server instance from the following list: [1] slapd-varrius Which instance do you want [1]:

   Enter the number corresponding to your choice, and then press Enter. Or, to accept the default, press Enter without entering a number.

4. Directory Manager Distinguished Name (DN) Panel

   This panel has two parts, entering the Directory Manager DN and the Directory Manager’s password.

   1. First the script asks you for the distinguished name (DN) of the Directory Manager:

      Please enter the directory manager DN [cn=Directory Manager]:

      The Directory Manager DN, which defaults to cn=Directory Manager, is the administrator responsible for the user and group data in the Organization Tree. Be sure that the Directory Manager DN you specify in this script is the same DN that you set up for your Directory Server installation as well for as your Calendar Server configuration.

      Enter the Directory Manager DN, or press Enter to accept the default.

   2. Then the script asks for the Directory Manager’s password.

      Password:

      Enter the password for the Directory Manager and press Enter.

      The program checks to see if the Directory Server is running and listening on port 389 (the default port).

      If successful, it displays the detected version as shown in the example that follows:

      Detected DS version 5.2

      If unsuccessful, it tells you that it could not detect a Directory Server running, or listening on port 389. It directs you to fix this problem before allowing you to continue. The script exits. The example below shows this output:

      Directory Server not running or not listening to port 389. Detected DS version 0.0 Please correct the problem and re-run this script.

5. User and Group Directory Server Panel

   Will this directory server be used for users/groups [Yes]:

   Enter No if this directory instance is used to store only configuration data, or press Enter to accept the default.

   If you enter No, then you must also run this script against the directory instance that stores user and group data. (Do this before you run the configuration program csconfigurator.sh.)

   If your answer is Yes, you must specify a user and group base suffix for your Organization Tree.

6. User and Group Base Suffix Panel

   Please enter the Users/Groups base suffix [o=usergroup]:

   The user and group base suffix is the top entry in the LDAP Organization Tree. Be sure that the suffix you select here is the same suffix you specify for Directory Server, Calendar Server, and Access Manager.

7. Schema Type Panel

   There are 3 possible schema types: 1-schema 1 for systems with Calendar or Messaging 5.x data 1.5-schema 2 compatibility for systems with Calendar or Messaging 5.x data that has been converted with the Schema Migration Utility commdirmig 2-schema 2 native for systems using Access Manager Please enter the Schema Type (1, 1.5, 2) [1]:

   Enter the schema type, or press Enter to accept the default.

   ---

   Note –

   To use Schema 2 (options 1.5 or 2), Access Manager must be installed and configured. Otherwise, the Directory Preparation Script will terminate. You must install Access Manager before rerunning the Directory Preparation Script.

   ---

8. Domain Component (DC) Tree Base Suffix Panel

   If you chose Schema 1 or Schema 2 Compatibility Mode, you will be asked to provide your DC tree base suffix. If you chose Schema 2 Native Mode, you will not be asked this question.

   Please enter the DC Tree base suffix [o=internet]:

   In the Schema Type Panel described earlier, if you chose Schema 1 or Schema 2 Compatibility Mode, you will be asked to provide your DC tree base suffix. If you chose Schema 2 Native Mode, you will not be asked this question.

   The DC tree mirrors the local DNS structure and is used by the system as an index to the Organization tree that contains the user and group data entries. The DC tree base suffix is the name of the top entry on the DC tree.

   Enter a suffix, or press Enter to accept the default.

9. Series of Questions Panel

   This next panel asks a series of questions about updates to your LDAP.

   1. Updating Schema Files

      At this point the program checks to see if your schema has the correct schema elements. If your schema is missing some elements, it prints the following message:

      Detected bad schema elements in 99user.ldif. It is recommended that you update the schema. Do you want to update the schema files [yes]:

      Answer Yes to add required new elements to your schema. You need to update the directory with the new schema files each time you install a new version of Calendar Server or Messaging Server.

      Answer No if you want to delay updating the schema files.

   2. Configuring New Indexes

      If you chose to update the schema in the previous step, you will be asked if you want to configure new indexes. For more information about indexing attributes, see Attribute Indexes.

      Do you want to configure new indexes [yes]:

      To approve indexing, press Enter.

      If you have already performed this indexing step for the same attributes, answer no.

   3. Reindex Now

      You can choose to do the indexing now, or you can do it at a later time. If you choose to defer the indexing, rerun the script with indexing turned on when it is convenient. Indexing can take a long time, but the Directory Server is still functional, that is, is not put into read only mode during indexing.

      Reindex now [yes]?

      If you want to do the indexing at a later time, answer no, otherwise, press Enter and accept the default.

10. Summary of Settings Panel

    Before the Directory Preparation Script updates the Directory Server configuration, it displays a summary of your settings and then asks if you want to continue.

    Here is a summary of the settings that you chose: Server Root : /var/opt/mps/serverroot/ Server Instance : slapd-varrius Users/Groups Directory : yes Update Schema : yes Schema Type : 1 DC Root : o=internet User/Group Root : dc=red,dc=sesta,dc=com Add New Indexes : yes Reindex New Indexes Now : yes Directory Manager DN : cn=Directory Manager Now ready to generate a shell script and ldif file to modify the Directory. No changes to the Directory Server will be made this time. Do you want to continue [Y]:

    If you chose Schema 2 Native Mode in Running the Directory Preparation Script, the DC Root will be the same value that you entered for the User/Group Root.

    To change any of your settings, enter no and rerun the script.

    If you want to continue, press Enter. The Directory Preparation Script generates an LDIF file and a shell script. The names of the files it creates are as follows:

    /var/tmp/dssetup_timestamp.ldif /var/tmp/dssetup_timestamp.sh

    If you chose to continue, you will see messages printed out as the program works. The following is an example of the output you will see:

    Generating files... Checking to see if Suffixes need to be added Checking to see that uid uniqueness plugins are turned off Adding indexes Adding Indexes for User/group Tree (backend:userRoot) Checking indexes for member No new indexes required Checking indexes for mailAlternateAddress No new indexes required Checking indexes for mail No new indexes required Checking indexes for mailEquivalentAddress No new indexes required Checking indexes for cosspecifier No new indexes required Adding Indexes for DC Tree (backend:internetdb2) Checking indexes for inetCanonicalDomainName No new indexes required Checking indexes for inetDomainBaseDN No new indexes required Adding Indexes for PAB Tree (backend:pabdb2) Checking indexes for memberOfPAB No new indexes required Checking indexes for icsCalendar No new indexes required Checking indexes for un No new indexes required Checking indexes for memberOfPABGroup No new indexes required Checking indexes for icsCalendarOwned No new indexes required Checking indexes for memberOfManagedGroup No new indexes required Adding Indexes for New PAB Tree (backend:PiServerDbdb2) Checking indexes for MemberOfPiBook No new indexes required Checking indexes for MemberofPiGroup No new indexes required Checking indexes for displayname No new indexes required Checking to see if DN needs to be created for suffixes Generating ldif for installer metadata Generating ldif for Adding schema for installer metadata Generating ldif for updating DN for cn=CommServers,o=comms-config The following files have been created: /var/tmp/dssetup_20041209114027.sh /var/tmp/dssetup_20041209114027.ldif Running /var/tmp/dssetup_20041209114027.sh will make changes to the Directory. You can run this file now or at a later time Ready to execute the script now.

11. Running the Script

    Do you want to continue [yes]:

    Press Enter to accept the default setting (yes). The dssetup_timestamp.sh script runs against your LDAP directory. If you do not want to run the script now, enter No to exit. If you exit, you can run the /var/tmp/dssetup_timestamp.sh script at a later time.

    The following is an example of the text output generated while the script is running:

    Running /var/tmp/dssetup_20041209114027.sh -D "cn=Directory Manager" -j /var/tmp/dssetup_20041209114027.pw Stopping Directory Server Updating Schema files... Copying 20subscriber.ldif Copying 50ns-delegated-admin.ldif Copying 50ns-mail.ldif Copying 50ns-mlm.ldif Copying 50ns-msg.ldif Copying 50ns-value.ldif Copying 55ims-ical.ldif Copying 56ims-schema.ldif Copying 70sun-schema2.ldif Copying 71sun-am.ldif Copying 60iplanet-calendar.ldif Copying 50ns-iabs.ldif Copying 98ns-dummy-uwc.ldif Copying 70delgated-admin.ldif Copying /var/tmp/99user_20041209114027.ldif to /var/opt/mps/serverroot/slapd-varrius/config/schema/99user.ldif Starting Directory Server Applying ldif file /var/tmp/dssetup_20041209114027.ldif modifying entry cn=schema modifying entry cn=schema modifying entry cn=CommServers,o=comms-config Done Applying ldif file /var/tmp/dssetup_20041209114027.ldif rejects to /var/tmp/dssetup_20041209114027.ldif.rej status = 0 Successful Completion. Consult /var/tmp/dssetup_20041209114027.log for details

Manually Updating Schema Files

If for any reason, you have decided not to run the Directory Preparation Script generated script, the following directions allow you to manually update your schema files for Sun Java System Directory Server.

If you update your LDAP directory schema manually and then later upgrade Calendar Server, you must manually update the LDAP server schema again. Calendar Server cannot automatically update the schema after the it has previously been updated manually.

To Update Your LDAP Directory Manually

1. Install Calendar Server 62005Q4.

2. Stop Calendar Server, if it is running.

3. Stop Directory Server, if it is running.

4. Copy the 60iplanet-calendar.ldif file to the following directory on the machine where your directory server is running:

   dir_svr_base/slapd-hostname/config/schema

   where dir_svr_base is the Directory Server installation directory and hostname identifies the machine.

5. If you want to index attributes, as the configuration program does, do it at this point. For a list of the attributes the configuration program indexes, see Attribute Indexes.

6. Restart the Directory Server. If you receive object identifier (OID) errors, see Resolving Conflicting OID's in the LDAP Schema Directory.

7. Configure Calendar Server by running the csconfiguration.sh program.

   For instructions on configuring Calendar Server, see Chapter 3, Calendar Server Configuration Program (csconfigurator.sh).

Resolving Conflicting OID's in the LDAP Schema Directory

If your LDAP schema directory contains conflicting OID's, the Directory Server does not know which OID to use and returns an error message. For example, the following message indicates a conflicting OID for the icsCalendarUser object class:

[24/Apr/2004:23:45:28 -0700] dse - 
The entry cn=schema in file 99user.ldif is invalid, 
error code 20 (Type or value exists) - object class icscalendaruser: 
   The name does not match the OID. 
   Another object class is already using the name or OID.
[24/Apr/2004:23:45:28 -0700] dse - 
Please edit the file to correct the reported problems 
and then restart the server.

This problem can occur when you install Calendar Server 62005Q4 and you also had an older Calendar Server release that dynamically updated your LDAP server schema 99user.ldif file.

To resolve the conflicting OID's, perform the following two steps:

1. Edit the 99user.ldif file and remove the older OID's. For Calendar Server 62005Q4, the following table lists the specific OID's that might cause problems.

   Object Class	Old OID	New OID
   icsCalendarUser	2.16.840.1.113730.3.2.141	1.3.6.1.4.1.42.2.27.9.2.44
   icsCalendarResource	2.16.840.1.113730.3.2.143	1.3.6.1.4.1.42.2.27.9.2.45
   icsCalendarDomain	2.16.840.1.113730.3.2.144	1.3.6.1.4.1.42.2.27.9.2.4

2. After you edit the 99user.ldif file, restart the Directory Server.

Chapter 3 Calendar Server Configuration Program (csconfigurator.sh)

After you install Calendar Server, and before running it, you must configure it. It is important that you run the two configuration programs in the following order:

1. comm_dssetup.pl

   Configure the LDAP directory server as instructed in Chapter 2, Directory Preparation Script (comm_dssetup.pl).

2. csconfigurator.sh

   Configure Calendar Server as described in this chapter.

This chapter contains the following topics:

• Gathering Your Configuration Information

• Running csconfigurator.sh

If you had an earlier version of Calendar Server or Messaging Server installed, you might need to migrate your LDAP directory entries from Schema 1 to Schema 2.

Do not run the configuration utility described in this chapter until you have read the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide. It will instruct you on the timing and options for running the configuration utilities.

Gathering Your Configuration Information

The Calendar Server configuration program csconfigurator.sh, creates a new ics.conf configuration file in the following directory:

For Solaris: /etc/opt/SUNWics5/config

For Linux: /etc/opt/sun/calendar/config

The configuration program will ask you many questions for which you must enter specific information about your installation.

Before running the configuration program, you should gather the following configuration information:

• LDAP Server Options

• Directory Manager Options

• Calendar Server Administrator

• Email and Email Alarms Options

• Runtime Configuration Options

• Calendar Server Startup

• Database, Logs, and Temporary Files Directories

To help you keep track of the configuration information, use the worksheets in Appendix B, Calendar Server Configuration Worksheet. (However, you should determine this information before you run the Java Enterprise System installer to avoid conflicts (such as port numbers) with other component products.)

LDAP Server Options

Calendar Server requires a directory server for user authentication and for the storage and retrieval of user preferences. The following table lists the options used to gather host and port information for the LDAP server.

Directory Manager Options

The following table lists the options used to gather the name and password of the user that is designated the Directory Manager.

Calendar Server Administrator

The Calendar Server Administrator is the user account that overrides any other Calendar Server ACLs. The Calendar Server Administrator user account must exist in your user authentication directory server. It is also used for proxy authentication. The following table lists the options used to gather the Calendar Server Administrator’s user ID and password.

Email and Email Alarms Options

You can configure Calendar Server to send an email alarm message to a Calendar Server Administrator in case a server problem occurs. The following table lists the options used to gather email information.

Runtime Configuration Options

You can configure the following Calendar Server runtime and system resource options.

Calendar Server Startup

You can configure the following options to automatically start Calendar Server.

Database, Logs, and Temporary Files Directories

Calendar Server creates and stores information in calendar database files, log files, and temporary files in specific directories.

Do not change the location or names of the logs and temporary files directories.

Running csconfigurator.sh

You can run the configuration program from a graphical user interface (GUI), or from the command line.

If you run the program remotely, you must set your DISPLAY environment variable properly and allow X-Windows connections from the server to display on your computer. For example, to use the xhost utility, execute the following command on your computer:

xhost +

This section contains the following topics:

• To Run the Configuration Program from the Command Line

• To Run the Configuration Program from the GUI

To Run the Configuration Program from the Command Line

1. Login as or become superuser (root).

2. Change to the /opt/SUNWics5/cal/sbin directory.

3. Run the script using the options chosen from the following table:

   Option	Description
   -nodisplay	Run the configuration script in text-only mode (non-GUI).
   -noconsole	Do not display text output. Use this with -nodisplay to run the configuration script in silent mode.
   -novalidate	Do not validate input field text.
   -saveState [statefile]	Save the answers that you input in response to configuration questions to a state file (text file). Unless you specify a fully qualified path for the state file, it will be saved in the default directory: /opt/SUNWics5/cal/jconfigure.
   -state [statefile]	Use the state file for setting input values.

   For example, to run the configuration script in command-line mode without saving the inputs to a state file.

   ./csconfigurator.sh -nodisplay

   The command-line version asks for the same information and in the same order as the GUI. Default values are indicated in square brackets, []. To accept a default value, press Enter on your keyboard.

   ---

   Note –

   For the text of the information contained in the various questions presented by the script, see the text in the GUI panels shown in the sections that follow.

   ---

To Run the Configuration Program from the GUI

1. Login as or become superuser (root).

2. Change to the /opt/SUNWics5/cal/sbin directory.

3. Issue this command:

   ./csconfigurator.sh

   The configuration program displays the following series of panels:

   • Welcome Panel

   • Administration, User Preferences and Authentication Panel

   • Email and Email Alarms Panel

   • Runtime Configuration Panel

   • Select Directories Panel

   • Archive and Hot Backup Configuration Panel

   • Ready to Configure Panel

   • Configuration Summary Panel

   ---

   Caution –

   The configuration program only configures a single domain. If you plan to use multiple domains (virtual domains, hosted domains), you need to add the domains using the Delegated Administrator command-line utility.

   ---

Welcome Panel

Figure 3–1 Calendar Server Configuration Program Welcome Panel

Click Next to continue or Cancel to exit.

Administration, User Preferences and Authentication Panel

Figure 3–2 Administration, User Preferences and Authentication Configuration Panel

User Preferences Directory Options

LDAP Server Host Name

Host name of the LDAP directory server you are using for user authentication. Default: current host

LDAP Server Port

Port number that the LDAP server listens on. Default: 389

Directory Manager DN

User name that can make changes in the directory server schema. Default: cn=Directory Manager

Directory Manager Password

Password of the Directory Manager. Default: None

Base DN

Entry in the LDAP directory used as the starting point from which searches will occur. Default: o=currentdomain.

This can be modified to fit your deployment needs. To retrieve the root suffix created by comm_dssetup.pl, click Get. The baseDN obtained this way is only a suggestion created from the current settings. Whatever you use for the baseDN, it must be consistent with the LDAP content.

---

Note –

Before you click Get, you must enter the Directory Manager DN and password to authenticate to the directory server.

---

Calendar Server Administrator Options

Administrator User ID

User ID of the Calendar Server Administrator; must be a user in the above LDAP directory server. Default: calmaster

Administrator Password

Password of the Calendar Server Administrator. Default: None

Click Next to continue, Back to return to the previous panel, or Cancel to exit.

Email and Email Alarms Panel

Figure 3–3 Email and Email Alarms Configuration Panel

Email Alarms

Specifies whether Calendar Server should send an email alarm message to a Calendar Server administrator in case a server problem occurs. Default: Enabled

Administrator Email Address

Email address of the Calendar Server Administrator who will receive the email alarm messages. Default: None

SMTP Host Name

Host name of the SMTP server where email alarm messages should be sent. Default: current host.

Click Next to continue, Back to return to the previous panel, or Cancel to exit.

Runtime Configuration Panel

Figure 3–4 Runtime Configuration Panel

Service Port

Port number that Calendar Server listens on to provide Web (HTTP) access to users. Default: 80.

Maximum Sessions

Maximum number of concurrent Calendar Server sessions. Default: 5000

Maximum Threads

Maximum number of concurrent Calendar Server threads. Default: 20

Number of Server Processes

Maximum number of Calendar Server processes to run on the server. Default: Number of CPU's on the server where you are installing Calendar Server.

Runtime User ID

UNIX user name under which Calendar Server will run. This name should not be root. If the account does not exist, the configuration program will create it. Default: icsuser

Runtime Group ID

UNIX group under which Calendar Server will run. If the group does not exist, the configuration program will create it. Default: icsgroup

Calendar Server Startup Options

Select one or both options by clicking in the check box.

• Start after successful installation

  Specifies whether to start Calendar Server automatically after a successful installation. Default: checked

• Start on system startup

  Specifies whether to start Calendar Server automatically after a system startup. Default: checked

Click Next to continue, Back to return to the previous panel, or Cancel to exit.

Select Directories Panel

Accept the default directories on this panel. While you are allowed to choose the store configuration and data files directories, it is not advised.

Figure 3–5 Select Directories Configuration Panel

Config Directory

Directory where the configuration file (ics.conf) is stored.

Database Directory

Directory where Calendar Server should create and store the calendar database files. Default: /var/opt/SUNWics5/csdb

Logs Directory

Directory where Calendar Server writes log files. Default: /var/opt/SUNWics5/logs

Temporary Files Directory

Directory where the Calendar Server writes temporary files. Default: /var/opt/SUNWics5/tmp

Then, Click Next to continue, Back to return to the previous panel, or Cancel to exit.

Archive and Hot Backup Configuration Panel

This panel allows you to select both automatic backup types, or either one of the two, or none. Select or deselect the boxes appropriately. Using both archive backups and hot backups is strongly recommended.

Prevent the catastrophic loss of all your database copies due to an equipment failure. Keep your automatic backup copies on a disk or disk system other than the one where your live databases reside.

For information on automatic backups, see Chapter 10, Configuring Automatic Backups (csstored).

Figure 3–6 Archive and hot backup Configuration Panel

Enable Archive

When this box is checked (default), csstored will take a snapshot of your calendar databases every 24 hours. At the end of the day, it stores the transaction log files for that day with the snapshot in the archive backup directory.

Archive Directory

Choose the backup directory by clicking Browse, or accept the default.

Enable Hot Backup

When this box is checked (default), csstored takes a snapshot of your calendar databases every 24 hours, but applies the transaction logs to the snapshot at a set interval (default is two minutes), thus ensuring a nearly complete duplicate of your live database.

Hot Backup Directory

Choose the backup directory by clicking Browse, or accept the default.

Keep Archives for (in days)

Click the up or down arrows in the Minimum and Maximum fields to select range of days of archival backups to keep in the backup directory.

Keep Hot Backups for (in days)

Click the up or down arrows in the Minimum and Maximum fields to select the range of days of hot backups to keep in the directory.

The number of copies actually stored at any one time depends on the size of the files and the size of the directory. When either the size limits, set in the ics.conf file, or maximum number of copies exceeds the limit, the oldest copies are purged down to the minimum number specified on this configuration panel.

Click Next to continue, Back to return to the previous panel, or Cancel to quit the configuration program.

Ready to Configure Panel

Up to now the panels have been gathering data needed for the configuration and performing some validity checking. You can go back and redo the configuration information at this point, or start the configuration.

Figure 3–7 Ready to Configure Panel

Click Configure Now to configure Calendar Server, Back to return to the previous panel, or Cancel to exit.

Configuration Summary Panel

Figure 3–8 Configuration Summary Panel

Click Details to view the details of the configuration log or Close to exit the configuration program.

Chapter 4 Database Migration Utilities

If you had an earlier version of Calendar Server (5.11 and earlier), after you install Calendar Server, and perform the postinstallation configuration, you may need to migrate the component databases and the LDAP database.

A Choosing the Right Utilities section is provided in this chapter to assist you in choosing the correct utilities to run.

This chapter contains the following sections:

• Postinstallation Database Migration Utilities

• Choosing the Right Utilities

• csmig

• csvdmig

• commdirmig

Postinstallation Database Migration Utilities

After you have installed Sun Java System Calendar Server, if you have calendar databases and LDAP database entries from your old Calendar Server 5.1.1 installation, run the following utilities in the order given:

1. cs5migrate

   Migrates your calendar databases from Calendar Server version 5 to version 6 format. These utilities are available for download from technical support.

   If you plan to use the Connector for Microsoft Outlook and have recurring components, then use cs5migrate_recurring, which creates a master record and exceptions for each recurring series.

   If you do not have recurring components in your existing database, or you do have them, but do not plan to use the Connector for Microsoft Outlook, use cs5migrate.

   Both cs5migrate and cs5migrate_recurring are available only from technical support. They are not packaged with the product.

2. csmig

   Assigns an owner to each calendar in the Calendar Server 6 database and maps each calendar ID (calid) to an owner, if needed, which allows support for hosted (virtual) domains and the LDAP Calendar Lookup Database (CLD) plug-in. This utility is packaged with Calendar Server. Run this utility after cs5migrate and before csvdmig.

3. csvdmig

   Upgrades a Calendar Server 6 site to use hosted (virtual) domains by adding the calendar’s domain (@domainname) to each calid. For example, in the domain sesta.com, jdoe’s calid would now be jdoe@sesta.com. This utility is packaged with Calendar Server. Run this utility after cs5migrate, and csmig.

4. commdirmig

   Migrates LDAP data from Schema 1 to Schema 2 in preparation for use with Access Manager 6.1 or higher. This utility is packaged with Access Manager.

Choosing the Right Utilities

Since there are so many potential utility choices, use the graphic below to choose which of the utilities to run.

Figure 4–1 Choosing Migration Utilities to Run

csmig

The csmig utility assigns an owner to each calendar in the calendar database and maps each calendar ID (calid) to an owner, if needed.

The csmig utility supports hosted (virtual) domains and the LDAP Calendar Lookup Database (CLD) plug-in. Calendars in the migrated database are accessible using the LDAP CLD plug-in. For information about the LDAP CLD plug-in, see Chapter 6, Configuring Calendar Database Distribution Across Multiple Machines.

This section describes the following topics:

• csmig Functions

• csmig Requirements

• csmig Syntax

• csmig Migration Steps

• csmig Tips and Troubleshooting

csmig Functions

The csmig migration utility performs the following functions:

• Migrates Calendars

• Assigns Owners to Calendars

• Updates LDAP Attributes

Migrates Calendars

csmig migrates both user and resource calendars in the current calendar database (*.db files) specified by the caldb.berkeleydb.homedir.path parameter. In the new destination target database, csmig updates entries required by the LDAP CLD plug-in in the calendar properties (calprops), events, todos (tasks), and group scheduling engine (GSE) database files.

csmig writes only to the destination target database; it does not update your existing calendar database.

Assigns Owners to Calendars

csmig assigns an owner to each calendar in the calendar database and maps each calendar ID (calid) to an owner, if needed. All default calids are kept as is, and no changes are made. Other calendars are mapped as follows:

• User calendars that don’t have valid owners will be owned by the user passed to csmig by the -c option. For example, if calendar ID jsmith doesn’t have an owner, it will be converted to orphan:jsmith, where orphan is specified as the -c option.

• Resource calendars that don’t have an owner will be owned by the resource user passed to csmig by the -r option.

• If a resource calendar has any colons (:) in the name, the colons are converted to underscores, so that the migrated name has only one colon.

  For example, a calendar named football with owner bkamdar will be converted to bkamdar:football. A calendar named tchang:soccer with the owner bkamdar will be converted to bkamdar:tchang_soccer. A resource calendar named auditorium:room1 with an owner admin1 will be converted to admin1:auditorium_room1.

Updates LDAP Attributes

csmig updates LDAP attributes for all relevant LDAP entries, including icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and for resource calendars, uid. csmig creates the icsDWPHost attribute for each calendar in the LDAP directory server database. icsDWPHost specifies the host name of the back-end server where a calendar resides.

csmig Requirements

The requirements for using csmig are:

• The calendar database must not be corrupted. Use the csdb check command to check your calendar database, and if necessary, run the csdb rebuild command to rebuild the database. For information about these commands, Appendix D, Calendar Server Command-Line Utilities Reference.

• You must have sufficient disk space for the new destination target database and if applicable, your backup database.

• To run csmig, log in as icsuser (or as the Calendar Server runtime user ID specified during configuration). If you run csmig as superuser (root), you might need to reset the permissions for the migrated files.

  You must also have privileges to manage the attributes of calendar users in the LDAP directory server that stores user preferences.

• Calendar Server must be stopped.

csmig Syntax

The csmig utility has the following syntax:

csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

The following table lists the utility options, gives a description of each, and gives the default value.

csmig Migration Steps

After you have installed and configured Calendar Server 6, you must run csmig to migrate your existing Calendar Server and LDAP data. Migration of the LDAP data is required for the LDAP CLD plug-in to work properly. Use these steps to migrate calendar data using csmig:

High Level Steps for Using csmig

1. Configure your Directory Server using comm_dssetup.pl.

   If you have not already indexed LDAP attributes using comm_dssetup.pl, do so at this time. This will greatly help performance of the LDAP data migration.

2. Using a staging server (not your production server), perform a test dry run.

   A dry run reports what csmig would do during an actual migration but does not migrate any data. After the dry run, and before you actually migrate, correct any errors and determine a plan to handle any unresolved calendars.

   For instructions on how to perform a test dry run, see csmig Migration Steps.

3. Migrate Your Production Data

   During a production run, csmig migrates the calendar database (.db files) and LDAP data (user and group preferences data), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and uid (for resource calendars). After the migration, all calendar resources will have an LDAP entry created.

   For instructions on how to migrate your production data, see csmig Migration Steps.

To Perform a Test Dry Run

1. Install Calendar Server 6 (if necessary) on the staging server.

2. Copy a snapshot of your calendar database to the staging server.

3. Mimic your production LDAP environment on the staging server by performing the following tasks:

   • Install Directory Server.

   • Install a snapshot of the LDAP database on this server.

4. Run comm_dssetup.pl to configure the staging Directory Server.

5. Run csconfigurator.sh to configure the staging Calendar Server.

6. Log in as icsuser (or, if its different, log in as the Calendar Server runtime user ID specified during configuration). If you run csmig as superuser (root), you might need to reset the permissions for the migrated files.

7. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

8. Run the csdb check command to check your database for corruption. If corruption is indicated, run csdb rebuild to rebuild the database.

9. Consider creating a catchall calid for user calendars that don’t have an owner. For example, the following command creates a user with the calid of orphan:

   ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

10. Stop the Calendar Server using the stop-cal command (if necessary).

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

11. Run csmig with the dryrun option. For example, you might enter:

    ./csmig -b sesta.com -o csmig.out -e csmig.errors
     -m csmig.map -c orphan -r calmaster dryrun

    This command assigns user calendars without an owner (orphan calendars) to the owner orphan and resource calendars without an owner to the owner calmaster.

12. Check the output mapping file (csmig.map). The mapping file lists entries that need to be updated in the LDAP schema.

13. Check the output, mapping, and error files. Resolve any LDAP issues or errors that you find. Determine how you will handle any unresolved calendars before the actual migration. Several options are:

    • Delete any unneeded calendars before you migrate.

    • Assign owners to any unresolved calendars.

    • Allow csmig to assign owners to the calendars during migration using the -c and -r options.

14. Run csmig to migrate your staging calendar database.

    For example, the following command migrates the calendar database to the /var/opt/SUNWics5/testcsdb/ directory:

    ./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com 
    -o csmig.out -e csmig.errors -m csmig.map -c orphan 
    -r calmaster migrate

15. After the test migration is finished, perform these steps to check out the newly migrated calendar database.

    1. Copy the migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database.

    2. Run csdb check on the new calendar database. The number of events and todos in the migrated database should match the pre-migration totals.

    3. Search for icsCalendarOwned entries and make sure that the entries match the pre-migration number of calendars.

    4. Log in to Communications Express and verify some of the calendars in the migrated database.

       If the test migration is successful, you are ready to migrate your production database.

To Migrate Your Production Data

1. Log in as icsuser (or as the Calendar Server runtime user ID specified during configuration). If you run csmig as superuser (root), you might need to reset the permissions for the migrated files.

2. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

3. Stop the Calendar Server using the stop-cal command (if necessary).

   cal_svr_base/SUNWics5/cal/sbin/stop-cal

4. Backup the following data:

   • Calendar database (.db files).

   • LDAP data: slapd database directory and LDAP database.

   • ics.conf file. This step is not actually required, but it can be useful if you need to revert to your original configuration.

5. Run csmig with the migrate option.

   For example, the following command migrates the calendar database to the /var/opt/SUNWics5/newcsdb/ directory:

   ./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com 
   -o csmig.out -e csmig.errors -m csmig.log -c orphan 
   -r calmaster migrate

6. Check for any unresolved calendars in the error file (csmig.errors) and resolve them according to your plan from csmig Migration Steps under csmig Migration Steps.

7. Run the csdb check command to check your migrated database. If any corruption is indicated, run csdb rebuild to rebuild the database.

8. Copy the new migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database.

9. Enable the LDAP CLD plug-in by making any necessary changes to the following configuration parameters in the ics.conf file:

   • service.dwp.enable = "yes"

   • service.dwp.port = "9779"

   • csapi.plugin.calendarlookup = "y"

   • csapi.plugin.calendarlookup.name = "*"

   • caldb.cld.type = "directory"

   • caldb.dwp.server.default = "default-server-name"

   • caldb.dwp.server.server-hostname.ip = "server-hostname" (for each back-end server including the local server)

   • caldb.cld.cache.enable = "yes" (if you want to use the CLD cache option)

   • caldb.cld.cache.homedir.path specifies the location of the CLD cache directory. The default is /var/opt/SUNWics5/csdb/cld_cache.

     For information about setting configuration parameters for the LDAP CLD plug-in, see Chapter 6, Configuring Calendar Database Distribution Across Multiple Machines.

10. Restart Calendar Server using the start-cal command.

11. Log in to Communications Express and verify that your configuration is working by checking several of the migrated calendars.

    To disable alarms while you are making your checks, set each of the following parameters in the ics.conf file to “no”:

    • caldb.serveralarms = "no"

    • caldb.serveralarms.dispatch = "no"

    • service.ens.enable = "no"

    • service.notify.enable = "no"

    • ine.cancellation.enable = "no"

    • ine.invitation.enable = "no"

    • service.admin.alarm = "no"

csmig Tips and Troubleshooting

The section describes the following tips and trouble shooting examples:

• The csmig dry run calendar shows the wrong owner for a calendar.

• The LDAP calendar search doesn’t work correctly.

• The csmig dry run indicates duplicate calendar names.

• How do I assign orphan calendars to different owners?

• How do I move calendar users to another back-end server?

The csmig dry run calendar shows the wrong owner for a calendar.

Example Problem

A calendar named tchang:myCalendar has the owner jsmith in the calendar database, and the csmig dry run shows the mapping as jsmith:tchang_myCalendar. However, you would like to name this calendar tchang:myCalendar and assign the owner as tchang.

Example Solution

Before the migration, use the cscal utility to change the owner of the calendar tchang:myCalendar to tchang. Once this is done, the migration will map this calendar to tchang:myCalendar and add icsCalendarowned to the LDAP entry for user ID tchang.

The LDAP calendar search doesn’t work correctly.

Example Problem

After migration, the LDAP calendar search is enabled, but the calendar search dialog does not return any results or returns only partial results.

Example Solution

Enabling the LDAP calendar search allows Calendar Server to search (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)).

Manually run two different searches on the LDAP data with the following filters and compare the output:

• LDAP search with filter (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))

• LDAP search with filter (icscalendarowned=*substr*)

Since the server uses the filter that includes icsCalendarUser object class, the LDAP server might have been deployed with the schema check disabled, and some calendar entries may have been provisioned without the icsCalendarUser object class.

The csmig dry run indicates duplicate calendar names.

Example Problem

The csmig dry run mapping file and output file indicate that there is a duplicate calendar name. For example, in the original database, jsmith owns the following calendars:

• basketball with 5 events

• jsmith:basketball with 10 events

The dry run indicates that during a migration, the two calendars will be merged, and the resulting calendar will be jsmith:basketball with owner jsmith and 15 total events

The output file will include the following warning message:

Error modifying calendar properties, error=2

Example Solution

If you don’t want the two calendars to be merged, change the owner of basketball to a user other than jsmith before the migration. This will preserve the data integrity of the two separate calendars.

How do I assign orphan calendars to different owners?

Example Problem

By default csmig assigns all orphan calendars to a single owner, but I would like to assign different owners for some orphan calendars.

Example Solution

csmig doesn’t accept the mapping file in the command line. However, you can assign owners to the orphan calendars in the original database before the migration. Check the dry run mapping file for all orphan calendars. Then use the cscal utility to assign owners to the orphan calendars before the migration. Run csmig in dryrun mode again to verify the new owners.

How do I move calendar users to another back-end server?

Example Problem

How do I move users from one back-end server to another?

Example Solution

To move a calendar user, you export each of the user’s calendars on the original server and then import the calendars on the second server. After the calendars are moved, you can delete the calendars on the original server. For instructions on how to move calendars, see Managing User Calendars.

csvdmig

The csvdmig utility modifies the Calendar Server database and LDAP directory server database for sites that want to use hosted (virtual) domains.

Be sure to run csmig before using this utility if you are moving from a non-hosted environment.

This sections contains the following topics:

• csvdmig Functions

• csvdmig Syntax

• csvdmig Examples

csvdmig Functions

The csvdmig utility adds the domain name to the user ID as follows:

• The format of calendar ID's (calids) is changed:

  From: userid[:calendar-name]

  To: userid@domain[:calendar-name]

• Access Control List (ACL) access rules are changed:

  From: userid

  To: userid@domain

• The LDAP directory server user entries for the Calendar Server attributes are modified as:

  userid[:calendar-name] to userid@domain[:calendar-name].

• Updates the owner and attendee fields in events and tasks in the calendar database.

  For example: if jsmith in the domain sesta.com is the owner of an event, the new owner field would contain jsmith@sesta.com.

The csvdmig utility updates the databases and LDAP directory in place. That is, it does not create a separate migrated database, but alters the database you are converting. Therefore, to be safe, run csvdmig against snapshots of your databases and LDAP directory.

csvdmig Syntax

The csvdmig utility has the following syntax:

csvdmig [-t DestinationDB]
         [-c ConfigFile]
         [-e ErrorFile]
         [-m MappingFile]
         migrate [DB|LDAP]

The following table lists the options used by csvdmig, and gives a description of each.

Mapping File

The mapping file is an input text file that maps existing users to their respective domains. You must create the mapping file before you run csvdmig. Specify one entry per line with a space between the old and new values. For example:

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
 ...
usern usern@siroe.com

Destination DB

This utility does not move the migrated files into a new DestinationDB. If you specify the -t option, you must copy the database files to be migrated into that directory before running csvdmig.

If you do not use the -t option, the utility will migrate the files in the working directory, with unpredictable results.

csvdmig Examples

• Migrate the LDAP directory server data using default values:

  csvdmig migrate LDAP

• Migrate the Calendar Server database:

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

commdirmig

The commdirmig utility migrates your LDAP data from Sun LDAP Schema 1 to Schema 2 in preparation for using Access Manager for authentication services.

This section contains the following topics:

• Who Should Run the Utility

• When to Run the Utility

• Where to Find Documentation

• Where to Find the Utility

Who Should Run the Utility

If you previously used a version of Messaging Server 5 or Calendar Server 5, your LDAP entries were formatted Schema 1. In your new Calendar Server 6 2005Q4 environment, if you are going to use Access Manager for authentication, you must convert your LDAP entries to Schema 2 format by running this utility.

If you are not using Access Manager, you should still consider migrating your LDAP data, since Schema 2 is the preferred LDAP mode for all Java Enterprise System products that use LDAP. In the future it is possible that newer versions of the communications products (Calendar, Messaging and Instant Messaging) may not support Schema 1. However, the migration can be deferred until a later, more convenient time if you are not going to be using Access Manager at this time.

If you have a separate LDAP directory for preferences, you must run commdirmig on that LDAP as well as the one used for authentication.

When to Run the Utility

If you are migrating from a pre-Java Enterprise System version of Calendar Server, run this utility after you run cs5migrate, csmig and csvdmig.

Where to Find Documentation

The commdirmig migration utility requires special preparation and planning. It is documented in a separate guide, see Sun Java System Communications Services 6 2005Q4 Schema Migration Guide.

Where to Find the Utility

The commdirmig utility comes bundled with Delegated Administrator that you install from the Java Enterprise System installer.

A patch is also available from technical support for the utility.