
This technique can be used to install Warp Connect, the base
operating system and any or all of the networking add-ons
from a Netware server using IPX as a protocol.  This technique
minimally modifies the the standard Netbios and SRVIFS based
LAN install procedures so that there is as small an impact on
the install as possible on the install logic. My own testing has
been done on a token ring network with IBM Token Ring cards, but
this should be adaptable to other cards and topologies, including
Ethernet.

There are five main issues to deal with under this scenario:
        1. Creating the LAN transport diskette with a minimal
           Netware requester.
        2. setting up the Netware server
        3. Allowing the IBM Network Transport install logic
           to work when it cannot actually be allowed to 
           have access to the LAN adapter.
        4. Avoiding conflicts between the  minimal Netware
           setup used in the install procedure and the standard
           IBM SRVIFS setup.
        5. Cleanup of files and config.sys lines--artifacts of
           the install using the minimal Netware requester.


1. Creating the LAN transport diskette with a minimal Netware requester.

To create the Netware LT Diskette, I first installed Warp Connect
on a PC with a CD-ROM drive, and made it a code server, creating a set
of install diskettes that included an SRVIFS LT Diskette.  I took this
SRVIFS LT Diskette and removed the SRVIFS code, then substituted Netware 
requester code.  The Netware requester code is 90% at the 2.01 level -- 
except that the ODI driver was a more current one for the card, the 
Netware message files were from the 2.0 requester and I used the NWSTART.EXE 
from the newest R211FT.EXE to ensure that the requester had a connection ID 
prior to running login.exe in the config.sys.

I tore out the SRVIFS lines from the LT diskette's config.sys and replaced
them.  Here are the lines in my config.sys with the relevant CID and NW
requester stuff.

        DEVICE = NWLINK.SYS
        DEVICE = token.SYS
        device = route.sys board=1
        DEVICE = IPX.SYS
        DEVICE = NWREQ.SYS
        IFS = NWIFS.IFS
        run = NWDAEMON.EXE
        pauseonerror=no
        call=\nwstart.exe
        call=l:\os2\login.exe /script nul fs1/os2inst
        call=\map.exe z:=fs1/vol:connect
        call=\map.exe w:=fs1/vol:GRPWARE\CLIENTS\LADCLT
        RUN=Z:\CID\LCU\SRVREXX.EXE
        call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
        device=\mouse.sys
        SET SAVECONNECT=1
        SET OEMPROGRAM=\GRPWARE\LANSTART.EXE
        SET exitwhendone=1
        SET ADAPTER_NIF=PRNANDIS.NIF
        SET SRVNAME1=fs1
        SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1 


Here is a directory listing of the files used in the minimal Netware
requester for the LAN Transport diskette.

     NETH     MSG     3029   5-02-89   8:15a
     NET      MSG     2997   5-25-90   8:47a
     MAP      EXE    25527   7-18-91  11:08a
     IPXCALLS DLL     1348   5-21-92   4:27p
     NETAPI   DLL     1328   5-28-92   4:33p -- change name to NWAPI.DLL
     DDAEMON  EXE     9085   9-04-92  12:13p
     ROUTE    SYS    45440  11-10-92  10:40a
     LSL      SYS    20772  11-25-92   2:31p -- change name to nwlink.sys
     NWDAEMON EXE    40089   1-21-93   5:20p
     NWCALLS  DLL   108704   1-27-93   6:27p
     NWIFS    IFS    35684   1-30-93   9:44a
     IPX      SYS     9780   1-30-93  11:49a
     NWREQOS2 MSG    17902   2-02-93   5:58p
     NWREQ    SYS    30324   2-03-93   9:42a
     NWCONFIG DLL     3584   2-03-93  10:53a
     TOKEN    SYS    28176  11-17-93   1:22p
     NWSTART  EXE     8227  12-06-94   2:02p


Changing the name of LSL.SYS to NWLINK.SYS was done to avoid an install 
sniffer from determining that the Netware requester was already installed 
and no allowing me to re-install it.  Changing the name of NETAPI.DLL
to NWAPI.DLL was done because the install of the Peer product required 
functionality in the NETAPI.DLL that Novell's NETAPI.DLL did not provide, 
and the Peer product's install could not get to its own NETAPI.DLL when 
the Netware requester had its own NETAPI.DLL opened. Changing the name of 
this .DLL causes a rather nasty looking error message to appear when the 
Netware drivers are loaded on bootup, but the appropriate functions are
apparently found in the renamed .DLL and everything has worked correctly 
in my testing.



2. setting up the Netware server

To set up the Netware server, I xcopied the CD-ROM onto the server 
into the VOL:CONNECT directory then xcopied the grpware directory from 
the OS/2 code server. I also set up the requester drive letters so that 
they would point to the spots on the Netware server corresponding to the 
OS/2 code server and with equivalent rights.  Check the grpware.ini file
on the OS/2 code server to confirm.  The virtual CD-ROM on the Netware
server takes up about 260 meg.  You could also install from an actual
CD-ROM but there is a severe performance impact if you are doing multiple
simultaneous installs off a CD-ROM.



3. Allowing the IBM Network Transport install logic to work when it 
   cannot actually be allowed to have access to the LAN adapter.

You might notice that adapter information set up in the config.sys
segment above is for the IBM Parallel Port ANDIS driver, PRNANDI.OS2.

        SET ADAPTER_NIF=PRNANDIS.NIF
        SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1 

