As you read the scenarios and plan your migration path, keep in mind the following questions:
Is your system deployed on a single server or distributed across multiple servers?
Is it critical to minimize downtime?
Do you need to limit the time it takes to perform the migration?
Is it important to minimize the complexity of the migration process?
Are you running applications developed at your site that rely on LDAP Schema 1? (Have you created your own tools that provision directly against the LDAP directory and use Schema 1?) How complex a task would it be to convert your applications to use Schema 2?
These questions can help you to decide which scenario to use as a model for your own migration path. For example:
If you have a multiple-server deployment and your highest priority is to minimize downtime, your migration path might resemble Scenario D, Multiple Servers - Migrate Incrementally to Native Mode
If you have created your own provisioning tools that rely on Schema 1 and you have a multiple-server deployment, your migration path might resemble Scenario E, Multiple Servers - Migrate Incrementally to Compatibility Mode, Then to Native Mode
However, no single scenario is likely to correspond exactly to your situation. The scenarios are general examples. They do not attempt to replicate an actual user installation.
Read the assumptions and characteristics at the start of each scenario. Read all the steps in the scenarios that most closely resemble your situation. Then refine your specific migration strategy based on those guidelines.
The scenarios are as follows:
Scenario A: Single Server - Migrate to Native Mode
Scenario B: Single Server - Migrate to Compatibility Mode, Then to Native Mode
Scenario C: Multiple Servers - Migrate Directly to Native Mode
Scenario D: Multiple Servers - Migrate Incrementally to Native Mode
Scenario E: Multiple Servers - Migrate Incrementally to Compatibility Mode, Then to Native Mode
Once you have become familiar with your particular migration issues and designed your migration strategy, it is a good practice to migrate on a test system before you migrate your production LDAP directory and Messaging and Calendar servers.
Before you choose a migration strategy, you should understand the potential constraints on using the LDAP directory during the migration process.
Depending on the path you follow, old and new components might have to coexist during certain stages of the migration. Your installation temporarily could have a mixed environment, such as one of the following:
Schema 1; one or more servers upgraded to version 6; remaining servers running version 5.x.
Schema 2 (native mode or compatibility mode); one or more servers upgraded to version 6; remaining servers running version 5.x.
While your installation is in a mixed state, you might not be able to perform certain tasks such as domain provisioning. The following sections describe these issues in further detail.
The following provisioning tools are available:
To provision Schema 1:
For Messaging Server, use iPlanet Delegated Administrator.
For Calendar Server, use the command-line utilities provided with Calendar Server, as described in Appendix D, Calendar Server Command-Line Utilities Reference, in Sun Java System Calendar Server 6 2005Q4 Administration Guide.
To provision Schema 2, native mode or compatibility mode, use the Delegated Administrator console and command-line utility (commadmin). (In the Messaging Server 6 2004Q2 release, the Delegated Administrator utility was called User Management Utility.)
While the directory data is being migrated (while the Schema Migration Utility, commdirmig, is running), you cannot perform any provisioning tasks of any type.
Before and after the directory migration, your installation components can be in a mixed state, as described in Potential Restrictions During Migration. Constraints on provisioning depend on the relationships between the server version and configuration and the current schema level.
Provisioning Rules Before and After Schema Migration shows a matrix of the current directory schema level, the current server version and configuration, the provisioning tool you can use with each combination, and the provisioning constraints.
Table 2–1 Provisioning Constraints in a Mixed Environment
Directory Schema Level |
Server 5.x |
Server 6 - configured for Schema 1 |
Server 6 - configured for Schema 2 |
---|---|---|---|
Schema 1 |
1 For Messaging Server, use Delegated Administrator. For Calendar Server, use the Calendar Server command-line utilities. Full provisioning available. |
2 For Messaging Server, use Delegated Administrator. For Calendar Server, use the Calendar Server command-line utilities. Full provisioning available. |
3 Invalid combination for provisioning. * |
Schema 2, compatibility mode |
4 Use commadmin. Full provisioning available. |
5 Use commadmin. Full provisioning available. |
6 Invalid combination for provisioning. * |
Schema 2, native mode |
7 Invalid combination for provisioning. |
8 Use commadmin. No domain provisioning. No administrative provisioning. |
9 Use commadmin. Full provisioning available. |
* A Server 6 configured for Schema 2 will not run against a Schema 1 directory or a Schema 2, compatibility mode, directory. |
The following characteristics apply to the server-schema configurations shown in Provisioning Rules Before and After Schema Migration. They are numbered 1 - 9 for identification, not to indicate a required sequence of steps:
Configuration 1 is the beginning state of the migration.
Configuration 9 is the target state of the migration.
Configurations 2, 4, 5, and 8: These are interim states that can exist during the migration process (particularly when multiple servers are involved and you migrate one server at a time).
Configurations 3 and 6: You should never configure a server to use Schema 2 when the directory is Schema 1 or Schema 2, compatibility mode. Only configure a server to use Schema 2 after you migrate to Schema 2, native mode.
Configuration 7: Do not provision with this configuration. This state can exist temporarily during an incremental migration of multiple servers and directory domains, when some domains have been migrated to Schema 2 and others are still in Schema 1. However, you cannot use 5.x provisioning tools to provision against the Schema 2 domains.
Configurations 8: This state only works if you do not remove the DC Tree.
After you migrate the directory to Schema 2 (native mode or compatibility mode), 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.
In Schema 2, compatibility mode, a version 6 server and a 5.x server would provision using the DC Tree. In compatibility mode, the Messaging and Calendar servers continue to provision the LDAP directory exactly as they did in Schema 1.
During the migration from Schema 1 to Schema 2, compatibility mode, the inetDomainStatus attribute is copied to the organization/domain node in the Organization Tree.
In compatibility mode, two instances of inetDomainStatus exist, one in the DC Tree and one in the Organization Tree.
A 5.x server would reference inetDomainStatus in the DC Tree. A version 6 server would reference inetDomainStatus in the Organization Tree.
Access Manager-based provisioning tools such as the Delegated Administrator console and command-line utility (commadmin) ensure that the two copies of inetDomainStatus maintain the same value (active or inactive).
Your own provisioning tools (if you use any) also must ensure that the two copies of inetDomainStatus are set to the same value.
If a Calendar Server has configured separate LDAP directories for authentication and user preferences, you must run the Schema Migration Utility (commdirmig) against both directories.
To check if your Calendar Server deployment uses two different directories, examine the values for the following parameters in the Calendar Server configuration file, ics.conf:
local.authldapbasedn local.authldaphost
and
local.ugldapbasedn local.ugldaphost
If the basedn and host values for these parameters are different, Calendar Server is using two different LDAP directories.
While the Schema Migration Utility (commdirmig) is running, Messaging and Calendar servers can stay online and continue to look up user entries in the LDAP directory. (However, no provisioning should take place during the migration.)
In addition, commdirmig provides the following safety features that let you control and stage the migration:
You can migrate one domain (or selected domains) at a time.
You can perform a dry run of the migration.
By default, commdirmig operates in preview mode (performs a dry run). The commdirmig utility writes an LDIF-formatted audit file containing the changes to the directory data that would be made during an actual migration. The LDAP directory itself isn’t changed.
After the utility executes in preview mode, you can examine the LDIF audit file and review the intended changes to the directory data.
When you are satisfied that the changes are correct, you can use the ldapmodify tool to apply the LDIF entries to the LDAP directory. Or you can run commdirmig again in online mode, which directly migrates the directory data to Schema 2.
The commdirmig utility produces an undo file, which you can use to roll back the changes made to the LDAP directory.
If the migration is interrupted, you can run commdirmig again. The utility will resume the migration without changing any data that was properly migrated.
The commdirmig utility leaves the DC Tree in place.
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 the data has been migrated to Schema 2.
After you have completed the entire migration process, you can choose to remove the DC Tree with an LDAP command-line tool. Before you remove the DC Tree, be sure to verify that the migration was successful.