Guidelines for Running NetWare 5 Servers in a Mixed NetWare 5 and NetWare 4.10 / 4.11 Tree

  • 10015538
  • 4.0.44616659.2301567
  • 01-Sep-1999
  • 10-Sep-2003

Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.


Guidelines for Running NetWare 5 Servers in a Mixed NetWare 5 and NetWare 4.10 / 4.11 Tree


Novell NetWare 4.11

Novell NetWare 5.0

Novell Directory Services

Formerly KB 2943193


NetWare 5 servers introduced enhancements to the  NDS schema that previous versions of NDS for 4.1x do not understand.  This issue is addressed by updating 4.x the latest version of NDS prior to introducing NetWare 5 into the network.

NDS version 6.09 or later (NetWare 4.11) and 5.18 or later (NetWare 410) these are available on Novell's Minimum Patch List. The necessity of updating NDS is noted in NetWare 5's online and printed documentation, in the readme file and in several locations on our web site. In addition, Novell has notified the sales force and channel of the issue.

However, it has more recently been learned that if a new epoch on the schema is declared while a reset schema has been scheduled, the schema could potentially become corrupt.  (Note:  This problem could also happen in a straight NetWare 4.x environment.) To resolve this issue, Novell recommends applying DS v5.18 and DS v6.09 to all 4.10 and 4.11 servers respectively.  These updates have been tested by Novell and have just completed the testing cycle. This means that before declared official, any NDS update must be on Novell's corporate tree, and used by over 100 customers to ensure its quality. NDS version 5.18 and 6.09 have just completed this process, and are now available at in the following files: DS410Q.EXE and NW4SP9.EXE (the latest Support Pack for NetWare 4.11) has the lastest DS.NLM for 4.11.

General and complete guidelines for installing NetWare 5 in a 4.x tree are listed below:

Before installing a 5.0 server  into an existing 4.10 / 4.11 tree, three things must be verified :

1.  All NetWare 4.10 servers have 5.18 or higher.
2.  All NetWare 4.11 servers have 6.09 or higher.
3.  All NetWare 4.10 / 4.11 servers must have DSRepair v 4.59 (or higher).

Note:  If the NDS tree that was originally installed using NetWare versions 4.0 or 4.01 you should run "Repair local DS database" option under "Advanced options menu" with DSRepair v4.59 or greater on a NetWare 4.1x server holding the Master or a R/W of [Root].

This DSRepair addresses schema definitions that may not have been properly time-stamped if your tree began life with a NetWare 4.0 or NetWare 4.01 server. With the introduction of newer versions of DS, this could cause possible corruption with the Backlink attribute.

If your tree did not start out with a NetWare 4.0 or NetWare 4.01 server, it is not necessary to run this. If you are unsure at what version the tree started out, then we recommend running DSRepair on the Master or a R/W of [Root].

NetWare 5.0 servers introduce new schema extensions and containment rules into the tree that previous versions of DS for 4.1X do not understand.  To address these concerns there are three main issues fixed in NDS 4.10 (v5.17) and NDS 4.11 (v6.03) and DSrepair 4.59.

1.  Deletion of Schema (both classes and attributes).  Because of issues with schema synchronization, most, if not all, schema deletes will not correctly synchronize to NetWare 4.10 / 4.11 servers without replicas.  This is not particularly bad in most instances, because it just  means that some items are defined in the schema that are not being used, but the schema in that tree is technically out of sync.

Running DS v5.18 / DS v6.09 and the new Reset Schema option in DSRepair v4.59 will fix these problems.

2.   Restoring an object reference on a NetWare 5 server.  Another issue addressed in DS v5.18 / DS v6.09 is when you are restoring an object reference on a NetWare 5 server that requires the referenced object to also be restored.  If the referenced object resides on a NetWare 4.10 / 4.11 server that is not running v5.15 / v6.02, the reference object will not be created properly.
Consider the following example:    
(1)  The object Group1.Dept1.Company (an object with many member attributes) is restored.
(2)  Group1 has a member attribute Member1.Dept2.Company.
(3)  Member1 does not currently exist in the tree, and all replicas of Dept2.Company exist only on  NetWare   4.10 / 4.11 servers, none of which are running DS v5.18 / DS v6.09.

The result could be one of the following:
(1)  The object Member1.Dept2.Company  cannot be created correctly.
(2)  The restore will fail.
(3)  The restore will not fail but the group member Member1.Dept2.Company will not be created.

3.   Synchronizing new NetWare 5 schema additions from one NetWare 4.10 / 4.11 server to another NetWare 4.10 / 4.11 server.  DS v5.17 / DS v6.03 addresses a problem with schema synchronization when attempting to synchronize the new NetWare 5 schema additions from one NetWare 4.10 / 4.11 server to another NetWare 4.10 / 4.11 server.  In NetWare 5 a new Tree Root dependency was added to the schema.  This new schema is synchronized correctly from a NetWare 5 server to a NetWare 4.10 / 4.11 server, but the NetWare 4.10 / 4.11 server (prior to DS v5.17 / DS v6.03) does not pass the same new schema on to other NetWare 4.10 / 4.11 servers correctly.

DS v5.17 / v6.03 Suggested Guidelines

Even though these issues are rare it is recommended that users running NetWare 5 in a NetWare 4.10 / 4.11 tree upgrade all NetWare 4.10 servers to DS v5.18 and all NetWare 4.11 servers to DS v6.09.  This will ensure that the issues described previously will be addressed.  Note: Novell has implemented DS v5.17 / DS v6.03 throughout its own mixed tree of 4.10 / 4.11 and NetWare5 servers.

If this is not feasible, use the following minimum guidelines for upgrading selected NetWare 4.10 /4.11
servers to DS v 5.18 / DS v.6.09

