------------------------------------------------------------------------- 311-312.UPG -- 19980304 -- Info on Updating a NetWare 3.11 server to 3.12 ------------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Wed, 12 Oct 1994 14:49:15 EDT From: Princeton BITNET FTP Server Subject: upgrade.312 NETWARE 3.11 TO NETWARE 3.12 UPGRADE NOTES ------------------------------------------ WARNING ******* Please read these notes carefully. If in doubt please contact the Micro Facilities Team before proceeding with the upgrade. Discussions on the internet conclude that it is unwise to mix 3.11 and 3.12 modules together unless directed to do so. The instructions here have been tested and have resulted in no known problems to date. The following notes outline the procedure for upgrading Netware 3.11 to Netware 3.12. Given the distributed nature of the Novell network, it is impossible to produce a document which relates specifically to all the different configurations to be found within the University. Hopefully these notes will supply you with enough information to tackle the upgrade in a painless manner. All comments are welcome. When you upgrade is down to you. Our advice however is to upgrade at some point. I tend to adopt the approach of getting the system installed and up and running before applying the patches and upgrades. You may wish to upgrade as you go along. It does not matter what way you do it as long as your system arrives working in an upto date state. The 3.12 login, public and system files are stored on ucs-ml0. Please contact MFT for access. Only Supervisors need apply for obvious reasons. Once attached the directory structure looks like this: LOGIN login files PUBLIC public files SYSTEM system files KERNEL dos boot partition files These files contain a standard 3.12 installation complete with Macintosh support. Note that the Macintosh support is now a 200 user version. Within these directories the unicode and os/2 directories and files have been included for completeness but I suspect these will be of limited interest or use. Indeed, all files are included. Since I do not know what you have on your servers it is upto yourself to decide what you need. Also note that as far as flagging your files go, I do not know how you have set your system up. Therefore I can only talk generally about Netware systems and how I feel they should be set up. Please think carefully about what you are flagging during the upgrade process. More details on this area follow below. I also have to assume that you have the login, public and system files stored in their usual, default locations. If you have moved stuff around then you will have to take this into account during the upgrade process. If you intend to upgrade please move all files over to your server. It is important that this is done at the one time. Do not attempt to upgrade parts of the system. This includes the updating of the server kernel and will require some downtime of your server. So plan ahead. The whole process can easily be completed in under an hour. I would suggest however, to allocate a mornings downtime and take your time. There are no prozes for finishing first, only for bringing the server up again in one piece :-) The procedure to upgrade involves flagging the appropriate files in the LOGIN, PUBLIC and SYSTEM directories to READ WRITE and NCOPYing the 3.12 files to your server to replace the old 3.11 files. From there a 1.4MB floppy disk needs to be created onto which the contents of the KERNEL directory should be copied. The contents of this disk should be moved to the DOS boot partition of your server prior to re-booting the server. Do not upgrade the system files and then re-boot the server before upgrading the SERVER.EXE on the DOS boot partition. Follow these steps in the specified order: 1/. Upgrade your LOGIN, PUBLIC and SYSTEM directories 2/. Copy the contents of the KERNEL directory to a 1.4MB floppy disk 3/. Down the server 4/. Backup the DOS boot partition 3.11 kernel files to another floppy disk. 5/. Copy the new 3.12 KERNEL files to the DOS boot partition 6/. Restart the server 7/. If all goes well plunder the upgrades directory The following notes provide some useful information concerning the finer points of upgrading to 3.12. 3.11 to 3.12 Upgrade -------------------- Ensure that you have a backup of the 3.11 login, public and system directories. MFT can allocate space for you to do this should the need to revert back to 3.11 arise. 1/. If you do not have an upto date copy of your bindery then now is a good time to do so. Run BINDOPEN and BINDCLOS to obtain a copy of the bindery and store separately. The batch file BINDBACK.BAT can be used for this purpose which is outlined below. This batch file assumes a hard disk of c:\ to which the bindery files are copied to. Other assumptions include a search mapping to SYS:PUBLIC and a directory called SUPER of the SYS: volume. Edit to suit if required. The programs BINDOPEN.EXE and BINDCLOS.EXE can be found in the JRB210A.ZIP in the guest account of ucs-ml0/guest:pc/novell/utils. rem Batch file BACKBIND.BAT bindclos cd\system flag net$obj.sys -hsyt flag net$prop.sys -hsyt flag net$val.sys -hsyt copy net$obj.sys f:\super copy net$prop.sys f:\super copy net$val.sys f:\super flag net$obj.sys +hsyt flag net$prop.sys +hsyt flag net$val.sys +hsyt cd\super bindopen echo If no errors then continue to copy bindery to hard disk echo otherwise press Control-C to break pause copy net$obj.sys c:\ucs-ml0\net$obj.ml0 copy net$prop.sys c:\ucs-ml0\net$prop.ml0 copy net$val.sys c:\ucs-ml0\net$val.ml0 2/. Flag contents of SYS:LOGIN Read Write. The ones in particular to flag are LOGIN.EXE SLIST.EXE TOKEN.RPL eg flag login.exe +rw as these are replaced in 3.12. Actually token.rpl is needed for token ring and not an issue here. Boot images should be left where they are. Map a drive letter to the area where the 3.12 login files are stored and ncopy the login directory over. ncopy g:*.* /s /e /v The /S parameter ensures sub-directories are copied over, the /E copies empty sub-directories and the /V verifies the write. Note the the file attributes will be set to ROSDIRI - read only shareable delete inhibit rename inhibit. This is just what you want. Note also that the owner will now be SUPERVISOR as opposed to the name of your fileserver. This is not a problem provided you do not have disk quotas set for the supervisor on the SYS: volume. If you do then remove them. 2/. The PUBLIC directory is fairly straightforward. You should be able to flag all the files as RW and ncopy the new 3.12 public files over. Of those that are not updated you can flag them back again afterwards. The attributes will be set to rosdiri which is again what you want. Note that three new sub-directories will have been created NLS OS2 UNIX Leave the system login script NET$LOG.DAT. Also leave the NET$PRN.DAT as this contains settings from running PRINTDEF.EXE. Also leave the global PRINTCON.DAT if one exists. The 3.12 installation has some new .PDF's notably a APPLW2FG.PDF for IIF's and IIG's. The supervisor may wish to run PRINTDEF.EXE again after the installation has been completed to include this. Some files are not updated by 3.12. You can leave these in place, move them to another area or get rid of them altogether. MENU.EXE and *.MNU files are not updated in 3.12 so you may have to leave these in place if required. Novell have shipped a new set of menu utilities (Saber 1.0 Menus I believe). The 3.11 menu files are: MENU EXE 32,709 14/03/91 15:43 MAIN MNU 319 24/09/90 11:20 MENUPARZ EXE 103,529 14/03/91 15:44 MENUPARZ HLP 1,205 06/12/90 17:49 The following files are needed for the Netware Help. This has been removed from the 3.12 installation. It appears that placing these files in another directory other than SYS:PUBLIC the program produces an error while attempting to load the !NETWARE.NFO file. However, you are then presented with a directory listing from which you can select the *.NFO files. This appears to work ok. HELP EXE 14,825 07/06/90 9:41 PVMANUAL NFO 118,784 13/02/91 11:13 CONCEPTS NFO 94,208 13/02/91 11:27 !NETWARE NFO 1,114,112 12/02/91 16:09 NETWARE2 NFO 595,968 12/02/91 16:08 NFOLIO COM 10,410 14/08/90 0:00 NFOLIO EXE 194,139 14/08/90 0:00 NBACKUP is not included with the 3.12 upgrade. If you wish to keep this in place the following files will be required. NBACKUP COM 10,346 26/10/92 16:41 NBACKUP HLP 35,182 30/01/91 10:09 NBACKUP OVL 292,024 04/11/92 11:15 NBACKUP EXE 296,086 03/11/92 12:46 3/. The SYSTEM directory needs a bit more care. Obviously do not touch the bindery files, drivers referenced in AUTOEXEC.NCF, third party stuff. eg Mercury UPS Appmeter Cheyenne Arcserve Solomons Anti-Virus Toolkit for Netware NMAGENT.NLM is auto-loaded at boot time on a 3.11 server. It appears that this is not needed for a 3.12 server - at least not for the loading of the LAN drivers as in 3.11 - though it is still updated by 3.12. You may be able to take this line out of AUTOEXEC.NCF if you have it. Leave the following well alone. ..QDR plus PrintServer ID directories atps.cfg if you have one as well as mercury.ini If Macintosh support is installed then there will be two hidden files in the SYS:SYSTEM directory. VOLICON.AFP RWAH VOLNAMES.AFP RWAH Leave these alone. If the site has MERCURY installed most of the following files will be located in the SYS:SYSTEM and SYS:SYSTEM\MERCURY directories. These should be left in place. MGUIDE.EXE ADDQ.EXE MALIAS.EXE CH_SYN.EXE MERCURYS.NLM MERCURYC.NLM MERCURY.NLM MERCURYP.NLM ALIAS.SRC MERCURY.INI MERCURY/CONFIRM.MER MERCURY/MAISER.HLP MERCURY/LISTS.SMP MERCURY/FAILURE.MER MERCURY/MAISER.LKP Flag the 3.11 programs - leave the bindery alone remember - as read write. In a default 3.11 setup with Macintosh support the following sub-directories can be located in sys:system DR TSA DIBI NW-MAC The files in DIBI need to be flagged RW. The NW-MAC files are probably RW but need to be flagged as so if they are not. The 3.12 installation creates the following sub-directories NLS DIBI OS2 NW-MAC As a rough guide you can a. Flag *.NLM, EXE, LAN, DSK, NAM, HLP files as RW b. Flag bstop.ncf and bstart.ncf as RW (but you may have changed these so check before you upgrade them). c. The btrieve.trn file is a 0 byte file so check your own copy. d. The net$rec.dat file can be set to RW. The atnodes.dat is probably already set to RW. e. The products.dat will already be set to RW. If you have NFS installed then replacing the products.dat file with the one from 3.12 will then fail to show the installed products from the install.nlm. This will not be a problem for most of you. So be careful here. The current crop of 3.11 patches are not needed for this upgrade. So remove all references to patchman and the server patches from your AUTOEXEC.NCF before downing the server. You may wish to just comment them out using a semi-colon ;. I expect that we have not seen the last of patch manager. However, for this upgrade and the current updates detailed below it is not required. Details will be mailed to novell@ed of all new updates as they become available. 4/. The DOS boot partition should be dealt with as follows: a. Backup all the files to a floppy disk. If you need to replace the kernel back to 3.11 then if you have a backup there will be no problem. b. Delete the following files: (that way we can guarantee you are not going to mix versions up). NUT.NLM SERVER.EXE README.311 FILES.DAT VREPAIR.NLM V_MAC.NLM MAC.NAM INSTALL.NLM Leave in place: IO.SYS MSDOS.SYS COMMAND.COM AUTOEXEC.BAT STARTUP.NCF Also leave the .DSK files. I do not know what these will be on your setup. The KERNEL disk includes a few drivers but these will probably not apply to your system. c. Copy the contents of the KERNEL disk to the DOS boot partition. You can delete the .DSK files that are not relevant to the installation if you wish. Directory of A:\ DCB DSK 18,613 12/02/91 21:08 IDE DSK 14,049 26/04/93 16:09 ISADISK DSK 11,975 28/04/93 7:58 KEYB NLM 13,241 15/07/93 10:15 MAC NAM 14,977 13/11/90 16:48 NUT NLM 42,484 20/12/90 8:18 OS2 NAM 16,703 18/01/91 22:49 PS2ESDI DSK 8,428 28/04/93 8:27 PS2MFM DSK 8,759 31/01/91 11:01 PS2OPT DSK 35,506 14/05/93 9:59 V_MAC NLM 4,914 10/12/90 7:06 V_OS2 NLM 7,642 10/12/90 7:10 VREPAIR NLM 44,095 04/05/93 12:50 SERVER EXE 520,345 11/08/93 23:47 INSTALL NLM 169,700 17/08/93 10:23 FILEDATA DAT 2,164 16/08/93 0:27 FILES DAT 200,959 17/08/93 13:37 STARTUP.NCF There is no need for the command SET MINIMUM PACKET RECEIVE BUFFERS=100 as this is now set by default. It would also be useful to add the following line SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE=2048 which is need for a Mercury Mail installation. Note that this is set in startup.ncf and is not valid in autoexec.ncf. NW312 Post Installation Notes ----------------------------- 1/. Update only relevant files from the UPDATES directory which contains updates to the default installation. These files are also located on the guest account in ucs-ml0/guest:pc\novell\updates I have not patched the default installation as I do not know what is relevant to your installation. This may or not be a popular decision. I welcome your comments. Once you have installed the default 3.12 files then check the UPDATES directory. At present there are only a handful of archives. If you have fallen behind with patching your system then now is a good time to get back upto date. I have included below details of what is available and what was patched on UCS-ML0. This should hopefully point you in the right direction. My advice is to create a sub-directory SYS:SYSTEM\UPDATES and copy and expand the files into there. From here only the relevant ones can be moved into SYS:SYSTEM replacing older versions. This keeps those files not relevant to the current installation out of the SYSTEM directory. The Supervisor can then clear out the updates directory once satisfied that all necessary files have been relocated correctly. You may find it useful to keep the .doc files may here. All updates will be maintained on the guest account of UCS-ML0 should you wish to obtain a full copy at a later date. At the beginning of June 1994 the updates directory includes the following files: LANDR3.EXE updated ethernet drivers TCP187.EXE new tcpip stack NAM312.EXE Macintosh namespace driver 2/. Delete all .LAN drivers in SYS:SYSTEM except those needed for the installed adapter cards and IPTUNNEL.LAN which may be useful to some installations. A full copy will be maintained on the guest volume of UCS-ML0. eg flag *.lan +rw flag NE3200.lan +ros flag IPTUNNEL.LAN +ros del *.lan The .LAN drivers occupy 1,028,096 on a 4K block SYS: volume and are not needed. 3/. Add CONLOG.NLM to the begining of the AUTOEXEC.NCF right after the internal net number and UNLOAD CONLOG at the end. This NLM which ships with 3.12 provides a listing of console messages and is useful for checking the load sequence. It must be unloaded in order for it to close the file which is located in SYS:ETC\CONLOG.LOG eg. FILE SERVER NAME UCS-ML0 IPX INTERNAL NET 81D77031 LOAD CONLOG ... UNLOAD CONLOG The system administrator can load the CONLOG.NLM back up from the fileserver console and unload it at intervals in order to backup the CONSOLE.LOG file. ******************** Note from Andrew Short *************************** For RDATE.NLM to work properly, the set timezone GMT0BST must be the first command in autoexec.ncf after ipx internal net .. The reason it failed before is because (following your notes) load conlog.nlm was inserted at that point and this is sufficient to prevent subsequent NLMs from recognising the timezone. I thought this was clutching at a straw, but it worked. Setting the order in autoexec.ncf to file server name VET-LAB0 ipx internal net 81d7c403 set timezone GMT0BST load conlog.nlm and waiting for the next power cut to cause a re-boot was sufficient to get things right. Can I suggest you update your notes to draw attention to this? Dr Andrew D. Short Department of Preclinical Veterinary Sciences Royal (Dick) School of Veterinary Studies The University of Edinburgh Summerhall Edinburgh EH9 1QH UK tel: 031 650 6112 international +44 31 650 6112 messages 031 650 6100 messages int'l +44 31 650 6100 fax. 031 650 6576 fax int'l +44 31 650 6576 Email ADShort@ed.ac.uk 4/. Down server and replace the MAC.NAM on the dos boot partition 5/. Create a new boot disk from the NW312 dos boot partition. 6/. Restart server 7/. Login and check the file SYS:ETC\CONLOG.LOG for errors. NOTES FOR UPDATES ================= LANDR3.EXE ---------- When loading up the latest .LAN files, they now use for an ethernet installation the following NLM's. MSM31X.NLM ETHERTSM.NLM When updating the .LAN driver ensure that these .NLM's are also updated. Note that in the list produced by the modules command from the console and from within the MONITOR.NLM the MSM31X.NLM is displayed as MSM.NLM. TCP187.EXE ---------- The docs state that the patch TCP162.EXE must have been applied prior to installing this update. Netware 3.12 is already upto the necessary revision level so this does not apply. NAM312.EXE ---------- This archive only contain a readme file and the program MAC.NAM. It should be replaced on the dos boot partition and in SYS:SYSTEM. Example ------- After upgrading UCS-ML0 to 3.12 the only files that needed to be updated were: NE3200.LAN MSM31X.NLM ETHERTSM.NLM TCPIP.NLM MAC.NAM Below is a detailed list of all UPDATE archives available for NW 3.12 that I presently know about. Details are included as to their relevancy to systems installed within Edinburgh University. It is unlikely that many servers will deviate from these guidelines. Directory of F:\SYSTEM\UPDATES LANDR3 EXE 233,437 17/02/94 9:07 Self-extracting archive ======================================================================== @7154 ADF 2,657 27/04/92 13:54 Not in sys:system, not relevant. @7151 ADF 2,346 26/07/89 17:08 " " !NVL1301 CFG 1,169 12/03/92 14:28 " " !NVL1401 CFG 986 10/06/92 16:02 " " !NVL1501 CFG 11,994 11/01/93 15:24 " " !NVL0901 CFG 8,293 04/10/90 10:42 " " !NVL1201 CFG 7,378 26/03/92 9:08 " " !NVL0701 CFG 2,745 02/09/92 13:25 " " FIRMLOAD COM 1,628 04/01/91 8:57 " " STATS DOC 63,446 06/10/93 15:55 Doc file XLOAD DOC 3,472 06/07/92 11:00 " " LDR001 DOC 3,200 06/07/92 11:00 " " XLOAD EXE 13,872 06/08/91 16:47 " " The following .LAN drivers are only relevant if the appropriate ethernet card is installed. NE2 LAN 4,954 08/10/93 10:44 NE2_32 LAN 5,066 12/05/93 16:03 NE2100 LAN 7,224 24/09/93 16:25 TOKEN LAN 10,125 07/06/93 13:29 NE3200 LAN 13,811 08/10/93 10:51 In sys:system, replace. NE1000 LAN 4,468 20/01/93 15:18 NE2000 LAN 7,356 08/10/93 10:47 NE1500T LAN 7,226 24/09/93 16:25 TOKENDMA LAN 10,861 26/05/93 15:16 NTR2000 LAN 10,272 13/09/93 14:23 TRXNET LAN 3,075 07/01/93 13:23 PCN2L LAN 4,726 29/01/93 20:45 NE32HUB LAN 12,266 27/01/93 9:11 TOKENTSM NLM 9,040 30/09/93 15:30 In sys:system, not relevant. FDDITSM NLM 7,847 07/07/93 17:07 " " RXNETTSM NLM 6,202 06/01/93 10:04 " " PCN2LTSM NLM 5,691 30/01/93 11:32 " " PM311IO NLM 8,384 13/04/93 11:28 " " LSLENH3 NLM 10,500 02/06/93 11:34 " " IOSHIM NLM 1,649 09/06/93 9:50 " " LSLENH NLM 11,641 16/11/92 8:29 " " MSM NLM 15,628 04/10/93 13:03 " " PATCHMAN NLM 9,632 04/02/93 10:38 " " ETHERTSM NLM 8,841 28/09/93 14:41 In sys:system, replace. MSM31X NLM 16,483 04/10/93 13:04 In sys:system, replace. MONITOR NLM 117,775 26/10/92 9:21 Same version as for 3.12 LDR001 PTF 52,920 06/11/91 16:55 Not in sys:system, not relevant. LANDR3 TXT 26,049 15/11/93 11:28 Readme file for landr3.exe The following provides a brief description of some of the drivers contained in LANDR3.EXE. This is lifted from the LANDR3.DOC and only lists those files which carried a descriptive comment. MSM NLM - 4.01 Media Support Module (MSM) MSM31X NLM - 3.11 and 3.12 Media Support Module (MSM) ETHERTSM NLM - Ethernet Topology Support Module (TSM) TOKENTSM NLM - Token Topology Support Module RXNETTSM NLM - Arcnet Topology Support Module PCN2LTSM NLM - PCN2L Topology Support Module FDDITSM NLM - FDDI Topology Support Module NTR2000 LAN - Novell NTR2000 TOKEN RING Driver LSLENH NLM - LSL ENHANCED NLM. !NVL1201 CFG - NE32HUB CFG file @7151 ADF - NE2_32 ADF file !NVL0701 CFG - NE3200 CFG file !NVL1301 CFG - NE32HUB TPE CFG file !NVL1401 CFG - NE32HUB PME CFG file !NVL1501 CFG - NE2000 plus CFG file !NVL0901 CFG - NE2100/NE1500T CFG file @7154 ADF - NE2 ADF file FIRMLOAD COM - Use with TOKENDMA to load firmware PM311IO NLM - Use with SFT III 3.11 (Patchman) LSLENH3 NLM - Use with SFT III 3.11 IOSHIM NLM - Needed when running NetWare SFT III 3.11 with LSLENH3.NLM and the NE2000.LAN driver ============================================================================== TCP187 EXE 90,826 24/03/94 12:56 Self-extracting archive ========================================================================== TCP187 TXT 4,414 15/03/94 10:13 Readme file for tcp187.exe TCPIP NLM 193,985 08/03/94 10:30 In sys:system, relevant. README SDK 5,936 11/03/94 14:06 Readme file. Developers only. NAM312 EXE 26,011 02/05/94 8:58 Self-extrcting archive ========================================================================== NAM312 TXT 2,116 05/04/94 11:48 Readme file for nam312.exe MAC NAM 15,107 20/09/93 9:58 In sys:system & c:\ relevant Garry Scobie LAN Support Officer Micro Facilities Team EUCS e-mail: g.scobie@ed.ac.uk 15/07/94 ------------------------------ Date: Tue, 23 Aug 1994 10:04:34 +0100 From: Richard Letts Subject: Re: 3.11 to 3.12? > We have a 3.11 fileserver currently that is 100 user. We are > going to buy another fileserver. We need to upgrade our current 100 > user with a 250 user 3.12 we bought, and have the 100 user 3.11 on > another server. I noticed there is a migration utility with 3.12, so > that I could migrate the old server to the new one while installing > 3.12 (on the new server). What is the best way to do this upgrade? > Installing 3.12 on either server is an option. I want to maintain > user files and bindary from the 100-user server though. Basically, to upgrade from 3.11 to 3.12 on the SAME server: - get 3.12 patches from one of the FTP servers (eg netlab2.usu.edu) - backup the original server (twice) - delete everything from sys:public except the system login script, and any local files sys:system except the bindery and autoexec.ncf - copy sys:system and sys:public files off the install disks - remove the 3.11 patch lines from your autoexec.ncf - copy the 3.12 patches onto the fileserver, and add them to the autoexec.ncf - down the fileserver - copy server.exe off the install disks onto the DOS partition - type server - your fileserver should come up first time ------------------------------ Date: Fri, 26 Aug 1994 08:23:00 -0600 From: "John J. Jobst // IM-I" Subject: Re: NetWare 4.02 upgrade >Is there anything tricky about upgrading a server from 4.01 to 4,02? >There were no directions on any of the packaging. What are the steps? First do the usual stuff like backing up the server twice, ... - Down your server and get to a DOS prompt. - Mount up the CD-ROM. - Run the \netware.40\english\install.bat file. - Choose Install NW 4, then choose Upgrade. It will make backup copies of SERVER.EXE and other modules on your DOS partition, then should proceed with the upgrade. Gotcha's: If you followed the NW 4.0 installation and only made a 5M DOS partition, you may not have enough disk space. It will skip making backups, so you should do that first, manually. ------------------------------ Date: Mon, 30 Oct 1995 17:41:42 CST From: "Mike Avery" To: "Rugh, Jim" , netw4-l@bgu.edu Subject: Re: The 3.x-to-4.1 Migraine Utility >I tried to upgrade our 250-user 3.11 to a 1000-user 4.1 server using >Migrate - what a headache. > >Both servers and the workstation were together on their own 16Mbps token >ring. Perform2 showed that data transfer to both servers was well over >800KB/s. However, Migrate actually moved data at only 50KB/s, so it took >over 8 hours to move 1.5 gig. > >Finally as Migrate was close to being done, the workstation locked up. > >None of the trustee rights transferred. Faced with manually editing trustee >rights for 300 users and 50 groups, I backed out to the old server and went >to bed at 5 in the morning. > >Why would Migrate run so slow? What happened to my trustee rights? Ack. Been there, done that, got the scars to show for it. As to why it's slow and why it sucks, I suspect that the managers at Novell did not put a lot of emphasis on it. The idea being that you'll only use it once, so why worry about it? We had a large number of servers to migrate, and a number of them were large. We found that using FDDI and TCNS did not help. Basically, the system is not media bound. It's program bound and no reasonable hardware will help it. Here's what we finally settled on,with good results. First someone checks the 3.1? server to make sure that there are no groups, users, printers, or other objects with the same names as one another. Duplicates are renamed or removed. Uneeded users and groups are removed. A data cleanup is performed. The we use Migraine (I like that name, by the way) to migrate JUST the users and groups. We tell it to move no data. We tell Migraine to create the users with no passwords, but we set the users up so that they have to change their passwords as soon as they login. This minimizes help desk problems the day after the conversion, at a minimal security risk. If someone gets in, you'll know because the normal user won't be able to get in. Once the users and groups have been recreated, we used the the JRB Utilities "NETCOPY" program to move the data. It does a very fast job, and it maintains all the ownership and trustee rights information you want and need. Examine the options carefully and do a few tests before you kick off the major data move. NETCOPY will assign a file to the same users and groups that owned it on another server, if the same users and groups exist on the new server. Very nice. And you can have several PC's copying data. Now for the bad news. It's about $300.00 for a site license for the utilities. I think that they are worth far more. But, it could be a sticking point for some people. (I've never understood why someone will pay megabucks for the operating system and balk at $300 for utilities.) There is a subset of the utilities, not including NETCOPY on NETLAB2, in the APPS directory. I believe the name is JRB230.ZIP. You can use anonymous ftp. Ordering information is in the ZIP file. ------------------------------ Date: Tue, 14 Nov 1995 21:39:22 GMT From: Tim or Maria hobo Subject: Re: InPlace and Over the Wire Upgrades to 4.x >I am interested to hear horror stories and worst case scenario's of people >who have done either Inplace or over-the-wire upgrades from NW 3.x to 4.x. >I have heard that during an inplace upgrade, the printers get trashed and >have to be setup from scratch. I have also heard that during over the >wire upgrades, passwords get lost as well as printers getting trashed. > >Has anyone had things like this happen to them? Migration from 3.x to 4.x does not migrate passwords. You can either have the migration utility assign random passwords, which you then have to look up and give to the users, or you can leave it with no password. Then, you need to go through each user and set their account where they must change their password on the first login. ------------------------------ Date: Wed, 15 Nov 1995 21:14:07 +1300 From: J.Baird@ONO.LINCOLN.AC.NZ Subject: Re: InPlace and over the wire Upgrades to 4.x From: Tim or Maria hobo >Migration from 3.x to 4.x does not migrate passwords. You can either have >the migration utility assign random passwords, which you then have to look >up and give to the users, or you can leave it with no password. Then, you >need to go through each user and set their account where they must change >their password on the first login. That is true of over-the-wire migration, but the in-place upgrade does preserve passwords. I have done one in-place upgrade, and despite meticulous planning with off-line testing of every phase, the unexpected happened about 10 minutes after kick-off. The CD_ROM drive deactivated just after converting the bindery to NDS and part way through renaming the mail directories to match the new object IDs. This locked install, a reboot was required, and on restart Install reported SYS had been upgraded, but it happily converted the object IDs for trustees, file ownership etc on the other volumes. That left the mess on SYS to clean up. We decided against restoring and starting from scratch in case the deactivation recurred. We did restore SYS onto another machine and with the help of a spot of programming copied the mail directories and contents across renaming to match the new IDs in the process. We were also able to recover the trustee assignments and file ownership using existing tools. That glitch cost us 4-5 hours. Everything else went according to plan, although we did have a problem with macs connecting to the server afterwards and we eventually traced that to a problem in the NIC driver with Multicast packets. Installing the latest driver fixed it. John Baird ------------------------------ Date: Wed, 15 Nov 1995 10:56:33 GMT From: Teo Kirkinen Subject: Re: InPlace and Over the Wire Upgrades to 4.x >Migration from 3.x to 4.x does not migrate passwords. You can either have >the migration utility assign random passwords, which you then have to look >up and give to the users, or you can leave it with no password. Then, you >need to go through each user and set their account where they must change >their password on the first login. You can also run NETSYNC on the 3.x and 4.x servers, if you have separate servers. This will migrate the passwords in addition to the user accounts and groups. Unfortunately you have to use other tools (like JRBUTILS) to move the files, trustees etc, assign new mail directories, default servers etc. But when you have several thousands user accounts it is still easier than to give everybody a new password. ------------------------------ Date: Thu, 8 Feb 1996 17:21:10 -0600 From: Joe Doupnik Subject: Re: Upgrade NW 3.11 to 3.12 >It's time to me to upgrade a 3.11 to 3.12. I plan to backup everything, >then copy server.exe and neccessary files to the DOS partition, then load >install.nlm to copy system and public files over the 3.11 stuff. Is this >an acceptable way to do this? Also, would bindrest restore all print >queues information? ---------- If you have good tape backups then yes, the bindery can be moved over without a problem. But print queues often don't make the trip because they have files open during backups (unless you get clever and unload PSERVER). It's been years since I did the change from 3.11 to 3.12, and in those days my tape backup system was much less than currently. So I did it live, on the air, while folks watched. I removed NLMs from system, gutted executables from public, login, messages from all three areas etc. I then copied the NW 3.12 NLMs and msg files by hand to the server and rebooted. Not the safest way but it was quick and it worked. A good fresh install would be the best method. That lets you bump up the DOS partition to 15MB or so, it cleans out all old stuff for sure, and it reorganizes your disk for faster access of static items. Save autoexec.ncf separately (not to mention the tape backup software, if server-based). While you are about it you might raid&plunder the nw312 area of updates\nwos and get the current patches. Some go into C: and startup.ncf these days. Joe D. ------------------------------ Date: Wed, 21 Feb 1996 15:58:47 -0600 From: Joe Doupnik Subject: Re: A call for opinions >Is Netware v3.12 really a "patched" v3.11? Are there real reasons >for upgrading? To borrow a phrase, what is the "ROI." ---------- ROE, Rules Of Engagement is more like it. No, NW 3.12 is not just a "patched" NW 3.11. It is much more like NW 4 under the covers than NW 3.11, but it isn't quite (still has the NW 3 memory pools troubles, for example). My own view is NW 3.12 is a solid mature performer, difficult to beat then and now and for some time in the future. It is the pinnacle of the workgroup server in the sense it is independent of all the other servers on site. If one were to take NW 4.10 and remove directory services then NW 4.1minus would be the champ in this role because it has further refinements to its kernel. NW 3.11 is long in the tooth and patching can do only so much. The kernel, server.exe, is set in its ways and can't be redesigned by patches alone. NW 3.11, though, is a good system and continues to yield dependable fast service. The choice of upgrading to 3.12 or not thus becomes one of staying with current technology and improvements or not. NW 4 is just plain different, not an upgrade, but a much different way of doing business; folks with version-itis disease should be warned away. Joe D. ------------------------------ Date: Thu, 22 Feb 1996 09:08:43 +0000 From: Phil Randal Subject: Re: A call for opinions >Is Netware v3.12 really a "patched" v3.11? Are there real reasons for >upgrading? To borrow a phrase, what is the "ROI"? Yes - it includes the SEC* patches, PBURST, and some internal limits have been increased. Disk caching strategies have been tweaked too. It also includes a copy of Basic MHS, which is next to useless if you have more than one server on your LAN. ------------------------------ Date: Wed, 4 Mar 1998 22:32:24 -0500 From: "Nathan (Bud) Durland" Subject: 3.12 server upgrade mini-guide I've had many requests for a copy of a small checklist I devised for migrating a NW3.12 server to new hardware. To be honest, I am mildly surprised at the demand.. To make life easier, I posted it on my personal web page. It can be found at http://www.capital.net/~ndurland/novelltips.html. As it is, I might try creating a tips page, based on pearls of wisdom harvested here. If anybody has anything particular they'd like me to post, just e-mail it. ------------------------------