Remote Installation Services (RIS) allows administrators to install Windows on computers from across the network with almost no user intervention. You can also use RIS with the IntelliMirror technologies (User Settings Management, User Data Management, and Software Installation and Maintenance) to install Windows remotely and then automatically add a user's personalized work environment—complete with the user's computer settings, software applications, and data.
This capability can come in handy. For example, you might want to purchase a new computer and give it to an existing user, or recycle an old server as a desktop. Using RIS and IntelliMirror, simply boot the computer from the network and automatically install the appropriate version of Windows. When users log on for the first time, their settings and applications are downloaded from the network and they'll be up and running in no time.
It's not hard to see the advantages RIS offers to an administrator who is short of both time and money. The sections that follow describe how RIS works, help you determine whether the network meets the requirements for RIS, and explain how to install, configure, and use RIS to set up client systems.
Windows 2000 RIS servers can deploy only Windows 2000 Professional and Windows XP Professional (if the Windows 2000 server is running Service Pack 2 or later).
RIS is a combination of technologies that provides the nifty ability to easily boot a system and install an operating system from a remote server—all without requiring any data on the system beforehand.
The first technology that facilitates the ability to install an operating system remotely is Preboot Execution Environment (PXE). PXE allows a user of a computer with a PXE-compliant network interface card (NIC) to boot directly from the network by pressing F12 at bootup.
When the client boots to the network using a PXE-compliant NIC (or a network boot disk and a NIC that is supported by the disk), it requests an IP address from a Dynamic Host Configuration Protocol (DHCP) server, which also supplies the IP address of the nearest RIS server.
When a prestaged client (one whose computer account has already been created in Active Directory) contacts the RIS server, the RIS server queries Active Directory for the unique GUID for the client and then transmits the name of any operating system images the client is permitted to install. If the client isn't prestaged, it must at this point log on to a domain and use the Client Installation Wizard to select an operating system image. (RIS uses Group Policy to determine which images the user has access to, and it displays only those images.)
To use RIS, the network needs to have the following services running properly: Active Directory, DHCP, and DNS. You can install RIS on any Windows 2000 or Windows .NET server, but you should take some care to ensure that the RIS server is located on the same LAN as your clients (RIS is not slow-link aware, and installing Windows from across a WAN link isn't recommended. It also relies on DHCP broadcasts, which generally aren't forwarded by routers). If you have multiple sites, consider deploying a RIS server to each site.
RIS servers need to meet the minimum system requirements for the version of Windows Server you're using, and in addition they must have a separate 2-GB hard disk or partition for the operating system images. (You can get by with less if you deploy only a couple of images.)
As mentioned in Chapter 5, you shouldn't be using a system that meets only the minimum system requirements, especially when it comes to RAM. Don't deploy a server with less than 256 MB of RAM, and if you're going to combine services such as Active Directory, DHCP, DNS, and RIS, get more; the extra cost is small. In addition, RIS must be installed on an NTFS 5-formatted partition that is separate from the system partition. RIS doesn't support Encrypting File System (EFS) files.
Operating system images stored on a RIS server can be synchronized with operating system images on other RIS servers with the use of Dfs, as discussed later in this chapter. However, RIS cannot follow Dfs links, so all needed data and images must be stored locally.
RIS clients also need to meet or preferably exceed the minimum system requirements for the operating system that they will install. In addition, the systems should have a 10 Mbps or preferably 100 Mbps NIC that supports PXE remote boot or is explicitly supported by the remote boot disk. (See the section entitled Creating a Remote Boot Disk later in this chapter for more information.)
Before you can use RIS on the network, you need to install it, of course. Once you've chosen the server you want to use as a RIS server, use the following procedure to install the service and run the initial setup wizard:
Figure 25-18. The Add/Remove Programs screen.
Figure 25-19. Specifying a friendly description and help text for an operating system image.
The Remote Installation Services Setup Wizard does an adequate job of setting up the server with all of the default settings, but sooner or later you're going to need to tweak these settings.
RIS servers are administered from the Active Directory Users and Group MMC snap-in by right-clicking the server, choosing Properties from the shortcut menu, and then clicking the Remote Install tab. There are also Group Policy settings that you can use to change the level of interaction users have during a remote install.
Administering RIS servers and changing RIS Group Policy settings are discussed in the sections that follow.
You can administer most functions of a RIS server remotely by installing the Windows 2000 Administration Tools (Adminpak.msi) from the \i386 folder of the Windows 2000 Server CD-ROM. This tool also allows you to administer most other server services remotely.
The most reliable way to determine whether a RIS server is working is to boot a computer from the network and install an operating system from it. However, before you do that, check the integrity of the RIS server using Microsoft's Check Server Wizard. This wizard quickly checks the status of your RIS server and attempts to fix any problems it finds.
To use the Check Server Wizard, follow these steps:
Figure 25-20. Verifying the status of a RIS server.
The Check Server Wizard checks only that the RIS server is properly set up. It doesn't check the integrity of any operating system images on the server or the ability of clients to properly reach the server across the network. If you experience any problems, check the server's event log and check the functionality of the DHCP, DNS, and Active Directory services.
To enable the RIS server to respond to client requests or to disable the RIS server from serving client requests, follow these steps:
Real World
Reasons for Ignoring Unknown Clients
Selecting the Do Not Respond To Unknown Client Computers check box adds one extra step (creating a computer account for a client) to the process of deploying Windows, but it does so for a couple of good reasons. The first reason is security. If this check box isn't selected, anyone who can reach the server can receive an operating system installation, provided that the user has adequate permissions (they still need to log on to the domain).
The second reason is compatibility with existing remote-boot applications. If you don't select this check box and you are using another company's remote boot/installation program on the network, clients may not be able to reach the other program. When you clear this check box, you ensure that only prestaged clients with registered computer accounts use RIS. See the section entitled Prestaging a Client later in this chapter for more details.
You might want to view a list of clients that have used the server to install Windows or that are prestaged to install Windows from the server. To do so, follow these steps:
You might want to change how RIS configures clients, especially if your company has its own computer naming convention. By default, the computer name is created by appending a number to the user name used to log on to Active Directory during the client installation. You can change this to another scheme if you want.
The Active Directory location in which the new client computer account is created can also be changed. The default location is the Computers container in the same domain as the RIS server, but you can change this to the same container as the user's user account (probably the Users container) or to any other location in Active Directory.
Note that if an end user will be setting up the computer, the user's account needs to have sufficient permissions to create a new computer account in the specified location, unless the system is prestaged, as described in the section entitled Prestaging a Client later in this chapter.
To change the way in which RIS configures new clients, use the following procedure:
Figure 25-21. Selecting a predefined computer naming format.
You can combine several fields when defining a computer naming format. For example, the string %1First%10Last%# would yield computer names using the first letter of a user's first name and then 10 characters from the user's last name, followed by a number, for example JSMITH11. This would yield a NetBIOS-compliant computer name easily readable by earlier clients such as Windows NT and Windows 98.
Figure 25-22. Defining a customized computer naming format.
You can regulate the level of control users have over RIS installations by using Group Policy. To do so, use the following procedure (note that you can also apply permissions to individual operating system images, as discussed in the section entitled Managing Operating System Images later in this chapter):
Don't enable Custom Setup if you're going to prestage computers that will be set up by users, because it presents the possibility of creating duplicate computer accounts if the GUID, computer name, and Active Directory location don't exactly match the one created when prestaging the computer.
If you choose the Not Configured setting, the default setting is used unless the option is explicitly enabled or disabled by another GPO that applies to the user performing the installation.
Managing the operating systems available for install using RIS involves a few different tasks. You might want to add new operating systems to make it easier to deploy servers as well as different clients, or you might want to customize an existing operating system image with an unattended answer file. You can also restrict the users and groups allowed to install a particular operating system and change other properties of an operating system image. The following sections describe the process.
Adding CD-Based Images You'll probably want to add some operating systems after setting up the RIS server. For example, you might want to deploy both Windows XP Professional and Windows 2000 Professional (Service Pack 2 or newer must be installed to deploy Windows XP Professional).
To take a Windows CD or network share and create a new operating system image from it that RIS can deploy to clients, use the following procedure:
Figure 25-23. The Images tab of the RIS Properties dialog box.
You install RIPrep images from the computer you create the image on at the time you create the image. For more information, see the section entitled Using Remote Installation Preparation later in this chapter.
Figure 25-24. Specifying a friendly description and help text for an operating system image.
If you want to allow clients to install support for multiple languages, you need to copy the contents of the \i386\Lang folder (and all subfolders) from the Windows CD-ROM to the \\RISServerName\RemoteInstall\Setup\clientlanguage \Images\imagename\i386\Lang folder. To enable multiple languages during client setup, you need to replace the Welcome.osc file on the RIS server with an appropriately modified and renamed Multilng.osc, and create Client Installation Wizard screens for any additional languages. This procedure and customizing the screens in the Client Setup Wizard is discussed in the Windows 2000 Server Resource Kit.
The client installation screens only affect the RIS portion of the installation, not the actual Windows Setup, so using one version or another shouldn't adversely affect the actual setup process.
Adding Unattended Answer Files to Existing Images Answer files are small text files that are used to provide answers to the questions asked by Windows Setup. As such, they can be used to completely automate the Windows setup process, partially automate the process, or merely provide default settings.
When you add an operating system image to a RIS server, an answer file is created automatically that runs Setup completely automated with the default settings. This file is called Ristndrd.sif and it is located in the \\RISServerName\RemoteInstall \Setup\clientlanguage\Images\imagename\i386\Templates folder.
You can create additional answer files for CD-based images (you can't add answer files to RIPrep-based images) using the same techniques you'd use for a standard CD or network-based installation of Windows (which are discussed at length in Chapter 5).
After you've created an answer file, you can associate it with an operating system image in RIS. The answer file appears as a new operating system image, both on the RIS server and to RIS clients, although almost no additional disk space is consumed (just a couple of kilobytes for the answer file). The answer file simply modifies how clients use an existing image sitting on the hard drive.
To associate an answer file you've created with an existing image on a RIS server, use the following procedure:
If you want to manually create answer files for RIS images, do not alter the first two sections of the answer file: [data] and [SetupData]. These sections need to appear exactly as they do in the default answer file created by RIS.
RIS provides two answer files that you can use on any CD-based operating system installation: the default answer file that performs an automated installation into a single disk partition after repartitioning and formatting the partition, and another answer file that installs Windows without repartitioning or reformatting the hard drive.
Figure 25-25. The Select An Installation Image screen of the Add Wizard.
You need to create or modify an answer file if you want to automate the part of Setup that prompts for the registered user, company, and CD key.
Setting Permissions for Images To control which users and groups can install an operating system image using RIS, use the following procedure to modify the security settings for the answer file associated with each operating system image:
Changing Image Properties To rename operating system images, change their descriptions, or remove operating system images from a RIS server, use the following procedure:
When you remove an operating system from the list, RIS deletes the answer file for the image but leaves the actual installation files intact. To actually delete the installation files, open Windows Explorer and delete the physical folder containing the operating system image.
If all client computers that use RIS to install an operating system are to contain the same settings, all RIS servers need to be configured in exactly the same way. Unfortunately, Windows doesn't directly support replication of operating system images or RIS configuration settings between RIS servers. However, you can use Windows Distributed File System (Dfs) feature to replicate images stored on the hard drive to other Dfs servers.
To replicate RIS images using Dfs, you need to do the following:
Figure 25-26. Creating a new Dfs link.
Figure 25-27. Creating a new target.
Dfs only replicates changes to operating system images; you'll still need to add each image to all the RIS servers and configure their settings similarly for the operating system images to work properly.
RIS allows independent software vendors (ISVs) and original equipment manufacturers (OEMs) to add tools that are available after booting from the network. Because client systems might have blank hard disks before Windows is installed using RIS, the maintenance and troubleshooting tools provided by some ISVs and OEMs can be extremely useful. These tools can also provide administrators with a handy way to update such things as the client's system BIOS.
RIS doesn't ship with any tools installed, and there is no built-in mechanism for adding tools; instead, you must use the external setup program supplied with the tools to install them. You can then use the Tools tab of the Remote Installation Services dialog box (discussed earlier in this chapter) to view the properties for the tools or remove the tools' associated template files (files with the extension .SIF), making the tools unavailable to clients.
The Remote Installation Preparation (RIPrep) Wizard allows you to create a Windows installation complete with applications and settings, image it, and then deploy it using RIS.
This technique is very similar to using the System Preparation (SysPrep) tool in combination with a third-party disk-imaging program. However, using RIPrep has a couple of advantages. First, the hardware on the client systems can be completely different from that on the reference system, as RIS uses the Plug and Play functionality of Windows to perform a complete device scan (however, the systems must use the same Hardware Abstraction Layer, typically Advanced Configuration and Power Management [ACPI] PC). SysPrep performs only a partial device scan and requires systems to have identical mass storage controllers. (See Chapter 5 for more information on SysPrep.)
Second, there is no need to copy the system image to the client's hard disk, because all information is pulled from the RIS server after performing a network boot. In addition, the installation process can be automated to such a degree as to obviate the need for trained supervision of the installation—even untrained users will have no trouble starting a RIS installation.
The operating system and all applications and files must be installed in a single boot partition on the C drive of the reference computer for RIPrep to function properly.
To create an operating system image using RIPrep, follow these steps:
You should install applications from a permanently accessible location so that if an application needs to use the setup files again, it can do so without prompting the user for a CD-ROM. Usually this is done by installing applications from a network share containing the application's setup files.
Figure 25-28. Specifying a friendly description and help text for an installation image.
Real World
Remote Installation Cautions
Make sure that the BIOS on both the reference system and the RIS clients has up-to-date Advanced Configuration Power Interface (ACPI) support. RIPrep doesn't support mixing systems with different HALs (ACPI, Standard PC, uniprocessor, and multiprocessor). You can't include encrypted files in a RIPrep image.
Additionally, certain desktop shortcuts might not work properly on RIS clients made from RIPrep images. For example, the Microsoft Outlook 2000 desktop shortcut does not work after a RIPrep RIS installation unless you disable 8.3 name creation on the reference computer before running RIPrep. To do this, change the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystems \NtfsDisable8dot3NameCreation registry key from 0 to 1. For more information, see Microsoft Knowledge Base article Q250642.
You should also test the user profiles of the source computer before running RIPrep. To do this, after configuring all settings, log on as a different user and verify that the settings are applied. If the settings aren't properly applied, copy the Administrator profile (or whatever account you used when configuring the computer) to the All Users profile. To do so, log on with the account you used to set up the computer, open Control Panel, double-click the System tool (you might have to click the Performance And Maintenance link first), click the Advanced tab, click Settings in the User Profiles section, select your current account, and click Copy To. In the Copy To dialog box, enter the path of the All Users profile and then click Change. Select the Everyone group in the next dialog box and then click OK. If this procedure doesn't work, you can also manually copy the contents of your profile folder into the \All Users profile folder.
After you've installed and configured the RIS servers, you're ready to start deploying systems. Although this is in many cases an easy end-user job, you might need to do a little preparation beforehand, and you must ensure that client systems meet certain prerequisites. This section describes these preparations and, finally, walks you through a sample OS installation, just so you know what to expect.
A system that is to be used as a RIS client needs to meet the minimum system requirements for the version of Windows you will be installing and in addition must have a network card that either supports PXE remote booting or is supported by the remote boot disk.
When installing clients from a RIPrep image, the hard disk is formatted by default into one large partition on the first disk. If you prefer, you can have it create a partition on the first disk that is exactly the same size as the image partition and leave the rest of the disk unpartitioned. To do this, set the UseWholeDisk key in the Riprep.sif file from Yes to No. This file is located in the \\RISServerName\RemoteInstall\Setup\clientlanguage\Images\imagename \i386\Templates folder.
If the RIS client computer doesn't have a PXE-compliant network card, you must create a remote boot disk before using RIS. You can also choose to prestage the system by creating a computer account for the system in Active Directory before the installation, allowing the installation to proceed almost completely automatically, if desired. (Someone will still have to press F12 to boot the computer from the network, log on, and choose the operating system, but that doesn't count.)
You can prestage clients that you plan to set up using RIS by creating managed computer accounts for them in Active Directory. These computer accounts are associated with the client systems' globally unique identifiers (GUIDs), which are unique to every network card, and thus are not prone to theft by rogue clients. Prestaging clients further streamlines the installation process and increases security by eliminating the need for a user to create the computer account for the system using the Client Setup Wizard.
To prestage a client, follow these steps:
Figure 25-29. Assigning a name to a new computer.
Figure 25-30. Entering a GUID for a new computer.
Figure 25-31. Specifying a RIS server for the client.
Real World
Working with GUIDs
RIS uses a computer's GUID to keep track of client computers. The GUID comes from the PXE ROM on PXE-enabled network cards or from the network card's MAC address when you boot with the Remote Boot Disk. (In this case it is the MAC address with 24 zeros appended to the beginning of the address.) The computer manufacturer often writes the GUID on a sticker located on or inside the computer's case. It can also be located inside the system BIOS.
If you have trouble finding the GUID, there are a few ways you can locate it. The first way is using a network sniffer such as Network Monitor while the client performs a network boot. (RIS clients send their GUID when looking for a RIS server.) A much easier way to deal with this dilemma is to set up a RIS server configured to answer all RIS client requests on a private subnet. (see the section entitled Enabling or Disabling RIS earlier in this chapter.) Then connect any clients you want to prestage and have them perform a network boot, log on, and select an OS image. Just before the client performs the Windows installation, a summary screen is shown that displays the GUID, among other things. At this point the client is prestaged in Active Directory (as long as the RIS server you used is part of the Active Directory). You should write down the GUID for future reference.
If the client you are configuring doesn't have a NIC that is PXE remote-boot compatible, you need to create a remote boot disk to use RIS to install Windows on the system. To do so, follow these steps:
Figure 25-32. The Microsoft Windows Remote Boot Disk Generator dialog box.
The actual process of installing an operating system remotely is fairly easy, and you might choose to have users do it themselves. We'll walk you through the procedure here, just to cover all bases. To perform a remote OS installation, go to the client system and follow these steps:
You can control whether or not clients can perform automated installations or custom setups, gain access to RIS tools, or restart setup in case of a problem by using User Configuration-Windows Settings-Remote Installation Services-Choice Options in Group Policy, as described earlier in this chapter.