Novell DSMaint Procedure

(Last modified: 05Jan2004)

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

goal

 Novell DSMaint Procedure

Hardware upgrade

fact

Novell NetWare 4.1

Novell NetWare 4.11

Novell Intranetware 4.11

Novell intraNetWare for Small Business

Novell NetWare 5.0

Novell NetWare 5.1

Novell NetWare for Small Business 4.2

Novell NetWare 3.11

Novell NetWare 4.2

Formerly TID 2934033

change

Across the wire migration

Hardware Migration

Hardware replacement

Hardware Maintenance

fix

YOU MUST READ THROUGH THIS ENTIRE DOCUMENT FIRST BEFORE STARTING THIS PROCEDURE.  This is a compilation of other 4.x to 4.x/5.x migration documents and will attempt to make the process of migration as easy as possible.  

Novell's Upgrade Wizard v3.0 is designed to do a 4.x to 5.x migration based on what this document details.  Novell suggests that you use this program for NetWare 3.x or 4.x to 5.x across  the wire migrations.  For 4.x to 4.x or 5.x to 5.x hardware upgrades, follow the procedure in this document. Before beginning: DSMaint is not a substitute for backing up the NDS using an SMS compliant backup.  (TID:  2940285)  If used in NetWare 5 for hardware maintenance, there are additional processes; (TID: 2940285) also covered below. There are 2 ways in which a 4.x to 4.x/5.x migration can be accomplished:

1.  Same server: In this scenario the server will be upgraded (not migrated) from an older version of 4.x to a newer version (4.10 to 4.11 for example); hardware will not be changed, just the OS on the existing server.  This document will not cover this specific procedure.  See the Novell manuals for more  information.

2.  Different server: In this scenario a new server is brought in to run the same OS, a newer OS or hardware is being changed on the existing server (e.g., raid array).  All of the data and directory services database information needs to be migrated to the new machine.  This document will cover this procedure.

There is no easy way to test the DSMaint process with the production tree before doing it in the production environment.  The best way to test this would be to use a lab environment with a completely different tree.  As an aside, you cannot take the production tree DS and put it on a test LAN and get this process to work.  The problem with doing this is that the network is not the same (server IDs, names, etc.).  You also cannot 'trick' DSMaint into thinking it is the production environment by giving the test LAN the same servers, names, etc.  This will fail because the ID numbers of the specific servers are completely different (not the Internal IPX numbers - the directory service ID numbers).  Just use a completely different tree with servers specific to that tree to test this process.

DO NOT do this procedure and then try to go back. There are work-arounds, but do not approach this migration thinking that you just want to "test" it to see if it works - especially if you're testing it on a production server.

A quick explanation of how this procedure works: This procedure works for a 4.10 to 4.10 upgrade, 4.10 to 4.11 upgrade, 4.11 to 4.11 upgrade, Small Business to Small Business upgrade, or a NetWare 5 to NetWare 5 upgrade.  Basically this procedure uses an NLM called DSMaint or the DSMaint functionality that is built into INSTALL.NLM.  DSMaint allows for a complete backup of directory services into a single file.  It keeps DS ID's intact (therefore, no printing or trustee re-linking problems), and it keeps all DS partition replicas from the server intact.  The idea here is to run DSMaint on the source server, get the backup file, and then run it again on the target server.  This lays the exact same DS database down on the new server, and it picks up communicating with the other server(s) as if nothing happened, except that it was down for 20 minutes or so.  After DS is restored on the new server, then a restore operation will place the file system and trustees on the NetWare volumes, thus completing the upgrade.

Note to users of intraNetWare for Small Business (IWSB), NetWare for Small Business (NWSB) and NetWare 5 who want to move to a new server hardware platform:

There are 5 upgrade/migration scenarios possible with these versions of NetWare:

1.  NetWare 4.10 or NetWare 4.11 upgrading across the wire to IWSB or NWSB: DSMaint cannot be used to do this type of upgrade/migration directly.  To accomplish this task, the NetWare 4.10 or 4.11 server must first be upgraded to IWSB or NWSB through the in-place upgrade procedure.  Then the DSMaint procedure can be used to change hardware.

