NFAP and DS version compatibility issues

(Last modified: 14Feb2003)

This document (10070868) is provided subject to the disclaimer at the end of this document.

goal

fact

Native File Access for Windows

Novell eDirectory 8.6 for NetWare 6

Novell NetWare 6.0 sp2

Novell NetWare 6.0

Novell NetWare 5.1 sp5

Novell NetWare 4.11

CIFS

NFAW

NFAP

symptom

Server object goes unknown after installation of NFAW (CIFS).

cause

The following is an excerpt from the TID# 10066591 - Novell eDirectory 8.6 NDS compatibility matrix

If using NDS 6.x or 7.x with eDirectory 8.6 auxiliary classes are associated to objects, objects may show as being unknown (typically showing up as a yellow question mark with a circle in ConsoleOne). The reason for this is the object class attribute on the eDirectory servers adds the value for the auxiliary class and the NDS 6.x or 7.x servers do not have this value, subsequently changing the received object into an unknown class.
The objects could potentially cause confusion and would show unknown classes depending on which server is being queried. Auxiliary class schema extensions successfully install and replicate to NDS 6.x and 7.x servers, however, those servers will see the schema extensions as an unknown object.

Once all NDS 8.x servers are running version 8.78 or higher and all eDirectory 8.5 servers are running 85.23 or higher, eDirectory 8.6 can coexist without problems in any mixed environment as long as they meet the minimum version requirements for eDirectory 8.6 as referenced in TID #10063534.

The first release of NFAW used SYS:ETC\CIFS.CFG to configure and manage CIFS. However, when Support Pack 1 for NetWare 6.0 is installed and CIFS configured there will be an auxiliary class extension added to that servers NCP server object. NFAW makes use of the auxiliary class extension for configuration and management of CIFS via NDS rather than from a config file on the server itself. This can be seen in ConsoleOne:

1. Browse to the server object
2. Right click
3. Choose "Extensions of this object..."
4. A window will pop up containing a list of extensions for the selected object. In the list will be "nfapCIFSConfigInfo". This is the auxiliary class extension
which allows configuration and management through NDS and the ConsoleOne utility.

This works well unless the NDS versions in the tree are incompatible with auxiliary class extensions as outlined in TID# 10066591 - Novell eDirectory 8.6 NDS compatibility matrix. If there are NDS 6.x or 7.x servers in the tree, then the server running CIFS may show as unknown through ConsoleOne. This happens for the reasons outlined in the matrix excerpt above. What actually happens is that ConsoleOne is reading from a replica that does not recognize auxiliary class objects and the server object on that replica will be shown as unknown. When this happens it is impossible to manage the CIFS configuration since in order to do that the properties of the NCP server object must be accessed. If, however, ConsoleOne happens to be reading a replica that does understand auxiliary class extensions then the server object will show as valid and thus will be manageable.

If NetWare 6 has been introduced to an environment also containing NDS 6.x or 7.x servers there may be other objects popping up as unknown as well. This is not an issue specific to NFAP, but with all products using auxiliary class extensions. Under these conditions even the Admin object has shown as unknown due to the addition of the "posixAccount" auxiliary class extension.

fix

Possible Workaround
If eDirectory 8.6 has been introduced into an environment also containing NDS 6.x or 7.x servers (4.11, 5.0, 5.1) there is a workaround available that will allow management of CIFS and the NCP server object. The trick is to ensure that ConsoleOne reads a replica from a server that understands auxiliary class extensions. One way to do this is to create an admin user that will only connect to one NetWare 6 box. That box must hold a real copy of all the partitions in the tree. If the user then is only connected to a box that understands auxiliary class extensions and that box can satisfy every request without referring to any other servers then all objects will show as known and will be manageable. If that box does not hold a real copy of all the partitions in the tree then it is possible that as you drill down through ConsoleOne you may be referred to another server that does hold a real copy of the partition from which information is requested. If that reference server does not understand auxiliary class objects then the objects will show as unknown.
NOTE: This is a suggested workaround and NOT a supported SOLUTION!!

The solution to this problem is NOT to run NDS versions that are incompatible with auxiliary class extensions when running NFAW. Once all NDS 8.x servers are running version 8.78 or higher and all eDirectory 8.5 servers are running 85.23 or higher, eDirectory 8.6 can coexist without problems in any mixed environment as long as they meet the minimum version requirements for eDirectory 8.6 as referenced in TID #10063534. After the DS and OS requirements have been met then CIFS may easily be implemented and managed in the network environment.

NOTE: WHEN RUNNING NFAW DO NOT attempt to run NetWare 6 in the same tree as NetWare 4.11 servers. Although DS will be able to function and synchronize with this configuration NFAW will not, in most cases, be manageable. This configuration, although supported by DS, is not supported by Native File Access for Windows. First upgrade any 4.11 servers to an OS that will run DS 8.78 or above or eDirectory 85.23 or above. Also verify that all DS versions meet the requirements stated above for compatibility. ******This is the ONLY SUPPORTED SOLUTION with NFAW!!

NOTE: Please be aware that this solution has been written in the context of the manageability of Native File Access for Windows and does not reflect on the ablility of DS to function properly in a mixed NW 4.11/NW 6.x environment. According to Directory Services support the following is true, however these statements are specific to DS functionality in a mixed NW 4.11/NW 6.x environment and are not supported configurations in relation to the NFAW product:

* Use the latest DS on NW 4.11 if you want to use Aux Classes in a replica ring where you still have NW 4.11 servers (DS 6.16 and above have code to correct this).

* It is best to avoid using auxiliary classes in a mixed ring, but thanks to the "aux class lie fix" it is possible (check solution TID:10078859 Which DS versions contain the aux class lie fix?)

* When the NW 4.11 servers are just in the tree and don't have replicas with AUX class objects, DS 6.11 should be enough.

* If you've already installed NFAP and are getting side effects because of this, it is possible to remove the extensions added by the NFAP installation. After this the NFAP service will not be available anymore, but it will allow the servers running DS 7.x or 6.x to recognize the former NFAP server as an NCP server again. In order to do this choose the NFAP server object in Console One, right click it, choose the displayed auxiliary class and select "Remove". This will remove the auxiliary class from the object class attribute and all associated attributes.

document

Document Title:	NFAP and DS version compatibility issues
Document ID:	10070868
Solution ID:	NOVL78907
Creation Date:	10May2002
Modified Date:	14Feb2003
Novell Product Class:	NetWare Novell eDirectory

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.