Difference between revisions of "Migration Wizard"
m (Added reference to "Oldere Netware" re wiki articles)
m (tweak reference)
|Line 333:||Line 333:|
== Older NetWare versions ==
== 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 [
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 [Category:NetWare ].
= Troubleshooting =
= Troubleshooting =
Revision as of 20:28, 14 June 2007
Using the Migration Wizard to upgrade a NetWare server
- 1 Introduction
- 2 Choosing the right migration tool
- 3 Preparing the migration
- 3.1 Stuff you need
- 3.2 Preparing yourself
- 3.3 Prepare your NDS tree
- 3.4 Preparing the source server
- 3.5 Preparing the destination server
- 3.6 Preparing your migration workstation
- 3.7 Connecting your servers and your workstation
- 4 The Migration
- 4.1 Step 0: starting the Migration Wizard and modelling your project
- 4.2 Step 1: Copy File System Data
- 4.3 Step 2: Edit Configuration Files
- 4.4 Step 3: Begin NDS/eDirectory Migration
- 4.5 Step 4: Finish the NDS/eDirectory Migration
- 5 Post Migration tasks
- 6 Troubleshooting
- 6.1 Important TIDs regarding Migration issues
- 6.2 How to recover from a failed migration
- 6.3 Common error messages and their resolution
To help 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 got 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.
Choosing the right migration tool
Migration Wizard 8.1
The latest tool is the Migration Wizard 8.1.512.9 which is part of SCMT 1.1.051209 and is dated 9 December 2005. IT is the version included in SP5 and SP6 for NetWare 6.5 as well as in the SP5 and SP6 overlay CDs or DVD for NetWare 6.5. This version is also available for download at http://download.novell.com/Download?buildid=fxmzE0UYjbs~
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.
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
- 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.
- 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)
- The latest TRUSTEE.NLM available from http://ftp.novell.hu/pub/mirrors/ftp.novell.com/netwire/nsd/trust110f.exe
- (always useful) TOOLBOX.NLM 2.17 available at http://www.novell.com/coolsolutions/tools/13950.html
- a floppy drive cleaning kit in case you are using the Migration wizard 6.5
- a paper printout or a downloaded version of all the migration documentation so that you can look it up at any time
- an Internet connection to get additional information in case you get stuck somewhere
The first thing to do before starting a migration is to thoroughly read the documentation involved. This involves reading at least the 3 following documents:
- this document
- the documentation for the Migration Wizard. See the section above for the links to the correct documentation
- in case your migration is an upgrade, read the install/upgrade documentation for the destination NetWare version.
|Tip! If your destination server is a NetWare 6.5 server, you should read the OES documentation at http://www.novell.com/documentation/oes/index.html and not the NetWare 6.5 documentation which is outdated.|
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.
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.
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, 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).
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.
|Tip! Patches which are no longer on Novell's web site can still be found at http://ftp.novell.hu/pub/mirrors/ftp.novell.com/updates/|
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:
TCP Minshall Algorithm On (doesnÃ¢â‚¬â„¢t exist in NetWare 5.0) TCP Nagle Algorithm On (Off for NetWare 5.0) TCP Delayed Acknowledgement On (Off for NetWare 5.0)
Directory caching - only for TFS volumes (special extreme tuning just for migration)
Directory Cache Allocation Wait Time 0.1 Sec Directory Cache Buffer NonReferenced Delay 600 Sec Maximum Directory Cache Buffers 20000 (possibly less if your server does not have much RAM) Minimum Directory Cache Buffers 1500
Enable Hardware Write Back On Enable Disk Read After Write Verify Off
Dirty Disk Cache Delay Time 0.1 Sec
File system - only for TFS volumes
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.
Clean up your file system
Delete all unneeded files and directories to avoid unnecessarily copying unneeded stuff. Above all, delete support pack source directories, the BACKSPx directories in SYS:SYSTEM, old obsolete clients in SYS:PUBLIC\CLIENTS and old documentation directories (possible leftovers from NetWare 4.x).
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
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 / 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 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.
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.
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:
In non english speaking ountries, 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
TCP Minshall Algorithm On TCP Nagle Algorithm On TCP Delayed Acknowledgement On
Enable Hardware Write Back On
Client File Caching Enabled Off Level 2 OpLocks Enabled Off
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 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 already proposes you to 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.
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 int hat case, it is useful to only copy newer files. You also have the option to copy with users active or with login disabled.
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 i solder 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.
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.
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.
- 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.
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:
LOAD DSREPAIR Advanced Options -> Local Repair -> enable Rebuild operational schema -> press F10
- 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:
Advanced Options -> Global Schema operations -> (login) -> Reset Schema
- 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:
- 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.
Post Migration tasks
Now we are ready to install any additional products.
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:|
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 PRODUCTS.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
- NDS iMonitor
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
|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 | wikilink.
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.
- TID10080270 Server consolidation utility fails to copy files
- TID3213415 Error during Migration Wizard upgrade: "Can't license the connection to server <server name> Please install the licenses"
- TID3272039 Best practices for NetWare Server Migration
- TID3303779 Web Services no longer function after using Migration Wizard 7.1
- TID10100982 Migration Wizard fails in step 4
- TID10100692 Migration Wizard is asking for authentication to the destination tree which is no longer there
- TID10099052 SYS volume fails to migrate. Error code: 0X8998
- TID10098044 Out of disk space when doing step 1 of the Migration Wizard
- TID10095902 ABEND: LockDirectoryEntry called with entry already locked.
- TID10095334 MigWin32.exe - Unable To Locate DLL
- TID10094587 Unable to run Migration Wizard on Windows XP SP2
- TID10093818 DSBackupCreate Xd - An unknown error has occurred.) BACKUP.NDS
- TID10090638 Trying to migrate data from NetWare 4.x to NetWare 6 gives errors
- TID10085486 Migration Wizard step 4 option greyed out or not available
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 failues during the data copy, often there remain open SMS connections between the servers. Tghese will lead to possible failure of further copy attempts. It is therefore important that in case of a fata 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 problema sthat 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 her 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 stepo 3 is that the Migration Wizard did somehow not correctly record the success of step 3. In that case, step 4 is geyed 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 int he MDB database but rather in a Novell specific file format ont he server itself.