Do the installation from the latest overlay CDs. This is especially important if you use quite new hardware. Make sure you use the same code page and country code as your source server or else files with special characters in their names may cause problems during the migration. Make sure you install your server as a Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â server and you donÃ¢â‚¬â„¢t install any additional products. The Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â option is available early in the text part of the install for NetWare 5.1 and 6.0 and in the GUI part of the install for NetWare 6.5 OES/NetWare. Make sure you install the server with a temporary name in a temporary tree of its own. Name, tree name and IP address of the server must be different from the source server you want to migrate.

Do the installation from the latest overlay CDs. This is especially important if you use quite new hardware. Make sure you use the same code page and country code as your source server or else files with special characters in their names may cause problems during the migration. Make sure you install your server as a Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â server and you donÃ¢â‚¬â„¢t install any additional products. The Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â option is available early in the text part of the install for NetWare 5.1 and 6.0 and in the GUI part of the install for NetWare 6.5 OES/NetWare. Make sure you install the server with a temporary name in a temporary tree of its own. Name, tree name and IP address of the server must be different from the source server you want to migrate.

−

Create your volumes to match the volumes you want to migrate from the source server. However if your destination volumes are NSS volumes on NetWare 6.x servers, do not yet enable user or directory quotas on the volumes. Otherwise, the Migration Wizard may run out of space when copying compressed files and will create zero byte files. If quotas were ued on the source server, the migration wizard will automatically enable quotas on the destination server in step 4 of the migration.

+

Create your volumes to match the volumes you want to migrate from the source server. However if your destination volumes are NSS volumes on NetWare 6.x servers, do not yet enable user or directory quotas on the destination volumes. Otherwise, the Migration Wizard may run out of space when copying compressed files and will create zero byte files. If quotas were used on the source server, the migration wizard will automatically enable quotas on the destination server in step 4 of the migration.

<br>

<br>

Make sure you do install a license on the destination server, but you can use the demo license found on the NetWare installation CD. Just point the installation program to the LICENSE directory of the installation CD when the install asks you about the license. It is not needed to install your real licenses as whatever you license you install will be lost anyway after the NDS migration.

Make sure you do install a license on the destination server, but you can use the demo license found on the NetWare installation CD. Just point the installation program to the LICENSE directory of the installation CD when the install asks you about the license. It is not needed to install your real licenses as whatever you license you install will be lost anyway after the NDS migration.

Introduction

To help with migrating to new hardware (with or without version upgrade), Novell has a tool called the Ã¢â‚¬Å“Migration WizardÃ¢â‚¬Â. The version is now actually called the Ã¢â‚¬Å“Novell Server Consolidation and Migration ToolkitÃ¢â‚¬Â aka SCMT and includes both the Migration and the Consolidation tool in one tool. This document however will mainly concentrate on Server migrations, even though all tuning recommendations are also good for server consolidations. I will continue to call it the Migration Wizard for simplicity, especially since in certain cases; you may need to use an older version from before the name change.
Generally, the Migration Wizard works quite well. However without proper tuning, migrations can be slow, and also, if something goes wrong, the person doing the migration can feel quite lost. So the purpose of this document is to give recommendations on tuning the server configurations so as to speed up the migration and reduce the risk of problems and also, this document will propose a number of extra safety steps that will make it easier for you to recover from failed migrations.
DonÃ¢â‚¬â„¢t be scared by reading this document. The document deals with a lot of smaller or bigger things that could go wrong. This doesnÃ¢â‚¬â„¢t mean that you will see all these problems. It just mentions the problems that you could potentially face and how to prevent them or deal with them.

Tip! This document also applies to migrations from physical to virtual servers. If you plan to move a physical server to a virtual server under VMware, just follow the instructions on moving a server to new hardware.

Choosing the right migration tool

Migration Wizard 8.2

The latest tool is the Migration Wizard 8.2.709.14 which is part of SCMT 1.2.070914 and is dated 14 September 2007. IT is the version included in SP7 for NetWare 6.5, the SP7 overlay CDs or DVD for NetWare 6.5 as well as OES2. This version is also available for download at http://download.novell.com/Download?buildid=bibbruEYmPc~
It is important that you have the correct subversion as it fixes bugs found in earlier versions of the 8.x Migration Wizards. So donÃ¢â‚¬â„¢t use any versions from older NetWare 6.5 installation CDs.
The documentation for this version can be found at http://www.novell.com/documentation/scmt/index.html
This version supports migrations from NetWare 4.11 or later to NetWare 6.0 or 6.5 (including OES/NetWare and OES2/NetWare).

