Академический Документы
Профессиональный Документы
Культура Документы
0 Feature
for Windows Clients
Axel Buecker, Joao Miguel Galvao, Khathutshela Muvenda, Indran Naick
www.redbooks.ibm.com
SG24-5396-00
SG24-5396-00
August 1999
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix D, “Special notices” on page 235.
This edition applies to IBM WorkSpace On-Demand 2.0 Feature for Windows Clients for use with the
IBM WorkSpace On-Demand 2.0 and OS/2 Warp Server.
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .1
1.1 WorkSpace On-Demand 2.0 overview . . . . . . . .. . . . .. . . . . .. . . . . .1
1.2 The Feature for Windows Clients . . . . . . . . . . . .. . . . .. . . . . .. . . . . .3
1.2.1 Components . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .4
1.2.2 Server platforms supported . . . . . . . . . . . .. . . . .. . . . . .. . . . . .7
1.2.3 Client platforms supported . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .7
1.3 Client hardware considerations . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .8
1.3.1 Remote boot capability . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .8
1.3.2 Windows 95 and Windows 98 hardware . . .. . . . .. . . . . .. . . . . .9
1.3.3 Windows NT 4.0 hardware . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .9
1.3.4 Device support . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 10
1.4 Licensing and packaging . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 10
v
5.6.2 Enabling network adapters on Windows 9x. . . . . .. . . . . .. . . . 162
5.6.3 IBM Auto, Turbo, and 3COM . . . . . . . . . . . . . . . .. . . . . .. . . . 167
5.7 Printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 167
5.7.1 Windows 9x printing . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 168
5.7.2 Windows NT printing . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 169
5.8 Network protocol support . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 171
5.9 The Microsoft ScriptIt utility . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 172
5.9.1 Using ScriptIt . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 173
5.9.2 Multimedia support using ScriptIt . . . . . . . . . . . . .. . . . . .. . . . 175
5.10 Other client commands. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 176
5.10.1 Changing the client operating system . . . . . . . . .. . . . . .. . . . 176
5.10.2 Resetting a client. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 177
5.10.3 Redefining a client . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 177
5.10.4 Deleting a client.. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . 177
5.10.5 Querying client information . . . . . . . . . . . . . . . . .. . . . . .. . . . 178
vii
How to get ITSO redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
IBM Redbook Fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
This redbook will help you add the IBM WorkSpace On-Demand 2.0 Feature
for Windows Clients to your current WorkSpace environment. It is the result of
a residency conducted at the International Technical Support Organization,
Austin Center, during the final development of the product. The redbook will
help you to:
• Understand the IBM WorkSpace On-Demand 2.0 Feature for Windows
Clients product and the situations in which it is most appropriate to deploy.
• Understand the remote IPL and software distribution concepts behind the
IBM WorkSpace On-Demand 2.0 Feature for Windows Clients and the
implementation of this product.
• Plan and install IBM WorkSpace On-Demand 2.0 Feature for Windows
Clients in your enterprise.
• Define client workstations on your WorkSpace On-Demand server, and
boot and install these client workstations remotely over the network using
a Windows 9x or Windows NT workstation.
• Add applications to a managed Windows environment.
• Add support for additional network adapters and other types of hardware
to expand the hardware support provided by the IBM WorkSpace
On-Demand 2.0 Feature for Windows Clients.
This redbook also compares the IBM WorkSpace On-Demand 2.0 Feature for
Windows Clients against similar technologies available from other vendors,
allowing you to make an informed decision.
Randy George
Architect, IBM Austin
Ron Aguirre, Tsutomu Oya, Oscar Cepeda, Mike Foster, Milos Radosavlijevic,
and Temi Rose
International Technical Support Organization, Austin Center
Remi Trombetta
IBM France
Drago Belak
IBM Slovenia
David Dutcher
IBM Austin
Khoa Huynh
IBM Austin
Marc-Arthur Pierre-Louis
IBM Austin
Kerry Fehlis
IBM Austin
Norm Mattson
Golden Code Development Corporation
Reinaldo de Medeiros
IBM Brazil
Charlie Rouh
IBM U.S.
Neil Stokes
IBM Australia
Antonio Arias
IBM U.S.
Mala Anand
IBM Network Computing Systems Division, Austin
Martin Bense
GAD Gesellschaft fuer automatische Datenverarbeitung eG
John Case
IBM U.S.
Martin Dippold
IBM Global Services, Germany
Andy Erhenzeller
IBM U.S.
Ivan Faisal
IBM Indonesia
Steve French
IBM Network Computing Systems Division, Austin
Ann Gleason
IBM Network Computing Systems Division, Austin
xv
Aidon Jennery
IBM Network Computing Systems Division, Austin
Scott Jonston
IBM Canada Ltd
Larry D. Jones
Innova Solutions Inc.
Brian Howe
IBM Japan
Marcello Savio
IBM Brazil
Tim Sennitt
IBM U.K.
Peter Greulich
IBM U.K.
Toshi Shimizu
IBM Network Computing Systems Division, Austin
Timothy Sipples
IBM U.S.
Oliver Stein
IBM Germany
Larry Sullenger
IBM Network Computing Systems Division, Austin
Keiichi Togashi
IBM Japan
Robert Rose
IBM Network Computing Systems Division, Austin
Dick Reardon
IBM Network Computing Systems Division, Austin
Dan Wiggins
IBM Network Computing Systems Division, Austin
Starwalker Jj
Graphic Illustrations
Comments welcome
Your comments are important to us!
xvii
xviii WorkSpace On-Demand 2.0 Feature for Windows Clients
Chapter 1. Introduction
The Feature for Windows Clients enhances your WorkSpace On-Demand 2.0
environment by giving you the option to integrate Windows NT or Windows
95/98 based clients in a similar way as your current WorkSpace On-Demand
clients.
This chapter provides a brief introduction to the Feature for Windows Clients.
It covers functional descriptions of the components as well as the hardware
and software prerequisites. The licensing and packaging of the product is
also covered here.
User Authenication/
Logon Management
Workspace On-Demand
32-bit Server
Logon Screen
Note that both these components are physically installed on an OS/2 Warp
Server system, which is then known as a WorkSpace On-Demand server.
Introduction 3
A secure, enterprise-targeted operating system platform is now included
into your choice of desktop environments with the Feature for Windows
Clients.
• Windows 95/98
Even Windows 95/98 with its broad support on available hardware can be
deployed as the second new choice in the WorkSpace On-Demand
installation.
All of the supported client operating systems can be serviced from the same
server in your network. For smaller branch offices, this may impact savings in
costs as well as maintenance. The administrator only needs to keep one
server updated and running. There is no longer a need to deploy different
types of servers for different client and application requirements.
Naming Conventions
To make the naming of all these different flavors a little more convenient for
you, we will use the following terms throughout the book.
• WorkSpace On-Demand Client
To refer to the OS/2-based client
• WorkSpace On-Demand Manager
To refer to the WorkSpace On-Demand server installation
• Feature for Windows Clients
To refer to the Workspace On-Demand Feature for Windows Clients
• Windows 95/98 Client Feature
To refer to the Windows 95/98 client
• Windows NT Client Feature
To refer to the Windows NT client
• Windows applications
To refer to Windows 32-bit applications
1.2.1 Components
The following components have been added or updated on the WorkSpace
On-Demand Manager to provide support for Windows Clients. There is
currently no graphical interface available for the Feature for Windows Clients.
The architecture on the client and the components are described briefly
below:
• Feature for Windows Clients
While WorkSpace On-Demand 1.0 and WorkSpace On-Demand 2.0
provided server-based management of WorkSpace On-Demand machine
images using Remote Program Load (RPL) or Dynamic Host Configuration
Protocol (DHCP) boot for operations, the Feature for Windows Clients
support is implemented differently. Since these operating systems do not
remote boot from the Warp Server, a remote-install paradigm is used.
The client systems are set up to first boot from the network. DOS RPL is
used to initiate an unattended remote install to the local client hard disk of
the target system.
The install process uses input parameters from a response file to drive the
configuration of the client system. Each client (each unique MAC address)
Introduction 5
will have its own response file containing information about its
configuration (for example, IP address and hostname).
Once the install process is completed, during subsequent reboots, the
client system still sends a RPL boot request to the server. After a brief
handshake with the server, the client continues the boot process from the
operating system image on the local disk. The boot process completes
with the client machine booting up to the WorkSpace On-Demand logon
panel.
The boot process will be discussed in more detail in Section 2.2, “The boot
process” on page 18.
• Network Logon Client
To incorporate the changes necessary for the secure Feature for Windows
Clients environment, updated versions of the IBM Networks Primary
Logon Client for Windows NT and the IBM Networks Client for Windows 95
are shipped with this product. They differ from the versions distributed
through IBM Software Choice and they are not available separately.
• Desktops
To adjust the look and feel of the Feature for Windows Clients, a standard
WorkSpace On-Demand desktop is available. Administrators can also
create their own desktop images and logon bitmaps.
When users change the appearance of their desktops or alter application-
specific settings, this information is stored in the user profiles. There is a
method provided with the Feature for Windows Clients where an
administrator is able to define all the basic settings and then deploy the
user profile on the primary domain controller.
When users are logging on to the primary domain controller using the
Feature for Windows Clients, they get their local user profiles updated by
the ones on the server side. Temporary changes now made by a user are
not saved back to the server. Each time a user logs on she or he will find
the same corporate desktop setup.
To restrict the users’ access to their desktops and several system
functions, you use the Windows system policies. These files are controlled
by the administrator using the System Policy Editors for Windows 95/98 or
Windows NT and by deploying them in the right places on the primary
domain controller that every user has access to. There are two
preconfigured, restricted policy files shipped with the product, one for
Windows 9x and one for Windows NT environments.
1.2.3.1 Windows 95
There are multiple versions of Windows 95 currently available. The version of
Windows 95 supported in this environment is:
• Windows 95 OSR2 OEM Version which is available only through the OEM
preload channel.
Introduction 7
Other versions of Windows 95 are not supported. You need to have the
original CD to have it installed on your WorkSpace On-Demand boot server.
1.2.3.2 Windows 98
The Windows 98 retail version is the version supported in this environment.
You need to have an original CD to install it on your WorkSpace On-Demand
boot server.
The client machine must also have a BIOS setting that allows the network
adapter to be one of the boot devices.
Support
For support, IBM requires that both requirements are met, and the network
adapters selected are on the list of supported adapters.
1.3.2.1 Processor
The Windows 95/98 Client Feature runs on any INTEL-based system
(personal computer or network computer) that is capable of running Windows
95 or Windows 98. For performance reasons, we recommend at least an
INTEL 486 33 MHZ.
1.3.2.2 Memory
The client’s operating system requires at least 8 MB of memory. We found
that at least 16 MB of memory is sufficient. The amount of memory also
depends on the number of applications that you are running on your clients.
Because memory prices have dropped, it is the most cost effective method of
increasing workstation performance. With 64 MB of memory, the Windows 95/
98 Client Feature performs best in a standard office environment.
1.3.2.3 Diskspace
As mentioned earlier in this chapter a hard drive is required on your clients.
The maximum hard disk size supported on the Feature for Windows Clients
workstations is 8 GB.
1.3.3.1 Processor
An INTEL 486/66 or an INTEL Pentium 90 processor is the minimum
recommendation for a Windows NT 4.0 client.
1.3.3.2 Memory
A minimum of at least 12 MB of memory is required on x86-based computers,
and 32 MB is recommended for a better performance. However, the exact
amount of RAM required on your client depends on the number of
applications that you intend to run concurrently.
Introduction 9
Again, the more memory you have available for your clients, the better
performance you get. The Windows NT Client Feature in the office
environment also performs well with 64 MB of memory installed. There may
be performance improvements with 128 MB installed.
The default installation partition size is 250 MB, which can be customized. It
is recommended to increase the default partition size for Windows NT
machines to 600 MB to accommodate the service pack. If possible, make the
default partition size equal to the smaller of 8 GB or the largest disk available
in your rollout environment. The other diskspace is not going to be used any
way.
The maximum hard disk size supported on the Feature for Windows Clients
clients must not be greater than 8 GB.
Only FAT16 partitions will be created on the target client. Use of any other file
system is dependent on the particular operating system’s ability to modify/
convert the partition as part of the unattended install. (For example, Windows
NT 4.0 allows the option to convert a FAT16 partition to NTFS as part of the
install process by customizing the installation response file UNATTEND.TXT.)
Each WorkSpace On-Demand workstation that needs to use the Feature for
Windows Clients requires a WorkSpace On-Demand 2.0 client licence and
the appropriate Windows licence from Microsoft, that is, a Windows 95,
Windows 98, or Windows NT licence.
Figure 2 shows that for the traditional OS/2 type client where no additional
licensing is required. For each of the Windows platforms, an additional
licence is required.
Traditional
Client Windows 95 Windows 98 Windows NT DOS/Windows
Introduction 11
12 WorkSpace On-Demand 2.0 Feature for Windows Clients
Chapter 2. Feature for Windows Clients architecture
This chapter will focus on providing you with an overview of the IBM
WorkSpace On-Demand 2.0 Feature for Windows Clients architecture. This
chapter helps you better understand how the product functions as well as
provides an overview of what steps are required to perform particular
functions.
The topics include the new remote-install paradigm, the boot process, and
user administration.
2.1 Overview
WorkSpace On-Demand 2.0 provides the ability to manage machines, users,
and applications between OS/2 clients and OS/2 Warp Servers. The IBM
WorkSpace On-Demand 2.0 Feature for Windows Clients extends this notion
to Windows 95, Windows 98, and NT clients.
User/Authenication/
Logon Management
Workspace On-Demand
32-bit Server
Logon Screen
Logon Screen
Desktop
The new components on both the client and the server are described in more
detail in the sections that follow.
With current versions of WorkSpace On-Demand, the client code was always
located only on the hard file of the server. Using either the RPL or DHCP boot
protocol, the client machine loaded the operating software and applications
into memory.
The boot process is dependent on the condition of the machine, that is,
whether the machine is newly defined or already installed. If a machine is
newly defined, the operating software still has to be installed and configured.
If a machine is already installed, it only has to check whether there has been
an update. This section describes, in some depth, both processes.
RPL.MAP
2 WIN32 RPL.MAP
3 IBMLAN
RPLUSER
WCF1
.
. STATE.FIL
. RESPONSE.FILE
VERSION FILE
address
4
check and confirm
5
request
6
CNF
7 .cnf
load
8
IBMLAN$ connect
WRKFILES$
Z:
9
Y:
START STATE 10
Figure 4 describes the first 10 steps, and Figure 5 on page 23 describes the
remaining the steps. The steps are as follows:
2. The NETWIN command uses the existing RPL Process running on the server
to create the client. This puts an entry in the RPL.MAP and W32RPL.MAP
files.
The entry in the RPL.MAP file for the above client is:
0004AC7763EC WCF1 ~ W32DOSSB GA_SRV GA_DOM ~ ~ ~ ,,, Z R_DTK_NDIS ~ ~ ~
The entry in the W32RPL.MAP file for the above client is:
0004AC7763EC WCF1 W32DOSSB R_DTK_NDIS
Both these entries are constructed from the command line definition in
step 1 on page 20.
3. A directory for the client is created under the RPLUSER subdirectory in
which the NETWIN command places three files. This directory is the same as
the name assigned to the client. In our example, the directory
c:\IBMLAN\RPLUSER\WCF1 contains the following files:
STATE.FIL - The state file contains, most importantly, the current state of
the machine that, when newly created, is set to NEW. Other information
contained in the file is the operating system type, the operating system
release, the partition size, the install image to use, and the client type. All
of this information is gathered from the parameters on the command
issued in step 1 on page 20.
unattend.txt - The NETWIN command also creates a response file that the
client will use for installation. The information in the response file is also
gathered from the parameters on the command issued in step 1 on page
20.
VERSION FILE - This is used for administration.
4. The client is powered on, and the RPL feature (on the network adapter)
obtains control. The RPL feature attaches the workstation to the network
and sends a FIND frame. FIND frames contain the LAN adapter address
and are repeated periodically until a server responds.
5. The server receives the FIND frame sent by the workstation. The server
then checks the RPL.MAP file for a workstation record entry that matches
15 13
14 12
13 11
12
10 START STATE
STATE=NEW PREP 11
11 FDISK ,reboot
12
12 STATE=PREP POST FORMAT
FORMAT =XCOPY1
13
13 STATE=XCOPY1 POST-XCOPY1 XCOPY2
COPY 14
14STATE=XCOPY2 POST-XCOPY2 INSTALL
COPY RESPONSE FILE
15
STATE=INSTALL HYBRID
SETUP ,reboot 4 5 6 7 8
16 = HYBRID
11.Since the state is NEW, as it is a new client, int13h and function 41h are
used to see if the IBM/MS API extension is present in the BIOS. If this
function is present, it will use int 13h and function 48h to get the drive
capacity. Otherwise, it issues int13h function 8 to get the drive capacity.
At this point, the system also checks to see how much memory is
available. If there is insufficient memory to run the respective Windows
setup programs, DOS is installed onto the hard drive. This is not depicted
in Figure 5.
address
1
check and confirm
2
request
3
CNF
4 .cnf
load
5
6
1. The client is powered on, and the RPL feature (on the network adapter)
obtains control. The RPL feature attaches the workstation to the network
and sends a FIND frame. FIND frames contain the LAN adapter address
and are repeated periodically until a server responds.
2. The server receives the FIND frame sent by the workstation. The server
then checks the RPL.MAP file for a workstation record entry that matches
the network address contained in the FIND frame.
The workstation record contains two pointers. The first pointer is to a
server record entry, contained in the RPL.MAP file, and the second pointer
is to a DOS image file.
3. The workstation receives the FOUND frame with the address of the server
and sends a SEND.FILE.REQUEST frame back. This frame is a request
for the server to send the bootstrap program.
4. The bootstrap program information is contained in the boot block
configuration file (.CNF) on the server. The CNF file used is derived from
2.4.1 RPL.MAP
The RPL.MAP file contains two basic types of records: workstation records
and server records, as shown in Figure 7.
; server records
yyyyyyyyyyyy dosndtr.cnf 3 10 N IBMLAN$ DOS~TOKEN~RING~NDIS ~ ~ ,,, Z R_DTK_NDIS ~ ~
;workstation records
0004AC7763EC WCF1 ~ W32DOSSB GA_SRV GA_DOM ~ ~ ~ ,,, Z R_DTK_NDIS ~ ~ ~
The workstation record is the primary means by which the server determines
whether it should respond to a client’s FIND frame. Each client that you
Note
A client workstation may have more than one workstation record in the
RPL.MAP file. However, only one record may be active at any time.
When the server receives the FIND frame, it searches RPL.MAP for a
workstation record with a network address that matches the client’s address
contained within the FIND frame. If it finds a match, it responds to the client
with a FOUND frame. If it cannot find a match, it ignores the FIND frame.
After the server responds to the client with a FIND frame, and the client sends
a SEND.FILE.REQUEST frame, the server must determine how to assemble
the boot block to be sent to the client. The required information includes:
• The type of network adapter installed in the client.
• The operating system to download: DOS, OS/2, or Workspace
On-Demand.
• For an OS/2 or WorkSpace On-Demand client, the FIT file that should
be included in the boot block.
• The files that should make up the boot block.
Again, RPL.MAP plays a key role in this process. A client’s workstation record
in RPL.MAP contains certain information, such as the client’s workstation
name and the location of the FIT file, that should be included in the boot
block. In addition, the workstation record contains a key field (as shown in
Figure 7 on page 26) that references a server record.
RPL.MAP contains one server record for each client operating system
supported on the server and for each network adapter installed in the client
workstation. For example, there is one server record for an IBM Token-Ring
Adapter booting OS/2 Warp 4, and another record for an IBM Token-Ring
Adapter booting WorkSpace On-Demand 2.0.
4 W32DOSSB For DOS Remote IPL, this is the name of the diskette
image used to IPL the client (an extension of .IMG is
assumed). This field is limited to eight characters in
length for a DOS client.
5 GA_SRV For DOS Remote IPL, this field contains the name of
the Remote IPL server where the diskette image file
and other files for the DOS workstation are stored.
This name is limited to 15 characters.
6 Z or GA_DOM For DOS Remote IPL, this is the name of the domain.
For OS/2 and WorkSpace On-Demand clients, this is
the drive letter for the RIPL boot drive. Use a letter
from C through Z. Do not use a local hard disk drive.
12 R... or D... This field designates the server record to use for this
client. This field must match Field 12 of a server
record in the same RPL.MAP file. D... stands for a
disabled record, while R... stands for an enabled
record.
6 IBMLAN$ or ~ For DOS RIPL, this is the net name where the DOS
images are located. The images are assumed to be in
the \IBMLAN\DCDB\IMAGES directory path from this
share. For OS/2 and WorkSpace On-Demand RIPL,
this field must contain a tilde character.
Apart from pointing to the LAN adapter support to be used at the Remote IPL
client, the 12th field in the OS/2 server record IDs also determines the client
operating system version to be started at the client. The rules for naming
WorkSpace On-Demand server record identifiers (that is, Field 12 in the
server record) are as follows:
The record identifier must be 48 characters or less and have the format
s_BBvv_nn_aaappppp....
The rules for naming server record identifiers for other versions of OS/2 are
as follows:
The record identifier must be 48 characters or less and have the format
s_BBvv_nn_aaappppp....
• s defines the state of the remote IPL client:
• R - indicates the client is enabled
• D - indicates the client is disabled
From each of the server records a number of events take place. These are
described in Section 2.2, “The boot process” on page 18. These events are
controlled by a number of batch files as described in Figure 8.
Workstation record
dosndtr.cnf
W32DOSSUB
Autoexec.bat = W32_haut.bat
connect
W32RIPL.BAT
W 32 setup.bat
state
doshbrid.cnf
HDISK.COM
The boot block definition files are located in the \IBMLAN\RPL directory.
These definition files define an operating system and the way it is loaded into
a Remote IPL workstation. A definition file is required for DOS, OS/2, and
WorkSpace On-Demand requesters.
Every server record in RPL.MAP must contain a reference to a valid CNF file.
A number of default CNF files are provided for all network adapters and
operating systems supported by WorkSpace On-Demand.
A number of client workstations can use the same CNF file. For example, if
two clients boot the same operating system and have the same type of
network adapter, they will use the same CNF file. Typically, you do not need
to change CNF files unless you change the network adapter in a client
workstation.
Using the data contained in the CNF file, the server creates a boot block that
is sent to the client workstation in a series of FILE.DATA.RESPONSE frames.
This transmission occurs at the very beginning of the IPL process.
Figure 9 on page 36 shows the default DOS CNF file for the IBM Token-Ring
Network Adapter.
Figure 10 shows the definition file sent to the client to force it to boot from it’s
own hard disk. Once a client is completely installed, it uses this configuration
file, unless it is deleted, reset, or redefined.
Figure 10. Boot from hard disk, boot block definition file
HDBOOT.COM is a small bootstrap executable that reads the first sector of the
hard drive and gives control to the OS bootstrap program located on the hard
disk. This boot image avoids the overhead of loading/initializing DOS,
CONFIG.SYS, AUTOEXEC.BAT, and so forth, just to have the system reboot
from the local hard drive.
Alternatively, the paths can be fully qualified. If you provide a fully qualified
path and filename, you must specify the entire path including the drive letter
and all subdirectories.
All fields, including the CNF file parameters, are separated by spaces. Some
values in the CNF file can contain parameter lists used by other software.
Fields that contain these embedded parameter lists must be separated by
tilde characters.
Table 3 describes the entries in the CNF file along with their expected file
names and parameters.
Table 3. The boot block definition file - Field descriptions
Entry Description
RPL A CNF file may contain only one RPL entry. This entry specifies the first
program to be run on the client. No parameters are supplied with this entry.
In Workspace on Demand RPL, this is the RPLBOOT.SYS.
ORG A CNF file may contain only one ORG entry. The entry specifies the
hexadecimal segment number of a contiguous memory block on the client.
Files following this entry in the CNF file are bound to this memory address.
No parameters are supplied with this entry.
DAT A CNF file may contain several DAT entries. These entries specify files that
are to be stored in the boot block and passed to the client. These files are
not used by RPLBOOT.SYS, but they can be read by DOS to handle I/O
functions. No parameters are supplied with this entry.
LDR A CNF file may contain only one LDR entry. This entry specifies the name of
the loader to be used on the client. For WorkSpace On-Demand, this entry
is BB20.US\OS2LDR ~ OS2LDR UFSD.SYS MFSD20.SYS-.
In this case, the OS2LDR is initializing using the RPL micro- and mini-FSDs.
EXE A CNF file may contain one or more EXE entries. These entries specify the
names of executable programs that are to be used on the client. Parameters
may be passed to an executable program as part of the EXE entry.
DRV A CNF file may contain one or more DRV entries. These entries specify the
names of device drivers to be used on the client. Each DRV entry requires
the following parameters:
The parameter list for the device driver. Fields within this embedded
parameter list must be separated by tilde characters.
Use the character M if the driver can be moved after initialization. Otherwise,
this parameter must be a tilde character.
If the driver can be moved, and it requires less memory than the original
driver image, RPLBOOT.SYS moves the driver to reclaim the unused
memory and adjusts all interrupt vectors that point into the driver’s memory
area.
BASE A CNF file may contain only one BASE entry. This entry specifies the
hexadecimal segment number (paragraph) that is the boot block base
address. The default base address is X’00C0H’.
To create the required files, MAKEIMG.EXE uses a file that contains a list of
files:
• To create W32DOSSB.IMG, MAKEIMG.EXE uses W32DOSSB.DEF.
• To create W32DOSUB.IMG, MAKEIMG.EXE uses W32DOSUB.DEF.
STATE.EXE acts as an agent between the server and the Windows operating
system installation on the client. STATE.EXE ensures that the client receives
all the files necessary to install the Windows 95 or Windows 98 operating
system (this includes the client application files).
Typically, you should not manually edit the STATE.FIL file, because the NETWIN
RIPLMACH and STATE.EXE commands provide most of the values the file
State Description
Fields Description
OSRelease Win95/Win98/WinNT.
The state daemon maintains a list of all the client’s states. It builds this list
from the value of the state variable in the State.fil contained in the clients
The NETWIN RIPLMACH /RESET copies the workstation.LOG file into the
workstation.OLD file and wraps the new log entry in the workstation.LOG file.
Once the operating system is installed on the client, subsequent boots are
from the hard drive of the client and nothing is logged on the server.
2.4.3 A sandbox
A sandbox is a Windows workstation that allows for changes. Sandbox
defined machines are used as part of the application package creation
process as well as the designing of different desktops.
A command line switch /SANDBOX is used with the NETWIN RIPLMACH command to
create a sandbox client. An entry in STATE.FIL identifies the client type. The
standard client will be identified as STANDARD and the sandbox client will be
as SANDBOX.
The boot logic checks the client type in STATE.FIL. If the client type is
SANDBOX, it will add a command line switch in the logon client installation
command. With the sandbox switch, install is executed with a unique system
policy file. If the switch is not specified, standard Feature for Windows Clients
install is executed on the client using a restricted system policy file.
The default response file that we ship allows the target client system to be
installed with full support for devices that are autodetected and processed by
For new OEM devices that are not part of the base operating system
package, the response file has to be modified by hand by the system
administrator. A sample response file and cook-book instructions are shipped
with this product to give some guidance to the administrators in customizing
new devices and their device drivers. The administrator is primarily pointed to
Microsoft resources (for example, Windows NT Resource Kit, Microsoft
on-line knowledge base on the Web, and so on) for additional information on
how to customize response files. More information on this topic can be found
in Section 5.4, “Machine classes and response files” on page 155.
By adding lines to an installation script, and placing the installable code in the
proper directory structure, these features are going to be installed
automatically. The features can include IBM’s Java Virtual Machine (JVM) or
the Tivoli Management Agent (TMA) that both ship with the Feature for
Windows Clients. This can also be any Fixpack available for the operating
systems.
The Feature for Windows Clients Logon Client is based on code developed
for the IBM Network Clients. The Logon Client for the Feature for Windows
Clients Windows 9x and Windows NT clients has been modified to account for
unattended installation, changes to the locations accessed for files, and
Windows registry updates that must be executed at the Windows client
platform.
= User’s Desktop
The Feature for Windows Clients supports roaming and mandatory profiles. In
order for a user to be able to log on, the user must be assigned a mandatory
profile. Each user can have two profiles, one for Windows 9x and one for
Windows NT.
The profile is assigned by using the NETWIN USER command with the /DESKTOP
switch. When this command is issued, a user profile is copied to the users
home directory. For Windows NT, this is stored in the profiles subdirectory
within the users home directory. For Windows 9x, the profile is stored in the
profiles.w95 directory within the users home directory.
Visible files
The Windows profile subdirectories are hidden. They are in the users home
directory, and to see them you need to change the attributes of the
directory. For example, if you have a user Manuel whose homedirectory is
at c:\homedirs\manuel, he would have a Windows NT Users profile stored
in c:\homedirs\manuel\profiles.
The second part of the user profile is a series of folders on the hard drive,
each of which serves a purpose in the user’s environment. The folder
structure stores shortcut links, desktop icons, startup applications, and so
forth.
In addition to the registry file, the system maintains a log file called
NTUSER.MAN.LOG or USER.MAN.LOG. This file contains a list of changes
that the user has made to his or her environment since he or she has logged
on. When the user logs out, these changes are applied to the NTUSER.MAN
or USER.MAN file. If there is a problem that prevents the changes from being
applied, the log file keeps the changes until the next logon when it can be
applied.
At logoff, the user portion of the registry will be deleted, and the rest of the
user profile specific changes are removed. During logon by the next user at
the machine, these settings will be reestablished. This is standard Windows
client functionality.
Default desktops are provided. The location of the default desktops are
shown in Figure 12 on page 46. An administrator can also create new
desktops, put them in a different location, and assign them to users.
\win9x\default
x:\IBMLAN\DCDB\win32app\desktop
\winnt\default
Since the desktop logon and network access settings are stored, for the most
part, in the computer’s registry database, system policy files for users
overwrite settings in the current user area of the registry, and system policy
for computers overwrites the current local machine area of the registry. This
allows you to control user actions (user profiles) as well as computer actions
for users and groups.
The default system policy file contains a default user setting and a default
computer setting. Use the System Policy Editor to manage the user desktop
by changing the default user settings and manage the logon and network
settings by changing the Default Computer settings.
All systems loging on to a domain with system policy files implemented will
use the same uniform policy defined by the system policy file.
When a user logs on to the OS/2 Warp Server Domain, the operating system
looks in the NETLOGON SHARE to see if there is an NTConfig.pol file
present for Windows NT or a Config.pol file present for Windows 9x. If the file
is found, the contents of the file are copied to the local computer’s registry
and is used to overwrite the current user and local machine portions of the
registry.
With the Feature for Windows Clients, there are three System Policy files: one
for administrators, one for a sandbox machine, and one for all other IBM
WorkSpace On-Demand 2.0 Feature for Windows Clients. The location for
each of these is shown in Figure 13.
x:\IBMLAN\REPL\IMPORT\SCRIPTS \admin\ntconfig.pol
\admin\config.pol
\wsod\ntconfig.pol
\wsod\config.pol
If a machine is defined as a sandbox, it will use the system policy files in the
sandbox directory. It determines this by a value in the local registry. These
too are not as restrictive. What happens if both apply?
Sandbox
When a client is defined with the NETWIN RIPLMACH command, and the
/SANDBOX switch is used, a client registry value Sandbox_enabled=1 is set.
On logon, this forces the client to use the system policy file in the
/SANDBOX/ subdirectory in the NETLOGON share.
The System Policy Editor entries change local computer registry settings in
the following ways:
1. Desktop settings for default user in System Policy Editor modify the
HKEY_CURRENT_USER key in the registry that defines the contents of
the user profile that is in effect for the computer.
2. Logon and network access settings for the default computer in System
Policy Editor modify the HKEY_LOCAL_MACHINE key in the registry.
When a user logs on to the domain, the contents of the NTConfig.pol file on
the server are merged with the NTuser.dat file found in the user profile
location for the user logging on. Settings in NTuser.dat that do not match
NTConfig.pol settings are overwritten, and thus, system policy controls the
It is possible to build a system policy file. Using the policy editor supplied with
Windows, you create a file called NTConfig.pol for Windows NT and
Config.pol for Windows 9x that contains settings for users (user profiles) and
computers (logons and network access settings). By saving the file to one of
the locations defined in Figure 13 on page 48, you implement the policy.
2.5.2.1 Installation
The Logon Client is installed by default since it is required by many of the
other management features of the product. This client code has been
converted to InstallShield. This change allows for an unattended installation
of the product.
Due to the raw size of this file for each user (200 K to 500 K), if this were part
of the DCDB, there would be a concern with its replication across the
network. In addition, the Windows client logon support is designed (by
Microsoft) to receive a user home directory location that, in turn, is used to
retrieve the user desktop. This is also the default location for the storage of
user information. For these reasons, the Windows User Profile is stored in the
user’s home directory versus being part of the DCDB.
Command
Line Windows User Management
Interface
The command line interface is the only interface available to add, delete, or
modify the attributes of a user that is related to the Windows environment. It
allows the administrator to manage users desktops and applications through
the command line. The Windows User Management interface uses the
existing interfaces to update or get to existing structures, such as the
NET.ACC, the DCDB, or the user’s home directory. The Windows User
Management interface uses the new WorkSpace interfaces to access data
structures or locations that are specific to the IBM WorkSpace On-Demand
2.0 Feature for Windows Clients.
The NETWIN USER command is the one command available for user
management. This command enables you to assign a desktop to a user
account and add, delete, and list the Windows applications that a specified
user account is assigned to. This command is covered in more details in
Section 6.1.1, “The NETWIN USER command” on page 177.
This chapter describes the steps required to plan and install the Feature for
Windows Clients. Since every live environment promises to be different, we
describe only one installation scenario.
The Feature for Windows Clients requires that WorkSpace On-Demand 2.0 is
installed on any server that Feature for Windows Client is going to be installed
on. This means that OS/2 Warp Server is a prerequisite. This feature has to
be installed on the primary domain controller and on every boot server that
manages Windows clients in the domain.
If the installation environment has only one local OS/2 Warp Server Domain
Controller, both components must be installed onto this server. If the
environment has only a Windows NT server, a Warp Server Domain
Controller must be introduced to support the Feature for Windows Clients.
The Windows Clients that are managed by the Warp Server machine would
be authenticated by the Warp Server machine but would still be able to
access resources or applications that are resident on the Windows NT
machine. There are two methods to achieve a measure of integration:
1. Duplicate the user IDs on both machines and ensure that the passwords
of the users are synchronized. If you intend to make use of the network
neighborhood browser on the clients, install the component on the server.
2. Install OS/2 Warp Server for e-business as the primary domain controller
and make the Windows NT server an additional server within this domain.
Additional servers only have the capability to be boot servers and cannot do
any application management. For this reason, when you install the software,
it detects whether the server is a primary domain controller. If it is a primary
domain controller, you can select to install both application management
support and remote boot support.
If the machine is an additional server, you only have the option to install
remote boot support. You can have multiple remote boot servers in your
environment. Users and applications would need to be associated with at
least one domain controller that has application management support
installed.
Figure 15 on page 57 describes the services that a client can get from the
various server members on the network. These services include the
following:
• A client can boot from an image on either the Primary Domain Controller
(PDC) or an additional boot server.
• A client needs to log on to the OS/2 Warp Server PDC for the userid to be
verified and for desktop and application access.
• A client can, however, access applications from all servers on the network
including Windows NT servers.
Client
This directory also tends to get very large. Ensure that you have sufficient
space on the drive for all the client operating systems as well as application
packages.
When you create new application packages, you will need to create new
directories on the server. If you install this product on a drive that is formatted
HPFS or FAT, you need to manually propogate the access control using the
NET ACCESS command to grant access to these new directories. Use the /APPLY
option with the NET ACCESS command to propagate the access controls to all
the subdirectories within the new directory.
Access Controls
3.2.1 Processor
We recommend a 90 MHZ Pentium processor or equivalent as a minimum.
OS/2 Warp Server exploits the features of Pentium hardware if it is present.
You should consider an Symmetric Multiprocessor (SMP) machine in cases
where multi-function support is required and where supported applications
are written to exploit parallel processing, such as Lotus Domino.
Total 52 MB
The Feature for Windows Clients also needs client operating systems to be
copied onto the server’s hard drive. Table 7 shows disk space requirements
for the individual client operating systems.
Table 7. Disk space requirements for Window Clients Feature clients
Total 425 MB
3.2.3 Memory
The WorkSpace On-Demand server memory size and hardware speed has a
major influence on performance. A minimum of 64 MB of memory is
recommended for optimal performance in many environments. Although
slower machines provide adequate performance with small numbers of
clients, a Pentium, or better, based server is recommended. An SMP machine
will not increase the speed of simultaneous RIPL but may provide a
performance boost during the application phase if other client/server
applications are running on the server.
Note
We recommend that you use the network-optimized 32 bit High
Performance File System (HPFS386) that provides enhanced file system
throughput for your server, improving boot-time performance at the client.
The Feature for Windows Clients requires DOS RIPL services on your
system. If DOS RIPL services is not installed on your server, the Feature for
Windows Clients installs it for you with the related DOS Year 2000 fixes.
Part Steps
Prerequisite Setup Install OS/2 Warp Server (see Section 3.3, “Software
prerequisites” on page 59).
Install WorkSpace On-Demand 2.0.
Client Operating Select and set up the Windows client operating systems that
System Setup will be used in your environment. Multiple selections are
acceptable. The following operating systems are supported:
Windows 95
Windows 98
Windows NT Workstation
For specific version information on the above operating
systems, see Section 3.3, “Software prerequisites” on page 59.
Year 2000 Each of the client operating systems supported have Year
Considerations 2000 related fixpacks.
Readme
The readme in the root directory of the Feature for Windows Clients
installation CD-ROM contains the latest information regarding the
installation of this feature.
This is the introductory panel. Select the yellow arrow to go to the next
panel.
This panel allows you to select the drive and the path to install the Windows
application data repository. The default path is \IBMLAN\DCDB. These
parameters are stored in the \IBMLAN\DCDB\WIN32APP.INI file.
Note
The above panel will not be shown if you reinstall this product. If you
reinstall, and you want to change the default path, delete the win32app.ini
file in the X:\IBMLAN\DCDB subdirectory, and the panel will reappear when
you reinstall.
This repository can get quite large, so it imperative that you select a drive
with sufficient space for all the Windows application data. The amount of
This is the last panel presented before the files are copied across to the
server. Remember, you cannot uninstall this product. You will need a backup
to restore the server to its current state.
When the installation is complete, remove any diskettes in your drive and
reboot the machine. If you encounter any problems during the installation,
check the following log files C:\OS2\INSTALL\BB20ERR.LOG,
C:\OS2\INSTALL\BB20HST.LOG, and C:\OS2\INSTALL\WPINSTALL.LOG.
These files will help you to determine what caused the installation failure.
Correct the problem and rerun the install command. The operating system is
able to determine where it failed and will resume the installation from where it
left off.
********************************************************************* **
WorkSpace On-Demand 2.0 Feature for Windows Clients
* Sample Partial Response file *
* *********************************************************************
*--------------------------------------------------------------------- *
* To install any Components for the Feature for Windows Clients, the *
* following selection must be set to 1. *
* --------------------------------------------------------------------- *
WCF_Win32.Selection=1
WCF_netwin.Selection=All
WCF_MachineManagement.Selection=All
* --------------------------------------------------------------------- *
* Client Management and Application Management Support for primary *
* domain controller *
* Valid Values: *
* None = Do not install Client Management and Application Management *
* Support on the primary domain controller *
* All = Install Client Management and Application Management Support** on the
primary domain controller (default) *
* Please note: All selections must be either set to ©All© or to ©None© *
* ---------------------------------------------------------------------
*WCF_DCExternalPackages.Selection=All
WCF_DCMachineManagement.Selection=All
WCF_AppManagement.Selection=All*
--------------------------------------------------------------------- *
* Remote Boot Support *
* Valid Values: *
* None = Do not install Remote Boot Support
* All = Install Remote Boot Support (default) *
* Please note: All selections must be either set to ©All© or to ©None© *
---------------------------------------------------------------------
*WCF_LogonClient.Selection=All
WCF_DSExternalPackages.Selection=All
WCF_DSMachineManagement.Selection=All
On a drive other than the CD-ROM drive, type MD install to create a new
directory and save the updated response file to the new directory (install)
you created.
Type E: (E: represents the CD-ROM drive) to assign the CD-ROM as the
current drive.
Type INSTALL and the path to the working copy of the response file, as well
as all other required parameters.
Using on line, type INSTALL /R:X\install\bbwfcid.rsp
/L1:os2\install\bb20err.log /L2:os2\install\bb20hst.log.
The feature install should run and then restart the system.
/B:BootDrive
/HELP
Provides task-oriented syntax and help for this command. This is an optional
parameter.
/L1:ErrorLogFilePath
The fully qualified path and file name of the error log file. The default is
X:\OS2\INSTALL\BB20ERR.LOG (X represents the boot drive).
/L2:HistoryLogFilePath
The fully qualified path and file name of the historylog file. The default is
X:\OS2\INSTALL\BB20HST.LOG (X represents the boot drive)
/R:ResponseFilename
Note
If you are installing this product on a domain controller and boot server
using a response file, the remote boot values in the response file must be
set to all. If you are installing this feature on the primary domain controller,
the remote boot value in the response file must be set to none. See "The
default response file bbwfcid.rsp" on the previous page.
The following is a list of the CNF files that are created as server records when
you install this feature. The installation process only adds these files the first
time you install this feature. To update these files in RPL.MAP, you can either
delete these files before you reinstall this feature, or you can run a command.
CNF files:
To manually update the RPL.MAP for these files, run the following command
from the INSTALL directory of this feature's CD:
To manually update the RPL.MAP for these files, run the following command
from the INSTALL directory of this feature's CD:
Windows 95 WCF_95R2 E C
Windows 98 WCF_98 E C
http://www.microsoft.com/year2000/
Microsoft Windows NT 4.0 is not Year 2000 ready. You need to apply service
pack 4 to the server client directory. Microsoft recommends Service Pack 4
Note
When you install Windows NT 4.0 Service Pack 4 using a Cmdlines.txt file
and Update.exe, you may receive file copy error messages for the following
files: Appserver.class, Context.class, Imtxas.class, Objectcontent.class,
and Securityproperty.class. Only files with 8.3 file names can be copied
using a Cmdlines.txt file and Update.exe. To work around this problem, use
the compressed Sp4i386.exe file from the Service Pack 4 CD-ROM, or
SP4I386.EXE from the standard download from the Microsoft Web site.
After you download the Year 2000 Update for Windows 95, a compressed
executable file named W95y2k.exe appears on your hard drive. This
executable file contains the files you need to update your Windows 95 system
for the year 2000.
After you download the Year 2000 Update for Windows 98, a compressed
executable file named W98y2k.exe appears on your hard drive. This
executable file contains the files you need to update your Windows 98 system
for the year 2000.
MAC: 08005ACF8ABE
Windows NT4.0
3.8 Tivoli Management Agent (TMA) and Java Virtual Machine (JVM)
The IBM Java Virtual Machine (JVM) and the Tivoli Management Agent
(TMA) are included as part of WorkSpace On-Demand 2.0 feature. JVM is
installed on clients through commands in the default response files for
Windows 95 and Windows 98 or CMDLINES.TXT for Windows NT. If you
want to use TME 10 products on your server to provide additional client
management capability, modify the default response files. For more
information on Tivoli, see Chapter 7, “The Tivoli TMA client” on page 205.
Server I/O
WorkSpace Classic
Figure 22 shows the different client requirements. The curve for the Classic
WorkSpace On-Demand client is high when the client boots. It drops and
flattens out when all the clients are up and running. It will not drop lower since
the clients all still have a dependency on the server for all of their files.
The Windows clients have two curves. The install curve represents the clients
during their install phase. Initially, the clients copy their files from the server,
which requires a lot of I/O. Once the files are copied from the server, the I/O
drops. At this point, the only dependency the Windows client has on the
server is for the boot image that forces the client to boot from the local hard
disk. The size of this image is within a megabyte. Each client that is installed
is using the same image, so this server cache does not need to be refreshed.
The operational curve maintains this low level. Again, at boot time, the client
requests only the small boot image that forces it to boot from the local drive.
The rest of the chapter describes the process in greater depth using the
StarOffice application suite as an example.
Install
Application
- = Application
Application
Application
tion Applica
Applica tion
Application
on
App
Applicati
Application lication
Applica
tion
Application
lication
Application
tion Applica
Applica tion
Application
App
Application
n
Applica tio
plica
tion
on
App Ap
Applicati
Application lication
Applica tion
tion Applica
Applicati
on
Application
Application
tion
Applica
lication
App
Application
Applica
tion n
tio
plica Applicati
Ap on
tion
Applica
Application Application
Install
Application
- = Application
Application
tion Applica
Applica tion
Application
on
App
Applicati
Application lication
Applica
tion
lication
App
Application
n
Application
Applica tio
plica
tion
Application
Ap
tion Applica
Applica tion
Application
tion Applicati
Applica on
Application
Application
on
App
Applicati
Application lication
Applica
tion
tion
Applica
lication
App
Application
Applica
tion n
tio
plica Applicati
Ap on
tion
Applica
Application Application
The following steps are required to enable a user to use the application:
1. The client image needs to be updated with the new package. These
changes then need to be distributed to the client workstations that will be
using this software.
2. Assign the package to the user using the NETWIN USER userid /ADD
/APP:appid.
3. The user's profile is updated to include the link(s) to the icon(s) for the
application.
4. The Win32 Application Updates file is updated to include the user registry
information associated with the added application (from the appiduser.inf
or appiduser.reg file). If the Win32 Application Updates file does not exist,
it is created in the user's home directory and then updated.
5. A Logon Assignment is added to give the user access to the Win32 shared
directory for the given application if the executable files are on a shared
directory at the server. The assignments are based on the APPDRIVE and
APPDIR values. No changes will be made if the Logon Assignment
previously existed. The USERS group is used to manage access to the
application files. The user is already part of this group, and the USERS
group is added to the access list for the alias.
6. The updated user profile is written back to the home directory for the user.
An entry is added to the User Datastore record for this user. The entry
indicates that the application has been assigned to the desktop indicated
by the TYPE.
The WorkSpace On-Demand Client downloads an additional file (Windows
Application Updates) from the user's home directory that is to be merged
into the user's unique Windows registry.
The Feature for Windows Clients will also support server-based management
and delivery of well-behaved Windows applications. Our definition of
well-behaved will be consistent with the ZAW definition (guidelines are part of
the Zero Administration Kit for Windows 95 and the Zero Administration Kit
for Windows NT support). A well-behaved application should at least meet
the following four conditions:
• Server-based (installation through run-from-server or a similar mode)
• No application-specific r/w files per user
• Application registry changes per user
• No changes or replacement of system modules
For this most extreme set of applications, the executable files can be stored
in common locations on the client platforms that need to execute the
application. These applications must be pre-distributed to each client platform
intended to support users executing the application. Within the document,
this set of applications is referred to as client-based applications.
DOMAIN: GA_DOM
SERVER: GA_SRV
USER: KHATY
WORKSTATION: nt40sp4
This will ensure a clean install and a proper capture of all necessary data
for the creation of your new application packages.
Note
Do not use the name administrator for a user account. This term is
reserved for local functions on Windows NT Clients.
3. Assign this user account a home directory on any directory with HPFS
capabilities. HPFS supports long file names used by Windows operating
system.
When you log on to the sandbox with this user account, you have an
unrestricted Windows client desktop.This enables you to save and
manipulate the desktop.
This is the data location where the application data will be installed. Select a
location for the application software. In our example, we created a directory
called c:\apps\wntapps with an alias WNTAPPS for Windows NT applications.
We also created an alias called W9xAPPS for the directory d:\apps\w9xapps
for Windows 95 and 98 applications.
Aliases can be created using either the NETGUI command or the NET SHARE
command. Since the sandbox user is an administrator, he or she has full
access to these directories, and other users only need read and execute
access.
Each application should have a unique subdirectory within the alias. For
example, Netscape for Windows NT would have a directory
d:\apps\wntapps\netscape and would be accessed from the client as
x:\netscape where d:\apps\wntapps is the path defined by the alias.
Note
During this process, try to use the same drive letter each time you connect
to a particular alias even if you connect to the aliases at different times.
This could, at times, cause errors when you assign the application package
to the user.
Figure 29 on page 96 describes the process and the details that are captured.
CRTPKG/FINISH
Captures these changes and
creates an application package
on the PDC that can be distributed
to other Windows clients.
The CRTPKG.INI file specifies what directories, drives, registry keys, and
files the CRTPKG utility excludes from the snapshots. Edit this file to change
Note
You must associate a unique drive letter with each alias whenever you
create an application package. Write down the drive letter you associate
with the alias. If you associate the same drive letter with different aliases
when you create subsequent application packages, you will be unable to
assign the application package to a user account.
Note
With Windows 95 and Windows 98, you would use the DLSNET command to
connect to the server with only an alias and a remaining path (rather than a
network path). Run this command on sandboxes before you connect to the
server.
4. Close any open windows and change to the directory c:\applcptr directory
where your CRTPKG.EXE file resides.
5. At a DOS prompt, type:
CRTPKG /START
Once you have checked all the above, you need to perform the following
steps to complete the application package:
1. Change to the c:\APPLCPTR directory.
2. At a DOS prompt, type:
CRTPKG appid /FINISH /APPDRIVE:X /APPDIR:"pathname"
In our example with StarOffice, we used the following command:
crtpkg soffice /finish /appdrive:w /appdir:"wntapps\soffice"
The output from this command was as follows:
Creating the application package: SOFFICE
Application package destination:
\\GA_SRV\C$\IBMLAN\DCDB\WIN32APP\SERVER\SOFFICE
\\GA_SRV\C$\IBMLAN\DCDB\WIN32APP\CLIENT\SOFFICE
Getting the file system difference...
Number of file changes captured: 221
Getting the system registry difference...
Number of registry changes captured: 263
Getting the user registry difference...
Number of registry changes captured: 10
Application package successfully created.
When you run the CRTPKG /FINISH command, a snapshot of the system is
taken. This is compared against the snapshot taken when the CRTPKG /START
command was issued and the differences extracted. These differences are
collected and stored on the server.
\C
(client files)
\CLIENT\appid
The files that are included here are the system registry entries, information
files, and a directory tree that you must copy to the client hard disks:
• The client files also contain registry changes that are made to the
HKEY_LOCAL_MACHINE key. Windows 95 and Windows 98 application
packages store these changes in the appidSYS.REG file. Windows NT
application packages store these changes in the appidSYS.INF file.
• Changes that are made to INI files reside in the appidINI.INF files (appid
represents the application package name).
Use the NETWIN APP command to verify that the application package is on the
primary domain controller. This command also enables you to describe the
contents of the application package and define the application package.
When you define an application package, you add application package
information to the APPSTORE.INI file.
Any product you select would need to be configured, and for each
workstation, you would need to distribute the related product files and update
the registry and INI files accordingly.
By distributing the client application files with the client image, the client
application files are automatically copied to your clients anytime you reinstall
the operating system.
When you create an application package, the CRTPKG utility copies client files
to the <IBMLAN\DCDB>\WIN32APP\CLIENT\appid directory. These files are
information files, system registry files, and a copy of the sandbox directory
tree. These files must reside on the local hard disk of the client. If these files
do not reside on a client, users cannot access applications from that client.
These files are described in Table 10.
Table 10. Application files on the primary domain controller hard disk
Files: Description
x:\<IBMLAN\DCDB.\WIN32APP\CLI
ENT\appid
Note
You do not need to compare files if you update the client image every
time you create an application package on the sandbox.
8. Copy the INF files you just renamed in the previous step in the
<IBMLAN\DCDB>\WIN32APP\CLIENT\ appid directory to the
\IBMLAN\RPL\NT40\I386\$OEM$ directory.
At a command prompt, type:
XCOPY <IBMLAN\DCDB>\WIN32APP\CLIENT\ appid\*.INF
X:\IBMLAN\RPL\NT40\I386\$OEM$
In our StarOffice example, we entered the following command:
XCOPY <IBMLAN\DCDB>\WIN32APP\CLIENT\ soffice\*.INF
X:\IBMLAN\RPL\NT40\I386\$OEM$
Write down the names of any.INF files you copied. In our StarOffice
example, the files names were OFFINI.INF and OFFSYS.INF
If the application package contains any files with long file names, you will
have a RENFILE.BAT file in your
<IBMLAN\DCDB>\WIN32APP\CLIENT\appid directory. If you have a
RENFILE.BAT file, copy RENFILE.BAT to the
\IBMLAN\RPL\NT40\I386\$OEM$ directory.
At a command prompt, type:
XCOPY <IBMLAN\DCDB>\WIN32APP\CLIENT\ appid\RENFILE.BAT
X:\IBMLAN\RPL\NT40\I386\$OEM$
In our StarOffice example, we issued the command:
XCOPY <IBMLAN\DCDB>\WIN32APP\CLIENT\ soffice\RENFILE.BAT
X:\IBMLAN\RPL\NT40\I386\$OEM$
If you are assigning multiple application packages, and this file already
exists for another application package, assign the RENFILE.BAT file a
unique name up to eight characters in length. You can also merge the
contents of the two RENFILE.BAT files. To assign the file another name
type:
RENAME RENFILE.BAT RENFILE2.BAT
Note
If the CMDLINES.TXT file contains commands to install service packs,
insert the rundll statements after the service pack information.
In our StarOffice example, the soffice subdirectory has two INF files,
OFFSYS.INF and NOTINI.INF, so we typed:
"rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128
.\OFFINI.INF"
"rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128
.\OFFSYS.INF"
12.If you have a RENFILE.BAT file in the CMDLINES.TXT file after the
commands for the .INF files, type:
".\RENFILE.BAT"
Routine Description
Adding an Application Package This activity is done on the primary
domain controller for the WorkSpace
On-Demand domain from which the
application is to be managed. After the
package has been created on the
sandbox machine, this command will
make the application available for the
system administrator to assign to users.
Removing Applications
As with WorkSpace On-Demand 2.0, the system administrator is
responsible for the deletion of the application files on the servers.
Command Syntax:
Options:
appid Specifies the unique application ID for the application.
Appid can be a maximum of 8 bytes in length. An appid
cannot contain imbedded blanks or any of the following
characters ' / \ [ ] : | < > + = ; , . ? *. appid is only allowed
when the /FINISH switch is specified.
/START Specifies that an initial snapshot of the sandbox system
is taken. This is executed prior to the application
installation on the sandbox system.
/FINISH Specifies that a final snapshot of the sandbox system is
taken. A DIFF operation is performed to determine
changes that occurred due to application installation,
and the appropriate files associated with the application
package are transported to the primary domain
controller.
/APPDRIVE:drive Specifies the drive letter of the location where the
application program will reside. For applications
installed on a server, a NET USE to the location specified
by the APPDRIVE and APPDIR values must be done
prior to execution of this utility. /APPDRIVE is a required
parameter when the /FINISH switch is specified.
/APPDIR:pathname Specifies the fully-qualified path name where the
application program will reside. If the application is to be
installed on a server, a NET USE to the fully-qualified path
name must be done prior to execution of this utility.
Since an alias will be used at the server to ease
assignment of the application access to users, the
Note
The alias at the server must have been created prior to execution of the
CRTPKG utility. /APPDIR is a required parameter when the /FINISH switch is
specified.
The files created at the primary domain controller along with the location they
will be stored at are:
PKG_DIRvalue\WIN32APP\SERVER\appid\
appiduser.inf or appiduser.reg Contains the user registry changes.
appid.dat Contains the values specified for
APPDRIVE, APPDIR, and TYPE.
[Desktop] Folder containing the icon(s) targeted for
the user desktop.
[Start Menu] Folder containing the entry(s) targeted for
the user Start menu.
[Programs] Folder containing the entry(s) targeted only
for the user Programs menu.
PKG_DIRvalue\WIN32APP\CLIENT\appid\
appidsys.inf or appidsys.reg Contains the system registry changes.
appidiniX.inf Contains the system ini file changes.
local files Contains the directory of local files installed
for the application.
The PKG_DIR value is a fully qualified pathname that will be retrieved from
\IBMLAN\DCDB\WIN32APP.INI.
The utility creates a set of files for the registry: .REG files for Windows 9x and
.INF files for Windows NT as well as INF file’s for both operating systems. It
also creates a directory structure of files on the client machine.
When used without parameters, the NETWIN APP command enumerates all
existing Windows applications and the applications’ types. The following
different options are available using the NETWIN APP command:
appid Specifies the unique application ID for the
application. Appid can be a maximum of 8 bytes in
length. An appid cannot contain imbedded blanks
or any of the following characters: ' / \ [ ] : | < > + =
;,.?*
/ADD Indicates that a Windows application definition will
be created for the domain. An application package
must have been previously created by the utility
on the sandbox Windows system.
/DELETE Indicates that a Windows application definition will
be removed from the domain.
/REMARK:"text" Specifies an optional comment that describes the
application. "text" can be a maximum of 256
characters in length and must be enclosed within
The NETWIN APP command must ensure that the following criteria are met
before attempting any Windows application management:
• The server service is started.
• The local machine is the domain controller.
• A user is logged on with administrator privileges.
PKG_DIR
Package
(IBMLAN|DCDB
default
) Directory
Windows
Win32APP\ APPSTORE.INI Application
Datastore
USRSTORE.INI User
Datastore
Applicaiton
SERVER\appid\ Package
Directory
Client
CLIENT\appid\ Application
Directory
Windows
Application
Application Alias Share Alias
or Local
Directory
app
Home Directory
Alias
USERID
User
Profiles
Windows
Registry
Updates
File
This chapter describes the client installation and configuration process. The
command line syntax to define a workstation is described in some detail. This
chapter also includes information on the client install process for Windows 9x
and Windows NT Workstation. Various methods of adding hardware support
are also discussed.
Information on some tools and utilities that aid the installation and
configuration process is also addressed.
There are two ways to define a client: Using the command line to define each
individual client or using the command line, together with a data file, to define
multiple clients all at once.
Note: BIOS
For a number of reasons, before you install a Windows operating system
on a client, verify that the BIOS is 4/15/98 or later. Check your PC vendor’s
documentation on how to do this.
Usually, when you create a single client for testing, or ad hoc client definition,
you would probably want to use the command line. However, when you are
defining multiple clients, it is best to use the data file option. Using data files
is explained later in this chapter.
When you define a client using the command line, you need to specify at least
the following parameters together with the clients name:
/ADD
/TYPE{:WIN95 | WIN98 | WINNT}
/RECORDID{:ServerRecordID
/RELEASE{:DirectoryName}
/MAC{:AdapterAddress}
If you do not specify a response file, it uses the default response files to
define the client. Table 12 lists the default response files for each of the
operating systems.
Table 12. Directory path for default response file
[System]
Locale=L0409
Display=Driver_65.Install, PCI\VEN_1013&DEV_00D6 ;CIRRUS LOGIC
VIDEO
DisplChar=16,800,600
[NameAndOrg]
Name="ITSO User"
Org=""
Display=0
[InstallLocationsMRU]
c:\windows=mru1
[Network]
Clients=VRedir
IgnoreDetectedNetCards=0
Protocols=NETBEUI
ComputerName=SAMPLE01
Workgroup=Workgroup
Security=SHARE
Display=0
ValidateNetCardResources=0
[MSTCP]
[VRedir]
LogonDomain="GA_DOM"
[Install]
AddReg=LogonClt.Reg
DelReg=
.Welcome
Copyfiles=CirrusVideo ;CIRRUS LOGIC VIDEO
[Registry.Welcome]
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Run,Welcome,,
[LOGONCLT.REG]
HKLM,"Software\Microsoft\Windows\CurrentVersion\Network\Real Mode
Net",AutoLogon,1,0
;HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",TMA,,"c:\$TIVOLI
\TIVOLI.bat"
;This is the 300gl file I specified and moved....
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",JVM,,"c:\$IBMJVM\
IBMJVM.bat"
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",Logonclt,,"C:\LOG
ON\LOGONCLT.BAT"
[Strings]
To define multiple clients using a data file, complete the following steps:
1. Create a data file. The data file format:
• Include an entry for each client to be created or modified.
• Enclose each client name within square brackets.
• Specify only one command line parameter per line.
• Enclose within double quotation marks all parameter values that
contain spaces.
Figure 32 on page 141 show the install process that is used for the different
operating system setup processes.
Windows 9x
setup.exe
runonce added by msbatch.inf runonce entries
logonclt.bat
Figure 32. Installation and configuration process for Windows client setup.
Parameter Description
5.2.1.1 Unattend.txt
The unattend.txt response file or answer file is a file containing the
information required to automate the install process. The format of the file
consists of section headers, parameters, and values for those parameters.
The section headers are predefined and some may be user-defined. It is not
necessary to specify all the parameters and keys. The file format is as
follows:
[section1]
; Section contains keys and the corresponding
; values for those keys/parameters.
; keys and values are separated by "=" signs
; Values usually require double quotes "" around them
;
key = value
.
.
[section2]
key = value
.
Information on the sections and keys can be found in the Microsoft Resource
Kit or at:
http://support.microsoft.com/support/kb/articles/Q155/1/97.asp
[Commands]
"command 1"
"command 2"
"command 3"
Enter the entire command line in double quotation marks. The following is an
example of a cmdlines.txt file for Windows NT Workstation for WorkSpace
On-Demand.
[Commands]
".\service\sp4i386.exe -U -Z"
"C:\logon\entry.cmd"
"C:\$IBMJVM\SETJVM.cmd"
"C:\logon\setlogon.cmd"
The cmdlines.txt file has all the comments removed. The file first installs
Service Pack 4 and then runs entry.cmd, installs the JVM and runs another
command file setlogon.cmd.
entry.cmd
The entry.cmd file has only one line:
RUNDLL32 setupapi,InstallHinfSection DefaultInstall 128 c:\logon\ntclean.inf
[DeleteAutoAdminLogon]
DelReg=DelAutoLogon
[DelAutoLogon]
HKLM,%AutoLogon%,%AutoAdmin%
[Strings]
RunOnceKey="SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
RunOnceEvent="LogonClt"
RunOnceProg="c:\logon\logonclt.bat"
AutoLogon="SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon"
AutoAdmin="AutoAdminLogon"
Val1="1"
Pass="DefaultPassword"
Val2=""
ntclean.inf adds registry entries that allow the workstation to autologon and
then run the batch file logonclt.bat.
rem ===================================================================
rem This file contains setup commands that are executed on
rem Windows NT clients when the client image is installed. Do
rem not change this file.
rem ===================================================================
@echo off
CD \LOGON
md c:\temp 2>nul
RUNDLL32 setupapi,InstallHinfSection DeleteAutoAdminLogon 128 c:\logon\ntclean.i
nf
call misc.bat
if not "%miscres%"=="2" del misc.bat
start /wait prninst.exe -Ic:\ibmwin32\unattend.txt
set cleanupf=%cleanup%
start /wait SETUP domain=%DOMAIN% sandbox=%SANDBOX% -s
chkini /ini=setup.log /section=ResponseResult /key=ResultCode /del=300 /errorlev
el /val=0
if not errorlevel 0 goto leave_files
:Success
if not '%cleanupf%'=='Yes' goto leave_files
chkini /ini=c:\$ibmjvm\setup.log /section=ResponseResult /key=ResultCode /del=2
/val=0 /errorlevel
if not errorlevel 0 goto DelIBMWin32
The file setlogon.cmd uses the regedit utility to import a text based file called
a registration file, or .REG file. The file setlogon.cmd contains just one line:
\WINNT\REGEDIT /s c:\logon\logonclt.reg
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]
"LogonClt"="C:\\LOGON\\LOGONCLT.BAT"
[HKEY_CURRENT_USER\Control Panel\Desktop]
"Wallpaper"="wsoddtbg.bmp"
[HKEY_CURRENT_USER\Control Panel\Colors]
"Background"="0 0 128"
Essentially, the logonclt.bat first installs any printers using the prininst utility
and then cleans up the system, deleting any unnecessary install files.
The setlogon file changes the background bitmap with the WorkSpace
On-Demand bitmap and resets the system.
Parameter Description
section name This parameter is the path to the directory that
contains the files. To indicate that the section
contains the names of files or subdirectories
that are on the root of the drive, use a
backslash [\] as the section name.
short name This parameter is the name of the file or
subdirectory in this directory to be renamed.
"long name" This parameter is the new name of the file or
subdirectory. This name must be in double
quotes.
It is not very important to know all the switches. However, they are described
in Table 15.
Some of the switches can be used with both Windows 95 and Windows 98,
and some can be used only with Windows 98.
Switch Description
For Windows 98 Only
/nf Do not prompt to remove the floppy disk from the drive
(for bootable CD-ROMs), same as if there is a file named
BOOTCD in the cabinet folder.<BR/> or if there is a
"BootCD=1" line in the Msbatch.inf file.
/t:<dir> This switch lets you specify where Setup copies its
temporary files. Note: Any existing files in this folder are
deleted.
The /p switch is not used by itself. The string can contain one or more
detection switches separated by a semicolon (;). For example, if you want to
use /p f and /p i, you type: setup /p f;i
Some switches are simply on/off switches. The absence of the switch implies
Off; the presence of the switch turns it on. A minus sign (-) appended
immediately after a switch turns it off.
Valid detection switches are available from the Microsoft Web site.
For Windows 9X type clients, it is best to start the install by adding a line to
the msbatch.inf file that contains all the install responses.
A part of the msbatch.inf file is reproduced below. The install section shows
the additional items to be executed after setup. In the figure, the product
registration and the logonclt.reg section are going to run after install. The
logonclt.reg section has a number of RunOnce items. First, it does an
automatic logon, installs the Tivoli client, then installs the JVM, and finally
runs a file called LOGONCLT.BAT.
:
:
[[Install]
AddReg=ProductID.Reg,LogonClt.Reg
DelReg=Registry.Welcome
[Registry.Welcome]
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Run,Welcome,,
[PRODUCTID.REG]
HKLM,"Software\Microsoft\Windows\CurrentVersion","ProductId",,%ProductID%
[LOGONCLT.REG]
HKLM,"Software\Microsoft\Windows\CurrentVersion\Network\Real Mode Net",AutoLogon,1,0
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",TMA,,"c:\$TIVOLI\TIVOLI.bat"
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",JVM,,"c:\$IBMJVM\IBMJVM.bat"
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnce",Logonclt,,"C:\LOGON\LOGONCLT.BAT"
:
:
:
LOGONCLT.BAT
The logonclt.bat file is the file that runs last on the client before configuration
is complete. Below is an extract of the logonclt.bat file for a standard
Windows 95 client. Some of the remarks have been taken out and the lines
are wrapped.
@echo off
rem ===================================================================
rem This file contains commands that are executed on
rem Windows 95 clients when the client image is installed.
rem ===================================================================
rem In this section, place commands to rename files that are in use
rem when XCOPY executes. rem attrib c:\windows\tasks\sa.dat -h
rem attrib c:\windows\help\windows.gid -h
rem attrib c:\windows\ttfcache -h
rem ===================================================================
rem In this section, place a command to XCOPY application package files
rem from a client's $WINTEMP directory to a client's WINDOWS directory
rem
rem xcopy C:\$WINTEMP\*.* C:\WINDOWS /s /e /h /k > c:\xcopy.log
rem ===================================================================
rem This section contains the log on executable .INF file for Windows 95
clients.
rem Do not change this section.
rem ===================================================================
rem In this section place commands to run any .INF files contained
rem in Windows 95 or Windows 98 application packages.
rem rundll32 setupx.dll,InstallHinfSection DefaultInstall 128
c:\appidini1.inf
rem ===================================================================
rem This this section, place a command to run the DELICN95.INF file. This
file
rem removes registry entries for icons on Windows 95 clients.
rem ===================================================================
rem In this section place commands to run any .REG files contained
rem in Windows 95 or Windows 98 application packages.
rem start /wait regedit /s c:\appidsys.reg
rem cd\
rem ===================================================================
rem In this section place a command to run the RENFILE.BAT program that
rem is contained in Windows 95 and Windows 98 application packages.
rem This program runs on Windows 95 clients.
rem The RENFILE.BAT program contains the long file names for the files
rem in your application package that were given short names when
rem the package was created. When this program runs on a client, the
rem files listed in the program are renamed to their original long file
rem names.
rem ===================================================================
rem This section includes set up commands for Windows 95 clients.
rem Do not change this section.
set cleanupf=%cleanup%
CD \LOGON
setkeys
chkini /ini=c:\logon\setup.iss /section=SdFinishReboot-0 /key=BootOption
/del=0 /val=3 /wr
if not '%cleanupf%'=='Yes' goto CallSetup
chkini /ini=c:\$ibmjvm\setup.log /section=ResponseResult /key=ResultCode
/del=1 /val=0 /errorlevel
if not errorlevel 0 goto DelIBMWin32
deltree /Y c:\$ibmjvm
:DelIBMWin32
deltree /Y c:\ibmwin32
:CallSetup
start SETUP domain=%DOMAIN% sandbox=%SANDBOX% -s
dosexit
This file is used to clean up the code on the client if requested to do so. The
details on how to change this is described below. Other processes can also
be added to this file for customization.
With the Windows feature the response file can be used to define a machine
class. Several default response files are included with the base product. The
Windows 95 response files are located in the c:\IBMLAN\RPL\W95\RSP
directory. The Windows 98 response files are located in the
c:\IBMLAN\RPL\W98\RSP directory. The Windows NT response files are
located in the c:\IBMLAN\RPL\NT40\RSP directory. Two machine specific or
machine class response files are included for each of the supported operating
systems.
[IBMFEParamSection]
This section should be changed to:
[SelectedAdaptersSection]
TRSR0001=TRSRPParamSection,\$OEM$\NET\IBMTRSR
[TRSRParamSection]
TRSR0001 represents the unique device ID. This ID is used to find the driver
details in the oemsetup.inf file. This file is contained in the
\$OEM$\NET\IBMTRSR directory. The TRSRParamSection can be used to override
the default parameters for the particular driver. \$OEM$\NET\IBMTRSR
represents the directory name where the driver is be contained. This driver
This method of installing video drivers only installs the video driver. Additional
utilities or applications provided by the manufacturer have to be installed
using other methods. Contact the video driver vendor for information on
automation options for their products.
Enabling support for an adapter describes the steps you would need to take
to get the adapter installed. These steps do not include how to create the
initial boot file that are used to boot the machine and copy the images to the
server. Check the online documentation or the redbook, WorkSpace
On-Demand Handbook, SG24-2028 for more information on how that is done.
The following example contains specific instructions for installing IBM Turbo
16/4 Token-Ring ISA Adapter on Windows NT:
1. Locate the newest Windows NT device driver diskettes from the adapter
manufacturer. The adapter must support unattended installation. Refer to
the manufacturer documentation for details about unattended installation.
2. List the files and directories on the device driver diskette.
[TRSRParamSection]
TRSR1080 represents the option name. TRSRParamSection points to the
[TRSRParamSection] that stores additional information about the device
driver upon installation. \$OEM$\NET\IBMTRSR represents the location where
the driver will be installed. IBMTRSR represents the unique subdirectory that
you make for each driver.
7. Save the UNATTEND.TXT file under a different file name in the
IBMLAN\RPL\NT40\RSP directory. The new file you saved is the response
file you use when you define clients. The filename is the value for the
/RSP parameter for the NETWIN RIPLMACH command.
UNATTENDED.TXT:
[unattended]
...
...
[Network]
InstallAdapters = SelectedAdaptersSection
[SelectedAdaptersSection]
TRSR1080 =TRSRParamSection, \$OEM$\NET\IBMTRSR
With this method, you will limit any confusion if adapters have similar file
names. If you have only one adapter type, you can copy the drivers directly to
the \IBMLAN\RPL\W95\OS or \IBMLAN\RPL\W98\OS directory so that it will
be distributed to the client with the operating system.
Because the instructions are so similar for Windows 95 and Windows 98, the
example describes how to install one type of adapter for Windows 95 and a
second example shows how to install multiple adapters for Windows 98. Both
these examples use the IBM Turbo16/4 Adapter.
Driver Location
Do not download and install device drivers for the token-ring adapter from
the Web.
For Windows 98 clients, the device driver for the IBM Turbo 16/4
Token-Ring ISA Adapter is packaged on the Windows 98 Microsoft CD.
The device driver is included with the CD image when you install Windows
98 on the WorkSpace On-Demand server.
3. Copy all files, including subdirectories, from the device driver diskette to
the IBMLAN\RPL\W95\OS directory. In our example for the IBM Turbo
16/4 Token-Ring ISA network adapter, you copy diskette two (the device
driver diskette) to IBMLAN\RPL\W95\OS on the boot server.
Caution
Before you copy the device driver diskette, verify that the file names on
the diskette do not already exist in the \OS directory.
4. Next, update the response file. List the files in the device driver diskette
and open the .INF file to obtain the value for the unique device ID of the
driver. In the case of the IBM Turbo 16/4 Token-Ring ISA network adapter,
you open NETIBM.INF. The device ID for this driver is *IBM1080.
5. Using any ASCII editor, open the MSBATCH.INF file in the
IBMLAN\RPL\W95\RSP directory.
6. Under the [Network] section, fill in the value for Netcards= with the device
ID you found in the .INF file. For example, in the case of the IBM Turbo
16/4 Token-Ring ISA Adapter, the device ID is *IBM1080.
7. MSBATCH.INF
[Network]
netcards=*IBM1080
IgnoreDetectedCards=1
[NetCardsDirs]
*IBM1080=NET\IBMTRSR
[NetCardsDirs]
*IBM1080=NET\IBMTRSR
*XYZ123=NET\XYZ
Your network adapter IBM Auto or Turbo 16\4 Token-Ring ISA Adapter(0001) is
not working properly. You may need to set it up again. For more
information, see the Network TroubleShooting Windows Help.
During the Windows client installation process, some clients with 3COM
3C90x adapters stop responding after the HDBOOT executable loads. This
may be caused by a down-level version of the LanWorks BootWare ROM. To
request the current version of the MBA Flash Update for the
http:\\www.3comm.com
To continue with the installation process after you update the BootWare ROM,
reset the client system (using the NETWIN RIPLMACH/RESET command) or run
FDISK /MBR.
5.7 Printing
The IBM WorkSpace On-Demand 2.0 Feature for Windows Clients provides a
mechanism to configure local printers on a client machine. This feature uses
the support built into Windows 9x. However, Windows NT does not provide
any mechanism to install printer drivers and to configure local printer queues.
Note
To see a list of supported printer models, open the Add Printer Wizard in a
client (such as a sandbox for the same operating system). Printer drivers
not shipped with the Windows operating systems cannot be installed.
The result of adding this parameter is a section in the MSBATCH.INF file is:
[Printers]
PrinterName = PrinterModel, Port
If more than one printer is required for a client, the configuration information
should be added to a template response file.
Under the [Printers] section, make a separate entry for each printer. Use the
following format:
PrinterName=ModelName,Port (for a local printer) or
PrinterName=ModelName,UNCname (for a network printer).
Printer1 and Printer2 represent printer names. Canon Bubble-Jet BJC-600 and
HP Laserjet IIIsi represent driver models. LPT1 represents a local printer
port. \\printserver\share2 represents a UNC name for a shared network
printer.
Where name is the printer name, model is the printer model, port is the local
port where the printer is attached, driver is the driver file, data is the data file,
and config is the configuration file.
Since printer information can vary between clients, the unattended.txt file is
used to provide the client with printer information. To enable this support, the
NETWIN RIPLMACH command accepts the additional parameters on the printer
string that NT requires, recognized by the /TYPE=WINNT parameter.
Therefore:
NETWIN RIPLMACH... /TYPE:WINNT /PRINTER:="PrinterName, ModelName, Port,
Driver, DataFile, ConfigFile"
5.7.2.1 PRNINST
The PRNINST utility parses the UNATTENDED.TXT file looking for the
[Printers] section. The UNATTENDED.TXT file is copied to the C:\IBMWIN32
subdirectory during installation.
If the section is blank or not found, the utility exits without defining a printer. A
printer is configured for each entry found in the [Printers] section. If duplicate
names exist, the utility errors on the duplicate name(s) and continues through
the list.
The PRNINST utility runs once the spooler has been initialized by the
RunOnce facility in Windows NT. In addition, the utility runs under the
administrator context.
To define a printer using the NETWIN RIPLMACH command you need to do the
following:
1. Before assigning the printer to a client, copy the printer driver to the
\IBMLAN\RPL\NT40\I386\$OEM$\C\WINNT\SYSTEM32\SPOOL\DRIVER
S\W32X86 subdirectory.
2. Use one line when typing the NETWIN RIPLMACH command and all of the
parameters. The following example uses more than one line due to the
width of the page.
/PRINTER:"LOCALQ1,LASERJET.HP
PaintJet300,LPT1,driver,datafile,configfile"
/PRINTER:"LOCALQ2,LASERJET.HP
Paintjet300,LPT2,driver,datafile,configfile"
LOCALQ1 and LOCALQ2 represent the printer names. LASERJET.HP PaintJet300
represents the driver model for both printers. LPT1 and LPT2 represent the
ports.
For Windows NT, the default Unattended.txt file contains the following
abstract for protocols:
[ProtocolsSection]
NBF = NBFParamSection
[TCPIPParameters]
DHCP = yes
[NBFParamSection]
NetBEUI has to be selected, since the client is only supported on a local area
network. If a client needs to access files or printers on remote servers,
support for NetBIOS over TCP/IP is required. The following is a list of network
protocols that can be specified. Documentation on the configuration
parameters for each of the protocols is available from Microsoft.
• NBF
• NWLNKIPX
• TC
• DLC
• RASPPTP
• STREAMS
• ATALK
Note
Microsoft warns that it does not provide technical support for scripts
prepared with the ScriptIt tool. If you plan to use such scripts in a
production roll out, ensure that they work correctly and also ensure that
you have a feedback mechanism that reports the failure and success of
tasks preformed with this tool.
ScriptIt is not a traditional scripting language and does not offer many of the
traditional programming language constructs. Because the tools act as
though there were a user at the workstation, it needs to be started with
sufficient security privileges to perform the installation or configuration task.
Documentation and the tool is available for download from the Microsoft Web
site at:
http://www.microsoft.com/NTServer/nts/deployment/custguide/scriptit3.asp
Where script file is a text file that is in .ini format. Briefly, the script file uses
.ini file keys to identify the window titles and specifies the keystokes that
ScriptiIt should send to these windows as .ini key values. For example, the
script file entries:
[SCRIPT]
run=calc.exe
Calculator=9*12=
The above script will launch the calculator application and caculate the
product of 9 times 12. The basic ScriptIt script file can have the following
format and line types:
[SCRIPT]
run=command
runwait=command
WindowTitle=keystrokes
mkfile filename.ext=fileline
REM comment
[ADLIB]
WindowTitle=keystrokes
Keywork Description
Run lines(run and runwait) These run lines start executables, run
valid MS-DOS operating system
commands, and interpret valid WinBatch
commands.
Window title lines (title and title+text) Window title lines identify an instance of a
window and send the designated
keystrokes.
Make file lines (mkfile) Make file lines cause the script to open a
new file as specified by filename and write
lines of text to it as specified by the file line.
The ScriptIt tool is useful. However, by not having any of the sophisticated
features of traditional scripting languages, such as Perl or Rexx, limits its
[SCRIPT]
run=rundll32.exe shell32.dll,Control_RunDLL mmsys.cpl
Multimedia Properties={RIGHT 4}{TAB 2}{ENTER}
Add={ENTER}
Install Driver=C:\CRYSTAL{ENTER}
Add Unlisted or Updated Driver={ENTER}
Driver Exists={RIGHT}{ENTER}
CrystalWare(TM) Audio Driver={ENTER}
System Setting Change={ENTER}
Multimedia Properties={TAB 3}{ENTER}
3. Next, we change the Logonclt.bat file to include the step to install the
Crystal audio driver. This step is highlighted in the Logonclt.bat file in
Figure 34 on page 174.
Figure 34. Updated logonclt.bat file adding support for the Crystal audio drivers
4. Ensure that the appropriate files for the Crystal audio drivers are available
for installation. Figure 35 is a listing of all the files and their sizes. These
files were copied into the x:\IBMLAN\rpl\nt40\i386\$OEM$\c\crystal
directory.
18,944 BNT190RN.DOC
21,505 CSPNP.INF
236,032 CWB3DSND.EXE
8,625 CWBAUDIO.BIN
281,664 CWBAUDIO.SYS
126,976 CWBAUDLL.DLL
41,606 MIDIMAP.CFG
340 OEMSETUP.INF
To change the client operating system, you must redefine the client. You can
change the operating system using the NETWIN RIPLMACH command. You must
To reset a client:
1. Log on to the server where the client is defined.
2. From command prompt, type:
NETWIN RIPLMACH machinename /RESET
( machinename represents the name of the client whose operating you are
reinstalling.)
3. Restart your client for the changes to take place.
The NETWIN RIPLMACH command with the machinename provides you with
output of the client. From the command prompt, type:
This chapter describes the methods and tools that can be used to customize
a user’s environment. It provides details on the Windows User Profiles and
the System Policy files and how they can be changed to create a custom and
easy to manage environment.
Command line interfaces are the sole method of administering some of the
user options. The commands need to be executed by system administrators.
Remote Commands
Being able to remotely execute the NETWIN APP and NETWIN USER commands
is possible through the usage of existing mechanisms, such as NET
ADMIN and Telnet. In all cases, the command must be directed to a
primary domain controller to be executed with system administrator
privilege.
The NETWIN USER command must ensure that the following criteria are met
before attempting any user management:
• The Server service is started.
• The local machine is the domain controller.
• A user is logged on with administrator privileges.
The home directory information will be added to the users account on the
server.
A user profile defines the Windows environment that is loaded when a user
logs on. The user profile contains all user-defined settings for the computer,
including network connections, display settings, printer connections, and so
on. The primary goal of user profiles is to provide a user with a common
environment between computers, that is, allowing the user to roam with
common settings.
System policies are used mainly to restrict what users can do. For example,
you can use system policies to restrict what users can do from their desktops,
such as restricting certain Control panel options or configuring network
settings. Using a policy editor, you can create a file that contain registry
settings. These registry settings will be written to the user or the local
computer portion of the registry database of the client computer to generate a
desired environment for the user.
From the above summary, it is possible, at times, to use either of the two
mechanisms to control the user environment. As a rule of thumb, it is always
best to try to use the system policy file rather than the user profile to control
the user’s environment. This is because the system policy file is contained in
one central location and is easier to update.
The Feature for Windows Clients comes with a default desktop for both
Windows 9x and Windows NT. The location of the default desktop is shown in
Figure 12 on page 46. The process that occurs when a desktop is assigned is
also described in Section 2.5.1, “Building the desktop” on page 44.
When deciding what a user should be presented with, it is wise to consult with
the user community and understand their requirements. As a rule of thumb,
users who perform very specific, repetitive tasks daily prefer a simple
desktop; whereas, users who perform a variety of different tasks are able to
navigate their way around, and the layout of the desktop is not very
significant but needs to be less restricted.
The more restricted the desktop is made, the easier it is to manage, and this
lowers the overall cost of support. However, you need to ensure that this does
not hamper the overall productivity of the individual user.
For task-based users, you would want to create a profile geared toward
enhancing the work environment for the set of applications that the users
need. You would hide functionality from the user for two reasons:
• To simplify the user interface so that the user has easy access to the
functions required.
• To focus the user’s attention on what he or she must do to get his or her
job done.
In short, to create a new desktop, you set up a sandbox machine, modify the
desktop as you like it, and save the desktop. This saved desktop now can be
assigned to Windows users. The detailed steps to define a new desktop are
as follows:
1. Create a user account with administrator authority on the WorkSpace
On-Demand Domain controller. Do not assign the user a desktop.
2. Log on to the sandbox by using the user account you created.
3. Verify that user profiles are enabled if you are using a Windows 95 or
Windows 98 sandbox. To verify that user profiles are enabled:
• Click Start->Settings->Control Panel. The screen is shown in Figure
36.
• As shown in Figure 37, verify that the Users can customize their
preferences and desktop settings button and both User Profile
Settings boxes are selected.
• Click OK.
4. Customize the desktop to reflect the appearance you want your new
desktop to have. The way you customize the links and Start menu entries
is the way that those links and entries will display on the user’s desktop.
5. There are various attributes that you might want to change on the desktop
to reflect either a department or corporate standard. Most of these can be
changed by selecting properties from the desktop context menu.
To change the wallpaper, select the Background tab as shown in Figure
38 on page 183.
7. To change the screen saver, select the Screen Saver tab as shown in
Figure 40.
Figure 42. File listing for the Start menu, Programs tab
C:\WINDOWS\Profiles\indrann\Start Menu\Programs>dir
Figure 43. File listing for the Start menu, Programs tab, after modification
Note
To limit user access, verify that the command prompt is not available
from the desktop you create. A command prompt provides direct access
to local directories. In the previous example, the command prompt was
not excluded.
[version]
LayoutFile = layout.inf,layout1.inf, layout2.inf
signature = "$CHICAGO$"
SetupClass = BASE
[BaseWinOptions]
;msicw.reg ;this line was commented out
;
[msicw.reg]
;all the statements in this section need to be commented out
;DelFiles=DeleteICW
;CopyFiles=CopyINF,CopySYS,CopyICW,CopyHELP
;UpdateInis=UPD.Links
;PerUserInstall=ICW.links.pui
;AddReg=MSICW.RegEntries,MSICW.RegOLEObjects
;====================================================================
Most settings affect all users that log on to the domain. Care should be taken
to ensure that these changes and restrictions are required for all users. While
individual user restrictions can be implemented in the system policy file, it
makes the file more difficult to manage. Make every attempt to restrict the file
to generic computer and user settings. This is more of a problem when
managing large distributed environments, such as remote branches offices.
System policies and user profiles can be used to configure, in many cases,
the same settings. System policies, however, address a larger portion of the
registry and are usually easier to customize and manage. The following flow
chart in Figure 45 on page 192 describes how the system policies are
implemented.
NO YES
YES
NO
NO YES
Does Read
Default Computer Policy Machine-Specific Policy
exist? and write Registry entries
NO
YES
Read
Default Computer Policy End Policy
and write Registry entries process
Using the System Policy Editor (poledit.exe), you can create a file that
contains registry settings. The registry settings you define here are written to
the user or local computer portion of the Registry database on the client
computer to generate the required environment.
When you install the System Policy Editor on a Windows 95-based computer,
the installation process modifies the Windows 95 registry to allow system
policies to function correctly. You can install the policy editor from the
Windows 95 Upgrade or Retail CD, or you can install the editor that ships with
Windows NT Server 4.0.
After you complete the installation, the administrative tools group includes the
System Policy Editor.
When you run the System Policy Editor, select the Policy Template from the
Options menu, as shown in Figure 47 on page 196. The policy template
options lists the .adm files that are currently being used. If you have a custom
application, you can create your own .adm file and add it to this list.
WorkSpace On-Demand comes with a custom .adm file that needs to be used
when updating the system policy file that is shipped with the product. The
.adm files for WorkSpace On-Demand are contained in the
<IBMLAN\DCDB>\WIN32APP\POLICY directory and the file is called
WORKSNT.ADM.
As described in Figure 47, the COMMON.ADM file contains options that are
common to both Windows 9x and Windows NT. The WINNT.ADM file contains
options valid for Windows NT only. Therefore, instead of having one large
template file, you can have multiple custom templates that apply to
applications.
Box Checked
Box grayed
Since the policy file contains registry settings that may already have a value,
when you edit a policy, the state of the box value is as shown in Table 18.
Table 18. Policy status
Box Implication
Checked: Policy is implemented When the user next logs on, the user’s
computer conforms to the policy. If the
option was checked the last time the user
logged on, Windows NT makes no
changes.
When you select an option, the pane below it contains other configurable
items that relate to the setting you modified as well as information about the
option you selected.
Options
Default Computer Section: WorkSpace On-Demand: CD Auto Run
Option
Default Computer Section: WorkSpace On-Demand: CD Auto Run
Note
The system policy file must be saved on a server that can process client
log on requests. Place the NTCONFIG.POL file in the appropriate
subdirectory (WSOD, ADMIN, or SANDBOX) on every backup domain
controller.
Note
The system policy file must be saved on a server that can process client
log on requests. Place the CONFIG.POL file in the appropriate
subdirectory (WSOD, ADMIN, or SANDBOX) on every backup domain
controller.
In the system policy file, there is a Hide all items on the desktop. The
Windows desktop is made up of three windows. Each of these windows is
layered over the other. The lowest layer is the main desktop window. Above
this is a transparent window that contains the desktop icons. The topmost
window is the tray window (the Taskbar).
When you select the Hide all items on the desktop policy, the middle
transparent window’s visible status is turned off. The icons are still on this
window but they are not visible to the user. According to Microsoft, the current
design of the shell does not support hiding individual desktop icons on a
per-user or per-group basis.
Remove programs
The IBM WorkSpace On-Demand 2.0 Feature for Windows Clients does not
offer the same level of operating software or application software
management that the OS/2 client does. Duplication of operating system and
application files on client machines means that each time a critical file
changes, each of the client machines have to be updated. When the entire
operating system or a large application is distributed, redefining and
refreshing the image on the client is warranted. However, for incremental
updates, the refresh method used by WorkSpace On-Demand may prove to
be drastic in practice.
This chapter discusses the Tivoli TMA client that is shipped with the IBM
WorkSpace On-Demand 2.0 Feature for Windows Clients. This client is
specifically intended to resolve the latter problem.
Tivoli now delivers the first true, end-to-end management solution that
includes a single, standard, and unified method for managing everything from
desktop PCs and laptops to data center mainframes.
Tivoli Enterprise provides management solutions that make it easier for large
and small organizations worldwide to centrally manage all of their corporate
computing resources. Tivoli Enterprise gives businesses the power to
effectively manage the key software applications that drive business
performance and profits.
Windows clients with the Feature for Windows Clients installed have the
option of having the TMA within their software package (it is not installed by
default). This means the lcfd daemon could already exist on the user's hard
disk. However, by default, the preloaded TMA engine (the lcfd daemon) does
not start automatically, since it will only be of value if the Tivoli Framework is
installed in the customer's environment. Therefore, when the client is
installed, the TMA (lcfd daemon) exists under the ..\Tivoli\lcf directory in an
inactive state.
Endpoint Manager - The endpoint manager software runs on the TMR server.
The endpoint manager maintains the information related to known endpoints
and endpoint gateways.
1 Endp oint
Configure M an ager
EPM an d
EPG W
2
Endpoint Endpoint
Ga tew a y G atew ay Activate
3 3
En dpoint En dpoint
L ogin L ogin
Preloaded TMA
M achines
To enable the TMA, you need to complete the following steps in your
environment:
1. Create and configure the endpoint manager and endpoint gateways.
2. Activate the preloaded TMA.
3. Endpoint Login - The TMA logs in to the appropriate endpoint gateway that
you configured during the activation process. Then, you can activate the
preloaded TMA with the appropriate options. The active process of the
preloaded TMA allows you to specify options for the lcfd daemon, so you
can configure and control the endpoint login for all of the endpoints.
Start
Yes
Exists
lcf.dat?
No
Phase1
Establish Communication
with TMR
Phase2
EPM Selects Gateway
Phase3
Normal Login
No
OK?
Yes
End
The IBM WorkSpace On-Demand 2.0 Feature for Windows Clients install
program installs the TMA files in the $TIVOLI directory for each operating
system type on the boot server. The TMA install program would be added to
the list of OEM software to be installed for each operating system response
file provided. (TMA is installed on clients through commands in the default
response files MSBATCH.INF for Win9X clients or CMDLINES.TXT for
Windows NT clients.)
Each of these client agents have their own installation program, setup.exe.
These agents can be manually installed on the client by typing: setup
By default, the Feature for Windows Clients installs the Tivoli Management
Agent Version 3.6. The directory trees for the Windows client TMA on the
boot server are as follows:
By default, the TMA software is not installed on clients. If you want to use
TME 10 products, you need to modify the default response file and
uncomment a line on the MSBATCH.INF file on Windows 9X clients or the
CMDLINES.TXT on Windows NT clients, and the TMA will be installed.
See the documentation for Tivoli Framework 3.6 for more information.
To position the Feature for Windows Clients, you need to understand the
positioning of multiuser Windows application servers as well as the Windows
Terminal Server concept. We compare these architectures with the Feature
for Windows Clients so that, based on their individual merits, you can select a
solution suitable to your environment.
Protocol Restriction
Although RDP is designed to support many different types of network
topologies and many LAN protocols, such as IPX, Netbios, TCP/IP, and
so forth, the current version of the RDP implementation in the Terminal
Server only runs over TCP/IP.
• Super-Thin Client
The client software that presents, or displays, the familiar 32-bit Windows
user interface on a range of desktop hardware is as follows:
• New Windows-based terminal devices
• Personal computers running Windows 95, Windows 98, or Windows NT
Workstation
• Personal computers running Windows for Workgroups (Windows
Version 3.11)
Applications execute
1 on Server . . .
3 . . . User Interface
2 displays here . . .
. . . User Interface is sent
over any connection . . .
ICA is optimized for connections as low as 14.4 kbps. Only mouse clicks,
keystrokes, and screen updates travel the network to generate exceptional
performance.
On May 12, 1997, Citrix and Microsoft signed a joint development and
marketing agreement, whereby Microsoft licensed the MultiWin, multiuser NT
ICA
PC PC
Wireless
Terminals and
MetaFrame
Information
Appliances
RDP
Microsoft Windows
Terminal Server
Microsoft Windows NT
Server 4.0
If you need more technical information on Citrix products, check their Internet
home page.
There are two other computing models: the client/server and server-based
computing models. While all three computing models have a valid role in
today’s enterprises, it is important to note the differences between them.
Other factors may come into this. For example, in a client/server model, users
have the ability to store data locally. This has an associated cost should the
data be lost. When you enforce policies, you begin to change your computing
model.
In the following sections, we take the view that we will be working in a high
volume, low value transaction environment.
You can do similar things within the Windows environment depending on the
components you are using. Windows NT provides a very secure way of
forcing end users to log on to a domain server while preventing any local
logons. With Windows 9x systems, you need additional components
distributed to all clients to provide a similar security.
With WorkSpace On-Demand, you can keep much of your local hardware and
applications while making the transition to a new environment.
Should you choose this way, you need to ensure that your applications are
100 percent pure Java. Only these applications will run on any client platform
today and in the future. There are already different types of end user devices,
such as PDAs (PSION, NOKIA, PalmPilot, and so forth), cellular telephones
(NOLIA, Ericson, Philips, Nortel, and so forth), and WebTV devices (Philips,
Sony, and so forth), that give users access to Java applications but cannot
use platform proprietary Java code, such as Windows Foundation Classes
(WFC) or ActiveX controls. Therefore, be aware and keep your applications
as open as possible.
A.5 Summary
There are many different approaches and many emerging technologies and
each have their own inherent strengths and weaknesses. Usually, a choice is
made based on costs, applications, risks, and rewards.
WorkSpace On-Demand fully exploits your desktop PCs and often does not
require any additional server hardware, which protects your current
investments.
You can now flawlessly integrate Windows clients within your WorkSpace
On-Demand environment. Servicing all your WorkSpace On-Demand clients
from one server and providing the desktop operating system of choice helps
you keep the TCO low since you don’t need to deploy additional servers.
All platforms serviced within WorkSpace On-Demand give you full 100
percent pure Java client-side operating system environments. This helps you
to begin implementing new enterprise application models.
This is a list of network adapters that are supported for the IBM WorkSpace
On-Demand 2.0 Feature for Windows Clients. However, new network
adapters are added to this list periodically. For the latest list of supported
adapters for WorkSpace On-Demand, see
http://www.software.ibm.com/enetwork/workspace/about/adapters.html
The most vital role REXX plays is as a programming language for Windows.
A REXX program can serve as a script for the Windows operating system to
follow. Using REXX, you can reduce long, complex, or repetitious tasks to a
single command or program.
Although we have not included any examples here, REXX can be used to
customize your users desktops, automate their installs by running scripts in
the background, during installation. This language provides intelligent
scripting capabilities at no additional costs.
C.1 Features
For those unfamiliar with REXX, the following aspects round out its versatility
and function.
Object REXX supplies the user with a base set of classes. These are ALARM,
CLASS, ARRAY, LIST, QUEUE, TABLE, SET, DIRECTORY, RELATION, BAG,
MESSAGE, METHOD, MONITOR, STEM, STREAM, STRING, and
SUPPLIER. Object REXX is fully compatible with earlier versions of REXX
that were not object-oriented.
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the IBM
Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY
10504-1785.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
The following document contains examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the
examples contain the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and
addresses used by an actual business enterprise is entirely coincidental.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
This information was current at the time of publication, but is continually subject to change. The latest information
may be found at the redbooks Web site.
Company
Address
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
Additional Server. A server, other than the Boot Block. A set of executable code, device
domain controller, in an OS/2 Warp Server drivers, and data that is downloaded from a boot
domain. An additional server may be configured server to a client workstation in order to begin
as a backup domain controller and will the remote boot process.
automatically take over the functions of the Boot Block Definition File. ASCII text file used
domain controller should the domain controller to define the contents of the boot block.
fail.
Boot Image. Directory structure on a boot
Administration Client. A fat client running server that contains the clients’ operating
OS/2 Warp 4 onto which is installed the system files and, optionally, shared application
WorkSpace On-Demand Administration Client files.
component, thereby allowing an administrator to
manage WorkSpace On-Demand servers and Boot Information Negotiation Layer Server.
clients from the administration client system. Server that provides the IP address of a server
containing a boot block to a client that boots
Administrator. A person who manages a LAN using the DHCP PXE boot mechanism.
or group of LANs running OS/2 Warp Server and
WorkSpace On-Demand and who is responsible Boot ROM. A read-only memory module
for creating and maintaining client workstation, installed on a network adapter that allows the
end user, and application definitions. machine in which the adapter is installed to boot
from a boot server on the network.
Alias. A name by which a resource can be
referenced and accessed on a LAN. Aliases are Boot Server. A server running an OS/2 Warp
normally referenced using the Universal Naming Server and WorkSpace On-Demand Server that
Convention (UNC). is used to remotely boot client workstations.
Application Server. Server on which network Boot Storm. A scenario whereby a large
applications are installed for access by end number of client workstations are
users on client workstations. Note that an simultaneously booting from a boot server,
application server may also act as a file, print, or creating a heavy demand on the server and
boot server. network resources. A boot storm typically
occurs as a result of a power outage, after
Application Roaming. Concept implemented in which all clients boot simultaneously when
WorkSpace On-Demand whereby a user can power is restored.
move from one client workstation to another
while maintaining the same application icons Client. See Client Workstation.
and desktop settings. Client Workstation. A physical machine,
Backup Domain Controller. An additional typically a personal computer, that is used by an
server running OS/2 Warp Server to which user, end user to perform business tasks. In a
resource, and access control information is WorkSpace On-Demand environment, a client
replicated dynamically from the domain (also known as a client workstation) loads its
controller. In the event of a system failure at the operating system from a WorkSpace
primary domain controller, the backup domain On-Demand server.
controller can take over, without the knowledge CNF File. See Boot Block Definition File.
of the end user.
Domain. A group of servers running OS/2 Warp
BINL Server. See Boot Information Negotiation Server that share their resources for use by end
Layer Server. users on client workstations. Resources in a
domain can typically be accessed using only a
245
systems without the need to pass through a initiate the remote boot process. The insertion
bridge or router. time is programmable so that different machines
can stagger their boot process and thereby avoid
Server. A machine running OS/2 Warp Server
a boot storm situation. See Boot Storm.
that shares its resources on a LAN for use by end
users on client workstations. When running OS/2 Workplace Shell. Object-oriented user interface
Warp Server, a server may be defined as a implemented in OS/2 Warp and OS/2 Warp 4. By
domain controller or an additional server. default, WorkSpace On-Demand implements a
simplified version of the Workplace Shell, known
Share. The name given to a network resource
as the PMLOGON shell.
that identifies it on the network.
WorkSpace On-Demand. (1) A set of
Shared Resource. See Resource.
management utilities that enables an OS/2 Warp
Software Choice. Online subscription service Server server to remotely load a thin client
offered by IBM, whereby customers can operating system, known as WorkSpace
download new and updated software from the On-Demand Client, into a client workstation
Internet. across a LAN. (2) The client workstation
Thin Client. A client workstation that loads its component of WorkSpace On-Demand that is
operating system environment and applications loaded into a client workstation from a server
across a network from a server. The degree of machine running OS/2 Warp Server and
local processing power in a thin client may vary WorkSpace On-Demand Server.
considerably depending upon the implementation WorkSpace On-Demand Manager. The server
of the thin client concept. component of WorkSpace On-Demand that is
Traditional PC. See Fat Client. installed on top of OS/2 Warp Server. See
WorkSpace On-Demand Client.
Universal Naming Convention. System of
nomenclature whereby a network alias is WorkSpace On-Demand Server. A server
referenced by its server name, followed by the running OS/2 Warp Server and WorkSpace
alias name within the server. For example, an On-Demand that is used to boot client
alias might be \\RPLSRVR\WRKFILES, where workstations.
RPLSRVR is the server name and WRKFILES is
the alias name.
Universally Administered Address. The
adapter address of a network adapter that is
burned in when the adapter is manufactured. A
universally administered address consists of a
twelve-digit hexadecimal number. See Locally
Administered Address.
User. See End User.
User FIT. File index table that contains
redirection entries for operating system and/or
application files that are unique to a particular
end user.
Wake On LAN. Term used to describe an adapter
that inserts itself into a network at a
predetermined time each day. A Wake On LAN
adapter typically works in conjunction with a
machine’s BIOS to turn the machine on and
251
New desktops 181 registry keys 96
NEWFILE.LST 102 Reinstall 69
NTCONFIG.POL 48 Remote boot 8
NTUSER.DAT 48 Remote commands 177
Remote Desktop Protocol 216
Remote Program Load 5
O remove endpoint 214
Object-oriented programming 231
Rename.txt file 147
OEM devices 43
RENFILE.BAT 102
OOP 231
Response files 42, 69, 135, 155
Operating System files 153
Restricted desktop 16
Operating system install 62
REXX 231
Operating System release 134
REXX installation 233
OS/2 Warp Server 73
RIPL Support 8
OS/2 Warp Server for e-business 55
RISC-based Network Stations 3
other policy files 47
Roaming profiles 45
RPL control files 26
P RPLBOOT.SYS 21, 26
Packaging 10 RPLDIR 37
Partition 133 RPLGROUP 72
Performance 80 RPLTERM.BAT 22
PKG_DIR 128
Planning desktop 180
Platforms supported 4 S
sandbox machine 91
poledit.exe 193
sandbox policy file 47
Policy 191
Screen Saver 184
policy file format 194
ScriptIt Utility 170
port 213
SEND.FILE.REQUEST frame 21
Post-Install 71
Server 16
Primary Domain Controller 56
Server back-up 62
Printer ports 133
Server integration 55
Printer response files 169
Server Operating Systems 7
Printers 133
Server record 30
Printing 165
server record format 31
Processor requirements 58
Server Side Changes 16
Profiles
Server-based applications 89
Local 45
Servers supported 7
Mandatory 45
SETIVOLI.CMD 212
Roaming 45
setup.exe 148
Protocol support 169
SETUP.ISS 213
Single Server environments 55
Q Software distribution 104
Query client 176 Software Distribution Manager 62
Software prerequisites 59
sourcepath 142
R standard management 205
Record identifier 134
Registered user 134 StarOffice 102
registry changes 100 Start menu 203
W
T W32DOSSB File 38
TCP/IP 132
W32DOSUB file 38
TCP/IP Subnet 135
WCF_95R2 E C 72
Technology choices 225
WCF_98 E C 72
Terminal Server 216
WCF_NT E C 72
Testing 76
Web Browsers 16
Tivoli 78
Well Behaved Applications 88
Tivoli gateways 213
wildcard characters 28
Tivoli Management Agent 7, 16
Win32 Application Updates 87
Tivoli Management Framework 206
WIN32APP 57
Tivoli software 205
WIN32APP.INI 65
TIVOLI.BAT 212
Windows 16-bit 17
TMA
Windows 95 adapters 227
enabling 209
Windows 98 adapters 229
install prerequisites 208
Windows 9x
installation 211
Diskspace 9
introduction 206
Hardware 9
role 208
Licensing 10
starting 213
Memory 9
steps 210
Processor 9
stopping 213
Windows Application Datastore 128
TMA Installation 79
Windows Application Share or Local Drive 129
TMR Server 208
Windows applications 16
Total Cost of Ownership 222
Windows desktop 44
Traditional Client Licensing 11
Windows device support 10
TYPE parameter 178
Windows NT integration 57
Windows NT Workstation
U Adapters 227
UNATTEND.TXT 136 Disk space 10
Unattend.txt 143 Hardware 9
unattend.txt 20 Licensing 10
Unattended installation 69 Memory 9
unattended installation 68 Processor 9
Uninstalling 72 Windows registry 45
User Access 85 Windows Registry Updates File 129
User Datastore 129 Windows Resource Kits 10
User environment 43 winnt 141
253
WorkSpace On-Demand
6
Application Management 5
Benefits 1
Components 2
Desktop Management 5
Desktops 6
Environments 2
Feature for Windows Clients 5
Java Virtual Machine 7
Manager 4
Network Logon Client 6
Operating systems supported 7
Overview 1
Server platforms 7
TMA 7
Workstation Management 5
Workstation machine ID 28
Workstation record 28
Workstation type 136
Y
Year 2000 73
Year 2000 readiness 73
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete
this questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Was this redbook published in time for your needs? Yes___ No___