Comparison of Sun Java System LDAP Schema Modes for Communications Suite Products

Previous: Comparing User LDAP Entries for Schema Version 1 and Schema Version 2 Modes
Next: Functional Differences Between the Delegated Administrator Console and Utility

To Migrate to Schema Version 2 or Not to Migrate

While the examples given earlier in this document don't show a single user record with both calendar and messaging services, you might want both software applications to share the domain, user and group LDAP entries. If you do want both applications to share the same LDAP, they must both use the same schema mode.

This section discusses the things you need to consider about two products sharing the same LDAP entries, in order to help you decide whether its necessary to migrate your Schema version 1 LDAP to one of the Schema version 2 modes.

This section contains the following topics:

Facts About Schema Version 1 and Schema Version 2 Modes

If you have an earlier version of one of the Communications Suite products installed in Schema version 1 mode, and want to install a second product, you might be tempted to avoid migrating your Schema version 1 mode LDAP to a Schema version 2 mode. If so, consider the following facts:

For Schema version 1 mode, there is not one unified tool to use for user, group, resource and domain administration.

For Calendar Server, only command-line utilities are available, no GUI.

For Messaging Server, there are three separate tools used, a command-line utility, a GUI (iPlanet Delegated Administrator) and the Administration Server Console. None of these tools support Calendar Server. In Communications Suite 5, the latter two are deprecated and are no longer included in the distribution.
While it is possible to run both products in Schema version 1 mode, it places a lot of burden on the system administrators to keep it all straight and avoid deleting something the other product needs.

Schema version 1 based Calendar Server administration utilities allow entries to be fully deleted (purged) from LDAP without regard to another product's dependence on the entries. Thus, the administrator must be responsible for the integrity of the LDAP for both products. The administrator of a deployment of two products using Schema version 1 might find it difficult to avoid inadvertent purges or unwanted changes to a user's LDAP record. For the same reason, you should not attempt to have both a Schema version 1 mode product and a Schema version 2 mode product share the same LDAP.
Keeping your older Calendar Server deployment in Schema version 1 non-domain mode is no longer possible. Calendar Server 6.3 software automatically converts Schema version 1 non-domain configurations to multiple domain mode by creating a single default domain under the root at configuration time and assuming all non-fully qualified uid's imply the default domain. For Calendar Server 6.3, you can't avoid multiple domain mode.
Access Manager won't work with a Schema version 1 LDAP entries.
To Use Schema version 2 in either mode and its administration tool, Delegated Administrator, you must have Access Manager installed in legacy mode.
For Schema version 2 modes, there is one unified tool, Delegated Administrator Console (GUI) and its command-line utility equivalent, commadmin. You can administer both Calendar Server and Messaging Server domains, users and groups with these tools. Using a Delegated Administrator interface for both services, prevents an administrator from inadvertently deleting another service's LDAP entries.
If you plan to use Access Manager, you must choose one of the Schema version 2 modes for both Messaging Server and Calendar Server deployments.

Administration Tools for LDAP Entries in Both Schema Versions

This section lists the various tools used to administer LDAP in Schema version 1 mode.

For Schema version 1 mode, the following tools apply:
- iPlanet Delegated Administrator (Messaging only) — This software is deprecated and no longer bundled in the distribution.
- Administration Server Console (Messaging only) — This software is deprecated and no longer bundled in the distribution.
- Messaging Server command-line utility
- Calendar Server command-line utilities (many)
  
  For information about these command-line utilities, see Sun Java System Calendar Server 6.3 Administration Guide.
For Schema version 2 mode. the following tools apply:
- Delegated Administrator Utility (Command-line)
- Delegated Administrator Console (GUI)

Conclusions

Based on the facts presented in this article, here are some possible scenarios and conclusions:

Our deployment is using the Access Manager software installed in legacy mode.

Choose Schema version 2 native mode for both Calendar Server and Messaging Server products at configuration time.

If you have an existing two DIT LDAP structure with a DC tree, and you don't want to migrate to a single DIT structure, you can choose Schema version 2 compatibility mode.

We have Access Manager installed in Realm mode and want to add Communications Suite products.

You must have Access Manager installed in legacy mode in order to use Delegated Administrator.

Our deployment isn't using the Access Manager product. We don't have an existing product installed and there are no previous LDAP entries.

Install Access Manager in legacy mode to enable Delegated Administrator. Choose Schema version 2 native mode for both Calendar Server and Messaging Server products at configuration time. Delegated Administrator creates Access Manager-ready LDAP records, but you are not required to implement any other Access Manager features.

We have a two DIT LDAP structure, and we are willing to change to a single DIT LDAP structure.

Choose Schema version 2 native mode. Migrate your existing LDAP database to Schema version 2 mode. Use Delegated Administrator interfaces to administer domains, users and groups.

We have a two DIT LDAP structure, and we don't wish to change to a single DIT LDAP structure.

Choose Schema version 2 compatibility mode for both calendar and messaging applications.

We have a Schema version 1 two DIT LDAP structure, and don't wish to migrate it to Schema version 2 mode.

You can choose to keep all Communications Suite products in Schema version 1 mode, but administration of two products in Schema version 1 mode will be difficult and involve many different interfaces, some of which are deprecated.

For further information on migrating your old Schema version 1 mode system to Schema version 2 mode, see Sun Java Communications Suite 5 Schema Migration Guide.