Migration Wizard 6.5

If your destination server for your migration is NetWare 5.1, then you need to use the Migration Wizard 6.5 instead. The latest version is 6.5.502.7 and can be found at http://www.novell.com/coolsolutions/tools/17244.html
Once again, it is important that you use this version and not earlier 6.5 versions, especially since older 6.5 versions were not compatible with XP SP2. The documentation for this version can be found at
http://www.novell.com/documentation/migwiz65/index.html
While this version also supports migration to NetWare 6.x, it is recommended to use version 8.1 when NetWare 6.x servers are involved.

Preparing the migration

Stuff you need

Hardware

source server

destination server. Make sure your destination server is compatible with the NetWare version you want to install and that you have the required drivers

(recommended but not required) a small fast switch and patch cables to directly interconnect your 2 servers and your migration workstation

a reliable workstation running Windows 2000 or Windows XP with the latest patches and a relatively up to date client (4.91 SP2 or later). DonÃ¢â‚¬â„¢t rely on an Ã¢â‚¬Å“unknownÃ¢â‚¬Â workstation for your migration.

disable screen saver and power save mode if laptop.

Software

NetWare installation CDs. Use the latest overlay versions that already include the latest support pack

The appropriate Migration Wizard (see versions in the previous section)

Prepare your NDS tree

This can already be done a couple of days in advance so that you donÃ¢â‚¬â„¢t have a surprise the day of the migration. However if you do this before, recheck your serverÃ¢â‚¬â„¢s NDS health the day of the migration.

Tree health

It is important that your tree is healthy, especially the server you want to migrate. Time should be in sync, there should be no communication problems with any remote server and there should be no pending obituaries. Solve all your NDS problems before proceeding.

Server certificates

If your source server is running NetWare 5.1 or later, make sure it doesnÃ¢â‚¬â„¢t have any expired certificates. Run PKIDIAG.NLM to verify and fix your certificates. This is especially important if you are migrating to NetWare 6.x where a lot of services depend on valid certificates and will fail on expired certificates. While certificates can also be fixed after the migration, it may be a good idea to already eliminate this potential problem before the migration.

Special NDS preparation (upgrade to NetWare 6.x)

If your migration is not a same server migration but an upgrade from a NetWare 5.1 or lower to NetWare 6.x, then special care must be takes to ensure your tree is ready. You should make sure you meet the minimum NDS version requirements for all servers in your tree and you should use the deployment manager to prepare your tree (see the installation manual for your destination NetWare version for details).
For a smoothest possible migration from 5.1 to 6.5, I would recommend that your root servers for your tree are already running eDirectory 8.7.3.x (this requires NetWare 5.1 or later). For migrations from 6.0 to 6.5, the eDirectory version inluded with NetWare 6.0 SP5 is good enough for the migration, but if you are going to keep around some 6.0 servers for longer, you should upgrade them to eDirectory 8.7.3.
For upgrading to eDirectory 8.7.3, use the file edir_873_ir3_nw.iso which can be found at http://download.novell.com/Download?buildid=NUBsf-ZwOaE~

Preinstall your licenses (upgrade to NetWare 6.x)

If your migration is an upgrade to NetWare 6.x, I would recommend you do already install your NetWare 6.x licenses into your tree prior to the upgrade. This makes things easier later on. Use NWADMN32.EXE to install the licenses in the container of the server to be migrated or in a container somewhere above it. The normal documentation would only tell you to install the connection licenses after the install/upgrade, but doing it before makes things easier as your server would already be fully licensed after the first reboot after the NDS migration.

Normalize and repair volume objects

The Migration Wiazard assumes standard names and location for the NDS volume objects. It will fail on non standard names. Make sure the NDS objects for your volume names have their standard names (e.g. servername_volumename) and are located in the same container as your server object. If for some reason, you are not using the default names or location, then move and rename your volume objects to the standard convention before the migration. After the migration, you can once again rename them to whatever suits you. Also, run DSREPAIR and using the advanced options, do a volume and trustee repair.

Preparing the source server

