Installation With RIS

In the last of his two-part series on Windows 2000 Server installations, Bill tackles the complexities of Remote Installation Services.

• By Bill Boswell
• February 01, 2003

In last month’s column, I covered how to do server installations using unattended setup scripts. It’s possible to simplify the installation process even further using the Remote Installation Services (RIS) feature in Windows 2000. With RIS, you can simply boot a server with no operating system and come back in an hour or so to a machine with a fully installed operating system.

RIS uses the base installation files from the Setup CD to create a file-based “image.” This file-based image has an advantage over sector-based images such as those created by Symantec Ghost and PowerQuest Drive Image because it can accommodate differences in hardware. If you prefer using sector-based images, the latest versions of Ghost and PowerQuest include RIS integration.

In the past, it wasn’t possible to use RIS to install Win2K servers without resorting to a hack of the setup file. Service Pack 3 removed this limitation so that now you can use RIS to install Win2K Server, Win2K Advanced Server and Windows XP. See Knowledge Base articles Q308508, “Unable to Create Windows 2000 Server Image on RIS Server,” and Q304314, “How to Deploy Windows XP Images from Windows 2000 RIS Servers.”

I’m a big fan of RIS but, for some reason, it hasn’t really caught on in a big way. This is partly due to the requirement of having Active Directory, but it’s also because RIS has quite a few moving parts that can be complex to get set up and running. Here are the elements you’ll need to configure RIS.

RIS Server
A RIS server must be a Win2K member server in an AD domain. The domain can be in Mixed or Native mode. The server must have at least two partitions because the RIS image files can’t be placed in the system partition. The RIS partition must be formatted with NTFS and have a minimum of 1GB free space to hold the images files.

Install the Remote Installation Services via Control Panel | Windows Components. This requires a restart. Following the restart, run Risetup to create a file-based image on the server.

RIS Image
The Risetup utility can copy the setup files either directly from the Setup CD or from a folder that’s been slipstreamed with the latest service pack. Do not attempt to slipstream a service pack into an existing RIS image—you will render the image unusable. Instead, create a second image using slipstreamed files.

The initial RIS image created from the installation files is called a “flat” image. A utility called Riprep can be used to layer files from an existing machine onto the flat image. This Riprep image permits you to clone servers onto similar hardware. The Riprep utility can be accessed on a RIS server via a share called Reminst with the UNC path \\<server>\Reminst\ Admin\I386\Riprep.

The original version of Riprep refuses to run on a Win2K server, but a new version is available via links in Knowledge Base article Q313069, “Update for the Riprep Tool.” This new version will image Windows XP, Win2K Server, and Win2K Advanced Server. Microsoft states in the article that it doesn’t support imaging Win2K servers, although the updated Riprep seems to work fine as long as you aren’t running IIS or DHCP. Riprep requires that the RIS server have the proper flat image for the operating system you’re imaging.

Other Riprep limitations include the inability to image encrypted files and a bug in the Winlogon Registry entry that can be fixed using steps in Knowledge Base article Q248257, “Program Installation Problems on Sysprep or Riprep Installed Systems.”

The Setup Script
A RIS image includes a setup script in the form of a Setup Information File (SIF). The default SIF is called Ristndrd.sif. If you create a layered image using Riprep, a new SIF is built that includes instructions for handling the additional files. The SIF file resides in \RemoteInstall\Setup\<language>\ Images\<imagename>\i386\Templates.

The SIF created by Riprep needs very little modification. The only thing you need to do is add the 25-character Product ID. Here’s an example:

[UserData]
FullName = "%USERFIRSTNAME% %USERLASTNAME%"
OrgName = "%ORGNAME%"
ComputerName = %MACHINENAME%
ProductID = "BBBBB-BBBBB-BBBBB-BBBBB-BBBBB"

You can use the SIF to manage the installation of special drivers and handle application setup using entries in the SIF file. You can use Setup Manager to create multiple SIFs for the same image. Each SIF is listed separately in OS Chooser. Assign separate NTFS permissions to the SIF files to control which of them appear in the OS Chooser.

If the server where you install the image has a different mass storage device than the server imaged with Riprep, you’ll run into installation problems. Microsoft’s white paper, “Sysprep Update: Image Maintenance: Reducing the Number of Master Images Required,” (go to http://www.microsoft.com/windows2000/downloads/
servicepacks/sp2/deploytools.asp and click on the link "NewSysprep documentation") has tips for hacking unattended setup entries but, frankly, it’s easier just to use separate images for each server with a different mass storage device.

