WiseManager Documentation

By Serenity Systems International

Planning
The Serenity System Managed Client package consists of three basic software components: WiseManager, WiseServer and WiseClient. A key feature of the Managed Client environment as implemented by WiseManager is the fact that this application executes from the system administrator's workstation, which can be any workstation on the network, including a remote workstation using a dial up connection. This means that WiseManager can even be implemented and executed from the same system being used as the server. The WiseServer application resides and executes on the server. The WiseClient application resides and executes on each of the remote boot clients.

Server Prerequisites
The server must be running either the Warp Server Entry, Warp Server Advanced, Warp Server SMP, or the newly released OS/2 Warp Server for e-business (a.k.a Aurora) with "Remote IPL", "File and Print Service", and "TCP/IP" installed. A fresh installation with NO fixpaks applied is highly recommended.

Limitations of Remote Boot Clients
WiseManager supports OS/2 Warp 4 as a remote boot client. Users should be aware that it is not possible to invoke Netbios/Netbeui peer resource sharing from a remote boot client. For example, a printer attached to a remote boot client cannot be shared as a peer resource. Sharing a printer is accomplished by attaching the printer to a server, a non-remote boot Warp 4 client, or using a printer which has a built in adaptor to make it a network resource. However, printers CAN be accessed and shared through TCP/IP printing.

The fact that a client has or does not have local drives is not the issue. A remote boot client does not have to be diskless. Once the machine is booted from the network, the local hard drives can be used in exactly the same way as a non-remote boot Warp 4 client system. However, even then, if the client is utilizing local drives, the restriction regarding peer resource sharing remains in effect. Peer resource sharing is not available.

Server

 * System:Any system capable of running Warp Server should be acceptable for the evaluationprograms which limits the number of clients to five Managed Clients. However larger installations should utilize an SMP version of Warp Server, either Warp Server Advanced SMP, or Warp Server for e-business with the extra SMP option.
 * Processor:Pentium class processor(s) or equivalent. Because all of the client stations perform their own processing, they create little additional demand on the server processor.
 * Memory:Sufficient memory should be available to achieve a cache hit ratio of more than 95%. 64M is acceptable for small installations (a few client stations). 128M should be considered the minimum for medium size installations (10 to 30 client stations), and 256M (or more) is recommended for larger installations (more than 30 client stations per boot server).
 * Hard Disk:For small installations, the minimum requirement is a large capacity IDE drive with at least a RAID 1 hardware mirroring controller. For larger installations, fast ultrawide-SCSI drives with hardware RAID support is highly recommended.
 * Network Interface Card (NIC):A bus-mastering NIC is recommended. Users can also use multiple NICs to benefit from Warp Server's automatic load balancing capability.

Client

 * System:Generally, systems capable of running Warp 4 will provide acceptable performance. The IBM Network Station 2800, or other NLX form factor small foot-print PCs are highly recommended.
 * Processor:Pentium class processor or equivalent.
 * Memory:Same requirement as Warp 4.
 * Video:For best results, use video cards that are supported by the IBM GenGradd or Scitech display doctor drivers see http://service.boulder.ibm.com/os2ddpak/html/gradd/ and http://www.scitech.com).
 * Hard Disk:The use of a local hard disk for client systems is discouraged. This is an issue of design and implementation. Diskless clients provide more benefits from a standpoint of reliability, manageability, and problem resolution. However, some users may opt to utilize a small local harddrive to host the machine's swapper file. This will help reduce network bandwidth demand by the client system. For small installations, the benefit provided by use of local hard drives is negligible and use of local drives should be avoided.
 * Network Interface Card (NIC):The Managed Client environment is specialized and while many NICs support this environment, it is not always an easy task to determine which NICs fall into this category. Even different model NICs from the same manufacturer have provided mixed results. It is recommended that NICs tested and supported by Serenity Systems be utilized.

Network
A 16 MB/s token ring or 100BaseT ethernet network is highly recommended. A 10BaseT nework will work fine for small installations.

IBMLAN.INI
[server] section

NUMREQBUF
This is the number of request buffers. Four (4) should be defined for each requester.

Maximum value is 408.

MAXOPENS
Number of files, pipes, and devices which can be open simultaneously on the server. This value is ignored by the server under the HPFS386 file system.

Maximum value is 8000.

MAXSESSOPENS
Number of files, pipes, and devices simultaneously open for a requester. This value is ignored by the server under the HPFS386 file system.

Maximum value is 8000.

[remoteboot] section

MAXTHREADS
Number of threads that the Remote IPL service starts in order to perform asynchronous reading of the configuration files.

Maximum value = MAXTHREADS in the server's config.sys.

This value should be no greater than 6.

Increasing this parameter can decrease performance in larger installations.

PROTOCOL.INI
[protocol] section

NCBS
Should be set to 4 x n where n is the number of remote boot clients supported by this server.

SESSIONS
Total number of DOS and OS/2 remote boot clients supported by this server.

Install Warp Server
It is highly recommended that a fresh install be used with WiseManager. However, if you must use an existing system, please backup your system. The WiseManager installation process will cause changes to be made to the system in such a way that THERE WILL BE NO WAY TO RETURN THE SERVER TO THE STATE IT WAS IN BEFORE THE INSTALLATION BEGAN. The only way to restore the system will be from a backup!

Disk Partitions
The following represent a typical and recommended disk partitioning pattern. Your actual needs may be different.

