Schema Problems

     

Schema problems are not very common in an NDS/eDirectory tree. However, they do pop up once in a while, just to keep things interesting. The most common source of schema issues is schema synchronization problems between servers. The other has to do with trying to merge two DS trees into one. The following sections look at each of these problems.

Schema Synchronization Problems

Before discussing schema issues, let's first review what a DS schema is and how it may affect the network. The directory schema is the rules that define how the directory tree is constructed . The schema defines specific types of information that dictate the way information is stored in the DS database. The following is some of the information defined by the schema:

• Attribute information ” Describes what type of additional information an object can or must have associated with it. Attribute types are defined within the schema by specific constraints and specific syntaxes for their values.

• Inheritance ” Determines which objects inherit the properties and rights of other objects.

• Naming ” Determines the structure of the NDS tree, thus identifying and showing an object's reference name within DS.

• Subordination ” Determines the location of objects in the directory tree, thus identifying and showing an object's location in the directory tree.

The foundation for all entries in a DS database is a set of defined object classes referred to as the base schema . Object classes such as NCP Server , User , and Print Server are some of the base object classes defined by the base schema. For a complete list of the base object classes and attribute definitions, see Appendix C, "eDirectory Classes, Objects, and Attributes."

The DS schema can be modified and expanded to suit the specific needs of an organization. Object class definitions can be added to and modified for the existing base schema. Such additions are called schema extensions .

There are generally two types of problems associated with a schema: those that are DS rights related and those that are timing related (such as needing to wait for schema synchronization to complete between servers). DS rights- related problems are easy to understand and address. In order to extend the DS schema, you must have Supervisor rights to the [Root] object; without Supervisor rights, you are unable to make the changes. The timing-related problem requires some explaining. In large trees where schema extensions can take extended periods of time to be propagated to all servers, the very first installation attempt of an application, such as GroupWise, that requires schema extension may fail a number of times before a successful installation takes place.

As an example, let's assume that one application creates two custom DS objects during the installation process. During the first installation attempt, the application's installation routine attempts to create a new DS object by using an extended class. DS reports that this object class and the needed attributes do not exist in the schema, and the setup program adds them to the schema by using the server that is hosting the Master replica of [Root] . The installation then fails because the extension has not yet reached the server on which the object is to be created. Later (possibly 15 minutes or more in very large trees), the administrator attempts to install again. This time the installation finds the first needed object class but not the second one; therefore, the schema is once more extended, but the setup program fails again because the second class extension is not found on the target server. Later, a third installation is successful because all the necessary class extensions are already in the schema.

NOTE

A DS schema is global. Each server stores a replica of the schema in its entirety. The schema data is stored separately from the partitions that contain directory objects. (See Chapter 2, "eDirectory Basics," for more information about replica types.) You can perform modifications to the schema only through a server that stores the Master replica of [Root] . You need to have Supervisor rights to the [Root] object in order to modify the schema.

If it becomes apparent that DS had not yet propagated the schema extensions to the other servers in the tree, you can help speed up the process. From the console of the server that is holding the Master replica of [Root] , you issue the following commands:

 SET DSTRACE = ON SET DSTRACE = +SCHEMA SET DSTRACE = *SSA SET DSTRACE = *H 

(On Windows servers, the equivalent of using SET DSTRACE=*SSA is clicking the Schema Sync button on the Triggers tab located in the DS.DLM configuration screen.)

TIP

You can use the Schema Compare feature in NDS iMonitor to check whether the schema extension has propagated to the server on which you are installing the application. In NDS iMonitor, you select the Schema link, select to view the base class definitions, and then select the two servers whose schemas you want to compare (see Figure 11.10). Then you repeat the procedure to check the attribute definitions.

Figure 11.10. Comparing schemas between two servers.

Setting DSTrace in this way forces the server to immediately start an outbound schema synchronization process. You need to switch to the DSTrace screen and wait for the message SCHEMA: All Processed = Yes ; this may take several minutes, depending on the number of servers in the network and link speeds. If DSTrace says SCHEMA: All Processed = No , there are most likely other issues preventing the synchronization from completing.

