Guidelines for Running NetWare 5.0 Servers in a Mixed NetWare 5, and NetWare 4 Tree

NetWare 5.0 introduces many new features in NDS. It is backward compatible with NetWare 4.11, however to take full advantage of the new features in NetWare 5.0, NetWare 4.11 servers need to be upgraded to DS.NLM version 5.99 or later. In addition to the upgrade you may need to run a new version of DSRepair.NLM.

Document Content:

    1. The changes included in DS.NLM v5.99
    2. Implementation Guidelines for DS.NLM v5.99
    3. Changes made in DSRepair.NLM v4.56
    4. Suggestions for Rapid, and successful deployment of DS.NLM v5.99

    Changes in DS.NLM version 5.99

There are four main issues fixed in NDS 4.11 update v5.99.

    1. Running DS v5.99 and the new Reset Schema option in DSRepair v4.56 can fix these problems. (See Implementation Guidelines.)

    2. ACL inheritance. A new feature in NetWare 5.0 is the ability to have specific attribute ACLs now be inheritable. This is new behavior that will be masked from inheriting if the inheritance path includes a server running any DS version prior to 5.99. Note that 5.99 will not act upon these inheritable ACLs, but it will allow them to properly flow through to a NetWare 5.0 server holding replica(s) subordinate to the replica(s) on the NetWare 4.11 server. Without 5.99, you may get inconsistent results when evaluating rights on NetWare 5.0 servers that rely on this new feature.

    3. Restoring an object reference on a NetWare 5.0 server. Another issue addressed in DS v5.99 is when you are restoring an object reference on a NetWare 5.0 server that requires the referenced object to also be restored. If the referenced object resides on a NetWare 4.11 server that is not running v5.99, the reference object will not be created properly, and may cause collisions.

        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.11 servers, none of which are running 5.99.

        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.

    4. Synchronizing new NetWare 5 schema additions from one NetWare 4.11 server to another NetWare 4.11 server. DS v5.99 addresses a problem with schema synchronization when attempting to synchronize the new NetWare 5 schema additions from one NetWare 4.11 server to another NetWare 4.11 server. In NetWare 5 a new Tree Root dependancy was added to the schema. This new schema is synchronized correctly from a NetWare 5 server to a NetWare 4.11 server, but the NetWare 4.11 server does not pass the same new schema on to other NetWare 4.11 servers correctly.

    NDS v5.99 Implementation Guidelines

It is recommended that users running NetWare 5.0 in a NetWare 4.11 tree upgrade all NetWare 4.11 servers to DS v5.99. This will ensure that the issues described previously will be addressed.

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

    1. Any server without a replica, must be upgraded to DS v 5.99. 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.99 installed.

        Optional: After upgrading to DS v5.99, run the Reset Schema option found in the -a (advanced features menu) of DSRepair v4.56. 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.99.

        "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.99 or later
        (3) Run the "Reset Schema" option in DSRepair v4.56 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.0 server, must be upgraded to DS v 5.99. 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.0. 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.0 servers only.)
        (2) Install DS v5.99 on any NetWare 4.11 servers that lie in the path between NetWare 5.0 servers. This will ensure that ACL rights flow down to the NetWare 5.0 servers.

        To demonstrate this, consider a tree structured like figure 1 below.

(a) If you want the subtree consisting of partitions H, I, and J to utilize inherited ACLs, all the servers holding replicas of H, I, and J should be upgraded to NetWare 5.0. (Figure 2 above.)

(b) If you then decide to use inherited ACLs in the subtree consisting of partitions B, D, & E, and want those ACLs to flow down to the other NetWare 5.0 servers, in addition to upgrading all servers holding replicas of B, D, and E to NetWare 5.0, you must upgrade all NetWare 4.11 servers holding a replica of F to DS v5.99. This will ensure that the ACLs can flow down the tree. (Figure 3 above.)

Note: Even with DS v5.99 installed, F will not act upon the inherited ACLs because the servers holding replicas are NetWare 4.11. DS v5.99 is necessary for the ACLs to flow to the NetWare 5.0 servers below.
4. Any NetWare 4.11 server on which an object referenced by a NetWare 5.0 server will be restored, must be upgraded to DS v 5.99. This is to address the DS issue of restoring an object reference on a NetWare 5.0 server.
 

    Changes in DSRepair.NLM version 4.56

There are two main issues relating to NetWare 5.0 fixed in DSRepair v4.56

1. Added Reset Schema Option. The main change in DSRepair.NLM v4.56 related to NetWare 5.0 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.99 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.0 Servers. When previous versions of DSRepair for NetWare 4.11 are run, they incorrectly report that NetWare 5.0 servers "are not NDS servers". DSRepair v4.56 reports the correct information.

    Suggestions for Rapid and Successful Deployment of DS.NLM v5.99

For the easiest and fastest deployment of the new DS, the NDSManager utility is recommended. NDSManager detects the version of DS running on each server, and allows the user to copy the new DS as well as Rollcall.NLM to each specified server from a single point of contact. (See TID#2938530)