Feedback Search Top Backward Forward

Jumpstart Guide to the Windows Client Feature

Written by Ken Hubacher



I. Overview of Installation Process
II. Special Considerations During the installation
III. Getting a Quick Start

  1. Install Warp Server
  2. Install WorkSpace on Demand Release 2.0
  3. Install Client Feature
  4. Install NT40 Workstation Client Image
  5. Install an NT40 Client
  6. Create a Desktop
  7. Assign a Desktop
  8. Install a Service Pack
  9. Create/Assigning a Policy
  10. Create an Application Package
  11. Assign an Application Package
IV. File Mapping Reference


This guide is intended to supplement the "WorkSpace On-Demand 2.0 Feature for Windows Clients Administrator's Guide". It is aimed at giving you a low level understanding behind many of the processes and commands. It will hopefully explain the relationships between the processes and files that are used. The guide is designed to give you a quick overall feel for processes, such as the boot sequence, to help you understand the 'behind the scenes' of each administrator action, and most importantly give you a jumpstart section that will guide you through the setup of a system.

The philosophy behind the Windows Client Feature is the same as WorkSpace on Demand has been in the past; to reduce the cost of administration. This is achieved by setting up each workstation in RIPL mode and forcing a connection to the WorkSpace on Demand server everytime the workstation boots. This allows a very tight control on every workstation. The first boot of a pristine workstation causes a local install of either Windows 95,98 or NT Workstation from the boot server. After the necessary system files have been installed all subsequent boots (remember they are always RIPL boots), load a process that causes a local hard drive boot. Applications can be installed locally or at a server. Ultimately, a workstation "could/should" contain ONLY the OS system files and allow all application files to reside on a server. This would result in a very light weight workstation.

User roaming is also possible, allowing users to retain their own desktop and applications no matter where they logon. Desktops cannot be shared between Windows 9x clients and Windows NT Workstation clients. However, a single user can have two desktops assigned to him/her at one time allowing a logon in either environment. Or in other words, user1 can have a 95/98 desktop and a NT Workstation desktop assigned to him/her. Then, depending on which client type he/she logs on to would depend on which of the two desktops were given.

I. Overview of Installation Process

The boot process can be broken into two areas;

  • first time 'series' of boots for a pristine workstation
  • subsequent boots after installation is complete

The process starts with a pristine workstation which is configured to RIPL.

  1. The workstation is then booted.
  2. The server will service the RIPL request and sends down a DOS Boot Block image containing DOS and DOS LAN Requester.
  3. The workstation will make a connection back to the server and run autoexec.bat.
  4. Autoexec.bat will inturn call w32ripl.bat which will call w32setup.bat.
  5. W32setup.bat will execute state.exe.
  6. State.exe will look to the \ibmlan\rpluser\"machine"\state.fil.

State.fil describes several different attributes for the installation process. Some of the highlights are:

  • Partition size on client
  • Partition type
  • State of the install process

The state variable has a few different options:

This will result in partitioning the drive
This will result in formatting the drive
Format is verified
Windows files are brought to the client
Copy Verification
Other files are copied across
Copy Verification
Windows Setup process is ready to be launched
To indicate that a local hard drive boot is desired.

The other text that could be placed in the state variable is an ERROR. Example: Error41. If something goes wrong during the install phase (but prior to the NT install process) an error will be logged to the state variable in the state.fil.

The state file starts with "NEW" which tells state.exe to partition the drive. This size is also set in state.fil. After it partitions the hard drive, state.exe changes state.fil from "new" to "prep" and reboots the workstation.

The workstation repeats steps 1- 6. State.exe gets control again and looks to state.fil. State.fil now reflects "prep" so the state process formats the drive. The type of file system is also set in state.fil. After completing the format, state.exe changes state.fil from "prep" to "post-install" and starts the NT Workstation install (this is Phase I of the NT Workstation installation). At this point NT Installation has control of the machine (state.exe has relinquished control to the install program). The NT installation process will reboot the machine to complete its own install process.