If the setup program crashed in the middle of extending the schema, you might need to start over with a clean installation. The only way to verify a clean installation and extension on the DS base schema is to completely remove all extended class objects (related to the application you're trying to install) and re-extend the schema. You can use the following procedure to accomplish this:

1. Log out of all servers except the one you are installing the application onto.
   
   
2. Delete all related extended schema objects by using ConsoleOne and then remove all related file directories from the server volumes .
   
   
3. Use Schema Manager to delete all related extended schema class objects. If they do not all delete, verify that you are logged in to only one server.
   
   
4. Reinstall the application. During the installation, the application should notice that the schema is not properly extended and reextend the schema.
   
   

NOTE

There are some known schema synchronization issues that occur in mixed NetWare 5/6 and NetWare 4.x environments if the DS.NLM on the NetWare 4.x servers are not fully up-to-date. Refer to TID #10015538 for details. The latest DS.NLM for NetWare 4.x can be found at Novell's support Web site.

Schema Mismatch During a Tree Merge

With the increasing number of applications that leverage NDS/eDirectory for user authentication and storage of global configuration information, it is not uncommon to encounter schema mismatch errors when you're trying to merge two trees into one. In order to merge two NDS/eDirectory trees, the schema definitions used by both trees must be identical, down to every attribute definition ”including any flags (such as Immediate Sync ) and value bounds associated with an attribute.

The typical cause of schema mismatch is that different DS-aware applications are installed on the two trees. For instance, one tree might have GroupWise and ZENworks installed but the other tree has only GroupWise. Therefore, the second tree does not have the schema extension for ZENworks, and a tree merge fails as a result of this mismatch. There are two ways you can make the schema on the two trees identical. The first method is to simply extend the schema of the tree that is missing the necessary schema information by installing the required applications. This approach is generally successful in 90% of cases.

However, there are instances in which the software license may prohibit you from installing the second copy on a separate tree, even if you are not going to be running the application at all. There can also be situations in which you are unsure what application made which schema extension or in which there are a large number of applications involved. This is where importing schema information by using DSRepair comes in handy. The following steps outline the procedure for doing this:

1. Ensure that you are running the latest DS and the latest DSRepair modules.
   
   
2. Load DSRepair on the server that holds the Master replica of [Root] .
   
   
3. Select the Post NetWare 5 Schema Updates operation from the Advanced Options menu and then select Optional Schema Enhancements (see Figure 11.11). Both of these options are located under Global Schema Operations). In Linux/Unix, use ndsrepair -S -Ad ; in Windows, select the Schema menu.
   
   

   Figure 11.11. Global schema options.

   

   
   
4. Select Import Remote Schema from the menu (in the Linux/Unix platform, the option is called Import Schema from Tree) and select the desired tree to import the schema from. This process imports any schema definitions found in the remote tree that are not defined locally. Figure 11.12 shows a DSRepair log file of the import results.
   
   

   Figure 11.12. DirXML and other schema definitions being imported from the remote tree.

   
   

TIP

To verify that a schema is the same between both trees, you should perform the schema import three times ”first from source to target, second from target to source, and finally, from source to target ”or until no modifications are being made during the schema imports.

If you encounter "Error: -699 An unrecoverable error has occurred and the operation cannot be completed," chances are good that the syntax for one or more attribute definitions in the source tree and the target tree are different. For example, the old NetWare Web Server product creates an attribute called photo (to be associated with User objects) and uses SYN_STREAM as the value syntax. However, NetWare 6 and higher change this attribute to SYN_OCTET_STRING . Therefore, when you try to synchronize schemas between a NetWare 5 tree that was extended with the NetWare Web Server product and a NetWare 6.5 tree, you will encounter this -699 error. You can use one of the schema compare methods discussed later in this section to see whether this -699 error is due to the photo , pager , or rbsPageMembership attributes. If it is, you should refer to TID #10066345 for possible solutions. Otherwise, a call to Novell is warranted.

There may be rare cases in which a merge still fails with a schema mismatch error after you synchronize a schema between two trees. This could be a result of some class or attribute definitions in one tree not being the same as those found in the other tree. For instance, in one tree the attribute cellPhone may be defined with the DS_SYNC_IMMEDIATE_ATTR flag, but in the other tree the same attribute may not include this flag. You need to get Novell involved to have one of these definitions changed before you can merge the trees. However, it would be nice to know how many classes and attributes are involved before you open an incident.

If a merge still fails with a schema mismatch error after you synchronize a schema between two trees, you cannot use the Schema Compare feature in NDS iMonitor because it does not work across trees. You could, however, export the schema information to a file by using LDAP:

 ldapsearch -h  host  -D  admin_id  -w  password  -b cn=schema -s base objectclass=subschema >   filename  

and then use a text-compare utility to compare the two files for differences. Alternatively, you could use the two utilities mentioned in Appendix C, ReadClass32.EXE and ReadAttr32.EXE , to export the class and attribute definitions and then compare the output files for differences. However, the easiest method is to use Novell's Schema Compare utility, Schcmp (see www.novell.com/coolsolutions/tools/1509.html).

To use Schcmp to compare schemas between two trees, you first authenticate to both trees and then use the following command to create a text file that you can later examine by using a text editor:

 schcmp  server_in_tree1 server_in_tree2  > schema.txt 

Although it is not a requirement, it is best if you select the servers holding the Master of [Root] for the schema comparison. The following is an excerpt from Schcmp's output:

 Comparing NETWARE_51 with DREAMLAN6A... Classes unique to NETWARE_51      3x Computer System Policy      95 Client Config Policy      ... Classes unique to DREAMLAN6A      bhGadget      bhPortal      ... Attributes unique to NETWARE_51      App:Administrator Notes      App:Alt Back Link      ... Attributes unique to DREAMLAN6A      bhArguments      bhClassName      ... Syntaxes unique to NETWARE_51      NONE Syntaxes unique to DREAMLAN6A      NONE Definition differences for NETWARE_51 Class Definitions Country      Optional Attributes           App:Associations           App:Launcher Config           ... Definition differences for DREAMLAN6A Class Definitions domain      Super Class           ndsContainerLoginProperties           ndsLoginProperties           ...