Unable to target desired volume as host volume for NDPS Manager.
(Last modified: 21Oct2003)
This document (10027003) is provided subject to the disclaimer at the end of this document.
fact
Novell NetWare 5.1
Novell NetWare 5.0
Novell NetWare Clustering Services 1.0
Novell NetWare Clustering Services 1.01
Novell Distributed Print Services (NDPS) 2.0
Novell Distributed Print Services (NDPS) 2.1.1
symptom
Unable to target desired volume as host volume for NDPS Manager.
Unable to target cluster volume as host volume for NDPS Manager.
Desired volume does not appear in list of possible host volumes when creating NDPS Manager object.
Cluster volume does not appear in list of possible host volumes when creating NDPS Manager object.
Desired volume does not appear in list of possible host volumes when moving NDPS database from one server to another.
fix
Create the NDPS manager using iManager instead of using NWAdmin. iManager does not rely on a physical connection between server and volume. Alternatively, you can repair/ establish the link between server and volume, and use NWAdmin to create the NDPS Manager, as described in the fix below.
The volume object/name on which you intend to host an NDPS Manager will sometimes fail to be displayed within the dialog from which you must choose. This occurs when there is not an established link between the physical volume and the NDS object for that volume. It can be somewhat more likely for this condition to occur in conjunction with NetWare Clustering Services (NCS) and a cluster-enabled volume, but is not specific or limited to that configuration.
TO RESOLVE THIS PROBLEM IN A NATIVE NETWARE ENVIRONMENT, perform the following steps:
1. Ensure that the volume in question is actually mounted at the NetWare server.
2. From the server where the physical volume is mounted, use NWCONFIG.NLM | 'Directory Options' | 'Upgrade mounted volumes into the Directory'. For any volume that a properly linked NDS volume object doesn't already exist, NWCONFIG will create and link an NDS volume object using the default naming convention of 'servername_volumename.context', e.g. 'FS1_NSSVOL.PROVO.NOVELL'.
3. If trying to create a new NDPS Manager, from within NWADMN32 create a new NDPS Manager object. In the 'Resident Server' entry on the 'Create NDPS Manager Object' dialog select the NetWare server to host the NDPS Manager. The 'Database Volume' entry on the 'Create NDPS Manager Object' dialog should now show the NDS volume object just created and allows that volume as a possible host volume.
4. If trying to move the NDPS Manager from one NetWare server to another, after performing step two the volume should show in the list of possible volumes when loading NDPSM.NLM on the target server.
TO RESOLVE THIS PROBLEM IN AN NCS ENVIRONMENT with a cluster-enabled volume that has already been created and configured, perform the following steps:
1. Determine which of the NetWare servers running as cluster nodes currently has the cluster-enabled volume mounted, or migrate the cluster volume to a specific known node using the 'Cluster View' of the cluster in ConsoleOne.
2. During a non-production window or other time at which users or applications will not be looking for the cluster-enabled volume object in NDS, from within NWADMN32 or ConsoleOne temporarily rename the cluster-enabled volume object (i.e. 'clustername_volumename.context', e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL') back to the standard name format of 'servername_volumename.context', e.g. 'FS1_NSSVOL.PROVO.NOVELL'. Do not delete the volume object; use only the Object | Rename command from within NWADMN32 or ConsoleOne.
3. Once the cluster-enabled volume object has been renamed to the format of 'servername_volumename.context' using the name of the NetWare server which currently has the cluster-enabled volume mounted, use DSREPAIR.NLM | "Advanced options menu" | "Check volume objects and trustees" to have DSREPAIR check for a valid NDS volume object link to the currently mounted local physical volumes. The DSREPAIR.LOG should cite that DSREPAIR either found the local volume to be properly linked to this NDS volume object, or that DSREPAIR found the temporarily renamed volume object in NDS and re-linked it to the physical volume. See the description of what should appear in the DSREPAIR log later in this document.
4. After the "Check volume objects and trustees" process has completed and verifying the DSREPAIR.LOG shows a proper link was detected or established, in NWADMN32 or ConsoleOne rename the cluster-enabled volume object back to it's cluster-defined name in the format of 'clustername_volumename.context' (e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL').
5. From a Windows workstation where NWADMN32 is running, use Windows Explorer or Network Neighborhood to browse NDS and browse to the contents of the cluster-enabled volume object. It's important to actually browse NDS and locate the cluster-enabled volume object to browse the contents, i.e. 'clustername_volumename.context', e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL'. After browsing the content of the cluster-enabled volume object, using the 'NetWare Connections' function when right-clicking on Network Neighborhood should show a connection to the virtual NetWare server for the cluster-enabled volume that was browsed, i.e. 'clustername_volumename_SERVER', e.g. 'CLUSTER_NSSVOL_SERVER'. It is important that the workstation establish a connection to this virtual server prior to proceeding with the next step.
6. Now from within NWADMN32, create a new NDPS Manager object. When selecting the NetWare server to host the NDPS Manager using the 'Resident Server' entry on the 'Create NDPS Manager Object' dialog, select the NDS server object for the virtual NetWare server for the cluster-enabled volume on which you intend to host the NDPS Manager. i.e. 'clustername_volumename_SERVER.context', e.g. 'CLUSTER_NSSVOL_SERVER.PROVO.NOVELL'. As indicated by the example context, this NDS server object exists in the same context as the cluster-enabled NDS volume object does.
7. Once you have targeted the NDS server object for the virtual NetWare server, the 'Database Volume' entry on the 'Create NDPS Manager Object' dialog will now show all NDS volume objects that are properly linked to physical volumes on the specified 'Resident Server'. The cluster-enabled NDS volume object named in the format 'clustername_volumename.context' (e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL') should now appear in the list of volumes which can be targeted.
TO PREVENT THIS PROBLEM FROM OCCURRING IN AN NCS ENVIRONMENT when creating and cluster-enabling a new volume where you intend to host an NDPS Manager, perform the following steps:
1. Prior to cluster-enabling a newly-created volume, ensure that the NDS volume object is properly linked to the physical volume on the NetWare server. From the NetWare server where the volume is mounted run DSREPAIR.NLM | "Advanced options menu" | "Check volume objects and trustees" to have DSREPAIR check for a valid NDS volume object link to the currently mounted local physical volumes. The DSREPAIR.LOG should cite that DSREPAIR either found the local volume to be properly linked to this NDS volume object, or that DSREPAIR found or created an unlinked volume object in NDS and re-linked it to the physical volume. See the description of what should appear in the DSREPAIR log later in this document.
2. Now take the properly linked NDS volume object and cluster-enable that volume. During the process of turning the volume into a cluster-enabled volume the NDS volume object will be renamed, but renaming does not break the proper link between the NDS volume object and the physical volume.
3. From this point on, do not allow the cluster-enabled volume to be migrated or mounted at any other node in the cluster until you have completed the remaining steps. Migrating or failing the volume over to another node in the cluster will break the link between the NDS volume object and the physical volume.
4. From a Windows workstation where NWADMN32 is running, use Windows Explorer or Network Neighborhood to browse NDS and browse to the contents of the cluster-enabled volume object. It's important to actually browse NDS and locate the cluster-enabled volume object to browse the contents, i.e. 'clustername_volumename.context', e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL'. After browsing the content of the cluster-enabled volume object, using the 'NetWare Connections' function when right-clicking on Network Neighborhood should show a connection to the virtual NetWare server for the cluster-enabled volume that was browsed, i.e. 'clustername_volumename_SERVER', e.g. 'CLUSTER_NSSVOL_SERVER'. It is important that the workstation establish a connection to this virtual server prior to proceeding with the next step.
5. Now from within NWADMN32, create a new NDPS Manager object. When selecting the NetWare server to host the NDPS Manager using the 'Resident Server' entry on the 'Create NDPS Manager Object' dialog, select the NDS server object for the virtual NetWare server for the cluster-enabled volume on which you intend to host the NDPS Manager. i.e. 'clustername_volumename_SERVER.context', e.g. 'CLUSTER_NSSVOL_SERVER.PROVO.NOVELL'. As indicated by the example context, this NDS server object exists in the same context as the cluster-enabled NDS volume object does.
6. Once you have targeted the NDS server object for the virtual NetWare server, the 'Database Volume' entry on the 'Create NDPS Manager Object' dialog will now show all NDS volume objects that are properly linked to physical volumes on the specified 'Resident Server'. Because in this process you ensured that the NDS volume object was properly linked prior to cluster-enabling the volume, the NDS volume object shown in the 'Database Volume' entry should be the cluster-enabled NDS volume object name in the format 'clustername_volumename.context', e.g. 'CLUSTER_NSSVOL.PROVO.NOVELL'.
7. If at this point you are unable to see the cluster-enabled NDS volume object on which you intend to host the NDPS Manager, then some step within the specified process has failed. To correct this condition, follow the process entitled "TO RESOLVE THIS PROBLEM IN AN NCS ENVIRONMENT" described elsewhere in this document.
Background:
Normally, when a volume object is created in NDS using NWCONFIG or the NetWare installation process, the object ID for the NDS volume object is written to the physical volume. Applications requesting the extended volume attributes of the physical volume can use this object ID to reference the corresponding volume object in NDS.
This link between the physical volume and volume object in NDS doesn't exist when a volume object gets manually created in NDS (for example in NWADMN32), or if NDS was having problems at the time the volume object was created via NWCONFIG. It can also be broken if the object ID written to the volume isn't valid for the server where the physical volume is mounted. NDS object IDs are server-centric, meaning the ID for a single object will be different depending on the server being queried.
In an NCS environment, it is not uncommon for the object ID on the physical volume to be incorrect for the server where the drive is physically mounted, since the volume may be mounted at any one of multiple servers in the cluster. The object ID that was written to the physical volume is only correct for one of the servers in the cluster, the server where the volume was mounted when the volume object ID was written to the physical volume.
Tools such as DSREPAIR.NLM and NWCONFIG.NLM only deal with volume objects which match the default naming convention of 'servername_volumename.context', e.g. 'FS1_NSSVOL.PROVO.NOVELL'. As such, before these tools can be used to correct the link between the physical volume and NDS volume object in an NCS environment, the desired volume object to link to must be renamed to match this name format before the repair or verification process is used.
The NDPS management snap-in for NWADMN32 uses an inherently server-centric mechanism when deciding which server volumes should be displayed as potential targets for the creation of an NDPS Manager. During the creation of an NDPS Manager object you must select a host server and then the snap-in will show a list of the volumes mounted at that server. If the extended volume attributes for a volume mounted at the server doesn't have a valid volume object ID, that volume will be omitted from the list of possible volumes on which to host the NDPS Manager.
Novell is looking into methods to make the NDPS Manager object creation more friendly to the NCS environment and in general to situations where the link between the NDS volume object and the physical volume has been lost. Currently the NDPS snap-in support in NWADMN32 behaves as described above, and the processes outlined within this solution will have to be used in order to re-establish the link between an NDS volume object and the physical volume until a better solution is available.
DSREPAIR examples:
DSREPAIR checks each locally mounted volume for whether an NDS volume object is already properly linked to the local physical volume by reading an "Object ID" from the physical volume. If this object ID is set to 0x00000000, then the volume has never had an object linked to it. If this object ID is set to a value, then DSREPAIR attempts to locate that object ID in NDS. If the specified object ID cannot be found or the value was still uninitialized, DSREPAIR will create an NDS volume object in the server's context (if it doesn't already exist) using the default volume object name format "servername_volumename". DSREPAIR will then write the object ID of this volume object to the physical volume so they are properly linked.
The following output is what DSREPAIR would display if the NDS volume object for the local volume didn't exist, or was not linked to the volume. Note the log will cite "has been created" even if the object already existed but was simply unlinked:
Repairing volume object for volume NSSVOL
Directory services volume object ID: 000087B5
ERROR: The volume ID cannot be resolved in this database
New volume object DN: CN=FS1_NSSVOL.O=Novell.T=NW51TREE.
Contacted a replica on server: CN=FS1.O=Novell
The volume object has been created for this volume, ID: 00008D4A
The volume has been attached to the volume object
Volume: NSSVOL, object ID: 00008D4A, CN=FS1_NSSVOL.O=Novell.T=NW51TREE
Checking trustees on volume: NSSVOL
The following output shows what DSREPAIR would display if it finds a properly linked volume object for the local physical volume:
Volume: NSSVOL, object ID: 00008D4A, CN=FS1_NSSVOL.O=Novell.T=NW51TREE
Checking trustees on volume: NSSVOL.
If this is happening during the process of moving the NDPS Manager Database from on server to another, simply follow these steps.
1. Unload the NDPS Manager from the server it is currently running on.
2. Load the NDPS Manager on the server where the cluster-enabled volume is currently running using the following switch ---/DBVOLUME=.Cluster Volume Name.context.root
This is the target location where the NDSP Manager Database will ultimatly reside.
3. Update the load script as outlined in the documentation.
document
| Document Title: | Unable to target desired volume as host volume for NDPS Manager. |
| Document ID: | 10027003 |
| Solution ID: | 1.0.56902415.2550045 |
| Creation Date: | 21Feb2000 |
| Modified Date: | 21Oct2003 |
| 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.