But remember, the workstation will always RIPL first, so steps 1-6 are repeated again. State.exe gets control and sees that state.fil is set to "post-install". State.exe now knows that the workstation is into the NT workstation install and sets the state to "hybrid" and boots from the local harddrive. The NT workstation installation continues (Phase II) and will reboot the client.

In a separate but concurrent process, a server service named STATEDMN on the server continually monitors the client's state.fil. Once it is changed to "hybrid" (by state.exe) the STATEDMN process changes the RPL.MAP file from its specific workstation record (example: R_DTK_NDIS) to R_D_REBOOT. R_D_REBOOT is a boot block that causes the workstation to boot from its hard drive. This will change the boot process for the workstation. Now steps 1-6 become steps 1-4:

  1. The workstation is booted.
  2. The server will service the RIPL request and sends down a DOS Boot Block image containing HDBOOT.COM.
  3. HDBOOT.COM is a program that causes the workstation to boot from the hard drive.
  4. The machine boots from the local hard drive.

At this point the workstation will ALWAYS repeat steps 1-4 when it is booted, unless the administrator changes something for that workstation.

Install Boot Sequence

II. Special Considerations During the installation

Now that we've covered the main areas of the boot sequence, let's describe a few areas that require a little more attention. The Client Feature makes use of the Microsoft unattended install process of the NT Workstation, which is similar to IBM's CID Installation. Like IBM's CID Installation, NT 's unattended installation process makes use of an answer file (what IBM calls a response file), called UNATTEND.TXT, to give the installation program the various user definable settings. There is a default unattend.txt that is supplied with the Client Feature:


Later we will cover the ability to create multiple answer files (response files) to allow the administrator to install different items on different machines. For now let's assume you will use the default file. When you create a machine using the NETWIN RIPLMACH command this file will be copied to the machines user directory:


When NT workstation starts its install this file will be used as the answer file.

Within the answer file there are various items that you might define to a machine such as Network adapter type, machine name, domain name etc... One of the important keywords to understand is the OEMPREINSTALL keyword. The NT installation process looks to see if this keyword is set. Under the Client Feature it is set by default:

        oempreinstall = "yes"

This keyword tells the NT installation process that there will be a few added conditions to the installation process. Specifically a set of copy statements during Phase I of the NT installation and the execution of cmdlines.txt at the end of Phase III of the NT installation.

Let's re-visit the phases (discussed above in Overview of the Installation Process). The NT installation process has three phases. The first phase is a copyfile phase where NT copies all necessary files to the local hard drive. It then reboots (the phases are separated by this reboot) and Phase II continues to accomplish what would normally be seen as phase I during a regular "ATTENDED" installation of NT Workstation. Then phase III completes the configuration of the workstation. Phases I & II are Non-GUI type installation phases, Phase III is a NT GUI phase.

When oempreinstall = "yes" is present NT will do the following:

During PHASE I

This is the first non-GUI phase. NT is copying all necessary files from the server to the local hard drive.

  • Copy everything from the NT40\I386\$OEM$\C directory to the local drive
  • Copy everything from the NT40\I386\$OEM$\$$ directory to the 'system' directory. Normally C:\WINNT
  • Copy NT40\I386\$OEM$\*.* to a temp directory for phase II installation.
  • Then a reboot

The 'C' in NT40\I386\$OEM$\C designates the local target drive to copy files to. In this case all the files & directories under this path on the server will be copied to the local 'C' drive. If you add a NT40\I386\$OEM$\E directory then everything in that directory will be copied to the local 'E' drive.

The '$$' indicates a variable that is matched to the name of the system directory on the local machine. This is normally \WINNT. This is set in the unattend.txt file as "TargetPath = ". The default is "TargetPath = \WINNT". With this setting NT will use \WINNT on the local boot drive as its system directory. The $$ will be replaced with the "TargetPath" variable. Bottom line, anything in the NT40\I386\$OEM$\$$ will be copied to the local system directory (most likely C:\WINNT).


  • NT Boots from the local hard drive and runs another non-GUI process to arrange the local files in the right order.
  • Then a reboot.


This is the GUI phase where NT is building the configuration files for that machine.

Execute \ibmlan\rpl\nt40\i386\$oem$CMDLINES.TXT at the very end of Phase II.

