Previous      Contents      Index      Next
Sun Java System Communications Services 6 2005Q1 Schema Migration Guide

Chapter 4
Upgrading and Configuring the Servers

This chapter describes how to configure the Messaging Server and Calendar Server to use LDAP Schema 2. It includes the following topics:

Guidelines for Server Configuration
Configuring Messaging Server
Configuring Calendar Server

---

Guidelines for Server Configuration

The following rules and guidelines apply to server configuration:

You must upgrade a Messaging or Calendar Server to version 6 before you can configure it to use Schema 2.
We recommend that you upgrade the Messaging and Calendar servers before you migrate to Schema 2.
When you upgrade a server to version 6, you can configure it to use Schema 1 (until the directory data has been migrated).
After you migrate the directory data to Schema 2, you can reconfigure the server to use Schema 2.
If you migrate the directory data to Schema 2, compatibility mode, configure the servers to use Schema 1.

After you migrate the directory data from Schema 2, compatibility mode to Schema 2, native mode, you must reconfigure the servers to use Schema 2.

---

Configuring Messaging Server

The following procedures outline how to upgrade Messaging Server to version 6 and configure it to use Schema 2.

Upgrading Messaging Server to Version 6

To upgrade Messaging Server 5.x to Messaging Server 6, follow the instructions in “Upgrading to Sun Java System Messaging Server,” in the Messaging Server Administration Guide (http://docs.sun.com/doc/819-0105).

Running the Directory Server Setup Script

During the upgrade process, you run the Directory Server Setup Perl script (comm_dssetup.pl) to configure Directory Server 5.x for Messaging Server 6 and Calendar Server 6.

The comm_dssetup.pl script asks you to specify which schema version Directory Server is to use by setting the comm_dssetup.pl -t option, as follows:

-t 1 — Schema 1
-t 1.5 — Schema 2, compatibility mode
-t 2 — Schema 2, native mode.

Since you are upgrading your Messaging and Calendar servers before you migrate to Schema 2, you should specify Schema 1 at this stage. If you specify Schema 1 when you run comm_dssetup.pl, the upgraded servers will continue to use the existing schema without interruption.

If you also have installed Calendar Server 6 and have already run comm_dssetup.pl, you might not need to run the script again.

Note	You only need to run comm_dssetup.pl once for each Directory Server used by the Messaging and Calendar servers. However, if you are not sure what to do, it will not hurt your system to run it again. In fact, the script checks to see if the current version has already been installed and will notify you.

Configuring Messaging Server for Schema 2

To configure Messaging Server to use Schema 2, native mode, perform these tasks:

Edit the LDAP_SCHEMALEVEL option in the option.dat file to support Schema 2.
Change the service.dcroot configuration parameter to point to the root of the Organization Tree (by using the configutil command).

These tasks are described in the sections that follow.

Step 1: Edit the Schema-Level Option in the Option File

Set the LDAP_SCHEMALEVEL option value to 2.

You can set the following values for the LDAP_SCHEMALEVEL option in the option.dat file:

LDAP_SCHEMALEVEL=1 enables Messaging Server to support Schema 1.
LDAP_SCHEMALEVEL=2 enables Messaging Server to support Schema 2, native mode.

For details about editing and using the option.dat file, see Editing the Option File and Other Options in the Option File.

Step 2: Change the DC Root Configuration Parameter

Update the following configuration parameter with the configutil command:

service.dcroot

This parameter tells Messaging Server where to begin doing lookups in the LDAP directory.

For Schema 1, the value of this parameter is the root of DC Tree in the directory. The default value is o=Internet.

To configure Messaging Server to support Schema 2, change the value of service.dcroot to the root of the Organization Tree in the directory.

For information about using the configutil utility, see “Chapter 1: Messaging Server Command-line Utilities” in the Messaging Server Administration Reference.

Schema 2, Compatibility Mode

If you are migrating to Schema 2, compatibility mode, Messaging Server should continue to be configured to use Schema 1:

Set the value of the LDAP_SCHEMALEVEL option to 1.
Set the value of the service.dcroot configuration parameter to the root of the DC Tree.

In Schema 2, compatibility mode, the Messaging and Calendar servers continue to use the schema exactly as they did in Schema 1. The servers use the DC Tree to access the correct nodes in the Organization Tree. They use an RFC 2247-compliant search algorithm to look up user entries. From the Messaging and Calendar servers’ perspective, Schema 1 is still in place.

At the same time, Schema 2, compatibility mode enables you to use Access Manager features such as the commadmin utility or single sign-on (SSO). During the migration to Schema 2, compatibility mode, Access Manager object classes, attributes, and ACIs are added to the appropriate nodes in the Organization Tree.

Editing the Option File

Each line in the option.dat file contains the setting for one option. An option setting has the form:

option=value

The option.dat file is the file specified with the IMTA_OPTION_FILE option in the IMTA tailor file (msg_svr_base/config/imta_tailor). By default, it is located in msg_svr_base/config/option.dat

For more information about the option.dat file, see “Chapter 4: MTA Configuration,” in the Messaging Server Administration Reference.

Other Options in the Option File

Other LDAP Schema 2 options in the option.dat file let you customize Messaging Server’s interaction with the LDAP directory.

For example, LDAP_DOMAIN_FILTER_SCHEMA2 lets you set the LDAP search filter used for Schema, 2 domain lookups. (The default value for this option is objectclass=sunManagedOrganization.)

However, to configure Messaging Server to use Schema 2, you only have to set the LDAP_SCHEMALEVEL option. When you migrate to Schema 2, the Schema Migration Utility (commdirmig) automatically migrates all the current domain object classes and domain attributes from the DC Tree to the Organization Tree.

Your option.dat file also might contain options that customize Schema 1 values. After you migrate to Schema 2, these options become irrelevant and are not used. They do no harm. You do not have to delete Schema 1 options from the option.dat file.

For more information about the options available in the option.dat file, see “Chapter 4: MTA Configuration,” in the Messaging Server Administration Reference.

---

Configuring Calendar Server

The following procedures outline how to upgrade Calendar Server to version 6, migrate Calendar Server data to version 6, and configure Calendar Server to use Schema 2.

Upgrading Calendar Server to Version 6

To upgrade Calendar Server 5.x to Calendar Server 6, follow the instructions in “Database Migration Utilities,” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

After the upgrade/installation, you must configure Calendar Server and migrate Calendar Server data. For details, see “Post-Installation Configuration” and “Database Migration Utilities” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

Running the Directory Server Setup Script

During the upgrade process, you run the Directory Server Setup Perl script (comm_dssetup.pl) to configure Directory Server 5.x for Calendar Server 6 and Messaging Server 6.

The comm_dssetup.pl script asks you to specify which schema version Directory Server is to use by setting the comm_dssetup.pl -t option, as follows:

-t 1 — Schema 1
-t 1.5 — Schema 2, compatibility mode
-t 2 — Schema 2, native mode.

Since you are upgrading your Messaging and Calendar servers before you migrate to Schema 2, you should specify Schema 1 at this stage. If you specify Schema 1 when you run comm_dssetup.pl, the upgraded servers will continue to use the existing schema without interruption.

If you have just installed Messaging Server 6 and have already run comm_dssetup.pl, you do not need to run the script again.

Note	You only need to run comm_dssetup.pl once for each Directory Server used by the Messaging and Calendar servers. However, if you are not sure what to do, it will not hurt your system to run it again. In fact, the script checks to see if the current version has already been installed and will notify you.

For more information about running the comm_dssetup.pl script, see “Post-Installation Instructions,” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

Configuring Calendar Server to Use Schema 2

To configure Calendar Server to use Schema 2, you must set configuration parameters in the Calendar Server configuration file, ics.conf.

You also must set additional configuration parameters to support hosted (virtual) domains. For details, see Configuring Calendar Server for Hosted Domain Support.

(The Calendar Server configuration program, csconfigurator.sh, does not configure Calendar Server to use Schema 2 or to support hosted domains.)

To configure Calendar Server to use Schema 2, edit the following parameters in the ics.conf file:

local.schemaversion

local.schemaversion=”1” specifies Schema 1. If the server is using Schema 1, you also must specify the service.dcroot parameter.

local.schemaversion=”2” specifies Schema 2. If the server is using Schema 2, you also must specify the service.schema2root parameter.

service.dcroot

Specifies the root suffix of the DC Tree in the LDAP directory.

For example: “o=internet”

service.dcroot is active when the server is using Schema 1. If the server is using Schema 2, service.dcroot is ignored.

service.schema2root

Specifies the root suffix in the Organization (OSI) Tree in the LDAP directory, underneath which all domains are found.

For example: “o=sesta.com”

service.schema2root is active when the server is using Schema 2. If the server is using Schema 1, service.schema2root is ignored.

Configuring Calendar Server for Compatibility Mode

If you are migrating to Schema 2, compatibility mode, set the local.schemaversion value to 1.

In Schema 2, compatibility mode, the Messaging and Calendar servers continue to use the schema exactly as they did in Schema 1. The servers use the DC Tree to access the correct nodes in the Organization Tree. They use an RFC 2247-compliant search algorithm to look up user entries. From the Messaging and Calendar servers’ perspective, Schema 1 is still in place.

At the same time, Schema 2, compatibility mode enables you to use Access Manager features such as the commadmin utility or single sign-on (SSO). During the migration to Schema 2, compatibility mode, Access Manager object classes, attributes, and ACIs are added to the appropriate nodes in the Organization Tree.

Configuring Calendar Server for Hosted Domain Support

To support Schema 2, Calendar Server also must be configured to support hosted (virtual) domains. This section briefly summarizes the procedures for supporting hosted domains. For more information, see “Administering Hosted Domains” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

To migrate a site to use hosted domains, you must perform the following tasks:

Run the csvdmig utility. For details, see “Database Migration Utilities” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).
Set additional configuration parameters in the ics.conf file.