It is important for the reliability and the speed of the migration that the source server is updated and tuned for the migration.

Patch your server

Install the latest support pack on the source server (NW50SP6a, NW51SP8, NW60SP5) as well as any other patches recommended by the Migration Wizard documentation. If you plan to use the Migration Wizard 6.5, also install the latest TSA patch on your 5.x servers. For NetWare 5.0, the NSS patch NSS5H.EXE mentioned by the migration wizard is only needed if your server has any NSS volumes. The file containing the NICI 1.5.7 update is called 'NICID157.EXE'. Both these 2 files are no longer available on Novell's download web site.

Tune the SET parameters

For this, quit MONITOR if it is already loaded, and then load MONITOR with the command:

LOAD MONITOR !h

The option !h makes hidden SET parameters visible and this is important for the communication parameters.
Now select the option Ã¢â‚¬Å“Server ParametersÃ¢â‚¬Â and make the following changes in the following sections:

Purge Files On Dismount On (a quick way to purge deleted files on shutdown)

Clean up AUTOEXEC.NCF

Clean up the serverÃ¢â‚¬â„¢s AUTOEXEC.NCF to comment out all extra services. Especially disable any backup, open file manager and antivirus software as well as java applications, NDPS/iPrint and any server application that keeps files open. Also, make sure that SMDR.NLM and TSAxxx.NLM are not loaded from AUTOEXEC.NCF as the Migration Wizard will install newer versions and load them automatically.

Reboot your server

This will make sure that your server will just run in a minimum configuration which is best for the migration. If you donÃ¢â‚¬â„¢t reboot your server but just stop the services manually, the server could potentially abend when the migration starts.
This may especially if your server has been running for a long time and you have run regular backups. In this case, the server will abend when the migration wizard tries to unload the TSAs and SMDR.NLM.

Backup your trustees

Copy TRUSTEE.NLM to the SYS:SYSTEM directory of your server and then individually make trustee backup copies for each volume using the following command:

LOAD TRUSTEE /R volumename: SAVE volumename: volumename:trustee.dat

where of course you replace volumename by the real name of the volume. Include the SYS volume as well. The trustee backup is important in case the last step of the migration (trustee restore) fails. The /R option ensures the trustee backup uses relative directory names. This allows you to restore trustees even if the volume names or directory structures on the destination server change.

Update HOSTS file

Edit the file HOSTS in SYS:ETC and add an entry with the temporary name and IP address of the destination server. This will ensure that the file copy will not suffer from possible name resolution problems during the migration.

Backup your NDS

h) Take an NDS database dump using the following command:

LOAD DSREPAIR Ã¢â‚¬â€œrc

Note: You will not be able to use these NDS dump yourself. However in case things go badly wrong and you need Novell's help, they will be able to use your NDS dump file to restore the NDS on your server.

Verify your XNTP configuration (NetWare 6.5 only)

If you have a NetWare 6.5 server and you are using XNTP.NLM instead of TIMESYNC.NLM, then verify that NCP is not disabled for XNTP. In other words, the file SYS:\ETC\NTP.CONF should not contain the option. NONCP.

Preparing the destination server

Verify your BIOS configuration

Go into the serverÃ¢â‚¬â„¢s BIOS and make sure you set the clock correctly and you disable hyperthreading if this is a server with hyperthreading support (Pentium 4 or some older Xeon class servers)

Install your NetWare

Do the installation from the latest overlay CDs. This is especially important if you use quite new hardware. Make sure you use the same code page and country code as your source server or else files with special characters in their names may cause problems during the migration. Make sure you install your server as a Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â server and you donÃ¢â‚¬â„¢t install any additional products. The Ã¢â‚¬Å“pre migrationÃ¢â‚¬Â option is available early in the text part of the install for NetWare 5.1 and 6.0 and in the GUI part of the install for NetWare 6.5 OES/NetWare. Make sure you install the server with a temporary name in a temporary tree of its own. Name, tree name and IP address of the server must be different from the source server you want to migrate.
Create your volumes to match the volumes you want to migrate from the source server. However if your destination volumes are NSS volumes on NetWare 6.x servers, do not yet enable user or directory quotas on the destination volumes. Otherwise, the Migration Wizard may run out of space when copying compressed files and will create zero byte files. If quotas were used on the source server, the migration wizard will automatically enable quotas on the destination server in step 4 of the migration.
Make sure you do install a license on the destination server, but you can use the demo license found on the NetWare installation CD. Just point the installation program to the LICENSE directory of the installation CD when the install asks you about the license. It is not needed to install your real licenses as whatever you license you install will be lost anyway after the NDS migration.
If you plan to install additional products like Groupwise, ZENworks, Antivirus, Backup, wait till after the migration until you install them.

