If you are running NetWare, chances are that Novell and its representatives have been spending a great deal of time trying to get you to upgrade to 4.1, the latest and greatest version of its operating system. And if you haven't yet taken the plunge, you'll want to read the next three columns. If you are still running version 3.x NetWare, getting to 4.1 isn't easy or free of problems. You'll need to plot your strategy carefully. I've installed various versions of NetWare over the years, starting with what was called Advanced NetWare 286 back in the dark ages of the mid-80s. And, to Novell's credit, things do improve from one version to the next. However, that is a far cry from saying that it is a snap, especially if you have multiple servers running multiple versions of their operating system. I went to downtown Los Angeles to observe what one of that city's agencies was doing with their NetWare upgrade. My host was Chip Rubin, who works for the city's Deptartment of Public Works in the Bureau of Engineering, and maintains about 20 NetWare servers around town. Now, the words around town don't really give his empire justice: he has servers that are located more than 30 miles from each other and are still within LA city limits. Rubin's servers span the gamut from 3.11 to 4.02, and he was ready, willing, and able to bring everything up to 4.1. "We've been using NetWare 4.x for over a year," said Rubin. "It took us some time to develop the naming standards for Novell's NetWare Directory Services (NDS) and some of these have already been adopted by various other city agencies as well. We wanted to be sure that when everyone was up on NDS, we could merge our trees without having duplicate or conflicting names." Rubin came up with an eight-character scheme for all network resources: the first two characters indicate the city department code, the third position is the type of resource (file server, tape server, printer), and the last five characters indicate division and node numbers. "While these tend to produce rather cryptic names for servers -- such as 78F99002 -- it really doesn't matter," said Rubin. "Under NDS, users don't have to deal with file server names. We really wanted the eight character name to make it easier to identify network resources compliant with the DOS 8.3 file/directory standard." Speaking of names, since we had seven servers, we decided to name them after certain small characters in a famous movie. By the end of the weekend, it was an easy task to match their personalities accordingly. But I am getting ahead of the story. He, along with four others in his group, decided to do the upgrade in three separate stages: Stage one was a long weekend in April in which they would bring up two 4.1 servers, understand the processes involved, and work out any kinks. Stage two was during another long weekend where I flew into town and helped them upgrade five servers in their downtown headquarters. And the third stage was to deal with the remaining servers in the outlying regions. To prepare for stage one, Rubin and his merry gang first collected several tape backup mechanisms so that they would have at least two and in some cases three independent backups of each server. That was a good idea, as you will see: the process of upgrading NetWare involves a great deal of time intentionally restoring data (as opposed to doing so under some duress for some mishap) to a server at various times. The engineering bureau uses Intel's Storage Express as its primary backup device. This is essentially a PC without a keyboard that has (in this particular configuration) a DDS-2 tape drive and a 6-tape DDS-2 autoloader. The Storage Express box came in handy at several points in the process, mainly because it is a very high-throughput machine, and you can run several jobs concurrently on the thing. Our secondary backups were two different setups: we had a Maynard 2000 drive that was attached to another PC running MaynStream software, and another PC with two other Maynard drives running Cheyenne's ArcServe 5 backups. The former was used for the 3.11 servers, while the latter was used to backup 4.x servers (ArcServe is one of the few software products that can backup directory trees under Directory Services). And we had a third-tier of backups as well, an HP JetStore 2000 drive that was attached to a PC running Cheyenne's ArcSolo backup software. We needed all of them, at one time in the process or another. Next week, we'll describe the actual process that Rubin and his gang used for the upgrade. Col #26 Upgrading to NetWare 4.1 should be easier than it turned out to be. It turns out that you'll need your own twelve-step program to get your servers running this latest version of Novell's operating system, and after you are finished, you may need to check out other twelve-step programs for your own self. We were working with the City of Los Angeles' Bureau of Engineering. The bureau has 20 servers scattered around town, but our immediate task was to tackle seven servers that they had at their downtown headquarters. Our seven servers were all on the same token ring segment: the city engineering bureau found that this made their network operations more stable and easier to manage. Most of their servers were variations on IBM PS/2 model 95s that were running older IBM LAN cards, had differing megabytes of RAM, and were running out of hard disk storage. To add insult to injury, each server was running a different version of DOS as well. Chip Rubin was my host for the upgrade and the systems analyst in charge of the project. He and his staff decided to kill all these birds with the 4.1 upgrade and also bring up each server to two gigabytes of storage and 32 megabytes of RAM. So step one was to collect the software and hardware needed for the upgrade. However, we had one problem: we couldn't find the upgrade software that Novell had shipped to the city. Rubin had purchased his copies of NetWare from a Novell reseller, and the upgrades to 4.1 were free as part of the promotion at the time. Unfortunately, they had gotten lost in the mail. After several calls to Novell failed to turn them up, he asked me to try to use my own contacts to locate them. Thanks to Noreen Theede, head of Novell's PR department, we did find them, (they were mis-addressed and had been returned to Novell) and Novell shipped them back to Rubin. When they got the software, they were once again mis-addressed (only this time they did have Rubin's name on them). "Luckily, our United Parcel driver knows me. Otherwise, we would still be trying to find them," Rubin said, showing me a range of address labels he preserved when I visited him at the end of April. The second step was to make backup copies of all the servers involved. As I mentioned last week, we had gathered quite an array of systems to do this, just to make sure that we had valid copies of all data. We did the upgrades over two weekends: the first weekend was more of a shakedown to work out the process that we would use for the other servers. We managed, in fits and starts, to get two servers upgraded, which we called Bashful and Happy. (The bureau uses eight-character names for its servers, but for journalistic purposes we came to mutual agreement on our own naming scheme.) Our third step was to clean up (called a purge by Novell) any deleted files that were still present on the existing servers' SYS volumes. We found during our initial upgrades of Bashful and Happy that these purges hadn't been done in some time, and that deleted files were taking up lots of room that would be needed to install the new 4.1 software. So far, so good. Now came step four and the act of courage, to shut down each server and add the new RAM and disk drives to the box, and upgrade to DOS 6.22. This wasn't too hard, except we had to remove the HIMEM.SYS commands in CONFIG.SYS that the helpful DOS installation routines put there (they are incompatible with NetWare, of course). Next week, I'll continue with our tale with the real meat of the matter, when we actually started the upgrade process. The long and winding road to upgrading NetWare 4.1: 1. Purchase new hardware for each server: IBM LANStreamer token ring adapters, new RAM and disk drives. Collect the NetWare 4.1 upgrades needed. 2. Make backup copies of entire server. 3. Purge all deleted files from SYS: volume. 4. Down the server, add RAM and disk. Backup the old DOS partition. Create a bootable DOS partition on the new drive, so as to increase DOS partition to 30 megabytes and upgrade to MS-DOS version 6.22. Also increase size of SYS: volume so that 50 megabytes are available for the upgrade. 5. Start the in-place 4.1 upgrade process from the DOS partition via client access to CD-ROM on an already upgraded 4.1 server. 6. Make a new backup of the new 4.1 server created from this upgrade. 7. Delete and recreate all the remaining volumes via INSTALL loaded from the DOS partition, increasing the volume block size to 64Kb and setting 4.x volume optimization features ON. 8. Run upgrade process a second time to create a valid SYS: volume so that the server can be logged in to for a tape restore, increasing block size to 64 kilobytes. 9. With a "minimum" server up and installed in NDS, create a NDS replica; establish a valid bindery context; and wait for NDS to do its thing. 10. Restore the backup tape created in step 6. 11. Clean up AUTOEXEC.NCF and update the DS.NLM to version 4.77b. 12. Test all existing NLMs and start the upgrade any to 4.1-compliant releases. Col #27 Upgrading to NetWare 4.1 can be a long process, especially if you have a mixed collection of versions or if something goes wrong. Based on the work I did at the City of Los Angeles Bureau of Engineering, something almost invariably will go wrong. Last week I described the first four steps in our twelve-step program. Let's continue with our fifth step, which is where the actual in-place upgrade (Novellese for morphing your older server into a new version) begins. Novell has made things easier than ever, with just a few questions to answer before the upgrade gets going. We started with the server we called Dopey, which was running 3.11. Eventually, Dopey had to be abandoned because the CPU processor card connected to its motherboard was defective, which we uncovered when we added more RAM. We suspected something was wrong when we couldn't mount the SYS volume, do a VREPAIR, or run anything besides DOS on this machine. And, to make matters worse, Dopey's backup on the Intel Storage Express was mangled, so when we finally got a replacement server cobbled together, we had to use one of the other backups. Grumpy was our next server to get going, also another 3.11 machine. He managed to be our first machine that we got up and running on 4.1 that weekend, coming on-line at 2:15 pm, eight hours after we began. "This was still four hours faster than our first install with Bashful, so we were making progress," said Chip Rubin, my host and team leader for our upgrade soiree. But I am getting ahead of the story. We had some problems with other servers during this step: Sleepy couldn't log back into the server that had mounted the 4.1 CD ROM drive for some reason, so we had to down him and put another CD drive on to continue. This login is part of the convoluted automated install process, and it could have been caused by a slow router on the city's internal network. Server Doc also had this problem, but luckily when we retyped the password we got our login and continued on the install. The next step is to make a backup tape of the data that is now on this server. We'll need it in a moment. Then step seven is to delete and recreate all the remaining volumes via INSTALL loaded from the DOS partition, increasing the volume block size to 64Kb and turning on the setting for 4.x volume optimization. Why did we do this? We wanted to avail ourselves of some of the newer features of the 4.1 operating system, and one of them is to scrounge for extra space when it can. (Novell calls this sub-block allocation). However, our server had been setup with the existing 16 kilobyte block sizes, which don't do much under 4.1. To really take advantage of this feature, we had to down the server and perform a second installation routine, this time with the block size set to 64 kilobytes. That went relatively well, and none of the servers had problems at this point. However, in order to change the block size you basically have to start from scratch, meaning that you have to erase your data and run the install routine. Step eight was to run the upgrade process a second time to create a valid SYS: volume. so that the server can be logged in to NDS for a tape restore The rest of the process went quickly, and without too many problems. We had to create an NDS replica, establish a valid bindery context, and wait for NDS to discover the new servers. We restored the data that we had already backed up, which went reasonably well, with no surprises, which was good because by then Rubin's staff (including analysts Mark Haprov, Ernie Tsui, Karen Mallory, and Ray Uyemura) was feeling kind of punch-drunk. Next was to clean up our AUTOEXEC.NCF and update the DS.NLM to version 4.77b. Since Novell released the 4.1 software, they have since made some adjustments to their directory services NLM and have a new patch. The final step was test all existing NLMs and start to upgrade any that had released versions that were 4.1-compliant. What a weekend! However, we still had some problems. A few days later, Rubin tried to login to the network. I'll let him tell the story: "I received a message that the supervisor had locked me out ot the server. Curious, since I'm the big cheese, I tried numerous servers and got the same message. To my utter shock, there was no tree, no context, no network ... a complete NDS meltdown! Earlier in the day, we had had an IBM LanStreamer freak out in sending bogus frames around the net. I can only figure that those corrupted frames somehow adversely impaced NDS replicas, perhaps causing the meltdown. We ended up running DSREPAIR on all servers to get things back on-line. It is inconceivable to me that an NDS meltdown like this can happen. " Well, I hope I have given you a good feel for what went on during our 4.1 upgrade. Obviously, this is nowhere near as easy as it could be, although I give Novell some credit for making the 4.1 install easier than earlier versions. Hopefully, you all have learned a few things from my saga, and will plan your upgrade accordingly.
Click here to return to the previous
page
David Strom
Port Washington, NY 11050 USA
US TEL: 1 (516) 944-3407