2.  IWSB or NWSB upgrading across the wire to NWSB: DSMaint will work fine in this situation.  Follow this document.

3.  NetWare 4.10 or NetWare 4.11 to NetWare 5: Again, DSMaint cannot be used to do this type of migration.  Upgrade the 4.10 or 4.11 servers to NetWare 5 first using the in-place upgrade procedure, and then use NWCONFIG to change the hardware. here is one concern here for customers with NetWare 4.10: DS.NLM must be at version 5.15 or above to co-exist in the same tree with NetWare 5.  If DS.nlm is not at version 5.15 or above, NetWare 4.10 will not be able to exchange DS schema information correctly with NetWare 5.

To be as plain as possible about this here is the bottom line: NetWare 4.10 can be upgraded to NetWare 5 if there are no other 4.10 servers left on the network after the upgrade is completed.  If there are, there will be problems without DS.nlm v 5.15.

4.  IWSB or NWSB to NetWare 5: Do an in-place upgrade of the Small Business server to NetWare 5, and then use DSMaint to change the hardware.

5.  NetWare 5 to NetWare 5: The DSMaint procedure using NWCONFIG.NLM will work fine.

Some customers would rather not upgrade an existing server before doing DSMaint (as suggested in 3 of the 5 scenarios above).  They would rather have the existing server left untouched.  If this is the case, install the exact same version of NetWare on the new box that the old box has.  Then DSMaint the old server and follow this with an in-place upgrade on the new server.  For instance, moving from NetWare 4.10 to NetWare 5 using new hardware: You would keep the existing 4.10 server and install NetWare 4.10 on the new hardware.  Use DSMaint to bring the information across the to the new hardware, and then do an in-place upgrade to NetWare 5.

The reason an in-place upgrade is needed with some of the above scenarios is because of the changes made to the DS database.  Here is one example: DS in NetWare 4.10 and 4.11 does not allow the server licenses to be stored within the database.  If a DSMaint procedure were to be done directly from NetWare 4.10 to NetWare 5, the licensing information, and schema extensions would be lost on the new server.  Also, the names and number of the files containing the DS database have changed between 4.x and 5.x servers; this creates restoration problems.  Essentially, DS would have to be removed from the NetWare 5 server and then reinstalled to restore the correct database format if DSMaint were used directly to perform a migration.

Naming conventions: For purposes of this document, server A will be the old server (486/66) and server B will be the new server (Pentium II/400).  The idea here is that server B will completely replace server A in the tree.  Also, in NetWare 5 there is no INSTALL.NLM  NWCONFIG.NLM has taken the place of INSTALL.NLM  This NLM has the same functionality as INSTALL.NLM with just a different name.  When the document says to load INSTALL.NLM, if you are using NetWare 5, load NWCONFIG.NLM  Here are the steps:

1.  The tree MUST be healthy before anything is done.  There cannot be any communication errors, or synchronizing errors in the tree.  If there are, and the rest of this document is followed, THERE WILL BE PROBLEMS!  Here are a few things to check:

a.  Load DSRepair on the server that holds the Master of the [Root] partition and run "time synchronization".  Make sure that all servers are in sync and that there are no errors.  If there are time sync problems, see TID 10058645 for help in resolving them.

b.  Again, on the Master of [Root] in DSRepair run "report synchronization status".  Look for errors.  If there are errors, they must be addressed.  For example a -625 error means a communication error with a specific server.  Search the web for specific problem references for help concerning these error messages, or talk with Novell Technical Support about fixing them.

c.  Run a repair on the database of server A: Go to DSRepair | Advanced. Options menu and then Repair local DS database.  Select everything "no" except for "check local references".  Run the repair (hit <F10>).  Save the database if the number of errors are low -- you may want to have a look through the log file to see what the errors are - if there are any.

If there are no errors in either time sync, or report sync status, consider the tree healthy and happy.  If the tree is huge, you may want to run this same procedure (i.e., time sync and report sync status) at different points in the tree to guarantee that there are no problems.