Warning: If your destination server is a NetWare 6.5 SP6 server, don't install IPX on the destination server. There is a bug in SP6 that causes the SMS components (SMDR, TSAxxx) to fail communicating if IPX is installed, even when IPX is not used. If you need IPX on the destination server, only install it after the migration. If you are migrating from NetWare 4.x to 6.5, install NetWare 6.5 SP5 on the destination server and not SP6. While not confirmed, the bug probably also exists in SP7.

Verify your eDirectory version

You should make sure that the destination server does not ever have an eDirectory version lower than the source server. This is especially the case if the source server is a 5.1 or 6.0 server where the eDirectory was upgraded at some point and the destination is also NetWare 5.1 or 6.0. Also pay attention to the following fundamental incompatibilities:

the destination server should not be running eDirectory 8.6.x. There is a problem with this eDirectory version that can cause the Migration Wizard to fail during the NDS migration. So, if the destination server is a NetWare 6.0 server, make sure you upgrade it to eDirectory 8.7.3.

if you plan to migrate to eDirectory 8.8.x, then your destination server must be running eDirectory 8.8.2 (or 8.8SP2) and you must be using the Migration Wizard 8.2. Earlier versions of eDirectory 8.8.x will cause the migration to fail and earlier versions of the Migration Wizard will not support eDirectory 8.8.x.

avoid migrating from older eDirectory versions to eDirectory 8.8.x. Such migrations are prone to fail with the problem described in TID3395192 or other problems were the database on the destination server fails to open. If you want to go to eDirectory 8.8.x, then migrate to eDirectory 8.7.3.x and only do the upgrade to eDirectory 8.8.x after the migration is finished.

Clean up your AUTOEXEC.NCF

Only on NetWare 6.5 servers:
Aat the end of the installation, when the install asks you to reboot the server, do not click on the button yet, but use ALT-ESC to switch to the console screen and there type Ã¢â‚¬Å“EAÃ¢â‚¬Â to edit your AUTOEXEC.NCF.
In your autoexec.ncf, you can put a REM in front of the following lines:
SYS:\SYSTEM\NMA5.NCF (unless you have an SNMP based management platform which you want to use to mange your NetWare server)
AFPSTRT.NCF (unless you have Macintosh computers that need to access your server)
NFSSTART (unless you have Unix machines that need to access your server through NFS)
OPENWBEM.NCF
?STARTX

Then locate the line Ã¢â‚¬Å“MOUNT ALLÃ¢â‚¬Â, and add the following line just before it:

NSS /NCPDisplayNonTranslatableNames

In non english speaking countries, this option is important if you have file names with extended characters. The option only exists in NW65SP5 or later.

After having made these changes, switch back to the GUI screen and click the button to reboot your server

Tune the server

Load monitor using the command:

LOAD MONITOR !h

Go to Ã‚Â« Server Parameters Ã‚Â», and change the options in the following categories

Update the HOSTS file

Edit the file HOSTS in SYS:ETC. Clean it up to remove all sample entries except for localhost and the server itself. Then add an entry with the name and IP address of the source server. This will ensure that the file copy will not suffer from possible name resolution problems during the migration.

Backup the NDS

Make a backup copy of the NDS of the destination server using the command:

LOAD DSREPAIR -rc

Preparing your migration workstation

Make sure the workstation verifies the recommended configuration as mentioned earlier and then install the correct version of the Migration Wizard to the PC. Especially if your PC happens to be a laptop, verify the power options of the PC and make sure that it is configured to never go into sleep mode.

Connecting your servers and your workstation

For reliability reasons, make sure the source server, the destination server and the migration workstation are all connected to a same switch. Personally, I always use a small 5 port gigabit switch to which I connect the 3 computers and which in turn I connect to the remainder of the network. That way, IÃ¢â‚¬â„¢m sure I have a reliably and fast migration network. Also, given that the file migration can take some time, I would recommend the 3 computers and the switch to be connected to an UPS so that they can survive a power outage.