Cmdlines.txt is a kind of batch file for executing processes at the end of the installation. It contains items such as the installation of a service pack. The file is a text based file that contains a separate command per line, and must contain quotes around the command. Example:


III. Getting a Quick Start

This section is intended to get you up and running quickly with the Windows Client Feature. It will guide you through with hard coded examples to give you a feel for what the administrative commands are and what they actually do behind the scenes. Keep in mind that this is built with the following assumptions:

IBM 750 Desktop Machines(6887)
IBM Wake-On-LAN Token Ring Adapters

The idea here is to accomplish the following:

  1. Install Warp Server (SMP is what I used)
  2. Install WorkSpace on Demand Release 2
  3. Install Client Feature
  4. Install NT40 Workstation Client Image
  5. Install a NT40 Client
  6. Create a desktop
  7. Assign a desktop
  8. Install a Service Pack
  9. Create/Assign a policy
  10. Create an Application Package
  11. Assign an Application Package

1. Install Warp Server

Obtain a Warp Server CD (I used Warp Server SMP because it contains fixpak 26) and boot diskettes and install Warp Server on the server machine. Make the machine a Primary Domain Controller and choose a server name and domain name that is not being used in your environment. You must choose OS/2 RIPL Support because WSOD Release 2 requires OS/2 RIPL support to be installed. The WSOD Windows Client Feature (95/98/NT support) requires WSOD Release 2 to be installed before it can be installed. You have a choice for installing DOS RIPL support. You can choose to install it during the Warp Server install OR if you do not the WSOD Windows Client Feature will automatically install it then. If you have any trouble with this step refer to the Warp Server Manual. (TCP/IP is NOT required)


2. Install WorkSpace on Demand Release 2.0

Obtain a Workspace on Demand Release 2.0 CD and install it on the server you created. You start the install by putting the cd in the machine and executing install.exe from the root of the cd. The only choices you have are listed on one page. The default is everything and I that's what I used.


3. Install Client Feature

Make sure the server has access to the Austin Back Bone, if not reboot your machine when it's plugged into the site ring. Once your booted connect to the following server for the latest build of the Client Feature


You will find the US English build in

        \EN\BB210xx  -   xx designates the build number.

You can execute the install of the Client Feature by changing into the build directory and executing install.exe. You will only have two options, make sure you choose both of the options are checked. This is Client Feature Code and Client Feature Administration, and you want them both on the domain controller that you have just built.



4. Install NT40 Workstation Client Image

We have built the server and put the necessary Workspace on Demand processes on the server, but we do not have an actual NT Client Image on the server that the clients can install from. Now, let's put the NT40 Workstation image on the server. To do this is simple, because there's a batch file supplied with the Client Feature that will do the necessary xcopy for you. Type the following:

        WCF_NT  E   C

E - should be the cd rom drive, find out which drive is your CD Rom
C - should be where the RIPL Tree is located

Behind the Scenes:

WCF_NT.CMD xcopy's the I386 directory on the NT 4.0 Workstation CD to \IBMLAN\RPL\NT40\I386 directory in you RIPL tree.

5. Install an NT40 Client

In order to install a NT40 Workstation we will use one of the three default response files provided. Unattend.txt is the one we've already discussed. IBMPC.TXT and IBM300GL.TXT are the other two response files. For clients with standard IBM Token Ring Adapters (IBMTOK type adapters) we can use the IBMPC.TXT.

Remember this file is used to build the right configuration on the workstation such as lan adapter, video adapter etc...

There is one switch you will use in a minute that we need to discuss. This is the /SANDBOX switch and it will build the machine in a certain mode that will allow you to define desktops and add applications that a normal machine would not be able to do. When a machine is in this mode information can be written back to the server and saved so you can later define this information to other users. In a normal production environment you would not want this capability but in a test/build environment, like the one we're in now, we do want it.