1.  Any server without a replica, must be upgraded to DS v 5.15 / DS v 6.02. This is to address the deletion of schema issue.  

Note: Any servers which did not have a replica at one time, and then later received a replica, may have inconsistent schema from deletions which occurred before adding the replica.  These servers should also have DS v.5.15 / DS v.602 installed.

Optional: After upgrading to DS v5.15 / DS v6.02, run the Reset Schema option of DSRepair v4.59.  This will clean up any previously existing inconsistencies.  

2.   Any servers receiving the following NLS error on the server console, must be upgraded to DS v 5.15 / DS v6.02.

"Novell Licensing Services (NLS):  An older NLS schema extension has been detected.  If you have not converted your old licensing data, you may do so by running SETUPNLS.NLM."

If this message is displayed on the server, do the following:
(1)  Run SETUPNLS.NLM on the server.  If the message is still displayed, continue with step 2.
(2)  Upgrade the server to DS.NLM v5.15 / v6.02 or later
(3)  Run the "Reset Schema" option in DSRepair v4.59 or later on the server where the error is being       displayed.  This will update the schema, removing the old attribute.
3.   Any server in the same replica ring as a NetWare 5 server, must be upgraded to DS v5.15 / DS v6.02.  This will ensure that the synchronization of the inherited ACLs is consistent.  This should be done regardless of whether or not you are utilizing the inherited ACL feature.

If you plan to utilize the inherited ACL feature, use the following guidelines:
(1)  For inherited ACLs to be consistent, all servers in the replica ring must be upgraded to NetWare 5.  This will ensure that no matter what server in the ring a user attaches to, the inherited rights will be available.  (Remember that inherited ACL is a feature of NetWare 5 servers only.)

(2)  Install DS v5.15 / v6.02 on any NetWare 4.10 / 4.11 servers that lie in the path between NetWare 5 servers.  This will ensure that ACL rights flow down to the NetWare 5 servers.

4.   Any NetWare 4.10 / 4.11 server on which an object referenced by a NetWare 5 server will be restored, must be upgraded to DS v 5.15 / DS v6.02.  This is to address the DS issue of restoring an object reference on a NetWare 5 server.  
Changes in DSRepair.NLM version 4.59
There are two main issues relating to NetWare 5 fixed in DSRepair v4.59

1.   Added Reset Schema Option.  The main change in DSRepair.NLM v4.59 related to NetWare 5 is the addition of a new function called "Reset Schema".  This function will reset the schema on non-master [root] servers.  It requires DS v5.15 / DS v6.02 and above of DS.NLM to work.  This change was added to clean up any schema objects which were not deleted from servers without replicas.

2.  Incorrectly Reporting on NetWare 5 Servers.  When previous versions of DSRepair for NetWare 4.10 / 4.11 are run, they incorrectly report that NetWare 5 servers "are not NDS servers".  DSRepair v4.59 reports the correct information.

Implementation Guidelines

A convenient way to verify all servers' DS.NLM version is to use DSDIAG.NLM.  DSDIAG.NLM can be found on Novell's Support Connection for 4.1X servers. (DSDIAG.NLM is shipped with NetWare 5.0)
To verify all DS Versions, do the following :

STEP 2:  Select "Preferences"

STEP 3 : Select "Manage Naming Conventions."  Go down to "INPUT CONTEXT" and edit the "BASE DN" field.  Enter in ONLY the delimiter you're using. If you're using the "."  DOT delimiter, enter ".+."  If you're using the "\" slash delimiter, enter in "\".  Leave everything else at the default.  When finished, press F10, then "Return To Previous Menu.".  

STEP 4:  Select "Manage Identities."  PUBLIC is the default identity.  If PUBLIC has Object Browse rights and Read and Compare property rights on the ROOT object, you're OK.  If public does not have these rights, you will have to login as a user that has sufficient rights to walk and browse the tree.  

If you decide to assign PUBLIC these mentioned rights, do so just for the DSDIAG report then remove the rights.  Don't leave PUBLIC permanently with those rights because there could be discrepancies with future object creations that depend on the inheritance of PUBLIC and if PUBLIC is removed, their inheritance dependencies may be put in jeopardy.  The scope of this document is not object rights so the discrepancies will not be described nor explained.

Instead of using PUBLIC you can press the "INS" key and login with a user that has the appropriate rights.  If the delimiter being used is "\"  then you'll have to login with the Canonical syntax, \TREENAME\O \ OU\ OU\......\User.  An example is \NOVELL_INC\NOVELL\NTS\ADMIN.  The tree is NOVELL_INC, the O=NOVELL, an OU=NTS, and the user.

If the default delimiter is "." or DOT then login using the dot notation :  ".USER.OU.OU....O.TREE." , or ".ADMIN.NTS.NOVELL.NOVELL_INC.".

STEP 5 : Select "Generate Report" then choose "Check NDS Versions."  

STEP 6 : Select NDS for "Retrieve Server List Using NDS."  For every server object in the tree there is a "DS REVISION" attribute.  Selecting this option will use NDS to find the revision instead of needing to contact the actual server.

STEP 7 : Enter in "\TREENAME" or ".TREENAME." depending on the delimiter being used, for the Search Context.

STEP 8 : Leave "Type" at "Readable"

STEP 9 : Leave "Depth" at "SubTree"

STEP 10 : Press "Enter" on "Report File" the press "Enter" again.

STEP 11 : This screen will let you modify the file that the report will be written to.  When done, press F10, then F10 again to run the report.

Let the report finish.  The file you specified in STEP 11 will show ALL servers in the tree with their accompanying DS VERSIONS.  .