The Migration

The migration itself is a 5 step process. There is a first step (which I call 0) at startup, and then the Wizard itself presents a menu with 4 other steps.

Step 0: starting the Migration Wizard and modelling your project

If you installed the SCMT 1.1, then you actually have the main SCMT program which you can start and which will guide you through a number of questions upon which it decides whether you want to do a Migration or Consolidation.
However, you have the option to go straight to the Migration wizard 8.1 by using the following menu sequence:
Start -> All Programs -> Novell Server Consolidation and Migration Toolkit -> Tools -> NetWare Migration Wizard 8.1.
For the Migration Wizard 6.5, the situation is simpler. You just have one tool, and it starts you out with the Migration questions right away.

Once you have launched the Migration Wizard, you create a project, and select source and destination servers and you start modelling your project by dragging and dropping volumes or directories from your source server to your destination server. The easiest migration is you do a one to one copy where the destination server has exactly the same volume names as the source server. In that case, there are no adjustments to be done to scripts or configuration files that may refer to volume names. You can however also copy directories or volumes to volumes with different names. This is for example useful if your old server only had a SYS volume with the data on the SYS volume and on your new server you want to keep SYS separate and have a new volume for all your data. In that case, I would recommend you to drag and drop the complete SYS volume to the new destination volume. In case of volume remodelling, extra NDS operations are recommended at step 4 of the migration later on.

Special considerations regarding the SYS volume

If you have the simple case where source and destination server have the same volume names, special care must be taken with the SYS volume. By default, the Migration wizard will create a directory SYS.MIG on the destination SYS volume which will contain the root directory and all the system related directory of the source server. This is done to ensure that you donÃ¢â‚¬â„¢t overwrite system directories of the new server will old stuff from the old server. If there are additional directories you want to migrate to the destination server while keeping the original location, drag and drop these directories one by one. Avoid blindly copying directories that might conflict with already existing directories on the destination server. For instance, overwriting some system related directories could result is serious malfunction of the destinations server later on.

Print Queues in Special considerations regarding the SYS volume

Special care also needs to be taken of the printing related directories. If you have print queues on your old server, make sure you drag and drop the QUEUES directory from the old SYS to the new SYS volume. For this directory, you will get a conflict warning because the directory QUEUES already exists on the destination server. Resolve this conflict by using the Ã¢â‚¬Å“merge allÃ¢â‚¬Â option. For NDPS/iPrint, make sure you drop and drop the NDPS directory from the source to the destination server. This time you should not get a conflict because if you followed the instructions, NDPS/iPrint should not yet be installed on the destination server.

Modelling Complete

Once you have finished modelling your project, you click on the Ã¢â‚¬Å“Verify and MigrateÃ¢â‚¬Â button. After verification that your project is OK, you get the screen with the 4 migration steps numbered 1 to 4.

Step 1: Copy File System Data

Click on button Ã¢â‚¬Å“1Ã¢â‚¬Â to start the data copy. You will get a number of additional questions regarding your data copy, for instance what to do in case of conflict and whether you want to filter by type or date. This is useful if you run the data copy multiple times. You can indeed rerun step 1 of the migration as many times as you want. In subsequent runs in that case, it is useful to only copy newer files. You also have the option to copy with users active or with login disabled.

Warning: You should never disable login yourself on the server console during the migration process. This would in fact cause the migration to fail. Only the Migration wizard should be allowed to disable login.

Once you answered all the questions, you will get to the point where the Migration Wizard will install/update NLMs on your source and destination servers and load them. NLMs that are for instance updated are SMDR.NLM and TSAxxx.NLM. If you have old versions of these NLMs loaded and they have been used by a backup program after the last server restart, there is a risk that your source server will abend upon the unloading of the old versions of these NLMs. ThatÃ¢â‚¬â„¢s why it is important to follow the instructions on preparing the source server before the migration.

