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.