Table 4-1 describes the parameters in the ics.conf file used for hosted domain support. If any of the following parameters are not in the ics.conf file, add the parameter and its associated value to the file and then restart Calendar Server for the values to take effect.

For more information about editing the ics.conf file, see “Calendar Server Configuration Parameters,” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

Table 4-1  Configuration Parameters for Hosted Domain Support 

Parameter	Description
service.virtualdomain.support	Enables ("y") or disables ("n") support for hosted (virtual) domain mode. Default is "n".
local.schemaversion	Specifies the version of the LDAP schema: "1" = Schema 1. See also service.dcroot. "2" = Schema 2. See also service.schema2root. Default is "1".
service.dcroot	Specifies the root suffix of the DC tree in the LDAP directory, if local.schemaversion = "1". For example: "o=internet". In hosted (virtual) domain mode, Calendar Server uses the service.dcroot parameter and not the local.ugldapbasedn and local.authldapbasedn parameters. Conversely, in non-hosted (virtual) domain mode, Calendar Server uses the local.ugldapbasedn and local.authldapbasedn parameters and not the service.dcroot parameter.
service.schema2root	Specifies the root suffix underneath which all domains are found, if local.schemaversion = "2". For example: "o=sesta.com".
service.defaultdomain	Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. For example: "sesta.com".
service.loginseparator	Specifies a string of separators used for the login-separator when Calendar Server parses "userid[login-separator]domain". Calendar Server tries each separator in turn. Default is "@+".
service.siteadmin.userid	Specifies the user ID of the domain administrator. For example: DomainAdmin@sesta.com.
service.virtualdomain.scope = "select"	Controls cross domain searching: "primary" = Search only within the domain where the user is logged in. "select" = Search in any domain that allows the search. Default is "select".
local.domain.language	Specifies the language for the domain. Default is "en" (English).

Provisioning Rules for Hosted Domains

After you configure Calendar Server to support hosted domains (and after you migrate the directory data to Schema 2), user-developed applications and provisioning tools must use the following rules for provisioning new entries:

User entries must be underneath the people node in the Organization Tree.
Group entries must be underneath the group node in the Organization Tree.

Access Manager requires this hierarchy for provisioning user and group entries. Access Manager-based tools will not recognize users and groups provisioned under different nodes than the people node and group node, respectively.

Editing the Configuration File

Calendar Server configuration parameters are stored in the following file:

cal_svr_base/etc/opt/SUNWics5/config/ics.conf

The ics.conf file is an ASCII text file, with each line defining a parameter and its associated value(s). The parameters are initialized during Calendar Server installation. After installation, a user with administrator rights on the system where Calendar Server is running can edit the ics.conf file. You can edit the file by using a text editor such as vi on Solaris Systems.

For more information about editing configuration parameters in the ics.conf file, see “Calendar Server Configuration Parameters,” in the Calendar Server Administration Guide (http://docs.sun.com/doc/819-0024).

Previous      Contents      Index      Next

---

Copyright 2005 Sun Microsystems, Inc. All rights reserved.