Partager via

Troubleshooting Remote Installation Services

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting Remote Installation Services

What problem are you having?

  • I am not sure I have the correct Pre-Boot eXecution Environment (PXE) ROM version.

  • I am not sure whether the client computer has received an Internet protocol (IP) address and has contacted the Remote Installation Services (RIS) server.

  • I am trying to locate the globally unique/universally unique identifier (GUID/UUID) on a client computer so I can prestage the client computer within Active Directory for use with RIS.

  • Command settings are not being processed during the unattended installation.

  • Language choice options do not appear during the Client Installation Wizard session.

  • The client computer is prestaged to a RIS server but is being serviced by a different server.

  • I have client computers that use the older remote boot protocol, Remote program Load (RPL)-based ROMs.

  • I am investigating questions of security related to the Pre-Boot portion of the PXE-based remote boot ROM.

  • I am evaluating methods for replicating all of the operating system installation images currently located on one RIS server to other RIS servers on the network to achieve consistency across all client installations.

  • I am evaluating whether to place a RIS server and another vendor’s remote boot server on the same network.

  • I want to manage the RIS servers remotely from computers running Windows XP Professional on my network.

  • I want to add more network adapters to the RIS boot disk.

  • I want to know whether I can use the Active Directory object attributes to create a naming format that can be used with the RIS automatic computer naming feature.

  • After the restoration of a backup of a RIS volume, RIS does not function properly.

  • I created an image on my RIS server, but the installation image does not appear in the list of available operating system installation options when I attempt to install the image on a client computer.

  • I created an image using the Remote Installation Preparation (RIPrep) Wizard, started the Add Wizard, and clicked Associate a new answer file to an existing image, but I do not see the RIPrep image in the list in the Add Wizard.

  • I am evaluating the use of RIPrep in a situation where I want to preserve the file attributes and security settings defined on the source computer.

  • I want to use RIPrep in a situation where there are hardware differences between the source computer that is used to create the RIPrep based installation image and the destination computer that will install the image.

  • I am evaluating whether I can use RIPrep to support an installation on multiple disks or multiple partitions on the client computer.

  • I am evaluating the use of RIPrep in a situation where the disk sizes differ between the source computer used to create the image and the destination computer that will receive the image.

I am not sure I have the correct Pre-Boot eXecution Environment (PXE) ROM version.

Solution: When the Net PC or client computer containing a remote boot ROM starts, the version of the PXE ROM appears on the screen. Remote Installation Services (RIS) supports .99n or greater PXE ROMs, except in a few situations that require the .99L version. You might be required to obtain a newer version of the PXE-based ROM code from your original equipment manufacturer (OEM) if you have problems with the existing ROM version installed on a client computer.

I am not sure whether the client computer has received an Internet protocol (IP) address and has contacted the Remote Installation Services (RIS) server.

Solution: When the client computer boots, you will 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 the computers using the RIS boot disk.

Remote Boot ROM Load Sequence:

Step 1:

The client computer displays the message "DHCP." This indicates that the client is requesting an Internet protocol (IP) address from the DHCP server. This can also mean that the client has obtained an IP address from the DHCP server and is awaiting a response from the RIS server. To verify that the client is receiving an IP address, check the IP leases that have been granted on your DHCP server.

Troubleshooting

If the client does not receive the message, an IP address might not have been received or the Remote Installation (BINLSVC) server might not be responding. Consider the following:

  • Is the DHCP server available and has the service started? The DHCP server and remote installation servers must be authorized in Active Directory before they can provide IP addresses. Check to ensure that the service has started and that other clients that are not remote boot-enabled 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?

Step 2:

When the client receives an IP address from the DHCP server, the message might change to "BINL." This indicates that the client successfully leased an IP address and is now waiting to contact the RIS server. The client will eventually time out and post the error message "No Bootfile received from DHCP, BINL, or Bootp."

Troubleshooting

If the client does not receive the BINL message, this indicates the client is not receiving a response from the RIS server. Consider the following:

  • Is the server available and has Remote Installation Services started? RIS servers must be authorized before they can respond to client computers. Run Risetup -Check to authorize a RIS server. For more information, see Remote Installation Services server authorization.

  • Are other remote boot-enabled clients receiving the Client Installation Wizard? If so, this client computer either is not supported or is having remote boot ROM-related problems. Check the version of the PXE ROM on the client computer. Also, check Active Directory to see whether the administrator has prestaged this client computer to a RIS server that is offline or unavailable to the client computer.

  • Has an additional network card been added to the RIS server? If so, the server must be re-authorized in Active Directory. Run RISETUP -Check to re-authorize the server.

  • Is a router between the client and the RIS server not allowing the DHCP-based requests or responses through? The RIS server communicates by way of the DHCP packet type during the initial service request/response sequence. You might need to configure the router to forward the DHCP packets. For more information, see article Q257579, "PXE Clients Do Not Receive an IP Address from a DHCP Server Across a Router," in the Microsoft Knowledge Base.

  • Are there any error messages in the event log under the system or application logs specific to Remote Installation (BINLSVC), Domain Name System (DNS), or Active Directory?

  • Does the client computer have an account in Active Directory? If not, the RIS server might be configured to respond only to known client computers.

  • Is the RIS server also a DHCP server, and does it have multiple network adapters? If so, then there must be a scope for the subnet of each network adapter. For more information, see Configuring scopes.

