Remote Operating System Installation
The Microsoft® Windows® 2000 Remote OS Installation feature, based on the Remote Installation Services (RIS) technology, gives administrators the ability to deploy an operating system throughout the enterprise, without the need to physically visit each client computer.
One of the most challenging and costly functions performed by IT staff today is the deployment of a new operating system to client computers. The Remote OS Installation feature uses the new PXE-based remote boot technology to assist IT staff with the deployment of Windows 2000 Professional in a remote way, thus reducing IT support overhead in bringing new computers online, and in reinstalling operating systems in the field.
On This Page
Overview of the Technology and Terminology
Remote Installation Services Components
Using Remote OS Installation in an Organization
For More Information
Appendix A: Hardware Requirements
Appendix B: Network Cards Supported by the RIS Boot Disk
Appendix C: Frequently Asked Questions
Remote Operating System (OS) Installation and IntelliMirror™ management technologies are important change and configuration management features included in the Microsoft® Windows® 2000 operating system. Remote OS Installation allows systems administrators to use the new Pre-Boot eXecution Environment (PXE)-based remote-boot technology, and server-based software to install local copies of the Windows 2000 Professional operating system on computers throughout the enterprise. After Windows 2000 is operational on a computer, network administrators, using IntelliMirror technology, can provide policy-based management of users' Windows 2000–based desktops, including data, settings, and application software.
The following table highlights the Windows 2000 Change and Configuration Management features and benefits, as well as the underlying technologies that support these features.
One of the most challenging and costly functions performed by IT staff today is the deployment of an operating system (OS) to new or existing client computers. Currently, organizations spend a great deal of time and expense planning, designing, and rolling out the latest version of the operating system throughout the organization. Often this process is done manually, requiring a help desk professional to physically visit each computer.
The Remote Installation Services (RIS), an optional component of the Windows 2000 Server operating system, works with other Windows 2000 technologies to implement the Remote OS Installation feature, providing companies with the ability to remotely install a copy of the Windows 2000 Professional operating system on supported computers throughout the enterprise. Now an administrator can roll out a new version of the operating system to hundreds, even thousands of clients at one time, and do so from a remote location.
Computers that are PC98-compliant ship with a PXE Remote Boot ROM, which is required in order to use the Remote OS Installation feature. (PC98 refers to the annual guide for hardware developers co-authored by Microsoft with Intel, including contributions from Compaq and other industry hardware manufacturers. PC98 is intended to provide standards for hardware development that advance the PC platform and enable Microsoft to include advanced features, like RIS, in the Windows platform.) For computers in your organization that do not contain a PXE-based remote boot ROM, Microsoft provides the administrator with a tool to create a remote boot disk for use with RIS. The RIS remote boot disk can be used with a variety of supported PCI-based network adapter cards. The Network PC—a slimmed down version of a personal computer without a floppy disk or CD-ROM drive—will be one of the first client computers to take advantage of RIS. Because of its lack of an external floppy disk drive, the Net PC will require use of the Remote OS Installation feature for the installation of the workstation operating system.
Overview of the Technology and Terminology
This section provides an overview of the Remote Installation Services (RIS) architecture and other components and Windows 2000 services that are required to take advantage of the Remote OS Installation feature. This section also describes the client components and services that are required in order to implement Remote OS Installation in your organization.
Remote OS Installation Overview
Figure 1 illustrates the services and components that make up the Remote OS Installation feature.
Remote OS Installation uses some of the existing services that may already be deployed and in use within your organization, as well adds some additional services that you may or may not be familiar with. Windows 2000 Server ships with Active Directory™ directory service, an updated Dynamic Host Configuration Protocol (DHCP) server, and a compliant version of Dynamic Domain Name Server (DDNS) that is required by the Active Directory. When Remote Installation Services are installed, these additional services are added to the server:
Boot Information Negotiation Layer (BINL)—The BINL service is added during the RIS installation process. The BINL service is responsible for answering client computer network service requests, querying Active Directory on behalf of the client computer, as well ensuring that the correct policy and configuration settings are applied to the client computer during the operating system installation.
Trivial File Transfer Protocol Daemon (TFTPD)—This server side TFTP service is responsible for hosting specific file download requests made by the client computer. The TFTPD service is used to download the Client Installation wizard (CIW) and all client dialog boxes contained within the CIW for a given session.
Single Instance Store (SIS)—Single Instance Store is the service responsible for reducing disk space requirements on the volumes used for storing RIS installation images. When you install RIS as an optional component, you are prompted for a drive and directory where you would like to install RIS: This is the RIS volume. The SIS service attaches itself to the RIS volume, and monitors that volume looking for any duplicate files that are placed on that volume. If any duplicate files are found, SIS creates a link to the duplicates, thus reducing the disk space required.
Remote OS Installation uses the new Pre-Boot eXecution Environment (PXE) DHCP-based remote boot technology to initiate the installation of an operating system from a remote source to a client hard disk. The remote source—a server that supports Remote Installation Services (RIS)—provides the network equivalent of a CD-based installation of Windows 2000 Professional or a pre-configured Remote Installation Preparation (RIPrep) desktop image. The Windows 2000 Professional operating system is currently the only installation option supported by Remote Installation Services.
CD-based installation—The CD-based option is similar to setting up a workstation directly from the Windows 2000 Professional compact disc; however, the source files reside across the network on available RIS servers.
RIPrep image format—The RIPrep imaging option allows a network administrator to clone a standard corporate desktop configuration, complete with operating system configurations, desktop customizations, and locally installed applications. After first installing and configuring the Windows 2000 Professional operating system, its services, and any standard applications on a computer, the network administrator runs a wizard that prepares the installation image, and replicates it to an available RIS server on the network for installation on other clients.
Once the images have been posted on the RIS server(s), end users equipped with PXE based remote boot-enabled (or compatible boot disk) client computers can request to install those images from any available RIS server on the network. The fact that the user can install the operating system without administrator assistance means the administrator is free to complete other tasks requiring his or her attention, thus saving both time and expense normally associated with operating system installations.
How the PXE Remote Boot Technology Works
A new form of remote boot technology has been created within the computing industry. The new remote boot technology, Pre-Boot eXecution Environment (PXE), provides companies with the ability to use their existing TCP/IP network infrastructure with the Dynamic Host Configuration Protocol (DHCP) to discover remote installation servers on the network. Net PC/PC98-compliant systems, and computers equipped with network interface cards (NICs) supported by the RIS remote boot disk can take advantage of the remote boot technology included in the Windows 2000 operating system.
When a PXE-enabled client computer is turned on, the PXE-based ROM or RIS remote boot disk requests an IP address from a DHCP server using the normal DHCP discovery process. As part of the initial DHCP discover request, the client computer identifies itself as being PXE-enabled, which indicates to the remote installation servers on the network that it is looking to be serviced. Any available RIS server on the network can respond by providing the client with its IP address, and the name of a boot file the client should request if that client wants service from that server.
Below is a diagram, Figure 2, which describes the step-by-step process the PXE remote boot ROM goes through during every network service boot request.
After the procedure reaches step 7, the client side experience will be different, depending on the remote installation server vendor that is responding to the client request for service. The section below details the implementation of Remote OS Installation that is included in the Windows 2000 Server operating system.
How the Remote OS Installation Process Works
A graphical representation of how the Remote OS Installation process works is contained in Figure 3. Each step of the process is defined in detail below the illustration
The process of contacting a RIS server and selecting an operating system image is accomplished in a few steps. The steps below detail the sequence of events that occur when a PXE-enabled client computer starts on the network, and is serviced by a RIS server.
To accomplish a Remote OS Installation
A PXE-enabled client connected to the network starts, and during the power up, the computer initiates a network service request. As part of the network service request, a DHCP discover packet is sent to the network requesting an IP address from the closest DHCP server, the IP address of an available RIS server, and as part of that request, the client sends its Globally Unique Identifier (GUID). (The GUID is present in client computers that are PC98- or Net PC-complaint and is found in the system BIOS of the computer.). The DHCP server responds to the request by providing an IP address to the client. Any available RIS server can respond with its IP address, and the name of the boot file the client should request if the client selects that RIS server for service. The user is prompted to press the function key, F12, to initiate service from that RIS server.
The RIS server (using the BINL service) must check in Active Directory for the existence of a pre-staged client computer account that matches this client computer. BINL checks for the existence of a client computer by querying Active Directory for a client computer that matches the GUID sent in step 1.
Once RIS has checked for the existence of a client computer account, the Client Installation wizard (CIW) is downloaded to the client computer, and prompts the user to log on to the network.
Once the user logs on, RIS checks the Active Directory for a corresponding user account, verifying the password. RIS then checks the RIS specific Group Policy settings to find out which installation options the user should have access to. RIS also checks to see which operating system images the specific user should be offered, and the Client Installation wizard makes those options available to the client.
If the user is only allowed a single installation option and operating system choice, the user is not prompted to select anything. Rather, the Client Installation wizard warns the user that the installation will reformat their hard disk and previously stored information will be deleted, and then prompts the user to start the Remote OS Installation.
Once the user confirms the installation settings on the summary screen, the operating system installation begins. At this point, if a client computer account was not present in Active Directory, the BINL service creates the client computer account, thus automatically providing a name for the computer. The operating system is installed locally as an unattended installation, which means the end user is not offered any installation choices during the operating system installation phase.
The Remote OS Installation process is straightforward from an end user perspective. The administrator can guide the user through a successful operating system installation by pre-determining which installation options, if any, an end user has access to. The administrator can also restrict which operating system image or images a user has access to, thus ensuring the correct operating system installation type is offered to the user for a successful installation.
Remote Installation Services Components
The Windows 2000 Remote OS Installation feature simplifies the task of installing an operating system by providing a mechanism for computers to connect to a network server when they are initially started, and by allowing the server to drive a local installation of Windows 2000 Professional. There are several components that make up the Remote Installation Services (RIS), the technology that supports the Remote OS Installation feature. This section discusses the various components that an administrator or IT professional uses to install, configure, and implement RIS within their organization in order to deploy the Windows 2000 Professional operating system.
There are five major components that make up RIS:
Remote Installation Services Setup (RISetup.exe).
Remote Installation Services Administration.
Client Installation wizard (OSChooser.exe).
Remote Installation Preparation wizard (RIPrep.exe).
Remote Installation Boot Disk (RBFG.exe).
Note: For additional information on installing, configuring, and implementing Remote OS Installation, see the Windows 2000 Remote OS Installation walk through listed in the For More Information section of this document.
Remote Installation Services Setup
RIS is installed one of two ways, and requires a two-stage installation process. RIS is an optional component of the Windows 2000 Server operating system, and can be installed either during the installation of Windows 2000 Server, or after installation by using Add/Remove Programs in Control Panel.
The first stage of installation occurs when RIS is selected as an optional component during Windows 2000 Server installation or after the server installation by using Add/Remove Programs. The Windows Components wizard displays Remote Installation Services as an optional component for installation, and is illustrated in Figure 4.
After Remote Installation Services is selected as an optional component, the first stage of the RIS installation copies the required files to the hard disk drive on the server. After the setup of the server is completed, the administrator is prompted to shutdown and restart the server before installing Remote Installation Services.
To install Remote Installation Services
On the Start menu, point to Programs, then to Administrative Tools, and then click Configure Your Server.
In the Configure Your Server dialog box, click Finish Setup.
In the Configure Remote Installation Services dialog box, click Configure to start the Remote Installation Services Setup wizard.
In the Remote Installation Services Setup Wizard dialog box, click Next.
The Remote Installation Services Setup wizard prompts the administrator for information about specific settings used in the RIS installation. The wizard asks the administrator to provide the following items:
A location on the server where the RIS directory tree will be created.
Whether the RIS server should service client computers after completing Setup.
The location of the Windows 2000 Professional CD, or a location on the network that contains the installation files.
A friendly description and associated help text that describes the operating system image to users of the Client Installation wizard.
After the Remote Installation Services Setup wizard completes, depending on the settings chosen, the RIS server either services client computers, or pauses while the administrator configures advanced settings using the RIS administration settings. The section below describes the configuration options available to an RIS administrator.
Remote Installation Services Administration and Configuration Options
By default, a RIS server is not configured to service client computers immediately after the installation of RIS is completed. If the administrator wants to configure the server to service client computers at the completion of RIS Setup, the administrator can simply accept the default configuration settings, and begin offering users operating system installation images without changing a single configuration setting.
RIS provides the administrator with a variety of options and configuration settings. These settings provide flexibility with regard to specific scenarios, such as the type of automatic computer naming policy to use, which Active Directory container client computer accounts are created in, and which operating system images an end user will have access to. For more detail regarding individual configuration options, refer to the RIS walkthrough document in the For More Information section, or check the Remote Installation Services Help on the Windows 2000 Server CD, which is also available on the Windows 2000 Server Web site (http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx).
There are four methods used to configure the available RIS options.
The first method involves specifying which RIS servers are allowed to run on your network. This option prevents unauthorized (often referred to as rogue) RIS servers, ensuring only those RIS servers authorized by administrators can service clients. If an attempt is made to start an unauthorized RIS server on the network, it will be automatically shut down and thus unable to service client computers. A RIS server must be authorized before it can service client computers.
DHCP Manager MMC snap-in
The second method uses the Active Directory Users and Computers snap-in to set properties on individual RIS servers that control how the server supplies Remote Installation Services to requesting clients. This snap-in is available by going to the Start menu, pointing to Programs, then to Administrative Tools, and then clicking Active Directory Users and Computers.. The snap-in that appears is illustrated in Figure 5. Administrators wishing to remotely manage their servers from Windows 2000 Professional workstations can access the administrative tools by installing the Administrator Tools package located on the Windows 2000 Server CD.
Note: When using Administrator Tools on a system other than the RIS server, the administrator cannot add additional operating system images or verify the integrity of the RIS server. All other configuration options are available.
After the RIS server is selected, right click it to open the Properties dialog box, and click the Remote Install tab to access the RIS server configuration options. The Properties dialog box is illustrated in Figure 6.
The following list describes the major configuration options available in the Properties dialog box: for the RIS server
Co-existence of remote installation servers from multiple vendors: For companies that have remote boot and installation servers from other vendors that are operating on the same physical network, RIS servers can be set to respond only to service requests from clients that have been prestaged in Active Directory. When set to ignore boot requests from unknown clients, RIS servers can be introduced into a network without interfering with pre-existing remote installation servers that use the same remote boot protocols.
What clients the RIS server should respond to—These options allow the administrator to specify whether the RIS server should respond to client computers, and if so, whether they should respond when there is no previous knowledge of the client computer in the Active Directory (the client has not been prestaged). Prestaging clients allows for co-existence with remote installation servers from multiple vendors on the same physical network, optional load balancing, and increased security over what systems can perform a remote OS installation. The default settings can also be changed during the Remote Installation Services Setup wizard (RISetup.exe).
Respond to client computers requesting service
Remote Install tab
Do not respond to unknown client computers
Remote Install tab
Automatic client computer naming format—When the client computer name is automatically generated, this option determines how the name should be formatted. Several naming schemes are available, including the ability to use a custom naming format specific to the organization. This option provides flexibility in naming new client computers during operating system installation, without the need for end user or administrator involvement.
Client computer naming format
Advanced settings, New Clients tab
Default Active Directory location for the creation of new client computer accounts—This option allows the administrator to select a default Active Directory location where all remotely installed client computer accounts will be created during operating system installation. The administrator can choose any of the default containers or organizational units (OUs), or create a new OU specific to RIS-installed client computers.
Client account location
Advanced settings, New Clients tab
Available operating system images—This option allows the administrator to add new operating system versions or RIPrep images to existing RIS servers for installation by clients. In addition, administrators can associate a variety of unattended installation templates to CD-based installation images, thus providing greater flexibility in installation options. For example, an administrator may choose to only add a single Windows 2000 Professional CD-based image on the RIS server, but can associate several different scripted unattended installations files, all pointing to the single CD-based image.
OS image list
Advanced settings, Images tab
CD-based Windows 2000 Professional image
Third-party ISV maintenance and troubleshooting tools—Provides administrative staff, and if applicable end users, access to pre-OS maintenance and troubleshooting tools from third-party vendors. These tools can be used to maintain and troubleshoot client computers prior to loading or installing the OS. For example, flashing the system's BIOS prior to OS installation. Other examples include memory virus scanners, computer diagnostic tools, or inventory-based utilities.
Advanced settings, Tools tab
No tools installed
Best practice If automatic setup is the only installation option available to a user (as it is by default), the installation options menu will not be displayed, reducing the likelihood of end user error or confusion.
The third method of configuration involves using Group Policy to specify what installation options are presented to different groups of users during the Client Installation wizard (CIW). For example, it may not be appropriate for users to access the custom setup option or the tools available under the Maintenance and Troubleshooting menu. Rather, an administrator may want to allow normal users access to only the automatic setup option, and restrict access to all other options to administrators or help desk staff.
CIW installation options
Default Domain Policy–User Configuration–Windows Settings– Remote Installation Service
Automatic Setup only for all users in the domain
Best practice To automate the OS image to be installed by certain users, ensure those users have access to only the image that they should install. When only a single image is available, the image selection screen is not displayed and the single available image is automatically selected.
The fourth and final configuration method uses security descriptors, or Discretionary Access Control Lists (DACLs) to specify which users or group of users should have access to the operating system images available on the RIS server. Administrators can use this method to guide users through the selection of the unattended OS installation appropriate for their role within the company. By default, when an operating system image is added to an RIS server, the image will be available to all users serviced by that RIS server.
OS image availability to users in CIW
DACLs on .sif file in the image's template folder
Available to all users
Best practice To reduce the work involved in maintaining the security applied to images, where possible set the security on the templates folder of the image rather than on the individual .sif files themselves, and use user groups to grant and restrict access rather than individual users.
After the necessary RIS configuration options have been set, the administrator is ready to service remote boot-enabled or compatible client computers. An overview of the Client Installation wizard (CIW) is presented in the next section, as well as a description of the available installation options that can be offered to end users. As noted above, in order to request service from an RIS server, client computers can either use a PXE-based remote boot ROM, or a network card that is supported by the RIS remote boot disk.
Client Installation Wizard
Extended characters in the CIW: Because the CIW is running in a pre-boot execution environment, there is no support for extended characters in either the text displayed or the input fields (user name, password, domain, or any custom input parameters). Careful consideration should be taken before creating user or domain names that contain extended characters since they will be not be usable with RIS.
Once the client computer establishes a connection with the RIS server, the user is prompted to initiate a network service boot by pressing the F12 function key. The Client Installation wizard (CIW), illustrated in Figure 7, is then automatically downloaded to the client computer. The user is prompted to enter their user name, password, and domain. After authenticating the user in Active Directory, the CIW optionally provides the end user or IT administrator with the ability to select from a menu of installation options and operating system images to control how and which operating system image will be installed. If the user running the CIW has only been granted access to the Automatic installation option and a single operating system image, neither menu is displayed, and the user proceeds directly to the confirmation and summary screens.
The following installation options are included in the Client Installation wizard. Automatic setup is available by default. RIS uses Group Policy settings to allow access to the automatic setup option only, and to restrict all users and administrators from the rest of the installation options described below.
To control the setup options displayed to users in the CIW, use Group Policy as described in the "Administration and Configuration Options" section.
Automatic Setup—This option provides the easiest operating system installation path. It allows the user to choose which operating system to install, but does not prompt the user for specific configuration settings. If only one operating system option is offered, the user is not prompted, and an unattended installation of the operating system image starts automatically.
Custom Setup—This option allows the user running the CIW to override the automatic computer naming process, as well as the default location within the Active Directory where client computer accounts will be created. Help desk or administrators can use this option to pre-install a client computer for someone else within the enterprise.
Restart a Previous Setup Attempt—If selected, this option automatically restarts the operating system installation process when an installation attempt fails before completion. This option does not copy files from where the previous installation attempt failed, however the user is not required to answer any questions answered within the CIW from the previous setup attempt.
Maintenance and Troubleshooting—This option provides access to third-party maintenance and troubleshooting tools that can be used before operating system installation. Examples of these tools include system flash BIOS updates, computer diagnostic tools, and virus scanning utilities. See the For More Information section for ISV and OEM vendors that provide utilities for use with RIS.
If the user has more than one operating system image available to them for installation, the list of images is displayed for selection. The user is then presented with confirmation and summary screens, after which the installation of the image on the client computer begins immediately.
The screens and text displayed in the CIW can also be customized, and additional screens can be displayed to the user if desired. For example, if users must enter a specific configuration parameter during the CIW, a custom screen can be created and linked to those already displayed. Such parameters can then be passed to the .sif file of the selected operating system installation image. For more information on customizing the CIW screens, see the Windows 2000 Server Resource Kit (available in Microsoft TechNet).
Remote Installation Preparation Wizard
Note: See the "Remote OS Installation Usage Scenarios" section later in this document for details on how to combine the Windows 2000 Group Policy and Software Installation and Maintenance features with Remote OS Installation to create standard desktop images that include applications.
There are two types of operating system images supported by Remote OS Installation: CD-based images and RIPrep images. The CD-based option is similar to setting up a client operating system directly from the Windows 2000 Professional CD, but in this case, the source files reside on an RIS server. However, more companies are beginning to implement a corporate standard desktop policy. This policy requires that users install only approved versions of an operating system and associated applications or application suites. These desktop standards have a variety of names, such as Standard or Common Operating Environments (SOEs or COEs), but all usually involve packaging the operating system, required service packs, a set of applications, and appropriate operating system and application configuration settings into a single, tested, and supported unit.
In order to build and maintain standard desktops, many companies use disk imaging or cloning software that allows an administrator to configure a client computer exactly how he or she wants it, following company standards and software policies, and then make a copy of that image for installation on client computers on the network. Remote OS Installation supports creation and installation of standard desktop images using the RIPrep feature.
One of the biggest limitations in most imaging technologies is the requirement that the destination computer (the computer that will receive the image) contain identical hardware to that of the source computer used to create the image.
An important element of the RIPrep feature is the fact that the destination computer (the computer that installs the image posted to the RIS server) is not required to contain hardware identical to that of the source computer that was used to create the image. RIPrep uses the Plug and Play support in the computer running Windows 2000 Professional to detect differences between the source and the destination computers' hardware during image installation. The exception is that the hardware abstraction layer (HAL) drivers must be the same between the source computer and all destination computers that later install the image. However, in most cases, workstations do not require the unique HAL drivers that servers require. The primary difference in HAL drivers for workstations is whether systems contain Advanced Configuration Power Interface (ACPI) support versus a non-ACPI supported computer. When using RIPrep, you must create and maintain separate installation images for systems that have ACPI or other features that require the use of specific HAL drivers, but other hardware differences, such as video or disk controllers, can be automatically accommodated for hardware compatible with Windows 2000.
Note: If the source computer contains a 1 gigabyte (GB) disk drive and the destination computer contains a 2-GB disk drive, by default RIS will format the destination computers drive as a 2-GB partition in the same file system format as the source computer used to create the image.
The Remote Installation Preparation wizard (RIPrep.exe), which is part of the Remote OS Installation feature, is illustrated in Figure 8. The RIPrep wizard provides the combined ability to prepare an existing Windows 2000 Professional installation for use as an image to be installed on other computers, including any locally installed applications and/or specific configuration settings, and to replicate that image to an available RIS server on the network. The RIPrep feature currently supports replicating a single disk-single partition (C partition only) Windows 2000 Professional installation to an available RIS server. This means that the operating system and all of the applications that make up the standard installation must reside on the C partition prior to running the RIPrep wizard.
Creating the Source Computer
To create the source computer, the administrator first uses the Remote OS Installation feature to remotely install the base Windows 2000 Professional operating system. Once the operating system is installed, the administrator can install applications or application suites including in-house line of business (LOB) applications. The administrator then configures the workstation to adhere to company policies. For example, the administrator may choose to define specific screen colors, set the background bitmap to a company-based logo, remove any games installed by the base operating system, and set Internet Explorer proxy settings.
Configuring the Workstation
When creating RIPrep images, it is important to understand the relationship of user profiles, the changes made to a RIPrep source computer, and the desired result for users that log on to computers that are installed using the RIPrep image. Windows 2000 Logo-compliant applications properly separate user-specific and computer-specific configuration settings and data, and can therefore be installed computer-wide so that they are available to all users of the system. Such applications would also then be available to all users of systems later installed with the resulting RIPrep image. Non-Windows 2000-compliant applications may perform and/or rely on per-user configurations that are specific to the profile of the user actually installing the application prior to running RIPrep (typically a local administrator), rather than to all users of the system. Such configurations remain specific to that user, which may result in the application or configuration setting not being available or not functioning properly for users of computers installed with the RIPrep image. In addition, some non-application configuration changes, such as the wallpaper specified for the user desktop, are by default applied only to the current user's profile, and will not be applied to users of systems installed with the RIPrep image.
Therefore, you must thoroughly test any applications or configuration settings desired for use in a RIPrep image to ensure they will work properly with your organization's implementation of user profiles. To do so, make the change as one user (typically a local administrator of the computer), log off, and log on as a user account that is representative of your organization. If the changes you made are applied to the second user, the changes should also apply to users that log on to systems installed with a RIPrep image that contains the same change. To complete the test, create a RIPrep image, restore it to a different computer, and log on as a different representative user. Verify that the changes are applied and fully functional.
Some configuration settings can be copied directly from the profile they were applied to (the local administrator in the above example) to the All Users profile, such as the desktop wallpaper, some Start menu options, and shortcuts. However, all such changes must be tested carefully to verify that their functionality is not broken by the manual adjustments.
Running the Remote Installation Preparation Wizard
Once the workstation is configured exactly the way the administrator likes, they are ready to run the Remote Installation Preparation wizard.
The RIPrep wizard starts by prompting the administrator for specific settings relating to the image they are about to post on the RIS server. The administrator is asked where the image should be replicated, that is to which RIS server, and to provide a directory name on the RIS server where the image should be replicated. The wizard prompts the administrator to provide a friendly description and associated Help text describing the contents of this image to end users running the Client Installation wizard. After the initial image questions have been answered, the wizard configures the workstation to a generic state, removing anything unique to the client installation such as the computer's unique security ID (SID), computer name, and any registry settings unique to that system. Once the preparation phase is complete, the image is automatically replicated to the RIS server provided. After the image is replicated to the RIS server, it is added to the list of available OS installation choices displayed within the CIW. At this point, any remote boot-enabled or compatible client computers that use the PXE-based remote boot technology can install the image.
Remote Installation Services Boot Disk
There are two types of remote boot-enabled client computers:
Computers with PXE-based remote boot ROMs.
Computers with network cards supported by the Remote Installation Boot Disk.Figure 9: The remote boot disk generator
The RIS remote boot disk generator (Rbfg.exe), illustrated in Figure 9, can be used to create a boot disk to support existing client computers that do not have a PXE-based remote boot ROM, but that do have a supported network adapter. Using the RIS boot disk eliminates the need to retrofit existing client computers with new network cards that contain a PXE boot ROM in order to take advantage of the Remote OS Installation feature. The RIS boot disk simulates the PXE remote boot sequence, and supports frequently used network cards. The RIS boot disk works like the PXE boot process: turn on the computer, boot from the RIS boot disk, press F12 to initiate a network service boot, and the Custom Installation wizard (CIW) is downloaded and starts. Once the CIW starts, the rest of the RIS process is identical regardless of whether the client was booted using a PXE boot ROM or the RIS remote boot disk. For the complete listing of network cards currently supported by the RIS boot disk, see Appendix B.
Using Remote OS Installation in an Organization
Companies today have a variety of operating system deployment and installation mechanisms in place. This section explains how you can use the Remote OS Installation feature in addition to existing deployment mechanisms to further reduce the costs associated with OS and application deployment.
The following list of scenarios cover the majority of these deployment mechanisms in use today:
Manual (attended) OS installation using a CD-ROM.
Automatic (unattended) OS installation using a server share.
Third party OS plus application imaging technologies.
Manual (Attended) OS Installation Using a CD-ROM
This scenario is one of the most expensive mechanisms for deploying an operating system within an organization. Many companies today send a technician to the user's desk to perform an OS installation using a CD-ROM. Or the technician pre-installs the computer before it's delivered to the end user. This installation type is manual in nature, requiring a technician to physically visit the end user, and manually install the operating system. The technician must be skilled enough to answer technical questions during the installation, specifically regarding the hardware contained within the computer. The cost associated with just one computer installation using this method varies from approximately $180.00 to more than $300.00 depending on the success or failure of the installation process, and can result in variance from corporate standards for system configurations.
By setting up a single Windows 2000-based RIS server, a company can reduce the costs associated with this deployment method and ensure standardization of client computers. RIS can be used to reduce the costs associated with this OS deployment method in these two ways:
First, the technician would use RIS to initiate an unattended installation of the Windows 2000 Professional operating system over the network using either the built in remote boot capabilities of the computer, or by using the easy to create RIS boot disk. By employing RIS, the company reduces the time required by the technician, as well the required skill of the technician needed to install the OS. The technician would not be required to carry around the CD and boot disks, and since the installation is fully unattended, the technician could initiate the OS installation, and then move on to the next user.
As another option, the company could choose to forgo the necessity of the technician altogether by allowing the end user to install the OS on their own computer. As noted above, the administrator can guide the user through the correct OS selection, or choose an OS image to be selected for installation automatically when the user logs on to the Client Installation wizard. If the end user need only press F12, enter their username and password, and then press ENTER, substantial costs can be avoided when deploying the operating system company wide.
Automatic (Unattended) OS Installation Using a Server Share
This deployment mechanism involves the creation of a boot disk containing, in most cases, a copy of the MS-DOS® operating system, a network card driver specific to the computer being booted, and networking software that connects the computer to a network server share containing the OS installation files. This mechanism is also very costly, and requires a substantial amount of technical knowledge, and understanding of the hardware in use throughout the company.
By adding a RIS server to the mix, the technician can use the RIS boot disk, which is created with a single click by the administrator or end user. The RIS boot disk supports a variety of network cards in use today. You can use the RIS boot disk with computers that contain supported PCI-based network adaptors. The RIS boot disk does is not MS-DOS-based, and does not require specific MS-DOS-based networking software to connect to an available RIS server. Rather, the RIS boot disk simulates the PXE boot ROMs described earlier in this paper, and all necessary network card drivers are contained within the single RIS boot disk.
No longer will a technician have to create NIC-specific LAN-enabled boot disks, configure an MS-DOS-based boot disk with regard to conventional memory management, or configure networking settings specific to the organization or division. If your company already uses DHCP and TCP/IP, there is nothing more that needs to be configured to implement Remote OS Installation. Add to this the ability of the administrator to offer base CD unattended installations and/or fully populated RIPrep images that include applications and configuration settings, and you can see the cost saving potential.
Third Party OS Plus Application Imaging Technologies
Many companies have switched to implementing image-based OS deployment technologies. Companies are investing a substantial amount in the creation of hardware specific images that contain both the OS and applications used within the company. There are several third party imaging vendors that provide solutions for deploying the Microsoft Windows family of operating systems. These technologies can be less expensive, require less time to install, and in some cases, require less technical expertise than the deployment methods listed above. In some cases, companies actually perform hardware-based drive duplication, where the hard disk of the source computer is duplicated with a hardware disk duplicator. The resulting hard disk is then installed in a computer and shipped directly to the end user. Other companies can use the existing network for image replication from the source computer to the destination, using a form of boot disk that loads and connects to the network.
All of the imaging technologies available today require that the destination computer (the computer that will install the image) contain the exact same hardware as the source computer used to create the image. These technologies also require in most cases the use of an MS-DOS-based boot disk, which requires some knowledge of the network card hardware in existing computers. By using the RIPrep component of Remote OS Installation, companies can create a single image, and deploy that image across different types of computer hardware within the company. If the existing computers within your organization do not contain a compatible PXE boot ROM, the RIS boot disk can be used to initiate the installation of the RIPrep image.
Given the substantial investment in existing images, Microsoft is working with several of the third party imaging companies to provide integration support that will allow using the existing OS images with RIS. For more information on which vendors are integrating with RIS, see the For More Information section.
The following examples show how Remote OS Installation can reduce costs and increase productivity in an enterprise environment. The scenarios below may be useful in determining the best way to use the Remote OS Installation feature within your organization if you do not already have an OS deployment mechanism in place. The section below will cover the following scenarios:
Fresh OS Installation on new or existing computers.
Disaster OS recovery.
Pre-installing vs. prestaging.
Using Client Installation wizard options.
Remote OS Installation Usage Scenarios
Scenario 1: New or Existing Computers: A Fresh OS Install
When companies order a computer from an original equipment manufacturer (OEM) or independent hardware vendor (IHV), the computer arrives pre-installed with an operating system. In many cases, the installed OS violates the company's standard desktop policies. As a result, many companies erase the existing OS, and install a version that meets their corporate desktop standards. Companies might also have existing computers on which they want to install a new operating system, and avoid the upgrade process altogether.
Net PC and PC98-compliant computers support the DHCP-based PXE remote boot technology. You can use this technology to install the new OS image on these computers. For pre-Net PC/PC98 computers, the Windows 2000 Server operating system includes a remote boot disk generator that creates a floppy disk, which simulates the PXE remote boot ROM.
Remote OS Installation is configured to install the Windows 2000 Professional operating system by first repartitioning and formatting the hard disk. Once the repartition and format are complete, the operating system is installed in an unattended manner. The administrator can create customized, unattended .sif files that perform OS installations with different settings and features based on specific organization or company standards. For example, a company may require its sales teams to install their computers with only the TCP/IP protocol, yet allow the finance department to install both the TCP/IP and the IPX/SPX protocols due to their in- house accounting system. By using two types of unattended .sif files, the administrator can use a single CD-based operating system image for two different types of OS installations.
RIS also provides the ability to install a RIPrep-based OS image, complete with locally installed applications and configuration settings that the administrator has determined meet the company's desktop standard. The administrator first uses Remote OS Installation to install a client computer with the base Windows 2000 Professional operating system. Then they can install the application or full application suite, and any line of business applications specific to the company or division. The administrator may customize the installation to include a company specific background bitmap, and links on the desktop to relevant corporate resources. After the administrator tests the installation to ensure everything works and is compliant, they then replicate that installation (only a single disk/single partition is supported) to an available RIS server on the corporate network.
Once the OS image replication completes, it is now available for installation by any user the administrator has determined should have access to install that image.
Scenario 2: Disaster OS Recovery
At times, the hardware in a computer may fail beyond repair. In this situation, Remote OS Installation provides the ability to quickly and easily re-install the base operating system or RIPrep image on a computer that has failed completely. By combining the IntelliMirror technology, another change and configuration management feature of the Windows 2000 Server operating system, with the Remote OS Installation feature, a company can recover a large percentage of the entire user and computer configuration and data, including the user's personal data and settings. Once a new hard disk has been placed in the computer, the administrator or end user can initiate Remote OS Installation to install the base OS, or a RIPrep image complete with a base set of applications. After the image installation completes, the user logs on to the computer. At this point, any applications assigned to the user by the software installation and maintenance feature of IntelliMirror are available, as they were prior to the failure. Other Group Policy settings will be re-applied, the user's roaming profile is copied to the computer from the network, and user documents stored in a redirected My Documents folder are made available from the network. By separating the user state from the computer state, in a matter of minutes, the end user is up and running with everything they had prior to the hard disk failure, without the need for a help desk professional to re-install the operating system and the user's applications, and restore data from a backup.
Scenario 3: Pre-installing vs. Prestaging
Many companies today pre-install their client computers with an operating system before delivering the computer to the end user. Pre-installing the computer means that they have loaded the operating system and possibly applications, and have configured the system to meet company standards, before delivering to users. Pre-installation of the operating system by IT staff is a costly process, and increases the company's total cost of ownership. However by pre-installing, the administrator can manually enter a unique computer name and choose the specific Active Directory container the computer account will be created in. The administrator can use the RIPrep feature to install the OS and applications prior to delivery of the system.
Prestaging a computer account, on the other hand, is the process of creating a valid computer account object within the Windows 2000 Active Directory directory service. Prestaging a computer for use with Remote OS Installation allows the administrator the ability to deliver a blank computer directly to the user for OS installation. By prestaging the computer account in Active Directory, the administrator can configure the RIS servers to only respond to prestaged computers. This ensures that only those computers that have been prestaged as Authorized users are allowed to install an operating system from the RIS server. Prestaging can save both time and money by reducing, and in some cases eliminating, the need to fully pre-install the computer.
By prestaging the client computer, the administrator can define a specific computer name, and optionally, which RIS server will service the client computer. In order to prestage a client computer within Active Directory for use with Remote OS Installation, the administrator should follow the steps below.
To pre-stage a client computer
Locate the container in the Active Directory service in which you would like your client computer accounts to be created.
Right click the container, and then click New, and then Computer. The New Object-Computer dialog box appears, as illustrated in Figure 10.Figure 10: Pre-staging a client computer
Enter the computer name and authorize domain join permissions for the user or security group containing the user that will receive the physical computer this computer account represents.
In the next dialog box, illustrated in Figure 11, you are prompted for the GUID/UUID of the computer itself, as well as whether you intend to use this computer as a managed (Remote OS Install-enabled) client. Enter the GUID/UUID and select the This is a managed computer check box.
The GUID/UUID is a unique 32-character number that is supplied by the manufacturer of the computer, and is stored within the system BIOS of the computer. It should be posted on the case of the computer, or on the outside of the box it was shipped in. If not, locate the GUID by unpacking the computer and running the system BIOS configuration utility. The GUID should be stored as part of the system BIOS. Contact your OEM for a Visual Basic® Scripting Language (VBScript) that can be used to prestage newly purchased client computers within Active Directory for use with Remote OS Installation.
The next screen prompts you to indicate which RIS server this computer should be serviced by. This option can be left blank, which indicates that any available RIS server can answer and service this client computer. You can use this option to manually load balance clients across the available RIS servers within your organization, as well to segment the network traffic, if you know the physical location of the specific RIS server and where this computer will be delivered. For example, if a RIS server was located on the fifth floor of your building, and you are delivering these computers to users on that floor, then you could choose to assign this computer to the RIS server on the fifth floor.
Scenario 4: Creating Standard Desktops with RIPrep and Software Installation and Maintenance
If an Administrator wants to use Remote OS Installation to stage and standardize their computers, then they can consider installing the organization's key software at the same time.
The best way to describe this is to provide an example. Consider an organization that wants to bring in new computers, and customize both the Windows 2000 operating system and the Office 2000 suite of applications.
The administrator has Remote OS Installation set up and configured, and has the Software Installation and Maintenance feature of IntelliMirror configured. That is, there are existing Group Policy objects to manage the computers in the organization. The administrator has a Software Distribution Point for Office 2000, they have customized Office 2000, and then they have assigned Office 2000 to the computers in the appropriate GPOs. (For more information on how to do this, reference the Windows 2000 Software Installation and Maintenance Walkthrough listed in the For More Information section.)
Note: Care must be taken to configure the RIPrep source computer with applications from the same GPOs that apply to the destination computers (those that will install the RIPrep image) when they are deployed. The applications may be removed or removed and reinstalled if a different policy is applied to the computer when it is deployed.
The administrator installs the Windows 2000 operating system on a computer (that has the same HAL as the desired target systems), and configures the operating system the way that they want it. When Windows 2000 is installed and configured, the administrator adds it to the same Active Directory container where it will live when it is deployed. This container has a GPO with Office 2000 assigned to the computer.
The administrator starts the computer, and the Software Installation and Maintenance technology in IntelliMirror installs Office 2000 (applications assigned to the computer install when the computer starts).
After Office 2000 is installed, the administrator can take the computer running Windows 2000 with Office 2000 installed on it, and use the RIPrep tool of Remote OS Installation to build a Remote OS Installation image, and put this image on the Remote OS Installation server. Once this image is available, a person getting a new computer that supports Remote OS Installation only has to connect the peripherals (keyboard, mouse, monitor), connect to the network (plug a cable between the network card and the hub), turn on the computer, and press F12 when prompted to initiate a network boot.
The computer finds the Remote OS Installation server; download the operating system and the applications. When the computer restarts after remotely installing the OS, Windows Installer realizes that the software is already on the machine, and then only updates the application's advertisement information. This update of the advertisement information only takes a few seconds.
Note that when the user logs on to the computer, and selects the first Office 2000 application, the Windows Installer starts. Why is this? Office 2000 separates installation from user configuration to ensure proper separation between user-specific and machine-specific configuration. The Windows Installer starts each time a new user starts the application, in order to perform a small amount of user-specific configuration.
The key point is that Remote OS Installation and Software Installation and Maintenance allows administrators to rapidly and efficiently deploy both the operating system and applications, and still bring the applications into a state where they can be managed by Software Installation and Maintenance for future updates, and if necessary, removal.
Using the Client Installation Options
Using the Automatic Setup Option
The automatic setup option is the client installation option that all users of the Remote OS Installation feature have access to by default. The automatic setup option can be used to guide the user through a successful OS installation. The administrator is able to restrict the OS installation options in such a way that the user simply logs on, and the OS installation starts automatically. The user is not asked a single question during the OS install, which avoids lengthy calls to help desk professionals for assistance, thus saving the company additional expenses in support costs.
If the administrator decides, they can provide the user with multiple unattended OS choices. Remote OS Installation allows the administrator to provide a friendly description and associated help text that describes the OS options in such a way that an end user can choose the OS that best fits their need or role within the company. For example, the administrator can create several unattended answer files that install an OS tailored for the marketing users within the company. Each of the OS types provides a different subset of OS features given a specific type of marketing user. The administrator would restrict these OS types to only the marketing security group which ensures that only users that are members of that marketing security group are offered these OS choices. Now, the end users have a variety of OS installation types to choose from, but are able to make the choice based on the friendly description and help text provided when selecting each of the OS choices.
By pre-selecting the Remote OS Installation configuration options, the administrator predefines the automatic machine naming format and the location within Active Directory where client computer accounts will be created. IT staff will no longer have to manually preinstall computers for end users, ensuring that the computer account is created within the correct domain, or with the correct computer name. The administrator can simply define these attributes for a given RIS server and everything is done automatically during OS install.
By default, end users are restricted to only see the automatic setup option by the settings in the Default Domain Policy Group Policy object. If necessary, the administrator can modify the settings in the Default Domain Policy, and/or create additional group policy objects that allow end users access to the other installation options. For more information, see the Windows 2000 Help regarding Group Policy settings.
If you choose to offer end users multiple OS installation types, ensure the number offered is relatively small (a maximum of 3-5 is suggested). This will help to avoid confusion, and will assist in ensuring that end users select the OS that best meets their need and role within the company.
Group individual end users into security groups and use those groups to restrict the available OS installation options. Setting permissions for individual users on the individual setup information files (.sif) can become an administrative burden. Instead, use security groups to restrict the choices and where possible apply security on the Templates folder itself (which will apply to all .sif files in the folder) rather than on the individual .sif files.
Using the Custom Setup Option
The custom setup option is very similar to the automatic setup option, yet provides the administrator or help desk professional with the ability to set up a computer for someone else within their organization. This option can be used to fully pre-install a client computer or to prestage the client computer by creating a corresponding computer account within the Active Directory service. This setup option in many cases will only be used when the IT or help desk professional must perform the initial setup or re-installation of an end user's computer.
The custom setup option lets the administrator or help desk professional override the automatic computer naming and where the computer account is created within Active Directory. By default, the RIS server will generate a computer name based on a format defined by the Remote OS Installation administrator. The administrator can also define where client computer account objects (CAO) will be created in the Active Directory service during the operating system installation. By default, the automatic computer naming policy is set to create computer names based on the person who logs on to the Client Installation wizard.
In the case where an administrator or help desk professional is pre-installing the OS on the computer for someone else within the organization, it may not be appropriate to name the computer after the help desk staff. In that case, the staff person would be provided access to the custom setup option through Group Policy, and would be offered the ability to override the automatic computer name and default Active Directory location.
The custom setup option also gives an administrator or help desk professional the ability to prestage the client computer. Prestaging a client computer simply creates a corresponding computer account object within the Active Directory for that computer. Once the computer account has been prestaged, the administrator is assured that this is an authorized Known client computer that can be serviced by any available RIS server. Prestaging a computer account using the Client Installation wizard is done by entering all the information necessary to perform the installation, which results in the CAO being created, but canceling the CIW just prior to the actual OS installation starting.
Note: The simplest way to prestage a group of client computer accounts for use with Remote OS Installation is by using the VBScript provided by Microsoft to system vendors. The script uses a Microsoft Excel spreadsheet containing the required information to prestage client computers for use with RIS. When placing orders for computers that you want to prestage, contact your system vendor to request this script and a copy of the spreadsheet pre-filled with the GUIDs of the new systems you will be receiving.
If users are allowed to perform their own OS installations using Remote OS Installation, the custom setup option will not typically be used so that the standards defined for computer naming and location will always be followed. However, in cases where an IT or help desk professional must visit the end user, or perform a manual installation of the OS, the custom setup option can be used as appropriate.
Use custom setup if your company has a policy that requires that all computers are preinstalled with an OS prior to delivery to end users. The Remote OS Installation feature should provide the ability to avoid pre-installs, but if it is company policy to do so, the custom setup option is provided.
Using the Restart a Previous Setup Attempt Option
The option to restart a previous setup attempt is provided in the event that the installation of the OS fails for any reason. The Client Installation wizard can be customized to ask a series of questions about the specific OS being installed. For example, if an administrator wants to create a version of the Client Installation wizard that asks the user which type of protocols should be installed, which video resolution, and what the specific company name was, when restarting a failed OS setup attempt, the end user would not be asked these questions again. Rather, Setup would already have this information, and would simply restart the file copy operation and complete the OS installation.
Restarting a previous setup attempt does not restart the OS installation at the point where it failed. Rather, this option restarts the OS installation over from the beginning of setup.
This option may not be appropriate to offer to end users. This option will not attempt to fix any problems that occurred with the previous setup attempt and as such should be used as a Remote OS Installation troubleshooting option for IT or help desk staff.
Using the Maintenance and Troubleshooting Option
The Maintenance and Troubleshooting tool provides access to third party hardware and software vendor tools. These tools range from system BIOS flash updates and memory virus scanners, to a wide range of computer diagnostic tools that check for hardware related problems. These tools are available before installing and starting the operating system on the client computer.
If the options to display the Maintenance and Troubleshooting Tools menu is enabled by Group Policy, user access to individual tool images is controlled in the same way as operating system options, by setting specific end user permissions on the individual answer file (.sif) for that tool. For example, the Remote OS Installation administrator can allow end users access to only one computer diagnostic tool, yet provide help desk professionals with access to the entire suite of diagnostic tools. When the user calls a help desk professional for assistance, the professional can guide them through the diagnostic tool for retrieval of information necessary to diagnose the problem being encountered. If the help desk staff must visit the end user for further investigation, they simply log on to the Client Installation wizard and, based on their credentials, can access the tools they need to resolve the problem.
The maintenance and troubleshooting option may not be appropriate for end users. Make sure that if you allow access to this installation option, that you provide only those tools that cannot damage the computer or cause further problems.
See the For More Information section for details on vendors working on RIS-enabled maintenance and troubleshooting tools. If you do not see the vendor of a tool you use listed, contact the vendor directly.
The Remote OS Installation feature is one of the many features in the Windows 2000 Server operating system that helps reduce the costs associated with deploying a new version of an operating system throughout an enterprise. The Remote OS Installation feature provides an administrator with a number of options that both simplify and streamline the process of rolling out a new version of an operating system, and ultimately reduce the total cost of ownership.
For More Information
For the latest information on Windows 2000 Server, check out Microsoft TechNet or the Microsoft Windows 2000 Web site (http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx).
You can find the latest copy of the Remote OS Installation Walkthrough (http://www.microsoft.com/windows2000/docs/RemoteOS.doc), used to install, configure and use the Remote OS Installation feature on the Microsoft Windows 2000 Web site.
For information on the IntelliMirror Management features, and for a complete listing of the associated Walkthrough documents, please see Management Services (http://www.microsoft.com/windows2000/technologies/management/default.asp) on the Microsoft Windows 2000 Web site.
For more details on individual Remote OS Installation configuration settings, please see the Windows 2000 Documentation (http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx), Product Help, which can be found on the Windows 2000 Web site (http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx), and search for Remote Installation Services.
Several vendors have announced products or product plans for utilities that integrate with Remote OS Installation. For more details on tools compatible with the Maintenance and Troubleshooting option, search for integration papers on the Windows 2000 Web site under Management Services (http://www.microsoft.com/windows2000/technologies/management/default.asp).
Appendix A: Hardware Requirements
Remote Installation Server and Workstation Hardware Requirements
Server Hardware Requirements
Pentium or Pentium II 166 MHz (200 MHz or larger processor recommended).
64 MB Ram minimum. If additional services such as Active Directory, DHCP, and DNS are installed, then the minimum amount of RAM required is128 MB.
2 GB hard disk dedicated for the Remote Installation Service directory tree.
10 or 100 mbps network adapter card (100mbps preferred)
Note: A partition separate from the system's boot partition is required to install the Remote Installation Services. To accommodate the operating system installation images, you may want to dedicate an entire hard disk specifically to the RIS directory tree.
Client Hardware Requirements
Pentium 166MHz or faster processor.
32 MB Ram minimum.
800 MB hard disk drive.
Supported PCI Plug and Play network adapter card. (See Appendix B for supported network cards for use with the RIS boot disk.)
Optional: PXE-based remote boot ROM version .99c or later.
Appendix B: Network Cards Supported by the RIS Boot Disk
The following is a list of network card models that are supported by the RIS boot disk. The boot disk generator tool is available within the \Admin\i386 Subdirectory under the \Remoteinstall directory and is called Rbfg.exe.
Network Cards Supported by RIS Boot Disk:
3 Com Network Adapters:
3c900 (Combo and TP0)
3c900B (Combo, FL, TPC, TP0)
3c905 (T4 and TX)
3c905B (Combo, TX, FX)
AMD Network Adapters:
AMD PCNet and Fast PC Net
Compaq Network Adapters:
Netflex 100 (NetIntelligent II)
Netflex 110 (NetIntelligent III)
Digital Equipment Corp (DEC) Network Adapters:
Hewlett Packard Network Adapters:
HP Deskdirect 10/100 TX
Intel Corporation Network Adapters:
Intel Pro 10+
Intel Pro 100+
Intel Pro 100B (including the E100 series)
SMC Network Adapters:
Note: The RIS boot disk generator only supports PCI-based network cards (ISA, EISA, and Token Ring cards not supported).
Appendix C: Frequently Asked Questions
Question: How do I know I have the correct PXE ROM version?
Answer: When the Net PC or client computer containing a remote boot ROM starts, the PXE ROM message appears on the screen. You should see which version of the PXE ROM code is displayed during the boot sequence of the client computer. Windows 2000 RIS supports .99c or later PXE ROMs, except in very few situations that will require the .99L version. You may be required to obtain a newer version of the PXE-based ROM code from your OEM in the event you are not successful with the existing ROM version installed on a client computer.
Question: How do I know if the client computer has received an IP address and has contacted the RIS server?
Answer: When the client computer starts, you see the PXE boot ROM begin to load and initialize. The following sequence occurs with most PC98 and Net PCs, PXE ROM-based computers, and computers using the RIS boot disk:
Remote boot ROM load sequence:
Step 1: The client computer displays the message DHCP. This message indicates the client is requesting an IP address from the DHCP server. This may also indicate the client has obtained an IP address from DHCP and is awaiting a RIS server response. To verify if the client is receiving an IP Address, you can check the IP leases that have been granted on your DHCP server.
Troubleshooting: If the client does not get past the DHCP message it may mean the client is not receiving an IP address or that the BINL server is not responding, things to check are:
Is the DHCP server available and has the service started? DHCP and RIS servers must be authorized in Active Directory in order for their services to start. Check to ensure the service has started and other non-remote boot-enabled clients are receiving IP addresses on this segment.
Does the DHCP server have a defined IP address scope and has it been activated?
Is there a router between the client and the DHCP server that is not allowing DHCP packets through?
Are there any error messages in the event log under the System Log for DHCP?
Can other client computers—that is non-remote boot-enabled clients—receive an IP address on this network segment?
Step 2: When the client receives an IP address from the DHCP server, the message may change to BINL. This indicates the client successfully leased an IP address and is now waiting to contact the RIS Server. The client computer will eventually timeout, and post the error message "No Bootfile received from DHCP, BINL, or Bootp"
Troubleshooting: If the client does not get past the BINL message it means the client is not receiving a response from the RIS server. Things to check are:
Is the RIS server available and has the BINL (BINLSVC) service started? RIS servers MUST be authorized to start on the network. Ensure the RIS servers are authorized to run on the network. Use the DHCPMGMT.MSC snap-in to authorize both DHCP and RIS servers within the Active Directory.
Are other remote boot-enabled clients receiving the Client Installation wizard? If so, this may indicate this client computer is not supported or is having remote boot ROM-related problems. Check the version of the PXE ROM on the client computer. Also check in Active Directory to see if the administrator has prestaged this client computer to a specific RIS server that may be offline or unavailable to the client computer.
Is there a router between the client and the RIS server that is not allowing the DHCP-based requests/responses through? The RIS server communicates using the DHCP packet type during the initial service request/response sequence. You may need to configure the router to forward the DHCP packets.
Are there any error messages in the event log under the System or Application logs specific to RIS (BINLSVC), DNS, or the Active Directory?
Step 3: The client will then change to TFTP or will prompt the user to press the function key, F12. This means that the client has contacted the RIS server and is waiting to TFTP the first image file, which is the Client Installation wizard. You may not see the BINL and TFTP message, because on some computers this sequence simply flashes by too fast.
If the client computer does not get a response from the RIS server, the client computer will timeout, and displays an error message saying that it did not receive a file from DHCP, BINL, or TFTP. In this case, the RIS server did not answer the client computer. Things to check are:
Stop and restart BINLSVC on the RIS server. On the Start menu, click Run, and then type CMD. In the CMD window, type:
Net Stop BINLSVC Net Start BINLSVC
Check the RIS server properties to ensure that the Respond to Known client computers option is checked, and that the Do not respond to Unknown client computers is not checked, unless you have prestaged the client computers in the Active Directory prior to starting the client computer.
Check in the event log to ensure no errors relating to DHCP, DNS, RIS (BINLSVC), and/or the Active Directory exist.
If the client computer does not receive an answer after attempting to stop and restart the service, and after checking the properties of the RIS server to ensure the correct settings have been set, you should check the Event Log on the RIS server for any errors relating to DHCP, DNS, or RIS (BINLSVC). If possible, capture the network activity between the server and the client with a network sniffer, and you can provide the Microsoft Product Support Services with this information.
Step 4: At this point, the client should have downloaded the Client Installation wizard, and been greeted with the Welcome page.
Question: Does Remote OS Installation support the older remote boot protocol Remote Program Load (RPL)-based ROMs?
Answer: The Remote OS Installation feature uses the new PXE DHCP-based remote boot ROMs. As such, there is no support in the Windows 2000 operating system for the older RPL-based remote boot.
Question: Does Remote OS Installation support remote installation of Windows 2000 Server CD-based or RIPrep OS images?
Answer: No. Remote OS Installation does not support remotely installing Windows 2000 Server.
Question: Does Remote OS Installation support remotely installing an OS image (RIPrep or CD Based) on laptop computers?
Answer: Yes and No. Remote OS Installation has been tested with laptop computers in docking stations that support the required PXE ROM code, and with laptop computers in docking stations that contain NICs supported by RIS boot floppy. The systems must be located within the docking station with the network cable plugged into the network adapter located with the docking station. The Toshiba Protégé 7010CT and Tecra 8000 are examples of laptops that support the PXE boot ROM when used with the Toshiba NetDock (docking station). In order for these systems to function with RIS, they require the 99L or later version of the PXE ROM code for the specific network card located within the NetDock.
RIS does not support laptop computers that contain PC Card or PCMCIA network cards.
Question: Is the pre-boot portion of the PXE remote boot ROM secure?
Answer: No. The entire ROM sequence and operating system installation/replication is not secure with regard to packet type encryption, client/server spoofing, or wire sniffer based mechanisms. As such, use caution when using Remote OS Installation on your corporate network. Ensure that you only allow authorized RIS servers on your network, and that the number of administrators allowed to install and/or configure RIS servers is controlled.
Question: Can RIPrep-based OS images be replicated to alternate media such as DVD, CD, and/or Zip drives?
Answer: No. In a Windows 2000-based system, you can only replicate the source image to a single available RIS server on the network.
Question: Does Remote OS Installation preserve the file attributes and security settings defined on the source computer when using the RIPrep image feature?
Answer: Yes. The file attributes and security settings that are defined on the source computer will be preserved on the destination computer that installs that image. However, be aware that the RIPrep feature does not support the encrypted file system if enabled and used on the source client computer.
Question: Does the RIPrep feature support different hardware between the source computer used to create the RIPrep-based OS image and the destination computer that will install the image?
Answer: Yes. The hardware between the source computer and the destination computer can be different. The one exception to this is the Hardware Abstraction layer (HAL) driver used. For example, if the source computer has Advanced Configuration Power Interface (ACPI) support it will use a specific ACPI HAL driver. If you attempt to install this RIPrep image on a computer without ACPI support, it will fail.
Question: Does the RIPrep wizard support multiple disks and or multiple partitions on a given client computer?
Answer: No. The RIPrep utility only supports a single disk with a single partition (C:\ Drive) in this release of Remote OS Installation.
Question: How does the RIPrep wizard deal with disks that differ in size between the source computer used to create the image and the destination computer that will receive it?
Answer: The destination computer's disk size must be equal to or larger than the source disk used to create the image. For example, if the source computer has a 1-gigabyte (GB) hard disk, when that image is installed on a destination computer that has a larger (for example 2-GB)hard disk drive, the full 2-GB drive will be partitioned and formatted prior to installing the OS image. You can also configure support for formatting the destination computer's hard disk to the same physical size of the source computer. For more information, see the online documentation for on the UseWholeDisk= parameter.
Question: How do I replicate all of the OS images currently located on one of my RIS servers to other RIS servers on the network for consistency across all client installations?
Answer: The Remote OS Installation feature does not provide a mechanism for replication of OS images from one RIS server to another. There are several mechanisms that can be employed to solve this problem. Use the strong replication features of the Systems Management Server product. This product provides for scheduled replication, compression, and slow link features. You can also employ third party vendor solutions for OS image replication. Ensure that the replication mechanism supports maintaining the file attributes and security settings of the source images.
Question: Can I have a RIS server and a third party remote boot server on the network at the same time? f so, what are the implications?
Answer: Yes, you can have multiple vendor Remote Boot/Installation (RB/RI) servers on one physical network. It is important to understand that currently the remote boot PXE ROM code does not know the difference between different vendor's RB/RI servers. Therefore, when a remote boot-enabled client computer starts and requests the IP address of a RB/RI server, all of the available servers will respond to that client. Thus, the client has no way to ensure it is serviced by a specific RB/RI server. Using Remote OS Installation, an administrator can prestage client computers in the Active Directory, and mandate which RIS server will service that client. By configuring the RIS server to only answer known (prestaged) client computers, the administrator is assured that the client will be serviced by the correct RIS server. Not all RB/RI vendors have implemented the ability to ignore service requests, and therefore, you may need to segment off the specific vendors servers on the network so that clients are not answered by these vendors RB/RI servers.
Question: Can I remotely manage the RIS servers from Windows 2000 Professional-based workstations on my network?
Answer: Yes. If you are an administrator in the domain, and you have installed the Administrator Tools package on your Windows 2000 Professional-based workstation, you can administer the majority of the RIS configuration settings. There are some items that you cannot manage, for example, you cannot remotely add additional operating system images to RIS servers from computers running Windows 2000 Professional.
Question: Can I add additional network adapter cards to the RIS boot disk?
Answer: No. The Rbfg.exe utility is hard coded with regard to the number of supported network card adapters for this release of Remote OS Installation. Updates to the Rbfg.exe utility will be made available through normal distribution channels such as the Microsoft Windows Web site (http://www.microsoft.com/windows), Windows Update, and future Service and Feature Pack updates.
Question: Can I use Active Directory object attributes to create a naming format for use with the Remote OS Installation automatic computer-naming feature?
Answer: No. Currently the existing attributes supported with the automatic computer-naming feature use the Active Directory service. However, not all of the Active Directory object attributes are currently supported.
Question: Where do I look on the client computer to find the GUID/UUID for prestaging clients in Active Directory for use with Remote OS Installation?
Answer: The GUID/UUID for client computers that are PC98 or Net PC compliant can in most cases be found in the system BIOS of the computer. Microsoft encourages OEMs to ship either a floppy disk containing a comma separated file or spreadsheet that contains a mapping of computer system serial number to GUID/UUID. This allows you to script prestaging client computers into the Active Directory directory service. Microsoft also encourages the OEMs to post the GUID/UUID on the outside of the computer case for easy identification and prestaging of computer accounts. If the GUID is not found in the above-mentioned locations, you can use a network sniffer to analyze the network traffic of the client, locate the client's DHCP discover packet, and within that field will be the computer's 32 byte GUID/UUID.