Install the basic components of OS/2, MPTS, File & Print Service, Spooler Queues, and TCP/IP in the System Partition. Depending on the video driver needed for the server, you might need to include DOS. Installation of WinOS2 on the server is not recommended. The remote boot client stations WILL be able to run WinOS2.

File and Print Services
When you install the network portion of Warp Server, be sure to check the "More..." button to the right of the "File and Print Sharing Services" and check "Remote Boot Service for OS/2 Workstations (Remote IPL)" and "Remote Boot Service for DOS Workstations (Remote IPL)" (optional). Click "Okay" and then "Next". You should see the following screens:

MPTS
An evaluator offered this comment, which is being evaluated: I found this bit of the install a bit "shakey" under Warp Server for e.business. After GETRPL is executed and I reboot, I have to go back into install (icon on desktop) and perform page 3 - First apply FP9 (don't re-boot), then go into install again and click "I did it". I think some people could miss this step.

After following the prompts of this stage, a message is displayed which says the server is not started when, in fact, it is. There's a message in the VX-Rexx console to ignore this, so I guess it's OK, but someone could easily click the "try to start server" button. Now this is finished, the install program requests you select the re-boot option - unfortunately it doesn't do anything and a manual shutdown and re-boot is needed.

A "cold" boot (power off/on) is probably best at this point in my opinion. The installation program adds a NET Start RIPL line to the STARTUP.CMD file, unfortunately (as in my case) if you already use Remoteboot (OS/2 DOS or WSOD), this causes an error as the server is already started when the server starts.

Perhaps the install program could be changed to look at IBMLAN.INI to see if REMOTEBOOT is listed as a required service and only if not there, either add it into the IBMLAN.INI file or add the NET START RIPL (or REMOTEBOOT) command to the STARTUP.CMD file ??

Tip: Experience has shown that the netwok installation portion of Warp Server to be problematic - often causing traps during MPTS install. The base OS installation has improved to the point where problems are few and far in-between. Therefore, it is recommended to perform the installation in two phases: First, with the base OS and NO NETWOK - uncheck all of the options from the network installation screen (including TCP/IP) with the exception of MPTS. Then, specify that there is NO network adapter in the system. The installation will proceed to install a NULL network driver in the system. Once you're done with the base OS installation, you can go back and do a selective install for networking.

Install WiseManager
When you have finished with the basic Warp Server install, you are ready to install WiseManager. If you are installing or re-installing WiseManager on an existing system, be sure to stop all other on-going tasks which need the server. The WiseManager installation program may automatically reboot the server at various stages of the installation process without giving any prior warning message.

Place the WiseManager CD into your CD-ROM and from an OS/2 command line, issue the command: x:\install.exe  (for Warp Server) or x:\install.exe AURORA (For Warp Server for e-business) where x is the drive letter of your CD-ROM

You will see one of the two following screens (if the "I did that" button is grayed out, stop the installation program and double click the "WiseServer Installer" program icon on your desktop to restart the installation program):

The first time you invoke the WiseManager installation program, you will be prompted for the various locations in use. Generally, the default values will work fine. However, in the example above, you will need to change the location of the WiseManager directory (TVoice) to a different drive. The default setting points to the same drive as IBMLAN\RPLUSER. You can always invoke the "Drive Letters" option under the "Configuration" dropdown menu in the install program to change drive letters. From this point and on, simple follow the on-screen instruction to finish the installation.

This cannot be emphasized strongly enough. It is important to follow the instructions EXACTLY as stated and in the SPECIFIED SEQUENCE provided. At any time during the installation process, if you are not sure about a certain step, or if you have a question, STOP! If you skip one of the steps, it is very likely that you will have to do a complete Warp Server reinstall before you can use WiseManager.


 * Tip:Make sure that the TCP/IP services DDNS, DHCP, and BINL are NOT running during WiseManager installation. At a certain point during the installation, you will see a dialog box warning you about this. When you see that message, bring up the window list to determine if these tasks are running. If so, while you are in the window list, close the tasks DDNSAPS.CMD, DBCPSCPS.CMD, and BINLSCPS.CMD.
 * In addition, if you're doing a re-installation, it's important that the RIPL service and WiseServer service NOT be running. The RIPL service can be stopped by issuing the command NET STOP RIPL from an OS/2 command line. The WiseServer service can only be stopped by executing the "Stop WiseServer" function inside the WiseServer application folder.
 * Finally, it has also been reported that GETRPL, RIPLINST, and XCOPY may have problems with some brands of CD-ROM drives. If you get any error messages from GETRPL, RIPLINST, XCOPY, or if the CD-ROM seems to take a long time before recognizing the WiseManager installation CD, do not skip past them. STOP. This task may have to be completed using a different CD-ROM drive.

An evaluator offered this comment, which is being evaluated: I found this bit of the install a bit "shakey" under Warp Server for e.business. After GETRPL is executed and I reboot, I have to go back into install (icon on desktop) and perform page 3 - First apply FP9 (don't re--boot), then go into install again and click "I did it". I think some people could miss this step.

After following the prompts of this stage, a message is displayed which says the server is not started when, in fact, it is. There's a message in the VX-Rexx console to ignore this, so I guess it's OK, but someone could easily click the "try to start server" button. Now this is finished, the install program requests you select the re-boot option - unfortunately it doesn't do anything and a manual shutdown and re-boot is needed.

A "cold" boot (power off/on) is probably best at this point in my opinion. The installation program adds a NET Start RIPL line to the STARTUP.CMD file, unfortunately (as in my case) if you already use Remoteboot (OS/2 DOS or WSOD), this causes an error as the server is already started when the server starts.

Perhaps the install program could be changed to look at IBMLAN.INI to see if REMOTEBOOT is listed as a required service and only if not there, either add it into the IBMLAN.INI file or add the NET START RIPL (or REMOTEBOOT) command to the STARTUP.CMD file ?? After you have performed all of the steps, reboot the server before using any of WiseManager's services.

WiseManager Configuration
The first time you boot up the server after the WiseManager installation process, you should see the WiseServer icon on the lower left section the server's screen. If you have selected the Server and RIPL Services Auto-start options, those services will have been started. Underneath the WiseServer icon, you should see the name of your domain and the name of the RIPL server. If you don't see these things, and/or you see "RIPL Not Started" under the icon, something is wrong with the RIPL setup.

You should also have a folder on your desktop for WiseServer. Double click on that folder and you should see the following:
 * Double click on "WiseManager" to start the WiseManager program - a button with your domain name should be visible.
 * Click on your domain and you will be prompted for a logon userid and password. If the logon is successful, you will see a screen with the RIPL servers.
 * Clicking the server button will bring you to the work group screen, which has two groups: Main and Template.
 * Click on the Template group. The specific content of the next screen will depend on the NIC templates supplied. In our example, we'll use the Kingston KNE30 PCI 10BaseT network card at the client side. If the message "Workgroup TEMPLATES does not exist" appears, press the create button to create it. NOTE: If you are using a different card make sure you use the correct template. If you have the Kingston V4 card for instance, select the Kin_etherx_PCI template. If your card is not listed but is supported under OS/2 Ripl install it (see IBM Warp Server Documentation) and create a template for it, by right klicking anywhere in the Templates window and select "add new user".
 * Click the "KNE30RX PCI (pending)" button to bring up the "build" screen for a machine with the name of KNE30RXPCI.

NIC Address
NIC address is a unique burned-in 12 digit hex number identifying the primary network adapter in the client workstation. If you are building a client from the server side, you will need to know exactly what this address is. You can get this information by activating the RIPL function of the client workstation NIC and noting the value when the machine is powered on. Some NICs require a plug-in "boot prom" which needs to be activated while others have this function built in. Some machines may require a change in the BIOS settings in order to recognize this function. Others may need to run a DOS set up program.

Automatic Detection of NIC Address
An important feature of WiseManager is the ability to set up the system so the client systems will report the NIC address automatically to the server when the machine is powered on. This means that users don't have to build client machines from the manager's station or even track of the NIC addresses. This feature makes it much easier to set up networks.

Unfortunately, there is no definitive method available to associate a certain NIC address with a particular manufacturer and model number. So, it is not possible to know with certainty which device driver to load based solely on a given NIC address. In a group of similar network cards, you may only have ONE of them reporting the NIC address to the server at any given time. To utilize this "Self-definition" function, you must follow the instructions outlined below.

Wildcard Character Usage in NIC Address
Let's assume you have a number of new computers and they all have Kingston KNE30 PCI NICs. From what we know today, Kingston KNE30 PCI NICs use addresses that begin with 00C0F0. From the server side, in the template group for Kingston KNE30 PCI, specify a NIC address of 00C0F0?????? and click "Execute".

Building Remote Boot Client Machine
Depending of the system you have for the server, it takes approximately 30 seconds to "build" a remote boot client machine. If the build is successful, you should see the screen to the right. After that, you will see the Management Console for the template machine you just built (see the screen below). For now, just close the console.

Client Machine Power On
If the BOOT PROM is working, you should see some on-screen display indicating that it's searching for the server. The exact format of the indicator is NIC dependent. If you are offered a list of RIPL choices, select boot from network, and Non-Netware RIPL.

On most NICs, if it found the server with a matching NIC address or NIC address pattern, it will indicate a "FFC" count followed by a DOS section and then an OS/2 boot that is identical to what you would have see from a normal OS/2 Warp 4 boot. If the boot is successful, you will see the screen below:

NOTE: This screen shot will be revised so Application Group shows Basic, not General, and the second button will be Create not Execute. For a quick check, just fill in a "User" name and hit enter. The "User" name is NOT a logon user name but a name given to the remote boot client station, as it will be known to WiseManager. This name CAN be the same as the "Machine ID" which is a name given to the station as it will be known to Warp Server. The "User" name must be unique within a work-group. The "Machine ID", likewise, must be unique per domain. By default, "Machine ID" is set to "M" followed by the "User" name you enter and end with the last 4 digits of the station's NIC address.

Notice that the NIC address has been reported automatically to the server. It is VERY IMPORTANT that you don't shut off the machine at this point. If you do, you will have to do some manual cleanup of the \IBMLAN\RPL\RPL.MAP at the server.

For now, ignore all other fields and simply click "Create". After the machine has been "built" for you, the machine will reboot automatically. If everything works properly, you would have "built" a fully functional Warp 4 machine. There are several error messages displayed during the workstations boot, some of these are related to no DOS support being installed by default some are network related (such as IFNDIS) don't worry about these for the time being.

Destroy Template Machine
When you have finished building all of your machines, be sure to destroy the template machine from that machine's management console by invoking the "Destroy" function under the "Utility" system menu item. When you do this, the template machine no longer "exists" and the Automatic Detection of NIC Address function as described above for that NIC will be turned off and will not cause any "false boots".

Wildcard Character Usage For Mixtures Of NICs
For reasons already explained, if you have a mixture of NICs and you wish to use the Auto-configuration feature of WiseManager, you must take steps to ensure that WiseManager loads the proper network driver for each card. For instance, both the Kingston KNE40 and KNE30 use NIC addresses that begin with 00C0F0 but require different drivers. Therefore, if you activated the KNE30 template machine and power on a machine with the KNE40 NIC, it will be unable to boot - because it would attempted to boot with the KNE30 network driver!

Once the machines are built, there is no problem using mixtures of NICs.

Wildcard Character Usage For Certain IBM NICs
Certain NICs, including IBM NICs, present a different challenge: they don't seem to have a consistent NIC address pattern. Unlike the Kingston cards whose NIC address always begin with 00C0F0, the IBM Etherjet NIC seems to come with various starting NIC address patterns. You will have to either create multiple template machines for these cards, or make other adjustments as your installation progresses.

WiseClient Configuration
After you had built a client machine, everything about that machine can be managed from WiseManager. Using the previous example, if you click on the Main work-group you would have seen a button registered for the machine you just built. Note: The first time you do this you may get a message "error group does not exist" if so, press the create button. If, however, you had that window open while the machine is being built, you will need to right click anywhere on that screen and select "Refresh". The management console for that machine will appear. See Managing A Remote Boot Client for a full discussion on how to manage a remote boot client.

Quick Start
A newly installed machine is usually set to VGA and one of the first things users or support people do is reset the configuration to SVGA. This is a process well known to both users and support people, so let's take a look at how WiseManager can improve this process. And by doing that, provide you with a clear example at how effective WiseManager can be at supporting the operational nature of the network, including supporting users.

For this example, we will assume that the IBM GenGradd driver supports the video card on the client system. The WiseManager user goes to the the Application Launching window, to the left of the Management Console. Expanding the "Hardware" tree, the user will see "IBMGenGradd". Note: IBMGenGradd may not appear under the hardware tree for some users. They may see SDDOS2. If so, these users may install the SDD drivers (if the video in the client is supported by SDD). To make this change on the workstation, the WiseManager user executes a simple drag and drop of this item on the Management Console, anywhere within that window on the right. After a few seconds, you will see the client machine goes into an auto-reboot and you can check that the machine is indeed working in SVGA mode after that.

This example illustrates two important features of WiseManager. First, this illustrates the power which can be implemented in a Managed Client environment using WiseManager to manage workstations. Second, it demonstrates how this power can be implemented utlizing the simple drag and drop functionality made possible with the WorkPlace Shell. This powerful implementation often overlooked and under appreciated. However, WiseManager makes excellent use of this technology to support the administration of operations in the computing environment.

Drag and Drop Application Deployment
This same drag-and-drop action is all that is required to install or deploy either an application or hardware item onto a client machine. In addition, users can set up application groups and perform drag-and-drop deployment of a number of applications to a client machine. The WiseManager - Enterprise Edition also support drag-and-drop application deployment on a work-group, server, and domain basis. Deploying an application to hundreds of machines requires only one drag-and-drop mouse action!

The standard WiseManager installation CD comes with a set of configurations for a number of common OS/2 applications. Other than "free-ware", "trial-ware", or standard applications (such as Netscape), the "gut" of the individual program packages are not included. In order to set up an existing licensed or in-house package to be "deployable", you must follow the instructions in the Application section of this manual.

Managing A Remote Boot Client
All activities required to manage a remote boot client can be performed from the management console for that client.
 * Applications:All of the applications installed on this machine.
 * Hardware:All of the special hardware installed on this machine.
 * IBMLAN:Direct access to important directories and files for this machine in the IBMLAN directories.
 * WiseCfg:All configuration related directories and files related to user applications.
 * WiseWork:Actual working area for user applications.
 * WiseData & WiseLog:Reserved for custom software applications.

System Menu

 * Applications:Brings up the Application management console available for this client.
 * Setting:A pop-up menu for setting related functions for this client.
 * Utility:A pop-up menu for miscellaneous utility functions for this client.

Setting

 * Edit OS2.Key:Edit the OS2.KEY file for the remote client. OS2.KEY contains a list of "important" files that will automatically be backed up by the server.
 * Restore config.sys:Restores the client machine's CONFIG.SYS from the most recent backup.
 * RIPL param:Perform changes on the remote client's RIPL parameters.
 * System:Make changes to system related parameters for the remote client.
 * WiseClient:These are functions which modify or control the behavior of the WiseClient program as it runs on the remote boot client.
 * Configuration:Make changes to the WiseClient configuration for this remote boot client.
 * Debug:Affect debugging related features of WiseClient for this remote boot client.
 * On - Turn on WiseClient debugging for this remote boot client
 * Off - Turn off WiseClient debugging for this remote boot client.


 * Polling:The current version of WiseClient polls the server at preset intervals (polling) to determine if there are instructions assigned for execution. WiseClient is shipped with a default setting, which can be overridden by the user.
 * Default - Set WiseClient polling rate to the default setting.
 * Fast - Speed up WiseClient polling.


 * Restart:Restarts the WiseClient program.
 * Resume:Resume WiseClient from a suspended state.
 * Suspend:Place WiseClient in a suspended state. (This function has not been implemented in this release of the package.)

Utility

 * Backup:Perform a time stamped backup of "important" files listed in the OS2.KEY file for this remote boot client.
 * Rebuild:Rebuilds all of the "important" files from a backup set. (This function has not been implemented in this release of the package.)
 * Reboot:Reboots the client machine. A dialog box will pop up on the client side to allow the user to either decline the request, or pause to save their work - otherwise the machine will reboot after 30 seconds.
 * Resume:Resume WiseClient from a suspended state.
 * Suspend:Place WiseClient in a suspended state. (This function has not been implemented in this release of the package.)
 * Clone:Clone this machine. (This function has not been implemented in this release of the package.)
 * Destroy:Logically destroy this remote boot client. Note that all the files for this machine in WiseCfg and WiseWork ARE NOT AUTOMATICALLY DELETED. This allows for a graceful recovery of user data files in the event that the machine was destroyed accidentally.

Application
To take advantage of WiseManager's drag-and-drop application deployment function, users must take the application software apart and place the components on the server in the appropriate location and form. The WiseManager installation CD comes with a set of configurations for a number of common applications which can be used under OS/2. These applications will be referred to as "Standard Applications". All other applications will be referred to as "Custom Applications".

Anatomy of an "OS/2 Application"
In this document, the term "OS/2 Application" is extended to include any DOS or Java application which can be executed in OS/2 Warp 4. However, Windows 3.1 programs are handled differently and will be discussed separately.

Before any "OS/2 Application" can be made to run on a remote boot client station, there are six questions that must be answered. The"answers" to these six questions are conveyed to WiseManager via REXX "code stubs".

NOTE: If you are not familiar with REXX programming, and all you want is to install "Standard Applications" for your system, you can skip the following explanation and jump to the next section - Standard Applications.

To better illustrate this process, we shall use Netscape version 2.02 as an example and provide a brief discussion (see the DeskTop REXX Script section for a more detailed discussion).

If you do not have the Application Launch Window open, you can click "Application" from the system menu of a machine's Management Console to open it - NOT to be confused with the "Applications" tree branch which would display the list of applications already installed in that machine. Expand the Internet branch from the Application Launch Window and the NetScape2.20 (the program is V2.02 but the directories are named 2.20. Some users will use NS 4.61)  (and NetScape) branch. Double click on anyone of the six entries to open the corresponding REXX scripts. Should you click on an entry which does not require a REXX script, you will see the letters N/A, Not Applicable, appended to the item. Management Console Application Launch Window Application Launch Window with Internet Expanded

Application Launch Window with Netscape 2.20 Expanded

Config.sys
What needs to be done to the remote boot client's config.sys?

Double click "Config.sys" for Netscape2.20 and you will see these lines: libpath = BootDrive"\netscape2.20\program;" path = BootDrive"\netscape2.20\program;" which indicates that both the libpath and path statements in the client's config.sys file will be apended to with the translated result of BootDrive"\netscape2.20\program;" When you drag-and-drop the Netscape application onto the remote boot client, WiseManager looks up the value of the client's boot drive letter and then executes the steps necessary to modify the client machine's config.sys as instructed.

Create
What needs to be done on the server to create a working area for the remote boot client to run this application?

Netscape 2.20 does not need a working area and that's why you will see "Create (N/A)" listed.

Let's look at Netscape 4.04 instead. Expand Netscape and double click "Create" and you will see the following line: WiseWorkDir = MakeWiseWorkDir("NetScape") When you drag-and-drop the Netscape application onto the remote boot client, WiseManager creates a working area in the WiseWork directory reserved for the client to run the Netscape program.

DeskTop
What needs to be done to make this application visible on the remote boot client's desktop?

When you drag-and-dropped the Netscape 2.20 application onto the remote boot client, WiseManager issues a command causing WiseClient to execute the "DeskTop" REXX script for Netscape.

These "DeskTop" REXX scripts may be as simple as creating a WPS object for running the program, a WPS folder object for the package, or they could be an elaborate program for setting up the station to run in SVGA mode. If you are familiar with WPS object REXX programming, you would feel comfortable reading the one created for Netscape 2.20.

The "Desktop" REXX script should also include code to create entries in the client's startup folder if that's needed.

In general, the best way to create the "DeskTop" REXX script for a particular program is to install the package in a reference machine, and then use the Object Package function of Stardock's Object Desktop program, or similar utility program, to generate an initial version of the REXX script. Once you have done that, you can modify the script to the form required by WiseManager (see the DeskTop REXX Script section for a more detailed discussion).

FitSection
What entries do we need in the remote boot client's fit file?

Double click "FitSection" for Netscape to bring up the following: Fits.0 = 999 Fits.i = "; BEGIN Netscape" Fits.i = BootDrive"\OS2\NSCP.INI "WiseWorkDir("NetScape")"\NSCP.INI" Fits.i = BootDrive"\OS2\NSREG.DAT "WiseWorkDir("NetScape")"\NSREG.DAT" Fits.i = BootDrive"\Netscape\NS40.ICF "WiseWorkDir("NetScape")"\NS40.ICF" Fits.i = BootDrive"\Netscape\Users "WiseWorkDir("NetScape")"\Users" Fits.i = BootDrive"\Netscape "AppServer("Netscape") Fits.i = "; END Netscape" When you drag-and-drop the Netscape application onto the remote boot client, WiseManager interprets the REXX code stub and performs the necessary translation and appends the following lines to that machine's fit file. The entries may look like this: Z:\OS2\NSCP.INI \\MNOTEBOOK\WISEWORK\MAINOFFICE\DEMOSTATION\NetScape\NSCP.INI Z:\OS2\NSREG.DAT \\MNOTEBOOK\WISEWORK\MAINOFFICE\DEMOSTATION\NetScape\NSREG.DAT Z:\Netscape\NS40.ICF \\MNOTEBOOK\WISEWORK\MAINOFFICE\DEMOSTATION\NetScape\NS40.ICF Z:\Netscape\Users \\MNOTEBOOK\WISEWORK\MAINOFFICE\DEMOSTATION\NetScape\Users Z:\Netscape \\MNOTEBOOK\WISEPROG\Netscape The first three lines are file by file mappings. The last two lines are directory mappings.

Note that WiseManager translated WiseWorkDir("NetScape") into \\MNOTEBOOK\WISEWORK\MAINOFFICE\DEMOSTATION\NetScape where MNOTEBOOK is the name of the application server where NetScape resides; WISEWORK is a shared directory resource name; MAINOFFICE is the workgroup name; and DEMOSTATION is the user name for that remote boot client.

Note also that AppServer("Netscape") translates into \\MNOTEBOOK\WISEPROG\Netscape.

Remove
What needs to be done to remove this application from the remote boot client's desktop?

When an application remove instruction is executed, WiseManager issues a command causing WiseClient to execute the "Remove" REXX script for the application. This "Remove" REXX script is usually a very simple script which removes the WPS objects from the remote boot client, or de-registers certain WPS classes from that machine.

Not all items can be removed - some might require a complete rebuild of the client machine which, fortunately, doesn't take very long.

StartUp
What needs to be done to the remote boot client's startup.cmd?

For certain applications, it might be necessary to have an entry in the client machine's startup.cmd instead of relying on the startup folder to initialize the applications. For instance, certain network applications require that a network logon be completed before the program can start. One such application is WiseClient itself. If you look at the StartUp section of Basic -> Desktop, you'll see the following REXX code stub: startup.0 = 999 startup.i = "REM Begin DeskTop utilities" startup.i = "logon ManagedClient /p:ManagedClient /d:"domain startup.i = "start /min "BootDrive"\WiseClient.exe" startup.i = "REM End DeskTop utilities" When you drag-and-drop the Desktop application onto the remote boot client, WiseManager interprets the REXX code stub and performs the necessary translation and appends the appropriate lines to that machine's startup.cmd. The resulting entries could look like this: REM Begin DeskTop utilities logon ManagedClient /p:ManagedClient /d:touchvoice start /min Z:\WiseClient.exe REM End DeskTop utilities Notice that on the second line, WiseManager substituted the name of the client machine's actual domain name in place of the variable name domain.

Standard Applications
The procedure of setting up a standard application on the server so it can be deployed by executing a drag-and-drop instruction is fairly straight-forward. Steps III and IV are normally not needed for most applications. If in doubt, you should perform steps I and II, drag-and-drop the application onto a client machine, and try to run the applciation from the client machine. Most well packaged "OS/2 Applications" will execute at that point. Using a remote boot client machine as the reference machine, install the application on that machine's boot drive.

To minimize confusion, it's best not to use a production machine for this purpose. Use a reference machine and then "destroy" the reference machine when you have completed this process.

Transfer the newly created application to proper locations in the \TVOICE\WISEPROG directory on the server.

To do this from the server, go to the Application Launch Window for any of the machines defined for this server, find that particular application by expanding the application group branches. Once you found the application, right click and you will see a "Reference" menu item. Click on that and then "Execute". You will then be prompted for the ACTUAL location for the reference copy of that application as seen from the server. Once you have done that, WiseManager will automatically do all that is required to copy that application to the proper location. This application is now ready to be deployed. Identify files needed for WiseCfg

This step is unnecessary for most well packaged applications.

You need to identify all those files which are used by the application to store configuration related information and place a "reference set" in a sub-directory WiseCfg underneath the \TVOICE\WISEPROG\APPNAME directory where APPNAME is the name of the application - such as Netscape.

When creating the reference set, be sure to maintain the EXACT directory structure of the original setup. For instance, Netscape.ini resides in the top directory of the original Netscape directory. You will need to have a reference copy of Netscape.ini in the \TVOICE\WISEPROG\NETSCAPE\WISECFG directory. Likewise, if you have a file anyname.ini in the original \Netscape\mail directory, you will need to copy that to \TVOICE\WISEPROG\NETSCAPE\WISECFG\MAIL directory.

For most applications where this step is necessary, it is sufficient to mirror the directory structure in \TVOICE\WISEPROG\APNAME\WISECFG. However, packages such as DB2/UDB client, StarOffice, and Lotus SS for OS/2, requires some work before the package can be made drag-and-drop deployable. A screen shot is hereby provided to compare the directory structure of a normal StarOffice installation, and what's needed in the WiseProg directory.

Note that any files in the APNAME\WISECFG directory are only REFERENCE files. Each remote client station will have a set of files for its own use.

Identify files needed for WiseWork

This step is unnecessary for most well packaged applications.

The rest of the READ/WRITE files need to be identified by the applciation. Place a "reference set" of these files in the WiseWork subdirectory, underneath the \TVOICE\WISEPROG\APNAME directory where APNAME is the name of the application, such as NETSCAPE.

With most packages, it's only necessary to identify the directory structure of the original setup, rather than the actual files themselves - since these files will most likely be created when the program is executed on the client side. For instance, Netscape 2.02 contains a sub-directory called "mail" for storing all incoming email messages. All you need then, is to create the directory \TVOICE\WISEPROG\NETSCAPE\WISEWORK\MAIL. Netscape 2.02 will not function properly without this directory.

See application by application discussion regarding application deployment abnormalities.

Custom Applications
(under construction)

Client Machine Does Not Complete Booting
Q: The client machine started to boot but immediately stopped with some SYS**** message

A: The machine is damaged - logically. "Destroy" the machine from the server. Then follow instructions for the manual cleanup procedures to do a sanity check. When this is complete, re-create the machine.

Q: The client machine started to boot but immediately stopped with some network driver error message

A: The machine is attempting to use the wrong network driver. This is most likely caused by a unexpected NIC address pattern match. For instance, both the Kingston KNE30 and KNE40 use NIC addresses utilizing identical numbers in the first 6 digits. If you have both template machines active, even from different boot servers, you could run into this problem. You need to disable the template machine with the incorrect NIC address pattern.

Q: The client machine started to boot but stopped with some OS/2 network driver error message

A: This RIPL process begins in a 16 bit DOS mode, then converts to a 32 bit OS/2 mode. If the DOS stage of the boot process completes successfully but the OS/2 side doesn't, you will have to try a different network driver for the NIC card on the client side. Not all NICs and the associated drivers are well tested and supported in this RIPL environment.

Q: The client machines started to boot but some of them doesn't boot all the way

A: If you are using Ethernet, this is possible because of the 'boot storm' effect - the network got so busy that some packets got lost. Simply reboot the machine that didn't boot. If this problem persists, you will need to "stage" gang-bootups, or to use ethernet switches to segmentize the group. Contact technical support for further assistance.

Client Machine Won't Boot
Q: I powered on the client machine but all I see is an incrementing counter

A: The client machine can't find a server with either an exact NIC address match or a base match on the NIC address pattern. This could be caused by a faulty or improperly connected network cable or hub, a NIC address setting error, or incompatible NIC hardware. For example, a user could not boot a client machine with a Kingston NIC from an IBM 325 server. The user found that changing the Kingston NIC to a 3COM solved the problem. Changing the IBM 325 server to a different IBM model also solved the problem.

Client Machine Won't RPL
Q: I powered on the client machine and I get an operating system missing message

A: The Boot Prom on the client side NIC is not functioning. Some NICs require running a DOS program to activate the Boot Prom, others require a BIOS change in the computer, and still other NICs do not support RPL remote booting - only DHCP remote booting is supported. Currently, WiseManager only supports RPL remote booting.

Client Machine Booted From The Wrong Server
Q: The client machine booted but it's the wrong server.

A: If you have multiple RIPL servers and you also have multiple boot records for the client machine, you have no control over which server will be used to boot this client. This is the intended result of the automatic load balancing feature. In fact, if two servers have identical set ups, should one server be down, the client machines can still boot from the other server without disrupting users or losing productivity.

Double Click
Q: I double clicked an item and I was expecting to see the content of that item displayed, but nothing happened.

A: When you double click on item such as the "Config.sys" of an application, WiseManager issues a start command to bring up the editor to view that item. The default editor is the system E editor and sometimes the E editor will start in the background. If you bring up the window list, you should see the editor entry. You can change the default editor to whichever editor you want to use from the WiseManager installation program -> Configuration system menu.

Error in RPL.MAP - RIPL can't start
Q: RIPL was working but now I get an Error in RPL.MAP message when I try to do a NET START RIPL

A: Your RPL.MAP was damaged. Bring up the WiseManager installation program and click on the configuration drop down menu in the install program and do a "Rebuild NIC List". If problem persists, repeat the GETRPL step of the installation procedure.

Manual Cleanup of a Client Machine
Q: How do I manually delete a client machine?

A: Carefully follow these steps: In both of steps 8 and 9, you may get a message that some files in these two directories cannot be deleted. This happens when the WPS on the SERVER thinks that some objects for the CLIENT are still in use, even though this is not the case. If this occurs, the only thing you can do is to try and move those directories to a garbage partition and format the garbage partition.
 * 1) Make sure the client machine has been powered off for approximately 10 minutes, not less than 5 minutes.
 * 2) Startup the OS/2 LAN Server Administration program (LANGUI)
 * 3) Open Local Machine
 * 4) Open RIPL machine folder
 * 5) If the machine you're trying to destroy is still there, try to delete it (right click -> delete). Continue the process, even if you receive an error message. If you get a SYS3175 in NETAPI.DLL, edit RPL.MAP as described in the next step.
 * 6) Close the RIPL machine folder and reopen it. The machine you're trying to destroy should no longer be in this folder. However, the machine is still in the folder, close the LANGUI program and edit the file \ibmlan\rpl\rpl.map. Examine the last part of the file. You should see a line with the machine name you are trying to destroy. Remove that line and save the file. Re-open the RIPL machine folder, and the machine will no longer exist. Close the RIPL machine folder.
 * 7) Open the domain folder and then the user folder. The user entry for your machine should be gone. If not, delete it (right click -> delete). Close the LANGUI program.
 * 8) From the drive object, open the \ibmlan\rpl\machines folder. Check to see if a directory exists with a name matching the machine you're trying to destroy. If it's there, try to delete it from the WPS.
 * 9) Open the \ibmlan\rpluser directory folder. Check to see if a directory exists with a name matching the machine you're trying to destroy. If it's there, try to delete it from the WPS