Next, the Migration Wizard will backup the trustee and file ownership information and then it will actually copy the files. The time estimate during the trustee backup just counts for the trustee backup itself. To get an estimate how long the file copy will last, you will have to wait until the copy actually starts and best wait some 15 minutes into the file copy. The copy speed is not constant during the whole file copy. While copying big files, the throughput is high and while copying small files, the overhead is much higher and so the copy speed is lower. Because of this, the estimate can always vary. Apart from that however, the estimate given by the Migration Wizard 8.1 tends to be relatively reliable. The Migration wizard 6.5 however can give very bad estimates when the files on the source server are compressed. In fact, in that case, the file copy can sometimes take twice as long as estimated. Furthermore, the progress indicator continues based on the original estimate. That means you reach 99% of the copy in the estimated time, but the last percent can take very long.

Once the copy has finished, make sure you check the error log to see if any files were missed. You will always see a couple of files that could not be copied because they were open. You need to see yourself which of these files are just temporary system files and which files are important data. Another error you might see is error 0xFFFDFFF4. This is actually not really an error but just indicates that a file was not copied because it has the same date or is older than a file that already exists on the destination. This happens if you run step 1 multiple times and you choose the option Ã¢â‚¬Å“overwrite with newer onlyÃ¢â‚¬Â. For performance reasons, if you rerun step 1 just to catch files updated since the first run, include a date filter filtering on the last modified date. This avoids every single file being compared and will greatly reduce the time needed for the delta copy.

Warning: If during the file copy, one of the 3 machines (the 2 servers or the workstation) crashes, reboot the 3 machines before rerunning the file copy or proceeding with the next step. Other, the remaining machines will not properly close the file copy and the next migration step will fail.

Note: Step 1 is mandatory. You have to run it at least once in order to be able to continue your migration. If however you decide to use a different way of copying your data, you can simply do an "empty" run of step 1 where you don't select any data to be copied.

Step 2: Edit Configuration Files

Step 2 is actually a step where the Migration Wizard doesnÃ¢â‚¬â„¢t do anything. ItÃ¢â‚¬â„¢s a step suggesting you to manually edit some configuration files. I suggest that at this point, you make the following changes:

Assuming you want the destination server to take the IP address of the original server (which generally you want), itÃ¢â‚¬â„¢s now the best time to edit your AUTOEXEC.NCF and change the IP address to what it should be later once the destination server has taken over. I suggest not to use INETCFG.NLM yet as this point because editing AUTOEXEC.NCF is easier at this point and you can always use INETCFG.NLM after a successful migration.

Also change the TIMESYNC configuration so that the destination server will take the time from the same source as the source server. This will ensure that your clocks are in sync and that step 3 of the migration will not complain about unsynchronized clocks later on. Do *not* edit TIMESYNC.CFG as indicated in the documentation, but instead change the TIME settings in MONITOR.NLM. This will automatically update TIMESYNC.CFG for you.

If you want special SLP options and an SLP.CFG file, it is also now a good to configure them

If during your migration, you plan to change the volume names, now is the moment you should rename the NDS volume objects for those volumes were the name will change. For instance if you want to migrate the old SYS volume to a new DATA volume, you should rename the volume object SERVER_SYS to SERVER_DATA. Doing this ensures that all NDS references to the volume object (like home directory properties of the users) will follow the name change.

The following things should *not* yet be done as it is too early:

Do not edit the SYS:\ETC\HOSTS . Step 3 of the migration will make modifications to the HOSTS file. These modifications are generally not what you want if you have changed the serverÃ¢â‚¬â„¢s IP address as indicated above. Therefore, you generally need to modify the file HOSTS after step 3 anyway and so any edit you do now is just wasted time.

Do not add servers to your AUTOEXEC.NCF. Your destination server is installed in pre-migration mode. As such, most of the required services are not yet installed and putting those services into AUTOEXEC.NCF now will just confuse the installer later on.

Step 3: Begin NDS/eDirectory Migration

Step 3 is the most critical step of the whole migration process. ItÃ¢â‚¬â„¢s during this step that the actual identity of the old server is transferred to the new server and the old server is shut down forever (unless you do a special recover operation explained in the troubleshooting section). So make sure you have resolved all problems from prior steps and you are sure you copied all files you need. After step 3, it becomes much more difficult to still get files from your old server. It is also important that the NDS on the source server is absolutely healthy before this step or else the migration might fail, or existing problems might get worse.

Note: The button for step 3 will only become active if you have at least once run the file copy of step 1.

The actual NDS migration in step 3 consists of 3 major operations:

The NICI configuration files copy. This is done by floppy disk or by network. For version 6.5 of the Migration Wizard, the floppy disk method is the only method available. In that case, it is important that you have a working floppy drive both on the source and the destination server. Given the source server might have been running for year, dust may have gather in the floppy drive and therefore it is important to clean the drive as otherwise, the migration is likely to fail.

Next, the configuration files (AUTOEXEC.NCF, HOSTS and a couple of other files) are updated on the destination server to reflect the identity change of the server. This will also udpate the timesync configuration to match the source server.

Finally, the NDS is backed up on the source server, the source server is downed and the NDS backup file is updated and restored on the destination server.

Warning: If there are users with open files on the source server, it will not down automatically. It will show you the open files and ask you whether you really want to down the server. That question will however be replies negatively by additional commands sent to the server console. So be sure that on the source server, you switch to the main console screen, and if needed, execute the down command manually.

Note: The destination server can take a very long time to reboot. Give it a couple of minutes. Once these steps finished the destination server is also rebooted and step 3 is over.

Step 4: Finish the NDS/eDirectory Migration

Before executing step 4 in the migration wizard itself, you should reboot your migration workstation and also make the following changes on the server:

Edit the files HOSTS and HOSTNAME in SYS:ETC. This is especially important if you changed the IP address of the destination server in step 2 of the migration. Failing to update HOSTS and HOSTNAME will cause some products installed later to receive incorrect configurations. If you want to use your old HOSTS and HOSTNAME from the source server, you can use TOOLBOX, TBX or any similar tool to copy the files from SYS:\SYS.MIG\ETC to SYS:ETC. Only copy exactly the files your need. Do not do wildcard copies.

If you did a major NDS upgrade during the migration, you should run the following DSREPAIR options:

If the previous DSREPAIR reports schema problems for RBS and tells you to run DSREPAIR at a root server, or if you did an upgrade from NDS7 or older to eDirectory 8.6 or later on a non root server during the migration, then do the following in DSREPAIR:

Repair your volume objects. This will ensure that your volumes on the new server get attached to the old NDS volume objects. For this, do the following in DSREPAIR:

Advanced options -> Check volume objects and trustees

Run the back-linker process to verify and repair external references. For this, execute the following console commands:

SET DSTRACE=ON
SET DSTRACE=+BLINK
SET DSTRACE=*B

Verify whether your server acquired its license by typing the following command at the server console:

VERSION

Verify and fix your certificates by running PKIDIAG.NLM

Now you are ready to run step 4. Step 4 of the Migration Wizard will restore the trustee, file ownership and quota information.

Note: If for some reason, step 4 fails, you can rerun it as often as you want, and if you followed the instructions on server preparation, you can also use TRUSTEE.NLM to restore your trustee information.

Post Migration tasks

Now we are ready to install any additional products. First install any additional products you need that are included with NetWare, and then install any posisble other software you need (Groupwise, ZENworks, Backup software, Antivirus ...).

NetWare 6.5

For this, you need the NetWare 6.5 Overlay Products CD or the NetWare 6.5 overlay DVD matching the support pack you used to install your destination server.

Tip! On NetWare 6.5, you can also copy the CD image to the server and mount it using the command:

NSS /MountImageVolume=SYS:NW65PRODSP6.ISO

Now start the GUI environment using the command STARTX and from the Novell menu, select Install.
Select the option ADD and browse to the file POSTINST.NI at the root of the installation CD. You will then get a list of products you can install. From this list, install at least the following products even though some of them are already installed. Installing the products again will ensure the appropriate changes are made to the NDS. Ignore the version warnings you may get about some of these products.

Certficate Server

LDAP

NDS iMonitor

NRM

SMS

ConsoleOne

NMAS

If you want to install iManager on your server, you need to install the following additional products:

Apache2 admin server

Tomcat admin

Apache2 web & Tomcat

iManager

Tip! If you want iManager to immediately run after the installation without having to reboot your server, execute the following 2 commands *prior* to the installation of Apache2 and Tomcat:

SEARCH ADD SYS:/APACHE2
SEARCH ADD SYS:/TOMCAT/4/BIN

Older NetWare versions

The post install procedure for older NetWare versions is similar to the one above. I just have no list of default products to install for those platforms. Check for wiki articles to see if there are any recommendations for that version at wikiCatagoryLink.

Troubleshooting

Important TIDs regarding Migration issues

