Novell eDirectory 8.5 for All Platforms
Novell eDirectory 8.7 for All Platforms
A Guide to Identifying and Resolving -608 errors
This TID will attempt to make the troubleshooting and repair of -608 errors easier, without having to contact Novell Technical Support.
Once the object has been identified go to NDS iMonitor (or DSBROWSE) selecting the inbound server and the object identified. Write down all the values for the object class attribute, then all the attributes currently on this object. Do the same for the sending server.
Now compare the 2 lists of attributes and classes you have written down. This will give you a list of attributes which have not been synchronized. Verify that the Object class attributes are the same on both objects. If they are not then check the schema on both servers and verify that the class is defined on both servers. This can be achieved by using iMonitor version 2.0 or xbrowse.exe. Any problems here can be corrected by receiving the schema from a server with the correct schema.
If all the used classes are the same on the objects on both sending and receiving server, take the list of the attributes defined on the problem object and verify if the attributes are defined as optional or mandatory attributes on the used Object Classes. Start at the base class and work your way up the Super Class list. Make sure that the attribute is marked off on the list when it is defined on the class. The attributes not present in any of the used classes will be the attribute causing the -608 error.
iMonitor can prove a very efficient tool to determine which attribute is the one that is causing the problem. For more information on how to use it, check out TID 10092294, Troubleshooting -608 errors using iMonitor.
To repair the final scenario first compare the schema to the master of [Root], if there are no differences then establish if this attribute is required on the object. Run a local database repair. DSREPAIR will remove any attribute which is not defined by the classes on the ObjectClass list of the object. If this is a needed attribute and the problem is on a large number of objects the schema will have to be updated. This can be achieved by using Schema Manager, a .SCH file or an LDIF file to make the change.
There are 3 possible causes for this :
1) The object on the receiving server does not contain all the object class attributes the sending server has on the object.
2) The Schema on the receiving server does not have the same class definitions, i.e. there is a mismatch in the number of optional attributes.
3) There is an attribute on the object which may have been valid at some stage but the Schema rules have changed to make this invalid.
Formerly known as TID# 10076447