MIGRATORY PATTERNS - Part One

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

The gentle whoosh of the wings. The plaintive honk, honk, honk - splat. (Oh, well, I needed a car wash, anyway.) Yes, it’s time for our feathered friend, the Canada Goose, to migrate. It’s also time for our computerized friend, the LAN administrator, to migrate, too. Only this migration uses MIGRATE.EXE to upgrade to NetWare 4.1 and doesn’t necessarily involve travel - unless, of course, the migration fails and your company asks you to leave!

The migration process is complicated, not always particularly logical, and is infrequently encountered, so my first bit of advice is the old standard, RTFM - Read The "Friendly" Manual! (You’re correct if you guessed that I have replaced the real, unprintable word with the word "Friendly".) I know this is a trite suggestion, and that it isn’t the "macho" way. (Manuals? Manuals! We don’t need no stinking manuals!) Nevertheless, this may be the one time you should consider reading them. I’ve read the manuals, had formal training, and had lots of practice, but I am still discovering new wrinkles in the migration process.

While I will concentrate on using the MIGRATE command while upgrading a NetWare 3.x server to NetWare 4.1, you can also migrate from Banyan Vines, IBM PCLP 1.3 Extended Services, IBM LAN Server versions 1.0 through 3.0, Microsoft LAN Manager 2.0, and NetWare 2.xx, and NetWare 4.0.

Again, I have chosen to concentrate on a migration method that Novell calls "Across the Wire - Different Server", and will give short shrift to the "Across the Wire - Same Server" and the "In Place Upgrade" methods. I have been lucky in that clients have synchronized their NetWare upgrades with their purchase of replacement file servers, so the only one I regularly use is the "Across the Wire - Different Server" method. This is the easiest, safest, and, in terms of the performance of the server after upgrading, the most efficient.

For the "Across the Wire - Same Server" method, you need a workstation with enough storage space to hold all of the data from your server. This storage can be in the form of a large hard disk or a DOS-addressable (looks like a hard drive to DOS) tape drive. Since the data must be transferred twice, once to the workstation and once back to the file server, this method can take a long time. Add in the extra delay incurred by using the tape drive option (tape drives being way slower than disk drives) and you could set yourself up for a very long wait. This method is nearly an all or nothing proposition. If the upgrade fails or simply doesn’t turn out as expected, you may have to completely restore the original server configuration and start over. If you are lucky, you may be able to jump-start the process in the middle - if you are sure that the "copy to workstation" portion of the migration completed perfectly.

The "In Place Upgrade" method is fast and relatively simple to implement, but it is the least safe method. It is a true all or nothing proposition, without any method for restarting in the middle. What’s worse is the fact that you are stuck with the same disk block size that your old server had, usually 4K. NetWare 4.1 works much faster if you set the block size at 64K and let NetWare use its block suballocation feature to maximize efficiency. You lose that capability in this method. An extra complication is that old versions of NetWare used a different method of looking at the structure of IDE drives. If your DOS partition isn’t large enough, you are out of luck. But, then again, this might be just the right time to take the opportunity tom switch to the more appropriate SCSI drives - in your new server, of course.

My favorite is the "Across the Wire - Different Server" method - and, no, it’s not just because I get to sell a chunk of hardware. It follows my long-held belief that during any budgeting for network expansion, always throw money at the file server first. If you need new workstations, for instance, first determine if it would be practical to replace the file server and retire the old one to workstation duties. This way, the server stays up to date technologically, thereby benefitting your entire network. If you extend this principle to include the evaluation of the timing of your NetWare upgrade, you can synchronize your hardware and software upgrades.

This method is the safest way to upgrade to NetWare 4.1, since your old server simply receives a long series of read requests. It is not altered. The required workstation only acts as a go-between to control the process and log progress and error messages. If part of the upgrade doesn’t work right, you can do it over. You can bring up both servers at once and compare them to double-check the results. You can even delay cannibalizing the old server until the new server has proven its stability, providing an extra measure of safety. On one occasion, I had to switch back to the old server on the day after the migration, so I know first hand how valuable this trick can be.

Next month, I’ll cover the process of migration along with my hints for making it easier, including some that apply to new NetWare 4.1 installations.