Customers have asked about different scenarios with NDS, specifically performing a DSMaint procedure on a server that holds the master of a partition (be it [Root] or another partition).  With NetWare 4.0x this type of scenario required some NDS operations on the replicas before going further; however, that is not the case with NetWare 4.1x.  There is no need to make another server the master of a partition because NDS will recognize that the master is down and all requests will be routed through a Read/Write replica of the partition.  Then, when the new server (server B) is brought online, he will receive all of the updates that transpired while off-line.

The master of a partition is needed for only a couple of things: 1) Partitioning operations, 2) Janitor process; i.e., cleaning up deleted, renamed, or moved objects, 3) Limber process; i.e., server address and name checking, and 4) Other NDS background processes; i.e., flat cleaner.  With this in mind, when doing a DSMaint procedure on a server that holds the master of a partition, you would NOT want to do partitioning operations, or moving/deleting/renaming objects in the tree when this server is not online.  This should be obvious, but is mentioned here so as to make sure there is no ambiguity in this matter.  In other words, don't do anything to the tree while you're doing this procedure.

Another scenario that customers have asked about involves a server that does not hold any replicas.  Is the DSMaint procedure still used?  Absolutely! Every 4.x server (or above) contains a DS database.  Whether that database is filled with real objects or not is irrelevant to the process here.  A server that holds no replicas of any partitions is called an External Reference server.  These types of servers do not hold real objects like a server that has a Read/Write or Master replica, but pieces of objects are located on the server.  Without going into too much DS detail, the external references are the DS database on this type of server.  If DSMaint is not used, the printing, trustees, and anything else specifically identified with this server will be lost and have to be recreated by hand.

A final note about the server's database: if a server holds the only real copy of a partition, the DSMaint operation can fail with a -626 error upon trying to restore.  This will happen because the server is trying to contact other servers it knows about, but because no replicas of the partition are available, it thinks it can't continue.  This appears to be an issue in NetWare 5 only.  In either case, we suggest you make sure the server being migrated does not hold the only copy of any partition.  Novell recommends that you always have at least three real copies of any partition.  See DSDesign, Replication, and Partition Strategy (10014937).

2.  Make a backup of server A.  This backup must be SMS compliant (e.g., ARCserve, Backup Exec, or SBackup); this means that the backup must use Novell's TSAs to copy data and trustees from the server.  Make sure that the version of the TSAs on the server is the latest offered.  To do this, apply the server patch kit for 4.11 (IWSPx) or at least SMSUP6 for NetWare 4.10.  The version of the Tasks used is critical because the storage of the full-distinguished name in the trustee list is dependent upon this.

There is a switch in ARCserve that must be enabled because ARCserve does not backup the trustees by default.  Go to the ARCserve Scheduler console screen and into 'Configure ARCserve server'.  Make sure that "Use SMS logic for DOS and MAC files also" is set to yes.  If your backup program does not make use of Novell's TSAs, the trustees on every volume will have to be reassigned manually on server B.

Some customers have tried to copy their data from server A to server B (before making the DS switch) and wondered later why the trustees - ownership and file rights - did not make it.  Here is why: DS must go on first before the trustees are laid down with the file system.  The trustees are not a part of directory services; they are a part of the file system; so restoring DS will NOT restore the trustees.  The trustees are re-linked by unique names (full distinguished name; i.e., cn=admin.o=Novell) to directory services.  If that name in DS doesn't exist, the trustee is deleted.  Therefore, NCopy (which doesn't copy trustees) will not work.  In addition, a restore of the file system and trustees before DS is laid down will not work because the trustees will try and relink with NOTHING or to a name that doesn't exist in DS, therefore they will be invalid and will be deleted.  Don't do this.  