Before we create the client add some user specific data so it won't prompt you for it while NT does the installation. Edit C:\IBMLAN\RPL\NT40\RSP\IBMPC.TXT and locate the following lines and add anything:

        ORGNAME = ""                                    ORGNAME="IBM"
        FULLNAME = ""                           FULLNAME="USER"
        DHCP = Yes                                      DHCP = No
        TimeZone = ""                           
                TimeZone = "(GMT-06:00) Central Time (US & Canada)"

How to Create the Client, do the following:

                /MAC:  /TYPE:WINNT  /RSP:IBMPC.TXT

Now that you've created a client reference, change the state.fil so the partition is a little bigger than the default of 250mb. This will allow room to add service packs etc.. in the future. Edit C:\IBMLAN\RPLUSER\CLIENT1\STATE.FIL and change the PARTITIONSIZE from 250 to 500 if you have a large enough hard drive.

Ok, what do these values mean. You can find the details in the Admin guide but for now, I'll explain the ones that are not obvious:

what type of client is it? Values: WIN95 WIN98 WINNT
Which DOS boot block to use. This is lan adapter specific. In our case R_DTK_NDIS is the standard IBM token ring.
This specifies the directory under \IBMLAN\RPL to find the NT image. If you remember the image is \IBMLAN\RPL\NT40
This is the Dos Bootable image which starts the installation
This indicates which response file to use for the NT installation.
This creates the client machine in a special Non-production mode so certain processes have write access.

Behind the Scenes:

When you run the above command the following occurs. A directory is created under \IBMLAN\RPLUSER with the id you specified, in our case CLIENT1. Several files are copied into this directory, for now we will only be concerned with one. When you specified /RSP:IBMPC.TXT the process copies this file into the client1 directory and renames it unattend.txt. Now you have a specific response file for this machine. Some of the values you specify on the netwin riplmach command will be placed into the unattend.txt file, such as TCP/IP options etc... The other main process that takes place is a workstation record that is added to the RPL.MAP file. The type of record that is added is dependent upon the /IMAGE and the /RECORDID you specify. Some of this information is also stored in a new file called W32RPL.MAP. This new file acts as a holder of information about the clients because once you have finished installing the client image the workstation record in the RPL.MAP file is replaced by the R_D_REBOOT record so the client can boot from the local hard drive. But what if you wanted to reset the client to start the installation process all over again, without the original information you would have to re-enter all the information you typed above. Since it stores this information you can now simply issue a:


and the records will be put back to their original locations and the next reboot of the client will cause a re-install of the client's local hard drive.

Try and boot your client and see if it will install. Make sure that Remoteboot services are started.


6. Create a Desktop

Now let's create a desktop file. What is a desktop file and why is it important? The desktop file is used by NT to give a user a specific looking desktop with the appropriate icons and menus etc... NT supports desktop files for each user and roaming abilty, meaning that the desktop will follow the user from machine to machine as they logon.

To create a desktop file for a user you must log on as an admin at the server. So first let's create a user with admin privileges. We need to create an admin id with a home directory so I find it easiest to go through the GUI so you can assign a home directory. Create an ID called NTADMIN with the same password and a home directory that points back to your server with a local directory of:


Now, logon to the NT40 Client with this id and password.

Let's make a small change to the desktop by right mouse clicking on the desktop area, and going to properties. This should bring you to the "background" page in the folder. Choose a Wallpaper and press ok.

Ctrl - Alt - Del and choose logoff

At the server go to the users home directory, which should be C:\IBMLAN\DCDB\WIN32APP\USERS\NTADMIN

The customized desktop you've just created now exists under the \PROFILES in the admin's home directory (example: C:\IBMLAN\DCDB\WIN32APP\USERS\NTADMIN\PROFILES)

Create a directory :


and copy the contents from NTADMIN\PROFILES to the new directory so we can use it to assign to future users:

You've just created a desktop that can be assigned to users.

7. Assign a Desktop

Now that we've created a desktop the next step is to assign this desktop to a user. But first we need to create a user:


Now assign user1 the desktop that we just created:


Now go check user1's home directory. Where is it? We never specified a home directory when we created the user (net user user1 user1 /add). When you run the NETWIN USER command on a user that does not have a home directory the netwin user command will automatically assign the user a home directory in a default location: C:\IBMLAN\DCDB\WIN32APP\USERS\USER1

