A History of Two Schema Versions

There are two collections of object classes and attributes for Communications Suite products; that is, there are two schema versions you can choose to run in, called Schema version 1 and Schema version 2. Because of product changes over time, the collection of object classes and attributes used by Communications Suite products has been split between an older legacy version and the newer version.

Originally, the legacy schema collection was not named. To differentiate between the two schema collections, when the second collection was introduced, the terms Schema version 1 and Schema version 2 were created. The schema split occurred at the iPlanet to Sun^TM ONE branding change. Both schema versions are allowed in the current products, but at configuration time, you must choose which schema version mode your system will use.

Schema version 2 has two modes: native mode and compatibility mode. These modes are described in Schema Version 2 Background Information.

This article gives a comparison of the two schema versions, including the following topics:

• Object Classes and Attributes — Each schema version has a specific list of object classes and attributes it works with. Some of the object classes and attributes are the same in both versions, but there are also object classes and attributes that are unique to each schema version. To avoid confusion, use the same schema version for all of the Communications Suite products in your deployment that share the same LDAP database.

• Administrative Tools — The administration tools used to administer domains, users and groups are different for each schema version.

A discussion of the various consequences of choosing one schema version over the other is found in To Migrate to Schema Version 2 or Not to Migrate.

Schema Version 1 Mode Background Information

 The chief characteristic of Schema version 1 mode is its association with the use of two DITs, a Domain Component tree (DC tree) and an Organization tree. A DIT is a logical view of the relationship between domain, user and group LDAP entries, and implies how the information can be located.

Figure 1–1 Schema Version 1 Two DIT Layout

For Schema version 1 mode, the domain information is carried exclusively on the DC tree. The user and group information is all carried in the Organization tree. The domain nodes on the Organization tree are just place holders and don't carry functional attributes

The server software finds the distinguished name (DN) of the Organization tree domain by reading the value of the inetDomainBaseDN attribute in the DC tree domain node. The system uses this DN to search the LDAP for the Organization tree domain node, under which the domain's users and groups reside.

Domain nodes that function as aliases can be created in two different ways, with or without their own routing and access information. The alias domains that contain no routing and access information of their own reference another DC tree domain node, and use that node's routing and access control information. The alias domains, more properly called index nodes, containing their own routing and access control information, reference an Organization tree domain node. For more information about Schema version 1 aliases, see How Alias Domains Are Handled In Schema Version 1 Mode.

The two tree layout illustrated in Figure 1–1, shows how the LDAP entries are logically structured. In the figure, arrows from the DC tree show how the nodes in the DC tree point to the domain nodes in the Organization tree. Furthermore, it shows an alias domain node in the DC tree, siroe. This node carries its own routing and access control information, while still pointing to the canonical domain, sesta.com If it did not contain its own routing and access control information, it would point to the DC tree domain where the routing and access control information it's using resides, sesta.

In the earlier versions of Calendar Server and Messaging Server, each product provided its own provisioning and administration utilities based on Schema version 1 mode. In addition, Messaging Server offered the iPlanet Delegated Administrator GUI for provisioning and administration in the Schema version 1 environment, as well as an Administration Server GUI that was separately installable.

Schema Version 2 Background Information

With the release of Sun ONE Calendar Server, a new schema was introduced to provide compatibility with the Sun ONE Access Manager product, which was the new authentication and identity management product introduced in the Sun ONE branded software family. This new schema was called Schema version 2 to distinguish it from the heretofore unnamed Schema version 1. It has two modes that can be selected at configuration time: native mode and compatibility mode.

Schema version 2 native mode — This mode is associated with a single DIT LDAP layout containing an Organization tree, but no DC tree. For an example of this kind of layout, see Figure 1–2. In this mode, all domain nodes and their attributes are found in the Organization tree. Schema version 2 native mode is the default LDAP layout for new installations of Communications Suite products.

Figure 1–2 Schema Version 2 Native Mode One DIT Layout

Access Manager does not recognize hierarchical domain structures; therefore all domain nodes for this mode must be located only under the root node. No nesting of organizations is allowed in this schema layout. Another limitation of Schema version 2 native mode with Access Manager is the inability to define index nodes (alias domains) that carry alternate routing and access control information. In Schema version 2 native mode, the only kind of aliasing allowed is the simple kind which are just other names for the canonical domain. That is, all aliases must use the same routing and access control information as the actual domain.

Schema version 2 compatibility mode — This mode is the exception to this one tree structure. It uses the same two DIT layout as in Schema version 1 mode, with an Organization tree and a DC tree. However, unlike Schema version 1 mode, in Schema version 2 compatibility mode, the Organization tree domain nodes do carry some domain information. That is, they are decorated with an icsStatus attribute.

Compatibility mode is called Schema version 1.5 in the postinstallation scripts.

A new command-line utility, commadmin, was introduced for administration of Schema version 2 LDAP entries. This utility allowed an administrator to provision and manage domains, users and groups in Schema version 2 mode from a command line. The utility used the Access Manager SDK to create LDAP records compatible with Access Manager. Later the software product line was rebranded as Java Enterprise System. In Java Enterprise System 2005Q1, the Sun Java System Communications Services Delegated Administrator Console was introduced. It is a graphical user interface (GUI) with functionality similar to the command-line utility.

Originally the Delegated Administrator Console only supported administration of Messaging Server users. It now supports administration of both Calendar Server and Messaging Server domains, users and groups. However, there is some disparity between the functionality of the two tools. For a list of the differences, see Functional Differences Between the Delegated Administrator Console and Utility.

If Access Manager is not required, Schema version 2 native mode can be used to provision an Organization tree containing hierarchical (nested) organizations and index node aliases as in Schema version 1 mode.

For customers with Schema version 1 mode installations who wish to migrate to one of the Schema version 2 modes, there is a Schema Migration Utility. For more information on how to migrate your LDAP from Schema version 1 mode to one of the Schema version 2 modes, see Sun Java Communications Suite 5 Schema Migration Guide.

The next section contains more detailed information about the three schema modes just described: Schema version 1, Schema version 2 native mode, and Schema version 2 compatibility mode.