Novell does have programs on our web site that may help in easing this problem.  TCopy is a poor man's file migration utility.  However, it only works 4.x to 4.x (or 5.x) and both servers must be up and operating.  This means that a server OS upgrade hasn't been done and cannot be done because both servers cannot be on the wire at the same time.  Using TCopy is the same as restoring the file system before DS is restored.  Tbackup, on the other hand, will backup the trustees and allow you to restore them afterwards (IRF, ownership, rights, etc.).  The way to use  his program would be to copy the data from server A to server B and then after the DS is moved over, use the Tbackup file - that was run on server A before - to restore the trustee rights; this will work.  Both TCopy and Tbackup can be found on the minimum patch list page at http://support.novell.com OR if you have an SMS compliant backup program, use it and don't bother with the other methods.

3.  Log in to server A as admin or an admin equivalent.  This is important.  Just do it.  Make sure that you have a drive mapped to the system directory on server A.  Check in the system directory for a file called "backup.ds" or "backup.nds" (if using NDS v8.x, the backup file will be called 0000000.$hw).  If either of these files exist, delete them, or rename them to a different extension, i.e., .old.  If you don't rename this file if it exists, you will have problems.

The reason you must log in to server A is because when the process for backing up DS is completed, DS will be locked on server A.  This means that no one can log in anymore.  Hint:  Log in before this happens.

4.  On server A you are now ready to create the backup of directory services.  If server A does not already have the latest version of DS on it, go get it and apply it.  The latest version of DS also updates DSMaint.nlm among other NLMs.  

There are two ways in which the DS database can be backed up:

a.  On a NetWare 4.10 server: Load DSMaint.nlm at the system console prompt.  Choose "Prepare NDS for hardware upgrade".  This option will actually make the backup of directory services and create the file in the sys: system directory.  If your 4.10 server does not contain DSMaint.nlm, apply the patches to the server.  Go out to http://support.novell.com to the "minimum patch list" page and get the latest DS file; i.e., DS410X.EXE where 'X' is a number or letter (DS410K.EXE).

b.  On a NetWare 4.11 server (or intraNetWare/Small Business server): If DS411L or later is installed on the server (includes DS.nlm version 5.99a), follow the 4.10 procedure with DSMaint.  DS411L includes an improved version of DSMaint; use it.  If not, load INSTALL.NLM at the system console prompt.  Choose "directory options" and then "directory backup and restore options".  Then select "save local DS information prior to hardware upgrade".

DSMaint does not come standard with NetWare5.  If you try loading it you will receive a public symbol error message and the module will not load.  If DSMaint usage is desired, NWCONFIG.NLM in NetWare 5 contains the same code paths to enable a DS backup as the 4.11 version of INSTALL.NLM

When <ENTER> is pressed on the option to backup directory services, a warning screen is presented - READ IT!  An administrator will then be asked to log in.  Log in with full context; i.e., admin.novell.  If you do not use the full context for the administrator, a -601 error will result saying "unable to locate object".

Some versions of DSMaint will ask for an alternate path to store the file.  ALWAYS redirect the file to sys:system.  Never put the file on the A: drive!  Most NetWare customers have NDS databases that are larger than 1.44 MB.  DSMaint does not provide for a way to span diskettes, so do not ask for the data to be written to floppy.  If by accident you ask DSMaint to store the database backup file on the A: drive and your database is larger than 1.44 MB, skip directly to the procedure following step 11 (bringing server A back up).

After DSMaint has completed the backup process to sys:system, server A's directory services database is now locked.  This means that no one can log in to the server and no changes can take place in its database.  The reason the database is locked after a DSMaint process is because to do this procedure, a static copy of a dynamic process is needed.  NDS is dynamic - constantly changing.  So, taking a backup of it with the database open guarantees that it will change between the time the backup is taken and when it is restored - sometimes with consequences that are not easy to fix.  So, DSMaint locks the database to ensure that no changes take place.  Basically a dynamic process has been turned static and the backup can now be taken without any problems.  This is the point of reference.  Now when NDS is restored on server B, the other servers know exactly where to pick up and send updates.  Therefore, it is essential that the database on server A STAY LOCKED for the duration of this procedure (unless otherwise talked about in here).

