Lessons Learned While Upgrading to NetWare 4.1
Articles and Tips: article
Consultant
Novell Consulting Services
CURTIS PARKER
LAN Administrator, State of Utah
Information Technology Services
01 Aug 1996
NetWare 4.1 has brought many benefits of internet working to the state of Utah. With the implementation of a Wide Area Network (WAN) across the state, LAN users and administrators can use their network of servers as one network instead of as a collection of separate servers. The state's e-mail system immediately realized the benefits of servers in a single NetWare 4.1 Directory tree by making login and authentication to those servers simpler. This AppNote chronicles the events involved in migrating the state of Utah network to NetWare 4.1, which was accomplished by the ITS team comprised of Curtis Parker, Lisa Sato, and Jim Sorenson.
RELATED APPNOTES Nov 94 "Upgrading to NetWare 4.01: A Case Study of Canadian Tire" Aug 94 "Using DOS Batch Files to Ease the Transition from NetWare 3" Jan 94 "Novell's Corporate-Wide Upgrade to NetWare 4"
- Introduction
- Analyzing the Existing System
- Preliminary Preparations
- Performing the Upgrade
- Post-Upgrade Challenges
- Conclusion
Introduction
In 1995, the state of Utah decided to update its LAN from NetWare 3.x to NetWare 4.1. This case study chronicles the steps involved in that transition. The upgrade occurred in four phases:
Analyzing the existing system
Preliminary preparations
Performing the upgrade
Post-upgrade challenges
In this AppNote we document the tasks we performed during the upgrade process from NetWare 3.x to NetWare 4.1 and add additional helpful information that may apply to each task.
Analyzing the Existing System
Two servers, of the following configurations, were involved in the migration:
One server ran NetWare 3.11, the other 3.12.
Both had a mix of Token-Ring and Ethernet.
Each server supported approximately 300 users running both DOS and Windows. A small percentage of the workstations had been converted to the Virtual Loadable Module (VLM) client so most users would be running NETX in bindery emulation.
The servers were at different sites.
Both servers were using the same hardware platform.
Upgrading the disk configuration on both machines would require wiping out all the old data. Given that, and the above configuration, we decided to use the "same-server" migration technique at both sites to allow us to (1) increase the block size on the volumes and (2) adjust the size of the SYS volume.
Preliminary Preparations
Most of the preliminary steps we took before the upgrade fall under the category of "cleaning up" the server to be migrated. These are steps that you can follow if you find you need to make a similar upgrade.
Delete Bindery Objects
Delete the following:
Obsolete bindery objects
Users who no longer exist
Unused print queues
Check for bindery objects with the same name, but of different object type. Use the utility DUPBIND to do this.
|
Note: In our upgrade, most of the duplications were betweengroups and print queues. We renamed the queue to adifferent name. We suggest using a naming standard toidentify different object types, such as Q_LASERJET forprint queue objects or P_LASERJET for printer objects. |
Print User List
Use the utilities PRINTUSR and PRINTGRP to print a list of all users and their trustee assignments and all groups, their members and trustee assignments. This provides a hard-copy backup of this information should the migration of the bindery information fail requiring the information to be entered manually.
Run BINDFIX and VREPAIR
Run BINDFIX on the old server before migrating the bindery information. Run it twice so that the .OLD files it creates will have clean copies of the bindery. These .OLD files can serve as a backup of the old bindery.
Run VREPAIR on all volumes to clear up any problems that may exist there.
Note: If you are installing more than one server into a singlecontext, the migratation utility will allow you to merge theproperties of two identical user objects. If you choose tomerge the user properties on the first server (such as loginscripts) migrated take precedence. Also, if servers with common user names are beinginstalled into different contexts, you may have User objectswith the same name in different contexts. The user will beable to log in at either context and have different parts ofthe Directory tree visible in each one. If the user reallybelongs in both contexts, you can solve the problem afterboth servers are migrated by manually merging the rightsof one login ID to the other, deleting the second ID andreplacing it with an alias of the first.
Clean Up File System
Scan through all directories on the server looking for unneeded files and directories. Look for duplicate copies of applications (likely made as a backup to an earlier change), or backup copies of user's hard drives.
|
Note: If you are doing an in-place migration, the INSTALLprogram will need about 50 MB free disk space on volumeSYS for temporary storage during the migration process.Run PURGE after deleting the files and subdirectories. |
Copy STARTUP.NCF and AUTOEXEC.NCF
Make hard copies of the STARTUP.NCF and AUTOEXEC.NCF files on the migrating server. This documents hardware settings of disk and LAN drivers as well as what network addresses go to what network card. Print a copy of the system login script for hard-copy backup purposes.
|
Note: Because the system login script is in the fileNET$LOG.DAT in the SYS:PUBLIC directory, it willmigrate to the new server with the rest of the data. NETXusers running bindery emulation will still accessSYS:PUBLIC/NET$LOG.DAT by default for their loginscript. Modify this file with any appropriate changesnecessary to ensure that NETX users still work properly onthe NetWare 4.1 server. |
Migrate Workstations to the New NetWare DOS Requester
Installing from the server is the fastest way to perform the Requester upgrade. If you don't have a NetWare 4.1 server up and accessible with the Requester installation on it, you can copy the \CLIENT directory and subdirectories from the NetWare 4.1 CD to your server. If you have newer ODI drivers for your network cards or some that aren't included with NetWare 4.1, you can copy them to the \CLIENT\DOSWIN\DOS directory so that they will be available when you run the requester installation. Be sure to include the .INS file and delete or rename the corresponding .CO_file.
If you're daring, you can customize the INSTALL.CFG file in the \CLIENT\DOSWIN directory. Delete the lines containing file names that you know you don't need copied to the client workstation (such as ROUTE.COM). You can place default NET.CFG settings under the [REQUESTER] heading in the INSTALL.CFG file. Figure 1 shows suggested NET.CFG settings.
Figure 1: Suggested NET.CFG settings.
NetWare DOS Requester FIRST NETWORK DRIVE = F FORCE FIRST NETWORK DRIVE = ON NETWARE PROTOCOL = NDS BIND PREFERRED SERVER = SERVER1 NAME CONTEXT "OU=ABC.O=XyZ" SHOW DOTS = ON VLM = AUTO.VLM VLM = RSA.VLM AUTO RETRY = 5
|
Note: We recommend that you use "Preferred Server" rather than"Preferred Tree." As long as the preferred server is in theright tree, you will be sure to attach to the right server inthe right tree. AUTO.VLM andRSA.VLM enable auto-reconnect which works when the workstation losesconnectivity to the server but not when the server goesdown. |
Use the DOS Requester installation utility to perform the upgrade on each workstation. Then you'll be sure to have all the proper drivers copied to the proper places and all the proper settings in CONFIG.SYS, SYSTEM.INI, WIN.INI, REG.DAT, and so on. This will probably force you to visit each workstation to upgrade them. You may want to upgrade DOS and any other local software while you're at it. (Refer to Novell Application Notes in August 1993, June and May 1994 and March 1995 for more information on the DOS Requester.)
Change Server Name
We had to change the server name to comply with the state's server naming standard. You may have to do that as well. A server name change will involve, at the minimum, changes in login scripts, menus and any batch files that run MAP, CAPTURE or ATTACH commands referring to the old server name. We used the FILEFIND program with Norton Utilities to make global changes to these files on the server.
Many of our users had permanent drive mappings or capture settings in Windows, with Windows installed on local hard drives. These settings are stored in the WIN.INI file under the [Network] heading and include a reference to the server name.
|
Note: We used a PC Magazine utility called CHANGE.COM, aquick-and-dirty text search and replace program that we putin the system login script to change the server name inWIN.INI before the users ran Windows. |
From past experience, we've knew that HP printers with JetDirect cards would keep trying to attach to the old server name after the change even though it was also attached to the new server name and printing there just fine. In Ogden (the location of one of our servers), we weren't able to remove the old server/queue name in the JetAdmin utility while it was disconnected from that server name. For the Provo upgrade, we removed the server/queue from each printer while the server was up with the old name and deleted their print servers in PCONSOLE. This way, they didn't try to attach to the old server name.
Performing the Upgrade
We started the upgrade on a Friday afternoon. The users had been notified that the system would be down all weekend starting at 6:00 p.m. Friday night. The main task on Friday night was to start the tape backup. Most of the upgrade work was to be done on Saturday.
Run Migrate Utility
The first thing we did was run the AMU migrate utility in same-server mode to migrate everything except files and printer information to the working directory of the migration PC.
|
Note: If you do this, be sure the migration PC is running ODIdrivers, has at least 5 MB of available disk space and atleast 512KB of conventional RAM available. We recommendyou use the AMU to attach to servers. Don't log in to eitherthe source or target server before running the AMU. |
In this case, the primary information we were interested in migrating was trustee assignments. We had already migrated bindery information into the NDS tree using a temporary server that we brought down from the main office a week ahead of time. This was advantageous because we were able to set up partitioning and replication for the container into which the 3.x server was migrating, migrate bindery information into the NetWare 4.1 container, and allow the local LAN administrators to get familiar with the NetWare 4.1 administration utilities. This also gave us time to clean up the migrated objects, grant rights, and make sure that synchronization with other servers was stable.
|
Note: Of course, any changes made in SYSCON on the 3.x serverafter the objects were migrated also had to be done inNWADMIN after the upgrade. |
Run MIGPRINT Utility
With the temporary server in place, we also migrated printing information into the NDS container using the MIGPRINT utility. Because the AMU will not migrate printing information, you have to use MIGPRINT.EXE. But MIGPRINT cannot migrate to a temporary directory like the AMU can. The only way to migrate printing information is across-the-wire with MIGPRINT or in-place. However, you don't have to set up a temporary server like we did just to use MIGPRINT. As long as you have connectivity to another server in the tree that has a replica of the partition containing the container object you are migrating to, you can use MIGPRINT to migrate printing to that server.
Novell has reported a problem with the AMU where files did not actually copy to the target server when the two servers had names starting with the same character (see TIDs 1000787 and 1001198). This would imply that only across-the-wire migration where the AMU is copying files is affected. You might want to temporarily change the 3.x server name before you start the same-server migration.
Disable Logins and Perform Backups
At 6:00 p.m. we disabled login on the server and made sure that no users were connected. We also shut down e-mail gateways that were attached to the server and the Intel Virus Protect software that was running on the server. (The important thing is to shut down anything that keeps files open on the server so that no files are skipped during backup.)
We ran two separate backups. The local LAN administrators ran their usual Maynard backup software and we ran SBACKUP on the temporary server that we had set up. This was the primary reason for the temporary server. We wanted to have two tape backups of the system (since our lives depended on the tape) and we weren't confident that the Maynard software would be able to restore to a NetWare 4.1 server. In order to backup the Ogden server with SBACKUP, we loaded TSA312.NLM (ships with NetWare 4.1) on the 3.12 server. The backup worked fine.
However, the Provo server was still running NetWare 3.11, so we had to install some patches before TSA311.NLM would load. We got the patches from the NSE Pro: SBACK3.EXE, SMSUP2.EXE, LIBUP4.EXE and STRTL3.EXE. We didn't load all NLMs included in those files, just the ones that were required to load TSA311.
Results of the Backup
When we came in Saturday morning, we made sure that the backup had finished with no problems. In Ogden, the backup log showed several files were not backed up because they were open. We shut down the e-mail servers that had them open and ran a quick differential backup to pick them up. (We were careful to shut down all e-mail servers for the Provo upgrade.)
Performing the Actual Upgrade
The next task was to perform the actual upgrade. We shut down the 3.x server for the last time and added the new drives and the new RAID 5 SCSI controller to the system. In Ogden, this process took four hours. With the help of Compaq's technical support, we got the SCSI IDs straightened out. After that, it all worked fine.
We then installed NetWare 4.1. We set the server to be a secondary time server and installed NDS, placing the server in its proper context. We used NWAdmin's Partition Manager to install a replica of the partition and set the bindery context. We turned on DSTRACE using the command SET DSTRACE=+SYNC to see all the previously-migrated objects being copied to the new server.
Figures 2 and 3 show Provo's STARTUP.NCF file and AUTOEXEC.NCF file.
Figure 2: The STARTUP.NCF file at the Provo office.
SET AUTO TTS BACKOUT FLAG = ON SET Minimum Packet Receive Buffers = 200 LOAD CPQDA386.DSK SLOT=5 LOAD CPQS710.DSK SLOT=7 LOAD CPQS710.DSK SLOT=8 LOAD CPQSTAPE LOAD CPQSCD
The AUTO TTS BACKOUT FLAG setting tells the server to automatically backout TTS transactions if needed when the server comes up. Often, if the server abends, or power fails, the server will prompt you to back out incomplete TTS transactions. If no one is there to answer the prompt, the server will never come up. The setting shown above answers "Yes" to the prompts, thus ensuring that the server startup process can continue to completion. The rest of the commands in the STARTUP.NCF file load the Compaq SCSI drivers for drive array, CD-ROM and tape drive support.
Figure 3: The AUTOEXEC.CFG file at the Provo office.
set Time Zone = MST7MDT set Daylight Savings Time Offset = 1:00:00 set Start Of Daylight Savings Time = (APRIL SUNDAY FIRST 2:00:00 AM) set End Of Daylight Savings Time = (OCTOBER SUNDAY LAST 2:00:00 AM) set Default Time Server Type = SECONDARY SET Bindery Context = OU=PRC.OU=AS.O=UT file server name UTSTDPPR ipx internal net A1770C01 LOAD CONLOG FILE=CONSOLE.LOG SAVE=CONSOLE.BAK MAXIMUM=1000 ENTIRE=Yes MOUNT ALL SET NCP PACKET SIGNATURE OPTION=1 SET Maximum Packet Receive Buffers = 800 SET Maximum Service Processes = 100 ;CDROM Drivers LOAD CPQSASPI SCAN FOR NEW DEVICES LOAD CDROM CD MOUNT ALL LOAD PSERVER UTSTDPPRPS1 LOAD TCPIP FORWARD=Yes LOAD IPXRTR ROUTING=RIPSAP LOAD IPXRTRNM ;load LAN Drivers LOAD CPQTOKEN SLOT=1 FRAME=TOKEN-RING NAME=RING1-IPX BIND IPX TO RING1-IPX NET=A1770C80 LOAD CPQTOKEN SLOT=1 FRAME=TOKEN-RING-SNAP NAME=RING1-IP BIND IP TO RING1-IP addr=161.119.12.130
The CONLOG utility is a useful command in the AUTOEXEC.NCF file because it records all messages displayed at the console to a log file. This will trap any error messages that scroll by on the console so you can refer back to the log file to read them.
The syntax shown uses a log file named CONSOLE.LOG in the SYS:ETC directory. It renames the previous log file to CONSOLE.BAK, limits the size to 1MB and captures all messages on the screen at loading time to the log file.
The LDREMOTE.NCF file contains the command to load REMOTE.NLM with the password encrypted. This makes it difficult for intruders to discover your RCONSOLE password. To encrypt your RCONSOLE password, load REMOTE.NLM at the console, then type the command REMOTE ENCRYPT. Enter the password at the prompt and the encrypted form will be displayed on the console. You will then be asked if you want to copy the load command with the encrypted password to the SYS:SYSTEM/ LDREMOTE.NCF file. Doing so is much easier than copying the password down and then typing it into the AUTOEXEC.NCF file.
Load Patches
Once the new server was up and loading disk and NIC drivers properly, we loaded any patches or NLM updates that we thought were appropriate. (Check NetWire or the NSE Pro for the latest patches and updates for NetWare 4.1.)
At a minimum, install the DS.NLM update. NetWare 4.1 shipped with Directory Services Build 4.63. Do not use Build 4.63 if installing into an existing NetWare 4.1 network. The newer build (4.89a) is available on Netwire in DSENH.EXE. Do not install the DSREPAIR.NLM included in this file on a Netware 4.1 server. It is intended for 4.0x servers being upgraded to 4.1.
To update Directory Services, just copy the new DS.NLM to the SYS:SYSTEMdirectory and then, at the console, type
SET DSTRACE = *.
Restore Data
With the new server up and running, we started to restore data from tape. With TSA410.NLM loaded we used SBACKUP for the restore. Right before we executed the restore, we renamed the NetWare standard directories with .4 extensions (system.4, public.4, and so on) so that no 4.x utilities or system files would be overwritten with the 3.x version of the file by the restore. This required us to change the SBACKUP log file location to SYS:TSA because the default is SYS:SYSTEM/TSA which was just renamed to SYS:SYSTEM.4/TSA.
Once PUBLIC, SYSTEM, LOGIN, and MAIL had been restored from tape (they were the first directories restored), we renamed them with .3 extensions and then renamed the .4 directories back to normal.
|
Note: You could also use the backup software to exclude thosedirectories from the restore. We manually moved certainutility programs that were located in PUBLIC.3 into the newPUBLIC directory. |
Other Sundry Tasks
While files were restoring, we worked on various tasks like changing the system login script to fit the new 4.x environment. Not many changes were necessary because we wanted drive mappings and printer captures to stay the same. However, in Provo, since they changed print queue names and the location of the applications and the server name, more adjustments were needed. In both Ogden and Provo, there was a mixture of VLM- based workstations and NETX workstations, so we kept the login script in the NET$LOG.DAT file and placed the command INCLUDE SYS:PUBLIC/ NET$LOG.DATin the NDS container login script.
Having documented the printing setup on the servers, we went through the configuration of each printer and made sure it was working. Because Provo had decided to change all queue names, we didn't even try to migrate printing. We just set up each printer new from scratch. We found that the "Quick Setup" option in PCONSOLE was by far the quickest and easiest way to do that.
Those workstations using RPRINTER.EXE were changed to use NPRINTER.EXE and to run theVLM drivers. We copied NPRINTER.EXE to the SYS:LOGIN directory. We also added a batch file loop to the STARTNET.BAT file. That batch file is shown in Figure 4.
Figure 4: STARTNET.BAT file.
@ECHO OFF C: CD \NWCLIENT LH LSL LH 3C509 LH IPXODI LH VLM CD \ F: ECHO Loading printer support... :LOOP NPRINTER UTSTDPPRPS1 0 IF ERRORLEVEL 1 GOTO LOOP LOGIN
With NPRINTER in the LOGIN directory, there is no need to log in to the server to run NPRINTER. If STARTNET.BAT is called by AUTOEXEC.BAT, the machine will load NPRINTER every time it boots up.
The batch file loop corrects a timing problem with the print server for workstations that boot up quickly. If a workstation is running NPRINTER and is rebooted, the workstation might finish the bootup, load the VLM drivers and NPRINTER before the print server has decided that the previous NPRINTER session has ended. So the print server will refuse the connection because it thinks that printer is already attached. If the batch file continues to loop on the NPRINTER command, it will eventually load successfully when the print server terminates the previous NPRINTER connection.
|
Note: Since the state of Utah has a master license agreement withNovell, most servers were installed with 1000-user licenses.The GroupWise DOS client (OF.EXE) had to be patched tocorrect a problem with connection numbers over 255. If auser's connection number was 260, for example, that userwould get the e-mail of the user at or near connection 5.The problem was fixed in version 4.1a and above. The patchfile name is PAT1000.EXE. |
Reinstall LAN Workgroup
We had to reinstall Novell's LAN Workgroup which provides a BOOTP Server NLM. There were also several updates and patches required for LAN Workgroup to run on a NetWare 4.1 server. Check with the vendor of any add-on software that runs on the server and make sure you acquire any updates needed for NetWare 4.1 compatibility.
Since many of the familiar NetWare 3 utilities like ATTACH and SALVAGE have been incorporated into other utilities in NetWare 4.1, we installed the batch files in the N4BATS.EXE file available on NetWire or the NSE Pro. It contains files like ATTACH.BAT and SLIST.BAT, which just run the equivalent command in NetWare 4.1. This makes it a little easier for users accustomed to the old commands.
Migrating Trustee Assignments
After the files finished restoring, we finished the "same-server" migration from the working directory on the migration PC to NDS on the new server. Because we had already migrated all bindery objects, we selected only trustee assignments for migration. This has to be done after files are restored because the same directory structure must be in place. If you have combined multiple volumes into one volume, it will still work as long as the directory structure is the same from the root down. Before you start the AMU, you will need to attach to the target server in bindery mode. Otherwise, attach to a different server before starting the AMU and then attach to the target server using the AMU.
Setting up the Tape Drives and CD-ROM Drives
The last task was to set up the tape drive and CD-ROM drives on the server. In Provo this took a few hours because we tried to run the tape drive and CD-ROM drives on the same SCSI host adapter. After trying several different adapters, SCSI ids, chaining order, we gave up and put them on different host adapters. Both Provo and Ogden will continue to use SBACKUP for backup until a reliable and NetWare 4.1- compatible backup package can be found.
Post-Upgrade Challenges
In the days following the upgrade, we had various problems with these servers. In Provo, SBACKUP caused the server to hang several times. We updated device drivers and SBACKUP-related NLMs, but it wasn't until we replaced the tape drive with a newer Conner drive that the problem went away.
We also had problems with high server utilization, packet receive buffer escalation, and service process escalation. A combination of updating the NIC drivers, disk drivers and the operating system itself seemed to resolve these problems.
We had loaded the 410PT1 and 410IT4 patches loaded on the servers. 410IT4 has a static patch to the SERVER.EXE file that seemed to significantly reduce CPU utilization on the server. These problems and their resolutions point to the main area of difficulty that we have seen with NetWare 4.1. That is, the compatibility and stability of drivers written for third-party hardware in the server. As time goes on, we are confident that Novell and third-party vendors will continue to optimize and stabilize software written for NetWare 4.1.
Conclusion
The most important thing we learned from these upgrades is that it is best to change as little as possible about the system's configuration during the migration. Both of these projects were done on a weekend with several staff members helping, so we had only from Friday night to Monday morning to finish the upgrades.
At Provo, the LAN administrators at the site decided to change the volume names, the volume where applications were located, the server name, the print queue names, and user login IDs. They also changed the configuration of the servers disk drives to Compaq's RAID 5 configurations. Afterwards, we agreed that all but the disk drive configuration should have been done before the upgrade. Each change required adjustments in workstation and user configurations, which was just too much work to do during one weekend for 300 different workstations.
Our experience with NetWare 4.1 has been generally good. When we started with version 4.01, we had many problems. Those problems were primarily with NDS and third-party hardware/ drivers installed in the servers. Since then, both of those components have stabilized considerably. To Novell's credit, they have been very good about continually working on NetWare 4.1 to clear bugs and optimize it for best performance and stability.
At this point NetWare 4.1 is stable enough to support mission-critical environments. We believe it is crucial to choose mainstream hardware and software vendors that make a continued effort to develop hardware and drivers that are compatible and optimized with NetWare 4.1.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.