Step 3:

The client then changes to Trivial File Transfer protocol (TFTP) or prompts the user to press a particular key (for example, F12). This indicates that the client has contacted the RIS server and is waiting to receive the first image file-CIW. You might not see the BINL and TFTP message on some computers because this sequence can occur very rapidly.

Troubleshooting

If the client computer does not get a response from the RIS server, the client will time out and send 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. Do the following:

  • Stop and restart Remote Installation (BINLSVC). To do so, click Start, and then click Run. In the Run dialog box, type cmd in the text field, and click OK. In the console window, type the following:

    Net Stop BINLSVC

    Net Start BINLSVC

  • Check the RIS server properties to ensure that the Respond to client computers requesting service option is selected and that Do not respond to unknown client computers is cleared unless you have prestaged the client computer in Active Directory prior to starting the client computer.

  • If the client computer does not receive an answer after it has attempted to stop and restart the service, and you have checked the remote installation server object properties to ensure that the correct settings have been set, check the event log on the RIS server for any errors relating to DHCP, DNS, and RIS (BINLSVC).

  • Check the TFTP Daemon to ensure that it has actually started, and check the event log to see if there are any TFTP errors.

Step 4:

At this point, the client should have downloaded and displayed the Client Installation Wizard application; a Welcome screen greeting the user should appear.

I am trying to locate the globally unique/universally unique identifier (GUID/UUID) on a client computer so I can prestage the client computer within Active Directory for use with RIS.

Solution: The GUID/UUID for most client computers that are PC98 or Net PC-compliant is provided in the system basic input/output system (BIOS) of the computer. Computer manufacturers are encouraged to ship either a floppy disk containing a comma-separated file or spreadsheet that includes a mapping of serial numbers to GUIDs/UUIDs. You can use this information to script the prestaging of client computers within Active Directory.

The GUID/UUID also appears on the outside of the computer. If it does not appear in the expected locations, one method for discovering it is to use a network utility to sniff the network traffic of the client computer and locate the DHCPDiscover packet; within that field will be the 128-bit, 16-byte GUID/UUID. Another method is to use the Windows Management Instrumentation (WMI) interface-- specifically, the universally unique identifier (UUID) value of the Win32_ComputerSystemproduct class. For more information about this, see the MSDN Library at the Microsoft Web site.

Command settings are not being processed during the unattended installation.

Cause: Incorrect directory information is being used. Correct directory information is required when the "OemPreinstall = yes" setting in a .sif file is being used.

Solution: Change the directory information to \\RemoteInstall\Setup\applicable_language\Images\applicable_name\$oem$.

Language choice options do not appear during the Client Installation Wizard session.

Cause: By default, RIS uses the Welcome.osc file to manage client installation image choices. To make multiple language installation image options available, you must replace the default Welcome.osc file with the Multilng.osc file.

Solution: The Client Installation Wizard uses the Welcome.osc file located in the \\RemoteInstall\OSChooser folder to manage client installation image choices. When you remove the Welcome.osc file and rename the Multilng.osc file to Welcome.osc, the Client Installation Wizard will also offer a menu of language choices to the user. You can edit the Welcome.osc file to create custom language options.

The client computer is prestaged to a RIS server but is being serviced by a different server.

Cause: When you prestage a client computer into a domain with multiple domain controllers, the replication delay of the client computer account information can cause a client computer to be serviced by another RIS server.

Solution: You can either wait for the computer account information to be propagated during the next scheduled replication session, or you can modify the replication frequency between your domain controllers. For more information on configuring replication, see Replication overview.

I have client computers that use the older remote boot protocol, Remote program Load (RPL)-based ROMs.

Solution: There is no support for the older RPL-based remote boot, so computers using this cannot use RIS. RIS uses the PXE DHCP-based remote boot ROMs.

Solution: There are inherent security limitations with PXE. The entire boot ROM sequence and operating system installation or replication process is not secure for packet type encryption, client or server spoofing, or wire sniffer-based mechanisms. You should exercise caution when using RIS on your corporate network. Allow only authorized RIS servers on your network. Also, control the number of administrators who are allowed to install or configure RIS servers. For more information, see Security Information for Remote Installation Services.

I am evaluating methods for replicating all of the operating system installation images currently located on one RIS server to other RIS servers on the network to achieve consistency across all client installations.

Solution: RIS does not currently provide a mechanism for replication of operating system images from one RIS server to another. There are several alternative mechanisms you can use, however. One solution is to use the strong replication features of the Systems Management Server product. This product provides for scheduled replication, compression, and low-speed link features. You can also use other vendor solutions for operating system image replication. If you do this, however, ensure that the replication mechanism you choose supports maintaining the file attributes and security settings of the source images.