As a last resort, you can boot to the command line and use the TouchVoice supplied REXX program TREDEL (residing in the TVoice\WiseProg\Install directory) to delete those two directories.

No Desktop
Q: When the client boots up, I get an "error re. SET RUN WORKPLACE= WinStart App" message and no desktop

A: Should this happen, it indicates that the last step of the WiseManager installation program was not completed. You need to re-execute the last step of the installation program and reboot the server. To do this, go to the utility drop down menu in the main or templates froup screen and select "reapply-ACLs". If the problem persists, check for the existence of a user ID ManagedClient and check the ACL of the \TVoice\Wise**** and \TVoice\Config directories. All ManagedClient logons should have Read Only access to the WiseProg and Config directory, and R/W access to the WiseCfg and WiseWork directories.

SYS1200
Q: When the client boots up, I get a SYS1200 (DOS can not start) message.

A: By default, WiseManager does not include DOS for the client and you will get a SYS1200 message from TCP/IP. It's only an informational message and can be safely ignored.

SYS3175 in NETAPI.DLL
Q: When I try to "destroy" a machine, WiseManager crashed with a SYS3175 message. The machine does not get destroyed.

A: As of July, 1999, there is a bug in the IBM supplied file NETAPI.DLL in deleting RIPL machines. Under certain conditions, if the machine was "damaged", you will end up with a SYS3175. The solution is to perform a manual cleanup of the damaged machine.