TID2961749 NSS update for Nw 6.0 pre SP2. This update is no longer available and you should only use SP5 on NetWare 6.0 anyway.

How to recover from a failed migration

The good thing about the Migration Wizard is that the source server can always be placed back into normal operation mode. Therefore, except for a bad hardware failure of the source server, you always have a way to bring the source server back to life. Let's see how to recover at the different steps of the migration.

Step 1 (Data copy)

The data copy is not destructuve to the source and destination servers. Also, step 1 is restartable. So if step 1 fails, you can start it over again and again. One important rule is that with fatal failures during the data copy, often there remain open SMS connections between the servers. These will lead to possible failure of further copy attempts. It is therefore important that in case of a fatal failure during the file copy, you reboot both the source and the destination servers so that they are in a clean state again.

Here are some common problems that may occur at the beginning of or during the file copy:

Abend of the source or the destination server. Sometimes, you might get an abend right at the beginning of the migration when the Migration Wiuard tries to unload the old SMS modules (SMDR.NLM, TSAxxx.NLM) and load the updated versions. With this kind of abend, it is just enough to restart both source and destination servers and start over again. With other abends you should more closely investigate what the reason for the abend could be. First recheck whether you applied all the recommended patches and did all other other recommended preparation stapes, and if none of these help, the debug your abend the "usual" way by looking at the abend.log file, searching the knowledgebase and askin for help int he support forums or using any other type of support resource.

Lost workstation connection during the migration. The file copy itself is actually done by NUWAGENT.NLM using a direct SMS connection between the servers. The workstation just monitors the copy process, receives the error messages and sends the instructions on what to do next. If for any reason, your workstation looses connection to the servers while doing the data copy, then the servers will continue with their current job until it is finished, and then they will get stuck waiting for an acknowledgement from the migration workstation. As this acknowledgement never arrives, the copy step never really finishes, and if you try to rerun the copy, you get a bad failuer. Therefore, if for some reson, your workstation lost its connection, it is important to once again reboot both servers after they have finished with the copy they were busy doing.

SMS errors while starting the data migration or no migration with no errors at all.

Migration successful but errors in error log for certain files

Step 3 (NDS migration)

A failure during the NDS migration seems to be most scary because after the NDS migration, the source server is no longer operational. However the source server can easily be revived as described here in the documentation. It is important that if you restore the source server that way, you take care of the destination server which might already have taken the name and address of the source server. So you may have to disconnect the destination server from the network (to avoid conflict) and return the destination server to its temporary state.

Step 4 (finish NDS migration/restore rights)

One issue a couple of people may have seen after step 3 is that the Migration Wizard did somehow not correctly record the success of step 3. In that case, step 4 is greyed out and cannot be selected. This is described and a fix is given in TID10100982. It is important to verify that step 3 was really successful and that the destination server has taken the identity of the source server and is already correctly integrated in the tree.

Common error messages and their resolution

%s is a NetWare 5.0 server. Install NICI patch 1.5.7 or newer on this server before proceeding with the migration, or data loss will occur!

If your server is running NDS7, you can safely ignore this message. If your server is running NDs8 or later, you should upgrade yopur server NICI to 1.5.7 as indicated by the error message. See the section about preparing the source server for more details.

Server 'NAME' won't return the correct time.

The complete error message is:

Server 'NAME' won't return the correct time. Please check the timesync status on this server.
--- Error caused by a NetWare API error ---
This error means that the error code returned has different meanings for different functions.
(Error code: 0X89fb Function Name: NWGetFileServerUTCTime)

This error can happen on NetWare 6.5 servers and is caused by the server using XNTP.NLM instead of TIMESYNC.NLM and NCP support for XNTP.NLM being turned off. The solution is to modify the file SYS:\ETC\NTP.CONF and remove the option NONCP from it. This is also described earlier in this document.

Invalid Microsoft Data Access Components (MDAC) version

The Migration Wizard stores the project configuration in an MDB file and the MDAC components to access the MDB file. If you get a message about your MDAC components being too old, you need to get the latest update from the Microsoft web site and install it. It is however a bit strange that the Migration Wizard is so picky about the exact version given the quite limited usage. The MDB database created by the Wizard is very small and the bulk of the data like for instance the file ownership and trustee information is not stored in the MDB database but rather in a Novell specific file format on the server itself.