Change to user1's home directory and do a dir to see the profile. Nothing there? The profile directory is hidden. Change directories to profiles:


Do a directory and you should see files and directories below \PROFILES.

Behind the Scenes:

The effects of what we've done above is pretty simple. When you logon with the admin id, you can make any changes you want. At the time of logoff the admin's desktop is saved to the home directory. You can copy this new desktop to the standard location (\ibmlan\dcdb\win32app\desktop\winnt\) so you can assign it to new users. You created a user without a home directory but when running the NETWIN USER command it creates a home dir for you in the default location \IBMLAN\DCDB\WIN32APP\USERS\. And copies the desktop files specified by the /DESKTOP switch to the users home dir.

8. Install a Service Pack

We first need to work with service packs before moving on to policies because the policy editor, poledit.exe, is not shipped with the GA release of NT 4.0 Workstation. It comes in Service Pack 4 however. So we will first work with the installation of a service pack, and this will get us poledit.exe, then in the next phase we will work with policies.

To install a service pack you must first get the service pack image to the WSOD server. Once it's copied, there are a few options you have to get the service pack on the client. One method is to use a separate product such as Tivoli to distribute the service pack to the client. Another alternative is to deploy the service pack with the Client Feature. If you have not installed the workstation, it makes sense to include the service pack as part of the install process. If you already have deployed the workstation and want to update it with a service pack the only method available WITH the Windows Client Feature is to add the service pack into the installation process and go back and reinstall everything from the beginning.

The steps to install a fix pack are (we will use service pack 4):

  1. Create a directory for the service pack. In our case create the directory SERVICE in the \IBMLAN\RPL\NT40\I386\$OEM$
  2. Copy the service pack I386 directory to the \IBMLAN\RPL\NT40\I386\$OEM$\SERVICE
  3. Now let's change the cmdlines.txt file install service pack 4 \IBMLAN\RPL\NT40\I386\$OEM$\CMDLINES.TXT
  4. Add the following line (include the quotes) ".\service\update\update.exe -Z -U"
  5. We need to edit the \service\update\update.inf file to prevent the copy of some files. Edit update.inf and place a semi-colon in front of the following line ;CopyFiles=Mts.class.files
  6. Now issue the reset of CLIENT1 on the server NETWIN RIPLMACH CLIENT1 /RESET
  7. Reboot the client and the install process should start over and include SP4.

First create the directory on the server for the service pack.


