
-------------------------------------------------------------------------
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 <BITFTP1@pucc.Princeton.EDU>
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 <R.J.Letts@SALFORD.AC.UK>
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" <jobst@SMTP.LMS.USACE.ARMY.MIL>
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" <mavery@aus.sig.net>
To: "Rugh, Jim" <JRugh@infosvcs.tmh.tmc.edu>, 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 <hobo@USA.PIPELINE.COM>
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 <hobo@USA.PIPELINE.COM>
>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 <kirkinen@CC.HELSINKI.FI>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <philr@HWCCES.DEMON.CO.UK>
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" <ndurland@CAPITAL.NET>
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.


------------------------------

