Jumpstart Guide to the Windows Client Feature
Written by Ken Hubacher
|
|
Jumpstart Guide to the Windows Client FeatureWritten by Ken Hubacher |
|
Introduction
IntroductionThis 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 ProcessThe boot process can be broken into two areas;
The process starts with a pristine workstation which is configured to RIPL.
State.fil describes several different attributes for the installation process. Some of the highlights are:
The state variable has a few different options:
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:
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 installationNow 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:
\IBMLAN\RPL\NT40\RSP\unattend.txt
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:
\IBMLAN\RPLUSER\
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 IThis is the first non-GUI phase. NT is copying all necessary files from the server to the local hard drive.
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). During PHASE II
During PHASE IIIThis 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:
.\SERVICE\UPDATE.EXE -Z - U
III. Getting a Quick StartThis 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) The idea here is to accomplish the following:
1. Install Warp ServerObtain 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) REBOOT 2. Install WorkSpace on Demand Release 2.0Obtain 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. REBOOT 3. Install Client FeatureMake 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
\\AUSPS302\NC21CID
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. REBOOT
IMPORTANT!!! 4. Install NT40 Workstation Client ImageWe 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 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 ClientIn 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:
NETWIN RIPLMACH CLIENT1 /ADD /IMAGE:W32DOSSB.IMG
/MAC:
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:
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 rpl.map 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:
NETWIN RIPLMACH CLIENT1 /RESET
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.
NET START RPL.
6. Create a DesktopNow 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:
C:\IBMLAN\DCDB\WIN32APP\USERS\NTADMIN
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 :
C:\IBMLAN\DCDB\WIN32APP\DESKTOP\WINNT\DESKTOP1
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 DesktopNow 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:
NET USER USER1 USER1 /ADD
Now assign user1 the desktop that we just created:
NETWIN USER USER1 /DESKTOP:DESKTOP1 /TYPE:WINNT
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:
CD 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\
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):
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:
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:
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
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.
A policy is a way to restrict system configuration choices that the desktop
configuration (above) does not effect. Example of these items include:
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,
Now you can customize your policy.
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.
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:
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.
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: \\
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:
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.
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.
|