MIGRATORY PATTERNS - Part Three

by Wayne M. Krakau - Chicago Computer Guide, July 1996

This is the actual migration portion of my series of articles on moving from NetWare 3.x to NetWare 4.1, concentrating on NetWare’s "Across the Wire - Different Server" method. (In the spirit of a programmer I once worked with who, in the middle of a design meeting on a large commercial project said, "Enough of this planning nonsense - let’s start writing code!" Luckily for him, we were in a windowless conference room, so he couldn’t be forcibly hurled out the window.)

Before you use the MIGRATE command, you must be aware of one its most serious weaknesses. It can either move user objects without passwords, or move them with randomly generated passwords, but it can’t retain their existing passwords. To overcome this, log everyone off your 3.x server and log in as the SUPERVISOR. Go to the SYSTEM directory on the SYS volume and run BINDFIX. Allow BINDFIX to remove outdated data and repair the three bindery files, NET$BIND.SYS, NET$BVAL.SYS, and NET$OBJ.SYS.

Rerun BINDFIX until it runs completely clean, and then run it once more. BINDFIX creates a backup of the existing bindery files with the suffix "OLD". By running it that one extra time, the resulting "OLD" files are copies of the clean files.

Copy these clean files, NET$BIND.OLD, NET$BVAL.OLD, and NET$OBJ.OLD, to the SYSTEM directory on the SYS volume of the new 4.1 server. Rename them back to their original names, using the "SYS" suffix. (It is not necessary to alter their attributes back to SYSTEM and HIDDEN.)

On the 4.1 file server console, load the INSTALL NLM (NetWare Loadable Module) by typing "LOAD INSTALL" at the colon prompt. Select "Directory options (install NetWare Directory Services)" from the menu. Select "Upgrade NetWare 3.x Bindery information to the directory" from the secondary menu. This option will open the bindery files in the SYSTEM subdirectory and use their information to add objects to your new server’s NDS (NetWare Directory Services) tree. The USER objects will retain their old passwords!

The reason that this works is that any time MIGRATE tries to add an object to the NDS tree and finds a matching object already there, it merges the characteristics of the new object into the old one. If you instruct MIGRATE to skip migrating passwords, the password property of each migrated user will be empty and the password of the existing USER object will remain untouched. If you instruct MIGRATE to create random passwords, the new, random password would override the existing password, defeating the purpose of this bindery manipulation procedure.

To run MIGRATE, you need to log into both the old and new servers at once from the fastest workstation you can get your hands on. For the sake of speed, you might even want to isolate the two servers and the chosen workstation on their own cable segment so they won’t be exposed to traffic from other devices on the network.

The connection to the NetWare 4.1 server must be a "bindery" connection. (The 3.x connection will be "bindery" by definition.) Although the documentation states that using VLMs (Virtual Loadable Modules) along with "LOGIN /B" is an acceptable method, don’t believe it! (In Part One of this series I admonished you to Read The "Friendly" Manual - but I didn’t tell you that I would guarantee its accuracy!) MIGRATE will not work properly unless the workstation uses the old ODI (Open Datalink Interface) shell programs, LSL, the MLID (the driver that the network card manufacturer supplies), IPXODI, and NETX (or EMSNETX or XMSNETX). I found out about this documentation the hard way. I migrated a system and only afterwards found out that the users’ rights didn’t transfer to the new server. I have since located a Novell Tech Note mentioning this undocumented requirement for old drivers.

Also, don’t forget that NetWare 4.x and NetWare 3.12 like to speak the Ethernet 802.2 protocol while earlier versions mostly speak 802.3 (keeping in mind that both terms are Novell’s own nonstandard terminology). You must make allowances for this mix. If all of the devices on your network can speak 802.2, then this is the time to switch them. If some can’t, you may need to load both protocols on the 4.1 server. Even if all of them can speak 802.2, you may want to temporarily load both protocols on the 4.1 server to allow for a transition period and to facilitate the simultaneous communication with both servers that is necessary for the migration.

Now, if necessary, create directories to hold the data transferred from the 3.x volumes to the 4.x volumes. If you don’t have an exact match, volume for volume, between the servers, you must design a structure for volume placement. If, for example, you take my suggestion to create a limited SYS volume, and your old server had applications installed on its SYS, you need this type of strategy. After the migration is done, you can move the individual directories to their correct positions using either NetWare Administrator or FILER so you can retain their rights assignments.

At this point, copy the MIGRATE directory down to the workstation’s local drive. This will keep the logging traffic off your server while MIGRATE runs. From this MIGRATE directory, run the MIGRATE command. Select the source (3.x) and target (4.1) servers. When you select what to migrate, you will be given the opportunity to select a specific target for each volume that you selected. That’s why preparing the target subdirectories prior to starting MIGRATE is important.

Finally, unless you are willing to stare at the workstation’s monitor for hours at a time, set the system NOT to pause on errors. MIGRATE considers even the smallest, most harmless warning message as an error, and will stop processing while awaiting manual intervention to get past these "errors".

After MIGRATE is finished, carefully review the seemingly endless log. This is the only way, short of stumbling into their aftereffects, that you will find potentially important error and warning messages. Then use NetWare Administrator (NWADMIN) to inspect the objects in your NDS tree. If you find any anomalies, such as missing rights, improperly assigned home directories, or unassigned group memberships, you can correct them prior to putting the server into production.

I have stopped using the MIGPRINT command for migrating the printing environment. By the time you figure out its bizarre syntax and manage to enter it without typos, you could have created all new print server, printer, and print queue definitions, with the added benefit of making sure that the new print queues don’t end up on the delicate SYS volume. This is also a great opportunity to retire old cryptic device names and to reorganize the printing environment for ease of use.

With the migration and subsequent testing completed, you are ready to release the new 4.1 server into production. For safety’s sake, leave the old server around, just in case there is a problem. That way, you can switch back to it or just manually copy over a critical file if necessary.

It’s time for one last suggestion. It is very tempting to try to implement many other improvements and additions to the network at the same time as you upgrade your server. Please, seriously consider using a staged implementation schedule for these changes. Effecting too many changes at once can strain both your technical and training resources to the breaking point, with the end effect being an unreliable network and panicked users.