Then copy the service pack's I386 directory to the directory you've just created. This step could be tricky depending on the layout of the service pack that you received. Both downloading it from the microsoft web site or the CD that was supplied to me contained a single 32bit Winnt program to extract the service pack into its respective directories. The way around this is to do the following: (What we're after is getting the service pack extracted temporarily so we can copy the contents to the 'service' directory \IBMLAN\RPL\NT40\I386\$OEM$\SERVICE.)

Place the executable (example nt4sp4_i.exe) in a directory that you have access to from a client. Copy it to C:\IBMLAN\RPL\NT40\I386\$OEM$.

Go to a client and logon as an administrator. Net use the following:

        NET USE Z: \\\IBMLAN$

Change to z: and go to the directory you just copied the exectuable to.


Run the executable.

You will see it extracting the files to a temporary directory, something like


When it finishes the extraction phase it will prompt you with a "Welcome" window.

DO NOT CONTINUE. Leave the window up and running but go to a DOS Prompt.

Now copy the service pack directory to the server:


        XCOPY *.* Z:\RPL\NT40\I386\$OEM$\SERVICE /S /E

This will move the service pack to the proper directory.

Now at the server enable the following line to



Edit the following line in SERVICE\UPDATE\UPDATE.INF to remark it out

        ; CopyFiles=Mts.class.files

Reset the client and reboot it.


Behind the Scenes:

First you move the contents of the service pack to the server within the NT40 image. Then you add the service pack installation line to the cmdlines.txt so the installation of the service pack can run at the end of phase II. Remember that cmdlines.txt is run at the end of phase III NT40 installation if the oempreinstall is equal to "yes"( this should ALWAYS be equal to yes). The service pack image itself is moved to a temporary directory on the local hard drive, during phase I, to be installed during phase III. The temporary directory is $WINNT$.~LS.

9. Create/Assigning a Policy

A policy is a way to restrict system configuration choices that the desktop configuration (above) does not effect. Example of these items include:

  • Removing the RUN option from the start menu
  • Disabling the logoff choice
  • Disabling the shutdown choice
  • Selecting which drives are visible

A policy works in a much different way (under WSOD) than the desktop. Only one policy exists for all users (defined with user privilege). One policy exists for all id's defined with administrator privilege. And one policy exists for sandbox machines. When any user or administrator logs on to a machine built with the /sandbox switch, this policy is used. The location for the policies are:


There already exists a default policy for users in the WSOD directory.

The tool to edit the policy files is called poledit.exe. This can be obtained from Service Pack 4. The two other files from the service pack you will need are Common.adm and winnt.adm.

To edit a policy,

  1. logon to a client machine with admin privileges.
  2. go to a DOS window and
  3. net use z: \\\IBMLAN$
  4. Change directories to z:\DCDB\WIN32APP\POLICY
  5. Make a backup copy of NTCONFIG.POL
  6. Run Poledit.exe (not usually in path, must find it in service).
  7. You will get an error, clear it. You will also get a file dialog box, cancel it.
  9. Add the following templates (Make sure in this order):
  10. Press OK and close the template dialog.
  11. Go to file and open a policy, choose NTCONFIG.POL

Now you can customize your policy.

  1. Double Click on the default user icon.
  2. Expand Shell and then Restrictions
  3. Here, for example, you can restrict what the START menu contains.
    Remove the RUN and the FIND options etc....
  4. When you are finished save the policy changes.

Now you have made changes to the policy NTCONFIG.POL that resides in the \IBMLAN\DCDB\WIN32APP\POLICY directory.

If you want a user to have these restrictions you must place this file in the \IBMLAN\REPL\IMPORT\SCRIPTS\WSOD directory.

This is the policy file that is used by all regular users when logging on to a client machine. If you are logging on as an admin the policy file is located in the ADMIN directory rather than the WSOD directory. And if the machine is a SANDBOX, it will look for its policy file in the SANDBOX directory.

10. Create an Application Package

Creating application packages enable an adminstrator to setup each application once and then assign it to as many users as needed. It also allows the users to roam from machine to machine and keep their own applications, and application specific files.

In order to set up an application you need to account for a few items:

  • Where the client sided portion of the application code will reside
  • Where the server sided portion of the application code will reside.
  • Save the changes made by the application to entities like the registry.
The way to accomplish the tasks above is to first run a utility called CRTPKG to capture the current environment, then install the application pointing it to the appropriate server shares (so the app will be installed ON the server), and finally run CRTPKG again to allow it to save the differences made to the system files such as the registry.

The steps that are involved are first creating an alias on the server so the application can be installed to the server. Logging on to a sandbox client with admin authority and sharing the new alias. Running CRTPKG to start the comparison tool. Install the application. And finishing the CRTPKG tool.

Get a copy of Netscape Communicator 4.5 to use for this exercise.

  • Create a directory structure with the following directories on the server.
  • Create an alias for the NT Apps
                    NET ALIAS NTAPPS \\ C:\APPS\NT
  • Logon to the sandbox client (with admin authority).
  • Net use s: \\\NTAPPS
  • Run the first phase of the CRTPKG
                    CRTPKG /START
  • Install Netscape Communicator.
  • Point the installation path back to S:
  • You can leave most of the default settings.
  • Reboot the client when finished.
  • Logon as admin again.

Make any application configuration changes that might be needed globally.

Start Communicator

It will prompt you for some profile information. You can create some profile info and save it to the admin's home directory.

Close Communicator

Net use s: \\\NTAPPS

Now finish by running the CRTPKG to save all system differences the application has made during its installation and configuration.


Important Note: The appdir must contain the alias and the path to the application. In the above example you can see NTAPPS specified because it is the alias and then the remaining path. This step CAN finish even if the appdir information is incorrect, however, the next step will check this information and fail if it is incorrect.

At this point we have only gotten the necessary files to the server. Now let's create a package on the server so we can assign it to other users. So at the server:

        NETWIN APP COM405 /ADD /REMARK:"Communicator 4.05"

Behind the Scenes:

What is essentially happening is you are first saving a snap shot of the client system when you run the CRTPKG /START command. This will save a snap shot of system files, registry information etc... into a directory on the client (C:\APPLCPTR\SNAP). Then you will net use to the alias where you want to place the application files. During the application installation you will point its destination to the alias so it can store the files on the server. After completing the installation you will want to reboot in case there are any additional changes the installation needs to make, and then do your own customizing. Once you have the application in a general state of readiness you can finish the process by running CRTPKG /FINISH with the additional switches. This will compare the system's 'before' snap shot taken during CRTPKG /START to the state the system is currently. The differences are then saved to the server in the following directory:


All the required files that were moved, copied or changed to the local system will reside. With these files at the server you can now assign users this application and no matter where they logon the application information that needs to be local will be propogated to the local machine. From the location mentioned above. This is how we ensure roaming capability. The NETWIN APP command will create a package reference on the server and create an entry in the APPSTORE.INI file located in:


Also refer to the Admin Guide's Section on creating and defining applications for a good picture describing the events.

11. Assign an Application Package

Once you have created an application package, assigning an application to a user is easy.


Ntuser1 being the userid that your assigning the application. When you logon with the userid for the first time you will see a panel telling you it is doing some work. It will then automatically log off. At this point you can log back on and the application should be there.

Behind the scenes:

Assigning the application to a user moves the changes saved in creating the application (\IBMLAN\DCDB\WIN32APP\CLIENT\COM405) to the users home directory, and more specifically the profile directory. Any other changes that do not belong here will get propagated during the first logon (after the application was assigned to that user). During this first logon the rest of the saved changes are propagated to the local machine. After the process finishes, it will logoff the user. At this point you can logon and will have access to the application.

IV. File Mapping Reference

NT 4.0 Image
Service Packs (User definable)
                \IBMLAN\RPL\NT40\I386\$OEM$\SERVICE (Default)
                \IBMLAN\RPL\RPL.MAP -  Original RPL Map File
                \IBMLAN\RPL\W32RPL.MAP  -  New Client Feature RPL Map File
Boot Block Image
                Example:  \DCDB\IMAGES\W32DOSSB.IMG
DOS Boot Batch Files
Answer File - Unattend.txt (Response File)
                \IBMLAN\RPL\NT40\RSP\unattend.txt  (Default)
                \IBMLAN\RPLUSER\\unattend.txt  (Specific)
Logon Code for WSOD
Desktop Files -
                \IBMLAN\DCDB\WIN32APP\DESKTOP\WINNT\DEFAULT     (Default)
                Placed in users home directory, default home dir
                \IBMLAN\DCDB\WIN32APP\USERS\ (Specific)
       - non-editable by user
                ntuser.dat - is editable by user
Policy Files - ntconfig.pol
                Placed in one of three directories, dependent on type of user logged on
                        \ADMIN -  When logged on as an admin
                        \Sandbox - When machine is a sandbox machine
                        \WSOD -  When logged on as a user & non-sandbox machine
Application Files
                \IBMLAN\DCDB\WIN32APP\APPSTORE.INI  -  App database file
                <machine>.log -  State.exe logs its events here.

                RUN.INI -  Result of the format operation

                MAPLCP.INI -  The results of the copy's between client and server

                CP.RES  -  Copy Results File.  Lists the files that were copied during the 
                                XCOPY1 and XCOPY2 stages.

                MEM.INI -  Approx largest block of conventional memory

                X:  Drive -     \\bootserver\IBMLAN\RPL
                                Image is retrieved from here.

                Y: Drive -      \\bootserver\IBMLAN\RPLUSER\
                                Client specific files accessed.

                Z: Drive -      \\bootserver\IBMLAN
                                Access to executables needed during installation.
                                        example:   \DOSLAN\NET\STATE.EXE