Installing Warp Connect Using a Netware Server

Return to The Warp Pharmacy:Software

Last update: 6th November, 1995

Symptoms
You've tried setting up Warp Connect to install over the Network with Netbios as a transport, but because of routing issues or the use of Netware servers as bridges, Netbios just doesn't work for your site as a transport mechanism for installing Warp.

Hardware
Any PC and Networking hardware that supports Netware servers and OS/2 workstations with both ODI and NDIS drivers for their LAN cards.

Problem
Warp Connect remote install was built upon SRVIFS, a Netbios based client server architecture. For shops that require a routable protocol, or use Netware servers for bridges, this can be a major impediment.

Procedure
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.

There are six main issues to deal with under this scenario:


 * Creating the LAN transport (LT) diskette with a minimal Netware requester
 * Setting up the Netware server
 * Allowing the IBM Network Transport install logic to work when it cannot actually be allowed to have access to the LAN adapter.
 * Avoiding conflicts between the minimal Netware setup used in the install procedure and the standard IBM SRVIFS setup.
 * Cleanup of files and config.sys lines--artifacts of the install using the minimal Netware requester.
 * Fix up protocol.ini and config.sys to use the NDIS drivers for LAN transport.

Creating the LAN transport (LT) 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 functionally 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.

I have put these files (minus token.sys and route.sys) in ftp.cdrom.com in /pub/os2/incoming/ltnwreq.zip.

proposed directory for placement: /pub/os2/network/netware

As of 25 July 1995, the file was still in the incoming directory.

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.

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.

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.

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.

Fix up protocol.ini and config.sys to use the NDIS drivers for LAN transport
This can be done either manually or with REXX. The manual process is: a. Run the Netware command USERLIST /a to get the MAC address you network card. This will need to be done from your USER.CMD and piped into a file before the install completes. b. run MPTS. Select Configure->LAN Adapters and Protocol. This will bring you to the "LAPS Configuration" screen which contains three windows, "Network Adapters", "Protocols", and "Current Configuration" c. In the "Network Adapters" window hi-light the adapter on your PC. d. In the "Current Configuration" make sure the "IBM Parallel Port..." selection is high-lited. e. Under the "Network Adapters" window, select "Change" and then confirm the change. f. In the "Current Configuration" window hi-light "0 - IBM Netware Requester Support" and select "Edit" g. Enter the Network adapter address in the appropriate field. If you are on ethernet, turn off TOKEN-RING frame header support and turn on the appropriate Ethernet frame header support for your site. h. Hit "OK" -> "OK" -> "Close"->"Exit"-> then "Update Config.sys" "Exit"

You can also do this with REXX.

For the config.sys, you only need to do one thing. You need to replace the parallel port ANDIS driver with the NDIS driver which corresponds to your card. I do this during the config.sys processing of my USER.CMD. You do need to know the names of the corresponding ODI and NDIS drivers for your NIC card.

-- begin REXX code segment -

/* find ODI driver, set up variables for corresponding NDIS */ /* environmental variables used in protocol.ini update */ cnt=pos('TOKEN.SYS',sline) if cnt > 0 then do          NIC='IBMTOK.OS2' 'set NIC=IBMTOK.OS2' 'set NIF=IBMTOK_NIF' 'set NIF_FILE=IBMTOK.NIF' 'set driver=IBMTOK$' 'set topology=TOKEN_RING' end /* do */ .... /* replace parallel port driver with NIC Driver */ cnt=pos('PRNANDIS.OS2', sline) if cnt > 0 then if NIC <> 'unknown' then do     sline=overlay(NIC,sline,cnt,12) end /* do */ -- end REXX segment

Protocol.ini processing is similar. You replace all the references to the parallel port driver and NIF files with those of your NIC driver. You also need to get your MAC address, make sure it is 12 characters in length and zero fill the leading characters, if it is not.

-- begin REXX code segment - /* get MAC address from userlist.txt, Switch NDIS Drivers */ ProtocolProc: Procedure /* output from userlist /a has been put in userlist.txt file */ source="\userlist.txt"

Do until LINES(source) = 0 /* spin through file */ sline=LINEIN(source)

/* find line with this PC's MAC address */ cnt=pos('*',sline) if cnt > 0 then do mac_addr=substr(sline,41,12) end /* do */ end /* do */

/* zero fill leading spaces */ do until cnt=0 cnt=pos(' ',mac_addr) if cnt > 0 then mac_addr=overlay('0',mac_addr,cnt) end /* do */

-- end REXX segment

You are then ready to tackle the protocol.ini. Note that the PROTOCOL.INI file from a CID install is not quite the same as what you are use to seeing MPTS (or NTS/2) create. It is sort of a minimalist protocol.ini, without many of the standard entries in the protocol sections (for example).

-- begin REXX code segment -

/* NDIS values put in environment during config.sys proc */ driver = VALUE("DRIVER",,"OS2ENVIRONMENT") NIF = VALUE("NIF",,"OS2ENVIRONMENT") NIF_FILE = VALUE("NIF_FILE",,"OS2ENVIRONMENT") NIC = VALUE("NIC",,"OS2ENVIRONMENT") TOPOLOGY = VALUE("TOPOLOGY",,"OS2ENVIRONMENT")

( some file handling code deleted )

Do until LINES(source) = 0  /* spin through file */ sline=LINEIN(source) sline=translate(sline)

/* insert MAC adress of NIC */ cnt=pos('NETADDRESS',sline) if cnt > 0 then do       cnt=pos('"',sline)        cnt=cnt+1        say sline        sline=overlay(mac_addr,sline,cnt,12)     end /* do */

/* replace LPT ANDIS driver with NDIS Driver */

cnt=pos('PRNANDIS_NIF', sline) if cnt > 0 then if NIC <> 'unknown' then do     sline=delstr(sline,cnt,12) sline=insert(NIF,sline,cnt-1) end /* do */

cnt=pos('PRNANDIS.NIF', sline) if cnt > 0 then if NIC <> 'unknown' then do     sline=delstr(sline,cnt,12) sline=insert(NIF_FILE,sline,cnt-1) end /* do */

cnt=pos('PRNANDS$', sline) if cnt > 0 then if NIC <> 'unknown' then do     sline=delstr(sline,cnt,8) sline=insert(DRIVER,sline,cnt-1) end /* do */

call lineout object, sline

/* If this is an Ethernet LAN, make sure frame header support is appropriate */ cnt=pos('= ODI2NDI$', sline) if cnt > 0 then if TOPOLOGY='ETHERNET' then call lineout object, '  ETHERNET_II = "yes"'

end /* do spin through file */

-- end REXX segment