لطفا منتظر باشید ...
Hack 63 Customize RIS
Once you know the basics of setting up RIS, you
can customize it for the needs of your own networking
environment.
In [Hack #62], we looked
at
how to install and set up RIS on a Windows 2000-based network. Once
RIS is successfully installed and authorized in Active Directory, you
are ready to customize your RIS settings to meet your needs. This
might include setting installation restrictions, defining a
computer-naming policy, configuring client response options,
prestaging clients in Active Directory, and permitting clients to
install operating system images.
Configuring RIS
To configure the RIS server to respond
to client requests, you need to log onto one of your domain
controllers or install the Administrative Tools package
(adminpak.msi) on the member server that is
running the Remote Installation Service. Execute the Users and
Computers MMC snap-in, right-click on the server that is running RIS,
and you will see a tab labeled Remote Install. On this tab, you can
enable RIS to respond to client requests (which is enabled by
default) and enable the option to not respond to unknown clients.
This ensures that you support only prestaged computer account objects
in your forest as part of your security strategy. If you have
multiple RIS servers as part of a load-balancing strategy and one
fails or is unstable, you can deselect the option to allow it to
respond to client requests.
The Advanced Settings button displays a window that allows you to
configure additional settings for RIS clients, such as the default
computer name that is generated for each client when a
user selects Automatic Setup on the Client Installation Wizard (CIW)
screen. By default, the username of the user who authenticated in the
CIW is used for the computer name, along with a number. The username
can be customized to use different variations, which you can control
by using variables recognized by Active Directory and the BINL
service. For example, CorpWks%# = CorpWks2 uses a
number incremented each time a computer account is generated when an
image is deployed/installed via RIS. You can refer to online help or
Microsoft TechNet for other variables or variations.
Taking advantage of the Advanced Settings is dependent on the
standards currently implemented in your environment. If you have
different standards per department, site, or domain, you will need to
determine if you can leverage this feature. You might need to use a
different solution during the build process. If you are predefining
the computer names, which are matched to the unique GUID of that
workstation, then this is a nonissue. In this screen, you also have
the option of specifying the organizational unit (OU) in which the
computer accounts are created. By default, they are created in the
Computers container.
Predefining computer accounts in RIS
If you are security-conscious or want to ensure that systems are
not arbitrarily imaged from RIS without approval, you should enable
the "Do not respond to unknown
computers" option on the RIS server. This also
allows for greater flexibility, but it requires some up-front work on
the administrator's part. Specifically, you can
precreate the computer accounts in their respective OUs in Active
Directory. Based on the organizational structure of the company and
delegation of administration, this will also have some bearing on how
you plan your implementation of RIS.
When precreating the computer accounts, you need to select the
"This is a managed computer" option
and the GUID of that computer is required. For computers that come
from one of the leading PC vendorssuch as Compaq, HP, or
Gatewaythe GUID can be found on a sticker adhered to the PC
case. If the system does not have that sticker, you can create the
GUID by using the MAC address of the network card installed in the
PC, or you can boot up the PC and access the BIOS; the GUID might be
displayed on the main screen. When using the MAC address of the
network card, since the GUID is a 32-byte value, you need to pad the
first 20 bytes with zeros; the remaining 12 bytes is the MAC address.
To load-balance your RIS servers manually, when you create the
computer account and specify it is a managed computer, you can
specify the RIS server to own (i.e., support)
the client. I don't like this approach, because
there is too much overhead management. Also, if the server were to
become unavailable, your clients would be unable to obtain any
images, updates, or components until that server became available
again. Setting up a dynamic load-balancing solution with RISby
defining one RIS server as the bridgehead and
all other RIS servers behind it to serve only the imagesis a
better approach. I have not used any other approach, but I have been
looking into how to leverage clustering or other solutions to further
bolster the redundancy of RIS.
Client Installation Wizard
The screens that are presented to the client when he interfaces with RIS are in OSCML
format (similar to HTML and modeled after HTML 2.0 format) and have a
.osc extension. You have great flexibility in
how to present those screens to clients, based on your organizational
needs and a touch of personalization (e.g., adding your company name
to display in the screens). There are also state variables that you
can use to make your image installations more dynamic; the values of
the response are passed back via BINL to the answer file located in
the template folder of the particular image. You can have up to 64
unique variables to use with the CIW. All variables, with the
exception of the %LANGUAGE% variable, are set
after successful login. As always, make a backup copy before
modifying the original file, in case you run into an error or you
want to revert back to the original for any reason.
OSChooser and the BINL service use the following
variables:
LANGUAGE
The only variable that can be set prior to logon. This variable
indicates the language in which the user wants to view the screens.
All OSC screens, as well as any ENUM functions the
server performs, are pulled from that language. The default value of
this variable matches the default language of the server. Refer to
the Multilng.osc file located in the
RemoteInstall\Oschooser directory for an example
of how to make the server multilingual.
SUBERROR
The server sets this variable internally for any errors it
encounters. You can add this variable to an error message screen to
diagnose internal failures inside the server.
MACHINEOU
Indicates to the server where the new machine account should be
generated.
MACHINENAME
Indicates to the server the name of the new machine.
SERVERNAME
Indicates the name of the server to which OSChooser is connected.
SERVERDOMAIN
Indicates the domain name of the server to which OSChooser is
connected.
BOOTFILE
Indicates when a tool is about to be started.
NETBIOSNAME
The NetBIOS name generated (using the
DnsHostnameToComputerName( ) call) for the
computer on which the image is being installed.
SIFFILE
This variable is local to the server path of the SIF that the user
selected to install the OS. It is similar to the following example:
X:\RemoteInstall\Setup\English\Images\Win2000.pro\I386\Templates\Ristndrd.sif
OPTIONS
This variable is filled with the results of an
ENUM action by the server. It contains OSCML and
should be placed between a <SELECT> tag and
a </SELECT> tag. See the Tools.osc
file located in the
RemoteInstall\Oschooser\%Language% directory for
an example.
MACHINEDOMAIN
The domain that the new client attempts to join during GUI-mode
setup. This might not correspond to the MACHINEOU
variable's domain.
SYSPREPPATH
The path to the sources for a Riprep-based image if you use
Riprep.exe to create your images. For example:
X:\RemoteInstall\Setup\English\Images\Win2000.prep\I386
INSTALLPATH
The TFTP relative path to the installation imagefor example,
Setup\English\Images\Win2000.pro.
SYSPREPDRIVERS
Indicates the path the server thinks best fits the Riprep-based
image. This path is used to find plug and play drivers.
MAC
Sent by OSChooser to indicate the MAC address of the client.
GUID
Sent by OSChooser to indicate the GUID address of the client.
MACHINETYPE
Sent by OSChooser to indicate the type of hardware on which OSChooser
is running. For example, on Intel platforms, you would use
INTEL = "i386"
USERNAME, *PASSWORD, USERDOMAIN
OSChooser looks for the credentials specified by these three values
to process the logon request. *PASSWORD is a
short-lived variable that is overwritten as soon as possible on the
server and is not accessible to OSC files or SIF files.
TIMEZONE
Set by the server to the server's current time-zone
setting. This setting is helpful if you are replicating images to
remote servers in different time zones.
RIS Custom Installation Wizard
Now, let's look at how to customize the RIS Custom
Installation Wizard screens and how you can modify them to suit your
environment. Here are the default screens that are displayed during
the client login and installation process when deploying operating
system images to clients using RIS:
Welcome.osc
Displays the welcome screen to the user.
Login.osc
Displays the login screen and requires the user to log into the
domain.
Choice.osc
Displays the setup optionsAutomatic, Custom, Restart,
Maintenance, and Toolsto the user. Remote Installation Service
(RIS) Group Policy settings control which options appear.
OSAuto.osc
Determines whether a computer account already exists in Active
Directory with the same GUID as the computer that is running Client
Installation Wizard. If a duplicate is found, DupAuto.osc
is displayed. If no duplicate is found, then
OSChoice.osc is displayed.
DupAuto.osc
Displays a message indicating that a duplicate GUID was found in
Active Directory and instructs the user to contact the network
administrator.
OSChoice.osc
Displays the list of operating system images available to the user
who logged onto the RIS server.
Warning.osc
Displays a warning to the user that the hard drive is going to be
formatted and all information will be lost.
Install.osc
Displays a summary page to the user.
All these screens are modeled after HTML Version 2.0 specifications
and are simple text files with an .osc
extension, indicating they are in the format of OSChooser
Markup Language (OSCML). All of these files are installed in the
RemoteInstall\OSChooser\<language> folder.
The files listed in this hack are only a subset of the total number
of .osc files stored in this folder. With these
files, you customize client login screens in a variety of ways,
including changing the text in the title or in the main body and
adding additional input fields. You can then use that new information
to further tailor the unattended installation of your Windows OS
image through RIS. When working with different languages, you will
need to modify Multiling.osc to list the
languages that will be supported by RIS; then, rename
Multiling.osc to
Welcome.osc.
There are 24 predefined variables you can use within your own custom
screens or answer files. These variables are available only in the
Install.osc file and in the answer file. Some
variables have predefined values, while others do not. To learn more
about the predefined variables, see the following URL at
Microsoft's web site:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp? url=/windows2000/techinfo/reskit/en-us/distrib/dsed_dpl_flwz.asp
To learn more about configuring your own Custom Installation Wizard
screens, see the following Microsoft Windows 2000 Resource Kit
article, which breaks down the tags that are supported in OSCML:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp? url=/windows2000/techinfo/reskit/en-us/distrib/dsed_dpl_KEMO.asp
You have a great deal of flexibility when hacking the screens used in
RIS; you can even create your own screens to request information for
your automated build. Say you want to create a screen to prompt for
the local administrator account password, the location of the
user's computer, and so on. With the default screens
and the reference material provided by Microsoft, you are on
your way.
Deploying Windows Images
Configuring RIS to deploy Windows images is a simple and
straightforward task. However, there are limitations to configuring
RIS with Windows 2000 and Windows XP images.
You cannot slipstream service packs into the i386 image on an RIS
server for Windows 2000 Professional images. To handle this issue,
see Microsoft Knowledge Base Article 258868 (http://support.microsoft.com/default.aspx?scid=kb;en-us;258868).
When you want to slipstream SP1 into a Windows XP image, you will
need to obtain a hotfix from Microsoft, because there are security
changes in SP1 for Windows XP. See Microsoft Q Article 327536
(http://support.microsoft.com/default.aspx?scid=kb;en-us;327536)
to obtain the hotfix.
Beyond those two important items, you might also run across minor
compatibility issues with video and network cards.
If you have Service Pack 3 for Windows 2000 installed on your RIS
server, you will also be able to support the deployment of Windows
2000 Server.
To add additional images to RIS for deployment, execute
RISSetup.exe. This executable also accepts two
command-line parameters:
-check
Runs only the server component of RIS setup. It performs a
verification of the components of RIS and corrects them.
-add
Installs a new CD-ROM-based version of Windows XP Professional,
Windows 2000 Professional, or Windows 2000 Server.
I recommend you keep handy the deployment guides that complement
Windows 2000 or Windows XP and refer to them when you are customizing
a build for automated deployment. Also, keep an eye out for any new
material posted by Microsoft or the other technical resources on the
Web, to help you along the way. Reference material is always a good
thing.
Once you've customized RIS for your own environment,
you might need to tune it further to make RIS server run effectively
[Hack #64].
Matt Goedtel
