Rebuilding an NDS Schema
Articles and Tips: tip
Senior Software Engineer
Novell, Inc.
01 Jul 2002
Sometimes you need to rebuild your NDS Schema. Below is an explanation of the issues that you may face when you select the "rebuild operational schema" option in the DSREPAIR utility, including information on how to decide whether the operation is appropriate for your situation.
The two main issues with "rebuild operational schema" are:
Flags
Rules changes
You may have done these things to customize your tree schema in order for a third-party application to work "correctly."
By default, when the Rebuild Operational Schema option is selected, the local DIB (Directory Information Base) schema is forced to comply with what the currently-loaded Directory Services knows to be its original schema definitions ( flags, rules, OIDs, boundaries, and so on). Additions to rules are left alone, but the option adds back any removed original rule to the class that is being checked.
If the current flags found in the DIB don't match what the loaded DS believes to be the real definitions, you can change them to comply with it. However, this action may have an undesirable consequence for some of the applications you have installed.
At one point I had changed the DSRepair utility to only check if the original flags and rules are present and leave alone any other flag or rule that may have been added or modified; however, technical support suggested that customers shouldn't do that. I see a benefit for either case, but eventually opted for the DSRepair switch: -anf.
This advanced mode "no flag" check allows DSRepair to rebuild the operational schema without modifying any flags that may have been changed by customers or their specific applications.
I only addressed flags because at the time there were few simple choices to allow removing or putting flags back into schema attributes/classes. But you can now use schema editors to add or remove rules without much effort, so no switch was provided for those type of changes.
In essence Novell wanted to give customers the flexibility to make educated changes, while still giving you the option to fix your trees if such modifications were to cause problems. However, we have indiscriminately advised customers to rebuild operational schema as if no one but Novell depended on it, and it is a practice that should stop.
There is an educated way of deciding whether or not you should use the anf option if you are unsure of the results. In the Local database repair, you can deselect everything but the following:
"Use temporary NDS database during repair?= YES"
"Rebuild operational schema?=YES"
You will then see what changes DSRepair is planning to do to that DIB set and you have the option to accept the changes or not. Using iMonitor/DSBrowse, you can then check the proposed changes to see if they would indeed affect working applications on your servers and decide whether or not you should save the changes.
This check is a quick one, and should be part of any TIDs that suggest running the Rebuild Operational Schema option. This easy check may prevent Novell technical support engineers from having to figure out what in the world happened to your applications when they stop working correctly.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.