5.  After DSMaint/INSTALL.NLM has done the backup of directory services, go to the client workstation that is already logged in, and retrieve backup.nds (backup.ds for DSMaint users) and copy it to the local workstation's hard drive.  DO NOT DELETE THE FILE on either the client or server - this is the NDS.  If there are any problems with the new server, this file will let us unlock DS on server A so that it can still function while problems with server B are being addressed.  Just leave it alone.  If there are multiple files, look at the date and time to be sure and copy only the one that was just made.

With this done, server A is ready to be turned off and put in a corner.  His DS database will still be locked if he needs to come back up, but he is currently not needed on the network anymore.  Do not do anything with server A besides ignoring him.  Do not fdisk and reformat.  Do not run him as a client workstation.  Just leave server A alone until after server B is functioning completely.

6.  Server B must have the NetWare OS installed onto it.  Give server B the EXACT SAME NAME as server A and the EXACT SAME IPX INTERNAL NETWORK NUMBER as server A - this is important.  A gotcha here is that server B must be installed into a NEW TREE; unless there is only one 4.x server (total) in the tree and then this doesn't matter.  A problem that has been seen by some customers is that after step 6 is done (before steps 1-5 are completed), both servers can be on the LAN communicating.  With both servers having the same IPX number and name this can confuse routers in finding the correct server to address data to because both are broadcasting themselves as the correct route.  The suggestion to fix this would be to do step 6 with server B  off-line.  Plug server B into the production LAN only after server A has been turned off.

Novell does not process Saps across trees (DS SAPs), therefore server B isn't known to the rest of the servers on the network even though it has the same name and IPX number as server A did.  Thus, the other servers will still believe server A is down even though there is another server on the wire with the same name and IPX number as server A had.  If server B is installed into the same tree that server A resides in and the other server(s) communicate with it; well, let's just say that bad thing corruption can occur.  Don't do that, put server B into a bogus tree.

Also, upgrade the DS on server B.  Make sure that it has the latest that is available from Novell.

When NetWare is installed onto server B, make sure that everything on it is the same.  For instance, if compression was enabled on server A, enable compression on server B (INSTALL.NLM can tell you about compression and suballocation in "Volume Options").  If name spaces were installed on server A, make sure name spaces are installed on server B (use "volumes" at the system console to check this).  The exception to this make-everything-the-same rule is that Suballocation and block sizes can differ from server A to server B.  In other words, server A can have a volume with suballocation disabled and a 4k block size and then server B's corresponding volume could have suballocation enabled and a 64k block size.  This specific difference doesn't matter.  You may also want to copy the contents of the DOS partition (C: drive) from server to server - this would include the Startup.ncf file - especially because this copies all of the patches from one server to the next.  If you do this copying procedure, realize that the drivers in the Startup.ncf will probably change because the new server will likely have different hardware; thus, different drivers and settings in the Startup.ncf file.  Also, DO NOT copy the patches from a 4.10 to 4.11 server; they are different.  Install the service pack to enable the patches.

Most customers will do step 6 well before steps 1-5 take place.  With step 6 already done, this saves a lot of time for the administrator, and makes the change to the new server appear more seamless.  Also, many customers will patch server B before the DSMaint process takes place.

7.  Log in to server B (in the bogus tree) as admin or an admin equivalent and copy the backup.nds or backup.ds file out to the sys:system directory.  Again:  Backup.ds is the file that DSMaint.nlm creates and uses.  Backup.nds is the file that INSTALL.NLM creates and uses.

8.  Load INSTALL.NLM on server B and go to "directory options" and then "remove directory services from this server".  Log in with full context and make sure that DS is removed.  Because this server is the only one in the bogus tree, it holds the master of [Root] and is a Single time source.  You will see error messages stating these two things and warning you not to continue - ignore them and go on.