TRAP 000d
Q: When the client boots up, I see a listing of all the driver. As this completes, the client dies with a trap d somewhere in SINGLEQ$

A: This is most likely caused by using a video controller that is non-compatible with the GenGRADD video driver. Reset the machine to run in VGA mode, and then select a native driver if one is available.

WiseManager Error
Q: I started WiseManager and click a domain button, I got the message "Can not locate \\DCNAME\WiseManD\Config"

A: WiseManD is the name of the alias that points to the location of the \TVoice\Config directory which contains the information of ALL of the RIPL servers in the domain DCNAME. An alias (not to be confused with peer resource) is a domain wide resource. Within a domain, \\SERVER1\WISEMAND and \\SERVER2\WISEMAND all point to the same location. Occasionally, the additional server is "out of syn" with the domain controller and may require a domain controller reboot.

To verify that this is indeed what's happening:

Issue a NET ALIAS command from both the domain controller and additional servers to make sure that WiseManD is a valid alias.

Issue a NET SHARE command from any server to make sure that the alias WiseManD has been shared. By default, WiseManager creates the WiseManD alias to be shared upon server startup.

Issue a DIR \\DCNAME\WISEMAND command from each of the servers. It should be a valid UNC name.

Verify that the \TVoice\Config was created by WiseManager with an ACL of R for the Templates group.

