Messaging and Calendar Server are running in a two-tiered, multiple-server environment
The installation does not include user-developed applications that rely on Schema 1
Multiple Servers - Migrate Directly to Native Mode shows a simple example of a distributed environment. Two front-end servers handle incoming and outgoing traffic and three back-end servers look up entries in portions of the LDAP directory. Each back-end server manages two domains in the directory.
The entire LDAP directory is migrated in a single step.
Some downtime is required while you upgrade the servers to version 6.
The entire system can continue running while you upgrade the servers one at a time.
The following steps outline how to migrate a two-tiered, multiple-server environment directly to Schema 2, native mode:
Upgrade the Messaging Servers and Calendar Servers from version 5.x to version 6 (if you have not already done so).
In the example shown in Multiple Servers - Migrate Directly to Native Mode, upgrade the servers as follows:
Upgrade Front-end Server 1 (F1).
Upgrade Front-end Server 2 (F2).
Upgrade Back-end Server 1 (B1).
Upgrade Back-end Server 2 (B2).
Upgrade Back-end Server 2 (B3).
For information about upgrading Messaging Server, see Upgrading Messaging Server to Version 6
For information about upgrading Calendar Server, see Upgrading Calendar Server to Version 6
Be sure that the upgraded (version 6) servers are still configured for Schema 1.
During the server upgrade, you run the Communications Services Directory Server Setup Perl script, comm_dssetup.pl. The script asks you to specify the schema version Directory Server will use:
Specify Schema 1.
Set comm_dssetup.pl -t option as follows: -t 1
You only need to run the comm_dssetup.pl once for each Directory Server used by the Messaging and Calendar servers, although it does no harm to run the script more than once.
For information about running comm_dssetup.pl, see Running the Directory Server Setup Script
Install Access Manager 6.1 or later.
Follow the Access Manager installation instructions in the Access Manager: Provisioned Directory Information in Sun Java Enterprise System 2005Q4 Installation Referencesection of the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Before you run the Java Enterprise System installation program, gather the information needed to install Access Manager with a provisioned directory.
For details, see the Access Manager: Provisioned Directory Information in Sun Java Enterprise System 2005Q4 Installation Reference section of the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX
During the installation, you are asked if you want Access Manager to use an existing provisioned directory. Answer yes.
The installation program asks you to specify the following parameters associated with your directory:
Organization Object Marker Class: Object class defined for the organization in the existing provisioned directory. The default value is SunManagedOrganization.
Organization Naming Attribute: Naming attribute used to define organizations in the existing provisioned directory. The default value is o.
User Marker Object Class: Object class defined for users in the existing provisioned directory. The default value is inetorgperson.
User Naming Attribute: Naming attribute used for users in the existing provisioned directory. The default value is uid.
After you install Access Manager, configure Access Manager to operate with the existing directory.
Follow the steps in “Chapter 4, Configuring Access Manager With an Existing Directory Server” in Sun Java System Access Manager 6 2005Q1 Migration Guide.
Do not provision your LDAP directory with Access Manager tools before you have migrated the directory to Schema 2. The Messaging and Calendar servers cannot recognize any new domain information provisioned by Access Manager tools until you perform the migration to Schema 2 and reconfigure the servers for Schema 2.
Install and configure the Communications Services Delegated Administrator console and utility (commadmin).
Use the Sun Java Enterprise System Installer to install Delegated Administrator.
After the installation, you must run the Delegated Administrator configuration program, config-commda.
Back up the LDAP directory.
Migrate the LDAP directory from Schema 1 to Schema 2, native mode.
Use the Schema Migration utility, commdirmig, to perform the migration.
In a direct migration, you run commdirmig once to migrate the entire LDAP directory. Do not migrate individual domains.
Do not provision the directory while commdirmig is running.
For information on running the commdirmig utility and on the utility options and syntax, see Chapter 3, Using the Migration Utility
Configure the Messaging Servers and Calendar Servers to use Schema 2, native mode. In the example shown in Multiple Servers - Migrate Directly to Native Mode, configure the servers as follows:
Reconfigure Front-end Server 1 (F1).
Reconfigure Front-end Server 2 (F2).
Reconfigure Back-end Server 1 (B1).
Reconfigure Back-end Server 2 (B2).
Reconfigure Back-end Server 2 (B3).
For information about reconfiguring Messaging Server, see Configuring Messaging Server for Schema 2
For information about reconfiguring Calendar Server, see Configuring Calendar Server to Use Schema 2
Stop and restart the Administration Server.
You can use the following commands:
Verify that the following processes are functioning properly:
The servers are working with the migrated schema
Provisioning can take place successfully
If you wish, remove the DC Tree (the defunct Schema 1 directory elements).
Do not remove the DC Tree until you have verified that the migration was completed successfully (as described in the preceding “verify” step).
You can use an LDAP command-line tool to remove the DC Tree.
This step is optional. The DC Tree is not used in Schema 2, but it does no harm to leave the deprecated DC Tree in the LDAP directory after Schema 2 is in place.