9.  Now, depending upon how the DS database backup file was made (on server A), a decision will have to be made on how to restore the file.  If DSMaint was used on server A for the backup, use DSMaint again on server B for the restoration.  And conversely, if INSTALL.NLM was used on server A for the backup, use INSTALL.NLM again on server B for the restoration.  As mentioned before, NetWare 4.11 and NetWare 5 do not come with DSMaint.nlm installed on the server by default.  A directory services patch must be applied to NetWare 4.11 before this NLM is located in the sys:system directory; check http://support.novell.com on the minimum patch list page for this patch.  For this reason, customers will sometimes rename their backup.ds file (created with DSMaint.nlm) to backup.nds.  This rename will allow the file to be used with the enhanced INSTALL.NLM on NetWare 4.11 or NetWare 5.  There is a gotcha here.  Some customers have reported that the restoration of the file failed after renaming it, however, they were successful if they used the same program that created the file.  Novell's advice is to use the same program to restore the file that backed it up.  Do not use the renaming technique unless absolutely necessary.

*Go back into Install/NWCONFIG.NLM or DSMaint and restore the DS information following hardware upgrade.  Remember to log in, using full context; i.e., ".admin.novell".  In NetWare 5, same server hardware maintenance, NWCONFIG must be loaded with -dsremove and the locked database removed before restoring the database from the captured file.  NWCONFIG, Directory options, Remove directory services from this server.  Then restore the local DS as indicated.

Some errors can result at this point if the procedure was not followed correctly.  First, if all of the servers are not up and communicating (excepting server A), the file will not be restored.  This program "talks" with every server that server A knew about; if one is down, the restore will error out and fail.  Second, if the IPX number and name of server B are not the same as server A's, the restore will fail.  If this happens an error message will inform you that the IPX numbers are different between the servers and it cannot restore backup.ds because of this.  This specific IPX number problem can be fixed by making the IPX internal net numbers the same on server A and server B - if you do not remember server A's IPX number, bring A up (off-line!!!) and then type "config" at the console prompt; the number is listed right at the top of the screen under the server name, or jump into INSTALL.NLM and edit the AUTOEXEC.NCF file to find the number.

10.   With the restoration of directory services complete, the file system and trustees need to be restored on server B.  The backup software will probably have to be reinstalled on server B because it doesn't exist on the server's volumes yet.  After doing this, restore the file system and trustees; never restore NDS during a DSMaint procedure.  One gotcha here is that some backup software is very picky about versions.  If you backup server A with one piece of software, do not install an upgraded version on server B - install the same version that backed server A up.

The restoration of files on server B has brought up some questions from customers.  First, if the server is an upgrade to a newer version (i.e., 4.10 to 4.11), should every file be copied over - including system and public files?  Answer:  No.  There are 4 directories you will probably not copy from the server sys volume in this case:  system, public, login, and etc.  However, maybe some of the configuration files in the etc directory should be brought across - administrators should know this because they configured the server to use MPR, or NFS, etc.  Mail directories may need to be copied across if there are users that authenticate to the server with a bindery connection, or if programs used on the server use the mail directory (i.e., Pegasus Mail).  Secondly, if the server is not an upgrade (i.e., 4.11 to 4.11), should every file be copied over?  Answer:  Absolutely.  This type of migration by default means the two servers will be the same.

If you accidentally restore NDS to server B, there will be BIG problems if left in the production environment.  To fix these problems, repeat steps 8-10 again.  In other words, remove DS, restore the backup.ds file using DSMaint and then restore the file system again.  The file system MUST be restored again because DS was removed.  Remember, when DS is removed from a server all of the trustees to every volume attached to that server are GONE; thus the need to restore again.

FYI:  Some customers have seen situations where after restoring the DS database with DSMaint, all of the mounted volumes on  server B are not recognized by NDS.  To ensure that there are no problems with this specific issue, load install | directory options | upgrade mounted volumes into the directory.  This procedure in INSTALL.NLM will check directory services for a valid volume object for all currently mounted volumes.  For a volume where there is not an object, INSTALL.NLM will create one automatically.


11.  You're done.  Take a quick look around the server with NWAdmin to make sure everything looks good.  Make sure the printing works correctly, the login scripts function, and anything else you feel important is running well.  Give the server a good 20-30 minutes to contact other servers on the LAN and reestablish its synchronization ring, and then check the synchronization status in DSRepair (see step 1B).

