Keep the following in mind when creating custom schema files, especially when you are using replication:
When adding new schema elements, all attributes must be defined before they can be used in an object class. You can define attributes and object classes in the same schema file.
Each custom attribute or object class that you create should be defined in only one schema file. This practice prevents the server from overriding any previous definitions when the server loads the most recently created schema. Directory Server loads the schema files in numerical order first, then in alphabetical order.
When defining new schema definitions manually, best practice is generally to add these definitions to the 99user.ldif file.
When you update schema elements using LDAP, the new elements are written automatically to the 99user.ldif file. As a result, any other schema definition changes that you made in custom schema files might be overwritten. Using only the 99user.ldif file prevents possible duplications of schema elements and the danger of schema changes being overwritten.
As Directory Server loads schema files in alphanumeric order with numbers loaded first, you should name custom schema files as follows:
The number is higher than any directory standard schema already defined.
If you name your schema file with a number that is lower than the standard schema files, the server might encounter errors when loading the schema. In addition, all standard attributes and object classes are loaded only after your custom schema elements have been loaded.
Make sure that custom schema file names are not numerically or alphabetically higher than 99user.ldif because Directory Server uses the highest sequenced file for its internal schema management.
For example, if you created a schema file and named it 99zzz.ldif, the next time you update the schema, all of the attributes with an X-ORIGIN value of 'user defined' would be written to 99zzz.ldif. The result would be two LDIF files that contain duplicate information, and some information in the 99zzz.ldif file might be erased.
As a general rule, identify the custom schema elements that you are adding with the following two items:
'user defined' in the X-ORIGIN field of custom schema files,
A more descriptive label such as 'Example.com Corporation defined' in the X-ORIGIN field, so that the custom schema element is easy for other administrators to understand. For example X-ORIGIN ('user defined' 'Example.com Corporation defined').
If you are adding schema elements manually and do not use 'user defined' in the X-ORIGIN field, the schema elements appear read-only in DSCC.
The 'user defined' value is added automatically by the server if you add custom schema definitions by using LDAP or DSCC. However, if you do not add a more descriptive value in the X-ORIGIN field, you might later have difficulty understanding what the schema relates to.
These changes are not replicated automatically. To replicate, you must propagate custom schema files manually to all your servers.
When you change the directory schema, the server keeps a timestamp of when the schema was changed. At the beginning of each replication session the server compares its timestamp with its consumer’s timestamp and, if necessary, pushes any schema changes. For custom schema files, the server maintains only one timestamp, which is associated with the 99user.ldif file. This means that any custom schema file changes or additions that you make to files other than 99user.ldif will not be replicated. Therefore, you must propagate custom schema files to all other servers to ensure that all schema information is present throughout the topology.