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 vendors such 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