What to do if server B doesn't work correctly and server A needs to come back up INSTANTLY!

1.  Take server B off the network (unplug the LAN cable or down the server)

2.  Bring server A back over and plug him in and turn him on.  Server A will report an error immediately after mounting the sys volume that the local database is inconsistent and cannot be opened.  NetWare will suggest using DSRepair to fix the problem - ignore this, DSRepair cannot fix this.  The error is a result of the database changes made to NDS when the backup was taken with DSMaint.

3.  Load DSMaint or INSTALL.NLM (whichever one was used to do the backup) and choose the option to restore DS information after hardware upgrade.  If the NLM asks you where the file is, say "sys:system".  This will perform a restore of DS from the backup.ds file on server A.  After the restore, server A will be functioning as before.

4.  Remove directory services from server B through INSTALL.NLM so that this process (DSMaint) can be repeated cleanly again.

If this doesn't work (the restore of backup.ds on server A), Novell Technical Support can provide additional help with the restoration of this file.  Do not forcefully remove directory services from server A until you have talked with Novell about this problem unless you are confident that removing DS from server A will result in a faster resolution.  That should do it.

Here is a quick step-by-step for DSMaint:

1.   Make sure the NDS tree is healthy.
2.   Do a backup of server A with SMS compliant software.
3.   Log in to server A.
4.   Perform DSMaint backup of directory services.
5.   Copy backup.ds file to local client hard drive.
6.   Install server B into a bogus tree with the same name and IPX number as server A.
7.   Log in to server B and copy backup.ds to the sys:system directory.
8.   Remove DS from server B.
9.   Use DSMaint or install to restore DS to server B.
10.  Reinstall the backup software and then restore file system and trustees from tape.
11.  Verify the integrity of the migration.

Removing DS problems (usually happens with server A after server  is working properly):

If there are problems removing directory services from a server, you can use the command line "load install -dsremove" to take it off forcefully.  INSTALL.NLM will go down the same code path to remove DS as if the "-dsremove" switch was not loaded.  However, install will not stop the removal process of DS when errors are encountered as it normally does; it will continue on until it is completed despite any errors that come up.  Essentially it will rip the NDS files off the server no matter what.  So, any errors that come up, just ignore them (even if Install says, "directory services was not successfully removed").  If it asks you to log in, just hit <ESC> and go right by it.

Normally, INSTALL.NLM will contact the other servers in the tree and tell them that a specific server is having its DS database removed, therefore these other servers will remove all references to that server.  This is the clean way to do it.  When communication has broken down between servers, INSTALL.NLM has a hard time (obviously) contacting other servers to inform them of this change.  So, by forcefully removing DS from a server it can leave behind remnants that will cause problems if not taken care of.

So, if DS will not successfully come off of server B (i.e., if server A needed to come back into the tree because server B wasn't working correctly), just remove the DS (off-line) with the "-dsremove" switch.  Conversely, if server B is successfully placed into the tree and everything is working and server A's DS will not come off, just forcefully remove it; it wont matter that he cannot contact other servers because there really is a server A on the production LAN (it is server B).  There will be no consequences in removing DS from server A forcefully if everything worked out just fine in this procedure with DSMaint.

DS is not something to play around with.  Do not ever forcefully remove directory services from a server unless you understand all of the consequences.  In this situation with DSMaint, the -dsremove switch may be necessary.


*NOTE:  For NetWare 5.1 servers the backup file is created in SYS:\SYSTEM\$HWNDS.BAK see TID #10064949
.

note

The DSMaint procedure does not account for NICI server specific NICI information.

Do NOT use the DSMaint procedure to migrate the Certificate Authority server.

document

Document Title:	Novell DSMaint Procedure
Document ID:	10010933
Solution ID:	4.0.1409387.2203629
Creation Date:	25Jun1999
Modified Date:	05Jan2004
Novell Product Class:	Connectivity Products End of Life Groupware NetWare Novell BorderManager Services 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.