Potential Restrictions During Migration

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.

Provisioning Tools

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.)

Provisioning Rules During Migration

While the directory data is being migrated (while the Schema Migration Utility, commdirmig, is running), you cannot perform any provisioning tasks of any type.

Provisioning Rules Before and After Schema Migration

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.

Provisioning Rules for Integration with Access Manager

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.

Constraints in Compatibility Mode

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.

inetDomainStatus

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.

Guidelines for Calendar Servers Using Two LDAP Directories

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.