Downloads
20051.zip

Individualize OSChooser options

As a consultant, I install Windows 2000 so frequently—either on my own systems or on my clients' systems—that I now see the wizard panels in my sleep. I think I've manually installed Win2K one too many times. So, last Christmas, I asked Santa to deliver a completely automated voice-activated program for installing Win2K from start to finish, complete with all the applications and service packs I need. I figured I was going a bit overboard by asking for voice activation, but I did expect more than the lump of coal I got in my stocking! So what does a disgruntled engineer do when he doesn't get the program he wants for Christmas? He builds it himself.

I began by considering the options for deploying systems. I rated how important ease of use, flexibility, and installation speed were to me. I placed more emphasis on ease of use and flexibility than on installation speed. (Laptop computer manufacturers, for example, might find speed more important, given the number of systems they deploy. But I don't mind if an installation takes 2 hours to complete, as long as I have to be at the keyboard for only the first 5 minutes.)

I also took into account that I could be installing Win2K Professional on any number of systems, from any number of hardware manufacturers, and that the hardware could be significantly different in each case. This factor limited the possibilities for disk-cloning methods.

Microsoft Remote Installation Services (RIS) met my criteria; it's a great tool for deploying Win2K Pro. RIS's out-of-the-box capabilities are impressive. However, you don't have to stop at out-of-the-box functionality. You can build a better mousetrap; you can tweak RIS for your environment; you can push the envelope of automated installations.

RIS 101
Let's start with a brief review of the tool. RIS lets you boot computers over the network, with or without the aid of a boot disk, and perform automated installations of Win2K Pro. (The computers can have another OS already installed or a completely blank hard disk.) The power of RIS is that it easily boots into the environment and begins a Win2K Pro installation quickly.

I won't cover the details of how RIS accomplishes its purpose. RIS is simply a fancy method of launching a typical Win2K Pro unattended installation. If you're familiar with Windows NT-based unattended installations and files such as unattend.txt, you might be surprised to learn that RIS uses the same methods to automate installations. For additional information about the nuts and bolts of RIS, see Sean Daily, "Understanding Remote Installation Services," February 2001.

RIS Advantages and Disadvantages
The beauty of RIS is that the tool is simple to use after you set it up. You can start using RIS to automatically install Win2K Pro within 30 minutes of taking the tool out of the box. However, the downside is that in creating RIS's standard configuration, Microsoft made specific assumptions about options you might want when installing Win2K Pro. Therefore, the standard RIS environment leaves little room for customization. The only real flexibility you have with the standard configuration is the option to choose how to define machine names.

The standard RIS configuration might work well for some installations, but you need more flexibility for complex environments. What if you want to specify a hard-coded IP address for each machine instead of assuming DHCP-based addresses? What if you want to customize the components RIS installs on some systems? What if you want to add Microsoft Office, the latest service pack, or other applications to your system after you complete the Win2K setup? With enough time (and patience), you can work around these shortcomings and develop advanced installation techniques.

The OSChooser Foundation
In Mastering Windows 2000 Server, 2nd edition (Sybex, 2000), Mark Minasi documents a neat RIS trick: You can customize the screens that RIS presents. For example, I modified the \RemoteInstall\OsChooser\welcome.osc (OSChooser is RIS's Client Installation Wizard) file on my RIS server so that instead of displaying the typical Welcome to the Client Installation Wizard screen at the start of a RIS-based installation, the screen would display Welcome to Doug's Super Terrific Automated Win2K Installation Gizmo.

Because .osc files are stripped-down versions of HTML designed for character-based (i.e., non-GUI) displays, a quick edit of a file in Notepad lets my RIS server flash my personalized welcome to whoever wants to install Win2K Pro. Although this ability to customize the welcome screen can be a nice ego trip, it's not functional. With or without the customized introduction screen, RIS simply continues its usual installation process, making all sorts of assumptions about how you'd like to install Win2K Pro.

Recently, two brilliant NT engineers and I were working on a RIS project, and we stumbled across the real power behind OSChooser screens: the INPUT command. (As far as I can determine, the Win2K Server Help files don't document this command; we found the command in the Microsoft Windows 2000 Server Resource Kit Help files.) You can use the INPUT tag to create fields within OSChooser screens. These fields can collect information from the person performing the installation. With the right amount of file tweaking, you can configure the Win2K Pro installation process to use the information that the INPUT tag lets RIS collect.

This key point bears repeating: You can ditch the standard Microsoft Client Installation Wizard screens and make your own screens that ask the installing user any sort of question (e.g., Do you want to install Service Pack 1?). The screens then capture the user's response. When you have the response, you can use it to customize the installation routine. Figure 1 diagrams this process.

To better understand the INPUT capability, you need to understand unattended installation files, environment variables, and template files, and how they work together in an OS installation. Let's look at an example of how Microsoft automatically sets the time zone for a system in a RIS installation.

When you use RIS to install Win2K Pro, you don't have to tell your system what time zone the system is in. So how does RIS know which time zone to choose? It's quite simple. When a user boots into the RIS environment, OSChooser presents a series of screens to collect information from the user.

After the user moves through the last OSChooser screen, the Win2K installation process begins. However, while the user was working through the wizard's screens, OSChooser was secretly populating certain environment variables. The time zone is one of those variables. By default, OSChooser queries the RIS server for the time zone the server is in, then, on the target machine, the wizard populates the %timezone% environment variable with the same value.

To pass an environment variable in memory to the target computer, RIS uses an unattended installation file known as a template. If you're familiar with unattended installations, you'll see that a RIS template file (typically ristndrd.sif) looks like a standard unattended installation file, except that in the \[GuiUnattended\] section, the file refers to the time zone environment variable and not to an absolute value. For example, the prepopulated ristndrd.sif file on a standard RIS server would contain the following lines:

\[GuiUnattended\]
TimeZone = %timezone%

Before OSChooser starts the Win2K installation process, OSChooser writes each line of the template file to the target computer, converting each environment variable reference to its actual value. For example, OSChooser would rewrite the ristndrd.sif file lines above with the time zone's value:

\[GuiUnattended\]
TimeZone = 04

The unattended installation files guide the Win2K installation process. The Win2K installation automatically knows what time zone it should use from the relevant lines of the ristndrd.sif unattended installation file. Thus, installing users never need to select their time zone; OSChooser simply passes the correct value to the Win2K installation process by means of a template file and an environment variable.

Leveraging OSChooser
The INPUT capability opens up amazing possibilities: You can automate any customization that you need to perform from one Win2K Pro installation to the next. Do you need to set a fixed IP address for each Win2K Pro system that you roll out? Do you need to use a customized naming scheme for your corporate standards? Simply prompt the installing user for the information, put the values into environment variables, then reference those variables in the appropriate location in the template file.

Perhaps you need to set up some of your Win2K Pro systems with personal Web services and Microsoft FrontPage extensions. However, you won't need Web services on all systems, so you need to modify an OSChooser screen to ask the user whether to install Web services, then modify the unattended installation template to use the answer that the installing user provides. Let's walk through this hypothetical example.

Step 1: Modify an OSChooser screen. To prompt a user for input about whether to install Web services, you need to modify one of the existing OSChooser screens by adding an input field for the question. For this example, we'll modify the custom.osc file.

Listing 1, page 81, shows that this modification requires only one simple change to the custom.osc file. The code at callout A in Listing 1 shows the added INPUT statement. OSChooser will present the information from this edited file on a screen, including the customized question, "Web Services On or Off?"

Note that the INPUT statement in Listing 1's edited file refers to a value of "WEB". OSChooser stores data it collects from the user by placing the value in an environment variable. When the installing user enters a value in this field, OSChooser will populate the %WEB% environment variable with the value the user provides.

Step 2: Modify the template file. If we were to stop after this first step, nothing fancy would happen. An OSChooser screen would prompt users for an answer about whether to install Web services on the target system, but RIS wouldn't pass the answer to the target system. To do that task, RIS must reference the %WEB% value in the installation process's template file.

You accomplish this task by going to the \RemoteInstall\Setup\English\Images\\i386\templates directory and editing the ristndrd.sif file. Search for the file's \[Components\] section, and add the following lines:

iis_common=%WEB%
iis_inetmgr=%WEB%
iis_pwmgr=%WEB%
iis_www=%WEB%
fp=%WEB%

These values might already exist in some ristndrd.sif files, but by default, the values are probably set to Off. In a Win2K unattended installation file, the correct syntax for an answer must be either On or Off. (This syntax requirement explains the phrasing of the question on the OSChooser screen as Web Services On or Off?) RIS will paste the answer that installing users provide into the ristndrd .sif file as RIS copies the file onto the target computer.

Step 3: Run. After you modify the OSChooser screen to capture an environment variable and edit the appropriate template file, all you need to do is run the standard RIS installation process. When you launch the RIS install, OSChooser will display the standard Client Installation Wizard screens. Choosing the Custom Installation option when you launch the RIS install directs OSChooser to display your modified custom.osc screen.

If you've done everything correctly, installing users will see an input field on the screen displaying Web Services On or Off? and they'll need to enter a value of On or Off before continuing with the installation process. After users complete the installation, their systems will have standard Win2K Pro installations with Web services installed or not installed, as each user chose.

This example is rather simple. Nevertheless, it demonstrates the power and flexibility that are available to you through easy file-editing techniques. You can perform many per-user or per-machine customizations (e.g., for IP addresses, for administrator passwords, for Telephony API—TAPI—area codes) at the beginning of the Win2K Pro installation, eliminating the need to go back and set those options.

So Many Options
RIS is a great tool for deploying Win2K, and by customizing RIS, you can further extend the tool's capability. The key to customizing your installations is understanding which options are available in the Win2K unattended installation file. Table 1 shows which options OSChooser already uses. You, therefore, need to avoid using these values when you customize your RIS-based installations.

For further information about options for unattended installations, I recommend Microsoft's "Windows 2000 Guide to Unattended Setup" document, which you'll find in the deploy.cab file in the \support\tools directory of your Win2K CD-ROM. This file shows every option that you can customize during installation—all you need to do is identify the values that are important to your environment and modify the OSChooser screens to collect the necessary information from the installing user.

But what about installing additional applications, such as Office or Microsoft's service packs? Stay tuned for future Superior RIS articles.