I am evaluating whether to place a RIS server and another vendor’s remote boot server on the same network.

Solution: You can place multiple-vendor remote boot/installation (RB/RI) servers on one physical network. It is important to understand, however, that the remote boot PXE ROM code is not currently able to detect the difference between vendors' RB/RI servers. As a result, when a remote boot-enabled client computer starts and requests the Internet protocol (IP) address of an RB/RI server, all of the available servers will respond to that client; thus, the client has no way to ensure that it is being serviced by a specific RB/RI server.

With RIS, however, an administrator can prestage client computers into Active Directory and determine which RIS server will service a client computer. By configuring the RIS server to answer only known (prestaged) client computers, the administrator is assured that the client will be serviced by the correct RIS server.

Not all of the other RB/RI vendors are able to ignore service requests. You might need to isolate the specific vendors' servers on the network so that clients are not answered by these vendors' RB/RI servers.

I want to manage the RIS servers remotely from computers running Windows XP Professional on my network.

Solution: If you are an administrator in the domain, and you have installed the Windows Server 2003 Administration Tools Pack on the computer running Windows XP Professional, you can administer most of the RIS configuration settings. There are some items that you cannot manage, however. For example, you cannot remotely add more operating system installation images to the RIS servers from a computer running Windows XP Professional.

I want to add more network adapters to the RIS boot disk.

Solution: For this release of RIS, the Rbfg.exe utility cannot be modified to accommodate additional network adapters. Updates to Rbfg.exe can be made available through the same distribution channels that are used for other software updates and feature packs, however. You can obtain information about possible updates to Rbfg.exe (and the network adapter support in those updates) in the same way that you obtain information about other software updates.

I want to know whether I can use the Active Directory object attributes to create a naming format that can be used with the RIS automatic computer naming feature.

Solution: This is not supported. Although the existing attributes supported with the automatic computer naming feature do use Active Directory, not all Active Directory object attributes are currently supported.

After the restoration of a backup of a RIS volume, RIS does not function properly.

Cause: Backup restored the volume without a Single Instance Store (SIS) directory.

Solution: Verify the configuration of the RIS volume, then restore the volume again.

For information about how to verify the configuration of a RIS volume, see Verify the Remote Installation Services configuration.

For information about how to back up and restore SIS directories, see "Backup and Restore" at the Microsoft Windows Resource Kits Web site.

I created an image on my RIS server, but the installation image does not appear in the list of available operating system installation options when I attempt to install the image on a client computer.

Cause: The client computer has a different type of hardware abstraction layer (HAL) than the image.

Solution: When you use RIPrep to create new images, RIPrep ensures that the images viewed by the client computers are only those that are compatible with the computer. A client computer must have the same type of hardware abstraction layer (HAL) as the image. If it does not, the image will not appear in the list of available operating system installation options.

Cause: Permissions have been set that prevent users from seeing a particular installation image.

Solution: For information about setting permissions that permit or deny access to installation images, see Allow or prevent the installing of a RIS image by a user or group and Allow or prevent the viewing and installing of a RIS image by a user or group.

I created an image using the Remote Installation Preparation (RIPrep) Wizard, started the Add Wizard, and clicked Associate a new answer file to an existing image, but I do not see the RIPrep image in the list in the Add Wizard.

Solution: The installation images that appear in the list in the Add Wizard include only flat images; that is, those images created with the Remote Installation Services Setup Wizard. The list does not include images created with the Remote Installation Preparation (RIPrep) Wizard.

I am evaluating the use of RIPrep in a situation where I want to preserve the file attributes and security settings defined on the source computer.

Solution: RIPrep supports this. The file attributes and security settings that are defined on the source computer are preserved on the destination computer that installs that image. For more information about RIPrep, including information about requirements for the RIPrep replication process, see Creating an installation image with RIPrep.

I want to use RIPrep in a situation where there are hardware differences between the source computer that is used to create the RIPrep based installation image and the destination computer that will install the image.

Solution: You can use RIPrep in a situation where hardware on the source computer and the destination computer is different. The one limitation is that the computers must use the same type of Hardware Abstraction Layer (HAL). For example, if the source computer is an Advanced Configuration Power Interface (ACPI)-based computer, it uses a HAL that includes ACPI. If you attempt to install this RIPrep image on a computer that is not based or enabled on ACPI, the operating system installation process will fail.

I am evaluating whether I can use RIPrep to support an installation on multiple disks or multiple partitions on the client computer.

Solution: In this release of Remote Installation Services, the RIPrep utility supports only a single disk with a single partition. You can use RIPrep to make an image of a computer that contains more than one partition or disk, but RIPrep will only image the system partition.

I am evaluating the use of RIPrep in a situation where the disk sizes differ between the source computer used to create the image and the destination computer that will receive the image.

Solution: For details about working with different disk characteristics on the source client computer and the destination computer, see Creating an installation image with RIPrep.

Note

  • This topic does not apply to Windows Server 2003, Web Edition.