Recommendations for Schema Extension Programs

In addition to the prerequisites, the following practices are recommended for schema extension programs:

1. Find the Schema Master. Bind to the schema on the DC that is the schema master. Avoid unnecessarily changing the schema master role between DCs. To bind to the schema container on the schema master, see the sample code in Prerequisites for Installing a Schema Extension.
2. Before doing anything, check the allowedChildClassesEffective property of the Schema container to see if you can create attributes and/or classes. If attributeSchema and classSchema are not values in that property, you do not have sufficient rights to add attributes or classes to the schema. See Example Code for Checking for Rights to Create attributeSchema and classSchema Objects.
3. Make sure that the Schema Update Allowed is set appropriately in the registry of the schema master. If you need to create or set this value, restore it to its original state as part of your program's clean-up routine. To check and set this value, see the sample code in Enabling Schema Changes at the Schema Master.
4. Before adding attributes or classes, make sure that they do not already exist. If they do exist, verify that they are the same attributes or classes you are adding and not an attribute or class created by someone else with different syntax and properties that are incompatible with your attributes or classes.

   For attributes, query for cn, attributeID, governsID, lDAPDisplayName, and schemaIDGUID to ensure they are not already used. If you are adding a set of linked attributes (one forward link, one back link), make sure that the linkIDs are not already used. Note that you must query for governsID as well because the object identifier (OID) must be unique among attributes and classes.

   For classes, query for cn, governsId, attributeID, lDAPDisplayName, and schemaIDGUID to ensure they are not already used. Note that you must query for attributeID as well because the OID must be unique among classes and attributes.

   To check for naming collisions, see Example Code for Detecting Schema Naming Collisions.

   If attributes or classes exist that conflict with your new attributes or classes, your program should not apply your schema changes.

5. If such a collision exists, your program should not apply your schema changes. The schema administrator may need to resolve the collision and then run your program again. Alternatively, a different lDAPDisplayName could be used; however, any applications using the attribute or object must be aware of that change. To help avoid OID collisions, obtain an OID from an ISO name registration authority.
6. If your program is dependent on attributes or classes that it has added, update the schema cache before adding the new attributes or classes that are dependent on those attributes or classes. Note that the schemaUpdateNow operational attribute is synchronous. This means your Put method call will block until the schema cache is updated. When the call returns, the schema cache has been updated and the new attributes and/or classes are accessible.

   To update the schema cache, see Example Code for Updating the Schema Cache.