I did this so  that SRVIFS and MPTS would set themselves up for the 
parallel port rather than the Token Ring card.  This avoids device 
driver conflict during the install.  After the install completes  
I remove the minimal Netware LT rivers from the root directory of the
boot drive, run MPTS and 'change' the Parallel port driver out and
replace it with the IBM Token Ring NDIS driver.  I then tell ODI2NDI
the MAC address of the Token Ring Card. This completes the install. 


4. Avoiding conflicts between the  minimal Netware setup used in the 
   install procedure and the standard IBM SRVIFS setup.

The use of a Netware server as a code server presents a couple of more
challenges. The Netware requester has its own NETAPI.DLL which is much
smaller that IBM's NETAPI.DLL and provides less functionality. The CID 
install of the Peer Product requires functions of the IBM NETAPI.DLL 
which are not in the Netware Requester's NETAPI.DLL.  The Netware 
requester can use the IBM NETAPI.DLL, but the IBM NETAPI.DLL will not 
fit onto the LT disk.  

My fix for this is to rename the Netware NETAPI.DLL to NWAPI.DLL.  
NWIFS.IFS will put out a message that makes it look like
it failed to load when the name of this .DLL has been changed, but it
seems to work anyway.

The Connect Install has a sniffer that looks for LSL.SYS in your config.sys 
and may prevent you from installing the Netware 2.11 client if it finds it.
Again my fix is to rename the file.  I changed LSL.SYS to NWLINK.SYS and
there wasn't even a peep when I loaded it.


5. Cleanup of files and config.sys lines--artifacts of the install using 
the minimal Netware requester.

I use the USER.CMD function of the Connect install to clean up 
my config.sys and remove files.  If there is a USER.CMD in the local 
\grpware\clients\ladclt directory (this directory structure is created, then
removed by the Connect install process) it will be executed at the end of the
install.  I put the user.cmd I wrote in the root of the W: drive and use the
following command in the LT config.sys to copy it to the correct directory:

        call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*

note this will cause an error message when booting from diskette, but after
the line has been migrated to the config.sys partition being installed it
does its job.

below is a REXX code segment from my user.cmd file to clean up the mess
I made of the config.sys.  Note the file read/write logic is absent.

---------  begin REXX code segment ------
push stop
push '=\REFPART.SYS'
push '=NWLINK.SYS'
push '=TOKEN.SYS'
push 'SET CAS'
push 'SRVREXX'
push '=ROUTE.SYS'
push '=IPX.SYS'
push '=NWREQ.SYS'
push '=NWIFS.IFS'
push '=NWDAEMON.EXE'
push '=\NWSTART.EXE'
push '\OS2\LOGIN.EXE'
push '=\MAP.EXE Z:='
push '=\MAP.EXE W:='
push 'ADAPTER_NIF='
push 'ADAPTER_INFO'
push 'SRVNAME1='
push 'USER.CMD'
push 'PAUSEONERROR=NO'

/* if find match for any of the above, read in the next line without 
writing  the matched line to the new config.sys */

     do until test=stop
       parse pull test
       rtn=POS(test,sline)
       if rtn > 0 then
           do
             sline=LINEIN(source)
             oline=sline
             sline=translate(sline)
             linecnt=linecnt+1
             read='NO'
           end /* do */
     end /* do */


/* clean autorestart, libpath, dpath of lines migrated from LT Disk */
push stop
push ',CONNECTIONS'
push ';Z:\CID\DLL\OS2'
push ';\;\OS2;\OS2\SYSTEM;\OS2\INSTALL'
push ';\;\OS2\INSTALL;Z:\CID\DLL\OS2;\OS2\DLL;\OS2\MDOS'

  do until test=stop
     parse pull test
     cnt=POS(test,sline)
     if cnt > 0     then
      do
        sline=delstr(sline,cnt,length(test))
      end /* do */
   end /* do until */

--------- end of REXX Code segment ---

The install process migrates the minimal Netware requester files from 
the LT diskette to the root of the drive being installed.   Removing the
files is tricky because some of them are opened and locked by the Netware
requester during all phases of the install process.  And they must be
removed otherwise your 2.11 requester will grab these ancient files, attempt
to use them and fail on your next reboot.

In my user.cmd I deleted all the Netware files copied from the LT 
diskette that were not locked.  Then I set up the IBM locked file 
device driver to remove those files a simple del statement could not
remove.  This device driver is run from the config.sys and executes 
before the Netware drivers are loaded.  I used my user.cmd to insert 
the following two lines as the second and third lines of the config.sys:

       DEVICE=\OS2\INSTALL\IBMLANLK.SYS \OS2\INSTALL\IBMLANLK.LST
       RUN=\OS2\INSTALL\IBMLANLK.EXE \OS2\INSTALL\IBMLANLK.LST

then build the ibmlanlk.lst file with the following entries:
        DEL \NWCONFIG.DLL
        DEL \NETH.MSG
        DEL \NET.MSG
        DEL \IPXCALLS.DLL
        DEL \NWCALLS.DLL
        DEL \NWAPI.DLL
        DEL \NWDAEMON.EXE
        DEL \NWREQOS2.MSG

You need to make sure there is an End-Of-File character (x'1A') at the end of
the IBMLANLK.LST file for the IBMLANLK.SYS to work.  

This completed the cleanup.


As you can tell from the above, it is much easier to avoid all this by
building your code server the IBM way.  The only reason I do it is because
IPX is routable and Netbios is not (Netbios Over TCP/IP cannot be used by
the install process, its too big to fit on an LT diskette).

