Supporting Network Adapters
Although WorkSpace On-Demand supports a large number of network adapters, only a few of them are configured and enabled at the time the product is installed. This chapter describes how to enable other network adapters as well as how to add unsupported adapters to your list.
Enabling Adapters Supported by WorkSpace On-Demand 2.0
When you install WorkSpace On-Demand Manager on your server, the installation procedure edits the RPL.MAP file and enables those server records that correspond to the network adapter type installed in your server. However, it is likely that your clients will have other types of network adapter installed. To enable the server records that correspond to these other network adapter types, you must edit the RPL.MAP file.
When you edit the RPL.MAP file, you will see a large number of server records, many of which have a semicolon character as the first character in the record. This semicolon disables the server record by making the RPL service treat it as a comment. In order to enable a server record, you must delete the semicolon, save the file, and restart the RPL service.
Enabling Adapters Supported by OS/2 Warp Server
IBM officially supports a large number of NDIS network adapters with OS/2 Warp Server. For a list of these adapters, see the OS.2 Warp Server home page at:
http://www.software.ibm.com/os/warp/pspinfo/nic.htm
or the WorkSpace On-Demand home page at:
http://www.software.ibm.com/os/warp/workspace/nics/index.htm
Although these adapters are supported by OS/2 Warp Server, you may need to take a number of steps to support them under WorkSpace On-Demand. OS/2 Warp Server only delivers the OS/2 device drivers, but a WorkSpace On-Demand client that uses the IEEE 802.2 boot mechanism requires both DOS and OS/2 device drivers during the boot process.
You must therefore manually install the DOS driver, the NIF file and its appropriate MSG file from a device driver diskette, option diskette or diagnostics diskette. These diskettes are typically delivered with the network adapter. See the following section, Enabling Unsupported Adapters , for instructions on how to install the device drivers on your WorkSpace On-Demand server.
Enabling Unsupported Adapters
You can use any token-ring or Ethernet network adapter with WorkSpace On-Demand, provided that you can obtain functional DOS and OS/2 device drivers for the adapter.
To enable an unsupported network adapter, you must complete the following steps:
- Obtain the most recent DOS and OS/2 NDIS drivers.
- Create a directory structure for the new drivers.
- Copy the device drivers and the related files into the directory structure.
- Create a PROTOCOL.INI file for the DOS environment.
- Create a boot block definition (CNF) file for the new adapter.
- Modify the NDISDD.PRO file.
- Create and enable the associated server record in the RPL.MAP file.
This procedure will work for most NDIS-compliant network adapters that support Remote IPL. The following pages describe each step in more detail.
As an example, we add the Madge Smart 16/4 AT Plus Ringnode Adapter. For the remainder of this chapter, we refer to this adapter as the Madge adapter.
Obtain the DOS and OS/2 NDIS Drivers
Locate the most current DOS and OS/2 device drivers and other files for the network adapter you wish to add. You can usually obtain these files from the hardware vendor's Web site.
Install the DOS Driver
You must create new subdirectories within the \IBMLAN\RPL\DOS directory. For the Madge adapter, you should create the following directories:
Create a PROTOCOL.INI File for DOS
You must create a PROTOCOL.INI file for the DOS phase of the boot process. The easiest way to do this is to take an existing PROTOCOL.INI file from another adapter, and use it as a template. For example, when creating the PROTOCOL.INI file for the Madge adapter, we chose to copy the existing PROTOCOL.INI file for the IBM 16/4 Token-Ring Network Adapter and modify it. The PROTOCOL.INI file we copied is named IBMTOK.NIF and resides in the \IBMLAN\RPL\DOS\TOKENRNG directory.
The picture below,PROTOCOL.INI File for DOS, shows the completed DOS PROTOCOL.INI file for the Madge adapter.
PROTOCOL.INI File for DOS
The bindings= entry in each section must be:
This indicates that the physical DOS driver is identified in the smartnd section of the file.
[MADGE_MOD]
DriverName=smartnd$
This is the DOS driver section. It specifies that the name of the DOS driver is SMARTND.DOS (the DOS extension is assumed). This section indicates that all protocols should bind with the SMARTND.DOS driver.
Note the commented parameters at the end of the file. These were in the original file for the IBM Token-Ring adapter, but are not valid for the Madge adapter.
Install the OS/2 Driver
You must install the OS/2 driver and associated files into the correct place on your WorkSpace On-Demand server. Copy the OS/2 driver and the NIF file to the \IBMLAN\RPL\BB20.US\IBMCOM\MACS directory. For the Madge adapter, these files are:
The NIF file contains important information that is used in the Network Adapter drop-down list on the Hardware page of the Client Definition notebook.
The example below shows a part of the MDGND.NIF file shipped with the Madge adapter:
[MDGND]
Type = NDIS_SNGL
Title = "Madge Fastmac Plus OS/2 NDIS MAC driver for
Smart 16/4 Ringnodes"
The text in the Title field is used to populate the Network Adapter drop-down list in the Client Definition notebook. You can modify the text between the double quotation marks if you wish to provide a more meaningful description.
Create a PROTOCOL.INI File for OS/2
You must create a PROTOCOL.INI file for the OS/2 phase of the boot process. In our example, we copied the PROTOCOL.INI file for the IBM Token-Ring adapter from the \IBMLAN\RPL\DOS\TOKENRNG\OS2 to the \IBMLAN\RPL\DOS\MADGE\OS2 directory and edited the file to include the correct driver information. PROTOCOL.INI File for OS/2 shows the final OS/2 PROTOCOL.INI file after editing.
PROTOCOL.INI File for OS/2
The bindings= entry in each section must be:
This indicates that the physical OS/2 driver that loads is defined in the MADGE_MOD section of the PROTOCOL.INI file.
[MADGE_MOD]
drivername=smartnd$
This is the OS/2 driver section. It specifies that the name of the OS/2 driver is SMARTND.OS2. Again, note the parameters commented out at the end of the file. These are from the original PROTOCOL.INI for the IBM Token-Ring adapter and are not valid for the Madge adapter.
Create a Boot Block Definition File
You must create a boot block definition (CNF) file for your adapter. The CNF file defines the contents of the boot block that is downloaded to the client by the server's RPL service.
Again, it is best to copy and modify an existing CNF file. For our example, we copied the CNF file for the IBM 16/4 Token-Ring adapter. This file is named BB2USNTR.CNF and resides in the \IBMLAN\RPL directory. We copied this file to create a new file named BB2USMDG.CNF, which is also in the \IBMLAN\RPL directory.
You must now modify the CNF file for the new adapter. As shown in BB2USMDG.CNF, we load everything exactly as the IBM Token-Ring adapter does. The only change is to load the correct adapter driver (SMARTND.DOS) and the correct PROTOCOL.INI file (the same PROTOCOL.INI file that we modified earlier to support the Madge adapter). BB2USMDG.CNF shows the completed CNF file for the Madge adapter, with the changes highlighted.
Edit the NDISDD.PRO File
Among other things, the NDISDD.PRO file determines the contents of the Network Adapter drop-down list on the Hardware page of the Client Definition notebook. In order for your new adapter to be selectable from the drop-down list, the file must contain a record for your adapter.
NDISDD.PRO file shows an extract from the NDISDD.PRO file after adding a record for the Madge adapter. The new record is highlighted for clarity.
NDISDD.PRO file
The server uses the NIF file specified in NDISDD.PRO to build the CONFIG.SYS and PROTOCOL.INI files for client workstations that you define as having this adapter installed.
Field 2 in the NDISDD.PRO record must match the name of the subdirectory that you created within the \IBMLAN\RPL\DOS directory. In our example, this is the MADGE subdirectory.
Edit the RPL.MAP File
You must edit the RPL.MAP file to create a server record for your new adapter. RPL.MAP file - Server Record Entry shows the server record for the Madge adapter.
Test Your Definition
The new adapter should now be selectable from the Hardware page in the Client Definition notebook. Test your adapter definition by performing the following steps:
If the RPL service fails to restart, it may be due to two problems:
- There may be an error in the server record you entered in RPL.MAP.
- There may be an error in the CNF file. WorkSpace On-Demand reads all CNF files when it starts the RPL service and checks that the drivers and other files listed in the CNF files exist and are valid. Check the paths and file names listed in your CNF file to ensure all the files are correctly named and reside in the directories indicated.
- Use the remote IPL requester configuration GUI to define a client using the new adapter. If the adapter is not visible in the Network Adapter drop-down list on the Hardware page in the remote IPL requester configuration notebook, it may be due to a number of problems:
- Check the OS/2 NIF file, and ensure that it has a Title field. If the Title field is absent or contains only spaces, the adapter will not have an entry in the Override Network Adapter drop-down list.
- Check the RPL.MAP file and ensure that the server record for the adapter is enabled.
- Check the NDISDD.PRO file to ensure that field three matches the name of the OS/2 NIF file and field four matches the record ID of the server record in RPL.MAP.
After you successfully define a client with the new adapter, you should boot the client to ensure that all the necessary drivers and control files are valid and functioning correctly.