INTEGRATOR'S BLUES - Part 2

by Wayne M. Krakau - Chicago Computer Guide, November, 2002
This is the continuation of my adventures in migrating from a Novell NetWare 5 server to a new NetWare 6 server. At this point we have suffered through two marathon weekends, several weeks apart, thwarted by a combination of human errors and multiple software errors in both NetWare and Veritas Backup Exec. This exercise has descended well into the "Sometimes the bear gets you" category.

Now that we knew that the attempt to back up a NetWare 5 traditional volume and restore it to a NetWare 6 NSS (Novell Storage Services) volume (which I unaccountably misnamed Novell Storage System last month - oops) caused our latest failure, we attempted another migration a few months later. This time we would migrate all of the volumes, no matter how long it took.

I had the idea to duplicate the existing production NetWare 5 server and then use the duplicate for the migration, thereby relieving us of the necessity of completing the job during one weekend. We could start the migration earlier in the week while the production server was still running, and then update the new server with any changed data later

After spending many hours in repeated attempts at duplicating the production server, the administrator ran into insurmountable bugs in Backup Exec that were confirmed by Veritas. So much for sneaky ideas. The bear took another swipe at me.

On our third migration attempt, we ran into a problem with server-to-server communications. The two servers became confused as to whether to talk IP or the older IPX. After consulting with Novell, this time using one of my dealer technical incidents, we elected to set both servers to talk only IPX. The technician reminded us the while IP was appropriate for larger networks, IPX could easily outrun it on a small network like ours, which included only the two servers and one workstation. The prediction turned out to be true, as we migrated all of the volumes using IPX in less time that it took for just the first two using IP. We were quite pleased with ourselves.

Then the bear growled again. The eDirectory (formerly NDS) had obsolete information on users, printers, and queues, and the file system had obsolete rights assignments, all left over from the previous migration attempt. This time the folks at Novell were sympathetic and let us continue using the same support incident.

With Novell's help, we figured out that the Migration Wizard, the workstation-based program that controls the various steps involved in the migration process, had failed to automatically delete the files that it uses to temporarily store eDirectory and trustee (file rights). That's why we got the old information. This bug has since been fixed.

By the time the Novell technicians had figured out how to manually erase the obsolete information and transfer up-to-date information to the new server, eleven and a half hours later, it was again very late on Sunday night, so we had to give up and go back to the old server again. Thus, ended my longest support call ever. The bear had taken another bite out of me.

As we reconvened a few weeks later for yet another migration attempt, I had the distinct feeling that, if this try failed, the system administrator would see to it that I wouldn't be leaving the building by either the elevator or the stairs. I knew that I had the opportunity for only one more battle with the bear.

Finally, the migration ran cleanly. Then we started the post migration tasks, including testing printers, installing and testing new software versions, and testing the preexisting software.

In his last gasp for life, the bear launched one final attack. This client owned Tobit's David, an e-mail system that also included Tobit's network fax system, FaxWare, but they only used the FaxWare half of the product. Now, FaxWare didn't work.

We inspected the new server and realized that some undetermined critical files were copied to an archival directory, not to the one where they started. Rather than experimenting to try to fix the problem, we saw this as an opportunity to implement our plan to move the fax system to a communications server. After installing David (along with FaxWare) on the communications server and moving over all of its data, we ran into another problem. While FaxWare actually sent and received faxes, all of its phonebooks and fax archives were inaccessible. After many attempts at fixing the problem, we finally had to give up.

The system administrator called Tobit the next day and they walked her through reinstalling David on the new NetWare 6 (the migration target) server. It worked, but that didn't solve our long-term problem of moving the fax system to the communications server.

That's when they told her that they had purposely designed FaxWare so that it could NEVER be moved to another server. The original server name is embedded in each and every page of every incoming and outgoing fax as well as every individual phonebook record. FaxWare will not acknowledge the existence of any file with a different server name, so moving the system to a different server is not practical, unless you don't mind giving up your accumulated fax history and your phonebooks. I do hope that whoever thought of that bright idea is no longer in the computer industry and, therefore, can't do any more damage.

Well, the final score was the bear 3 and us 1, but the final victory was ours. I do, however, think that the bear died with a smile on his face, knowing that he left behind one final, and ultimately unsolvable, problem. Meanwhile, maybe I can find a job in a less stressful field, like lion taming.

©2002, Wayne M. Krakau