Common Store
As you might imagine, putting several file-based images on a RIS server can consume a lot of disk real estate. A special service called the Single Instance Storage (SIS) Groveler paws through the images looking for identical files, as determined by matching file names, hashes and byte comparisons. SIS Groveler then moves the files to a folder called SIS Common Store. In their place it leaves a reparse point a special NTFS structure that points at another NTFS record. You can spot a reparse point from a command prompt by doing a DIR. The file type will be flagged as “junction.”

The SIS Groveler analyzes CPU utilization to determine the best time to snatch CPU cycles so it can do its work. The initial analysis takes a few hours, so don’t expect to see any activity right after you install RIS. You can force SIS to work in the foreground using the GROVCTRL utility. The syntax is grov ctrl /f. Expand the GROVCTRL utility from the I386 folder on the Setup CD.

Configuration
RIS doesn’t use a Microsoft Management Console (MMC). Instead, a RIS server is configured using the Active Directory Users and Computers console. Open the Properties window for the RIS server, select the Remote Install tab, then click Advanced Settings (see Figure 1).

Figure 1. RIS server properties showing the Advanced Settings window.

The OS Images tab lists the names of the images you’ve installed. Set NTFS permissions on the SIF file so that only members of your deployment group have access. This prevents the accidental or deliberate download of the image.

The Automatic Computer Naming field lets you choose how RIS will name your computers. You can specify a standard prefix followed by an incremental number, such as W2K-S%n or whatever fits your naming structure.

The Client Account Location field specifies the OU where the associated Computer object will be created. This is useful if the OU administrator doesn’t have access rights to the default Computers container.

You can override the automatic naming and Organizational Unit location features using a Custom screen in the Client Installation Wizard described in the next section (see Figure 2 for an example). The Custom screen isn’t displayed by default. Enable it by using the Custom Setup option of the Remote Installation Services Group Policy.

Figure 2. The custom setup screen in the RIS Client Installation Wizard. (Click image to view larger version.)

Once you’ve configured the RIS server, stop and start the BINLSVC service using the NET command as follows:

net stop binlsvc then net start binlsvc

The Client Side
Now that you have a RIS image, the next step is to configure a client to use the image for an installation. Computers that meet the PC97 standard have an embedded Ethernet controller with a Pre-boot eXecution Environment (PXE) boot ROM that contains bootstrap code designed to find a RIS server with a suitable boot image. PXE is a diskless boot protocol developed jointly by Microsoft and 3COM.

The PXE boot ROM also contains a Globally Unique Identifier (GUID) that tags the machine as a “managed PC.” A GUID is a 128-bit number (16 octets represented in hex, represented by 32 numerals in the user interface) generated using an algorithm that guarantees its uniqueness. AD stores a computer’s GUID as an attribute of the Computer object when the operating system is installed using RIS.

If a machine has a network adapter that meets the PXE requirements but doesn’t have a PXE boot ROM, use the Rbfg (Remote Boot Floppy Generator) utility in \RemoteInstall\Admin\i386. The Rbfg utility places bootstrap information on a floppy along with a file called Risdisk that will boot a PC and initiate a PXE session.

The Adapters button in the Rbfg utility lists the supported adapters. This is purely informational. You don’t need to select a particular adapter. If you have a PCI network adapter that isn’t listed, it may work with PXE if it has a supported Ethernet controller. It’s best to experiment.

The Rbfg utility creates a GUID for a machine using the network adapter’s MAC address padded with leading zeros. If you use the same adapter to do RIS installations on multiple machines, you will get a “duplicate GUID” error. Use the ADSI Editor in the Support Tools to change the RemoteBoot-GUID attribute of the original machine to match the MAC address of its current network adapter.

Negotiation
When the machine boots using PXE, the boot ROM gets an IP address using DHCP. It then plays the digital equivalent of, “Button, button, who’s got the button?” by sending out a modified DHCP Discover packet with its GUID in the payload. The Binary Information Negotiation Layer (BINL) service on a RIS server listens for these special DHCP Discover packets and responds with a DHCP Offer packet that includes a copy of the client’s GUID, but no IP address. In effect, this packet tells the PXE client, “I’m a RIS server that’s heard your broadcast, and I have an image for you to download.”

