Different-server Migration using DSMAINT
Novell Cool Solutions: Feature
Digg This -
Posted: 30 Sep 1999
No one likes moving. All those boxes, all that tape. All those broken mugs. But we're guessing that most people would rather move across the country twice, in a borrowed cattle truck with balding tires, rather than attempt to migrate their stuff onto a new server. Whether it's your first migration or your fiftieth, it's just plain nerve-wracking. So we'd like to try to make it a little easier.
This article, adapted from a collection of very successful TIDs, will help you understand the issues involved in planning and carrying out a successful migration. We're focusing on the situation you face when a new server is brought in to run the same OS, or a newer OS or hardware is being changed on the existing server (for example, raid array). We'll explore what you must consider when all of the data and directory services database information needs to be migrated to a new machine.
Please note: DSMaint is not a substitute for backing up the NDS using an SMS compliant backup. For more information about that, see TID 2940285.
And one more thing. This is pretty tricky business, with lots of dependencies and decision-points, so please read through the entire document before you try anything. Or you'll find out too late that little gotcha in step 6...
Overview of Procedure
Note for Small Business and NetWare 5 users
If you don't want to upgrade before doing dsmaint
Why you might need an in-place upgrade
For the latest updates to this information...
Because of the complexity of these steps, and the potential impact of error, please read the entire document carefully before starting this procedure.
There are two ways in which a 4.x to 4.x/5.x migration can be accomplished -- same server, and different server.
Same server: In this scenario the server is upgraded (not migrated) from an older version of 4.x to a newer version (4.10 to 4.11 for example); hardware is not changed, just the OS on the existing server. This document will not cover this specific procedure. See the Upgrade manual, Chapter 3: Upgrade Using Same-Server Migration, for more information.
Different server: In this scenario a new server is brought in to run the same OS, or a newer OS or hardware is being changed on the existing server (for example, 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 in a lab environment with a completely different tree. Please note: 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 workarounds, 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.
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 relinking problems), and it keeps all partitions from the server complete and 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, a restore operation will place the file system and trustees on the NetWare volumes, thus completing the upgrade.
The most up-to-date versions of DSMaint.NLM are available on the Support site. Just go here, and type "dsmaint" in the file finder.
If you use intraNetWare for Small Business (IWSB), NetWare for Small Business (NWSB), or NetWare 5 and you want to move to a new server hardware platform, there are special considerations for you. There are five upgrade/migration scenarios possible with these versions of NetWare:
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.
IWSB or NWSB upgrading across the wire to NWSB
DSMaint will work fine in this situation. Follow this document.
NetWare 4.10 or NetWare 4.11 to NetWare 5
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.nlm to change the hardware.
If you have 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.
Bottom line: NetWare 4.10 can be upgraded to NetWare 5 if there are no other 4.10 servers to be left on the network after the upgrade is completed. If there are, there will be problems without DS.NLM v 5.15.
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.
NetWare 5 to NetWare 5
The dsmaint procedure using NWConfig.nlm will work fine.
Many administrators would rather not upgrade an existing server before doing DSMaint (as suggested in three of the five scenarios above). They would rather have the existing server left untouched. If this is the case for you,
- Install the exact same version of NetWare on the new box that the old box has.
- Perform the dsmaint procedure on the old server.
- Perform an in-place upgrade on the new server.
For example, if you are 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. You would then use dsmaint to bring the information across 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.
For more information on doing an in-place upgrade, see the Upgrade manual, Chapter 4: Upgrade Using In-Place Upgrade.
Throughout this example, server A will be the old server (486/66) and server B will be the new server (Pentium II/400). In our example, 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.
- Make sure the NDS tree is healthy.
- Do a backup of server A with SMS compliant software.
- Login to server A.
- Perform dsmaint backup of directory services.
- Copy backup.ds file to local client hard drive.
- Install server B into a bogus tree with the same name and IPX number as server A.
- Login to server B and copy backup.ds to the sys:system directory.
- Remove DS from server B.
- Use dsmaint or install to restore DS to server B.
- Reinstall the backup software and then restore file system and trustees from tape.
- Verify the integrity of the migration.
- Make sure the NDS tree is healthy.
The tree must be healthy before anything is done. There cannot be any communication errors, or syncing errors in the tree. If there are errors, and you proceed as outlined in this document, you will have serious problems. Here are a few things to check:
- 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 2930686 for help in resolving them.
- 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.
- Run a repair on the database of server A: Go to DSRepair | Adv. 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.
Many administrators have asked about different scenarios with NDS, such as 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 offline.
The master of a partition is needed for only a couple of things:
- Partitioning operations,
- Janitor process; i.e., cleaning up deleted, renamed, or moved objects,
- Limber process; i.e., server address and name checking,
- 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 administrators 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.
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 TSAs 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 administrators 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 relinked 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 offer some Cool Tools 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 best way to use this program is 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 earlier to restore the trustee rights. This will work.
If you have an SMS compliant backup program, use it and don't bother with the other methods.
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 either of these files exist, delete them, or rename them to a different extension, (such as .old). If this file exists and you don't rename it, you will have problems.
The reason you must login to server A is that when the process for backing up DS is completed, DS will be locked on server A. This means that no one can login anymore. Hint: login before this happens.
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:
- 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 to the Minimum Patch List and get the latest DS file; i.e., DS410X.EXE where 'X' is a number or letter (DS410K.EXE).
- 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 login. Login 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 administrators 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 login 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 directed in this document).
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 this file on either the client or server - this is 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. Server A's DS database will still be locked if for some reason it needs to come back up, but this old server is currently not needed on the network anymore. Do not do anything with server A besides ignoring it. Do not fdisk and reformat. Do not run it as a client workstation. Just leave server A alone until after server B is functioning completely.
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.Gotchas
One 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 administrators 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. To prevent this, do step 6 with server B offline. 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; corruption can occur. To prevent that, make sure you 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 namespaces were installed on server A, make sure namespaces 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 administrators 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 administrators will patch server B before the dsmaint process takes place.
Login 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.
Load Install.nlm on server B and go to "directory options" and then "remove directory services from this server". login 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.
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, administrators will sometimes rename their backup.ds file (created with dsmDSMaint.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 administrators 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 login, 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 (except for 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 (offline!!!) 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.
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.Gotchas
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 administrators.
- 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 four 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 administrators 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.
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, as outlined in Step 1.
What to do if server B doesn't work correctly and server A needs to come back up immediately
- Take server B off the network (unplug the LAN cable or down the server).
- Bring server A back over, plug it in, and turn it 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.
- 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.
- 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.
Problems removing DS (usually happens with server A after server B 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 login, 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 (offline) 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 won't 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.
This article is based on one of the most popular NDS TIDS, (2934033), and we present it here for your convenience. This is a compilation of several 4.x to 4.x/5.x migration TIDs that many people have found extremely helpful, and we hope this will make the process of migration a little easier. The TIDS are sometimes updated, so you may wish to refer to the Knowledgebase version in order to get the most current Support information.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com