Q: I started WiseManager and click a domain button, when I click on a Server button, the machine locked solid

A: There is an obscure bug in Aurora that's causing this and we are working to identify and report it to IBM. In the mean time, you can include the following SET statements in the config.sys of the server to get around it:

In your config.sys, do a set RPLFILES=x:\IBMLAN\RPL If it still locks up, do a set IBMLAN$=y:\ibmlan If it still locks up, do a set WRKFILES=w:\ibmlan\rpluser where x, y, w are the respective drive letters.

Fit File
The magic behind managing a remote boot client is through the use of network file mapping. The majority of desktop applications are not written to be network managable. Warp Server keeps a file mapping table (fit file) in the \IBMLAN\RPL\FITS directory for each of the remote boot clients. A typical entry might look something like: Z:\startup.cmd \\MNOTEBOOK\WiseCfg\System\Main\MTEST\startup.cmd which means z:\startup.cmd from the client side is automatically mapped to the UNC name listed.

There is a 64K limit per file mapping table and the "map to" name can not be a local file on the client side.

UNC Name
UNC names are used extensively in WiseManager. An UNC name begins with a pair of reverse slashes (\\) followed by a server name, another reverse slash (\), followed by a resource name, then followed by another reverse slash separating the rest of the name. For instance, the name \\MNOTEBOOK\WiseCfg\System\Main\MTEST\startup.cmd refers to the startup.cmd file located on the MNOTEBOOK server, in a sub-directory System\Main\MTEST underneath a directory pointed to by the shared directory resource WiseCfg - where ever WiseCfg is pointing to.

Work Area
For most applications, there are three working areas on the server that are needed by each remote boot client.

WiseProg
This is a read-only area for the actual "gut" of the applcation. Usually, only one copy of the application is needed for ALL remote boot clients to share. You can, of course, have additional copies which can be different versions.

WiseProg can also be mapped to any application server on the network. For instance, you could have a Linux, AS400, or RS6000 machine acting as your application server.

WiseCfg
This is a Read/Write area for all of the configuration related files (such as INI files) for that application. Each remote boot client has their own WiseCfg area for each of the applications they are authorized to use.

WiseWork
This is the Read/Write area for any other files for the application. Each remote boot client has their own WiseWork area for each of the applications they are authorized to use. For instance, if the application is a word processor, this would be the area to store the various letters, memos and so on which would be accessible from a particular remote boot client.

WiseData and WiseLog
Reserved for specialized vertical applications.