The PXE client replies with a DHCP Request packet sent directly to the BINL service on UDP port 4011. The BINL service responds with a DHCP Ack packet that contains the name and path of the boot image, Startrom.com.

This dual-headed DHCP process can cause problems when you configure RIS for the first time. In a routed network, an IP helper field in the router contains the IP address of a DHCP server. When the router receives a DHCP Discover packet, it forwards the packet to the DHCP server and then acts as an intermediary between the server and the DHCP client.

If the RIS server is also a DHCP server, this configuration works just fine. The server returns a single DHCP Offer packet with the client’s GUID in the payload and the client handles the rest. If the DHCP server and RIS server are on different machines in the same broadcast segment as the PXE client, the process also proceeds without problems.

If, however, the RIS server and the DHCP server are on different machines that don’t reside in the same broadcast segment as the PXE client, both servers must be included in the IP helper field at the router, and you must verify that both servers get the DHCP Discover packet from the router.

If you have more than one RIS server, don’t install RIS on a DHCP server. A PXE client that gets a standard DHCP Offer that contains its GUID won’t listen for responses from any other RIS servers.

Because BINL is actually a modified DHCP service, it must be authorized in AD. To do this, open the DHCP console, right-click the DHCP icon at the top of the tree, select Manage Authorized Servers, then click Authorize and type the name of the server you want to authorize. If the console can contact the server and get its fully qualified DNS name and IP address, it will place a DHCPClass object in AD that authorizes the server.

Client Installation Wizard
Armed with the name of the RIS server and the path to the boot image, the PXE client now uses Trivial File Transfer Protocol (TFTP) to download Startrom.com and execute it. Startrom.com uses TFTP to get two more files: Ntldr, the Win2K secondary bootstrap loader, and Winnt.sif, the Win2K setup script. It then prompts you to press F12 to begin the Client Installation Wizard (CIW).

If you don’t want to be bothered with pressing F12, replace the standard Startrom.com in \RemoteInstall\ OSChooser\I386 with another file in the same folder called Startrom.n12. Just rename Startrom.com to Startrom.std and Startrom.n12 to Startrom.com.

Windows .NET has additional Startrom images that permit using RIS to install the operating system on a headless server (a machine with no keyboard, mouse or video adapter).

The presence of TFTP on a RIS server introduces a potential security vulnerability. The TFTP service doesn’t authenticate connections, so you can pull a copy of any file in the \Remote Install folder. Don’t put any sensitive files in RIS images, and set Read permissions only for authorized administrators. Also, TFTP permits inbound traffic, making it possible to use a TFTP PUT command to place a hacked version of Startrom.com on the server that could scramble the Master Boot Record, Partition Boot Sector or the BIOS on a PXE client. Set NFTS permissions to block Write or Change.

When you press F12, Startrom downloads the first of a series of HTML files from the RIS server. These HTML files make up the Client Installation Wizard, or CIW. The files have an .osc (OS Chooser) extension and are stored in \RemoteInstall\OS Chooser\.

These OSC files perform a variety of duties. For example, Login.osc obtains the credentials that Startrom uses to authenticate to the BINL service. This authentication uses standard NTLM Challenge-Response, not Kerberos. You must provide credentials with sufficient permission to create a Computer object in the target OU.

OSC files use a subset of HTML 2.0 tags with additions that Microsoft calls OSC Markup Language (OSCML). You can use a text editor to modify the existing OSC files to add instructions to existing screens or to build screens of your own. See the Microsoft white paper, “Technical Guide to Remote Installation Services,” for a complete list of the OSCML variables.

The Choice.osc screen in the CIW lists the images stored at the RIS server using information in the SIF file. When you select an image, the CIW loads the associated SIF file and begins downloading the setup files.

Sit Back and Relax
From this point on, the server chugs away to install the operating system, then downloads any layered files from the Riprep image. You shouldn’t need to intervene except to log on when the installation has finished. RIS will make the entire boot drive into a single partition. You can modify this behavior with entries in the SIF file.

Using a combination of the unattended setups covered last month and the RIS setups covered this month, you should be able to deploy a fleet of servers and still have time to play all the cool electronic games you got for Christmas or even prepare for the Windows .NET certification exams.