Deploying Windows XP Embedded Remote Boot
Microsoft® Windows® XP Embedded with Service Pack 1
Summary: Windows XP Embedded offers developers a componentized version of the Windows XP operating system. Developers can choose exactly those components required to fulfill their design requirements, resulting in a reduced footprint that is specifically tailored for their designs.
Windows XP Embedded with Service Pack 1 introduced the Remote Boot feature. With Remote Boot, you can create a client device that does not require a hard disk or other persistent storage device. Instead, your client device can download a runtime image from a network server into the client's system memory (random access memory [RAM]); the memory-resident image becomes the system startup device and is subsequently started. This article contains guidance for deploying and troubleshooting Remote Boot.
This article supplements the original Remote Boot documentation supplied in Microsoft® Windows® XP Embedded with Service Pack 1. As a prerequisite, become familiar with the original documentation, which you can open by taking the following steps:
- On the Setup menu, click Remote Boot Setup.
- When installation is complete, run Remote Boot Manager.
- Click the Help button.
Alternatively, you can go to the Remote Boot Overview website.
Review the Release Notes
It is important that you review the release notes, which you can open from the Setup menu in Windows XP Embedded with Service Pack 1. In particular, search for topics pertaining to the terms "Remote Boot service" and "cloning."
Get the Latest Updates
After you install Remote Boot, check for updates on the Downloads website.
At the time of this writing, the updates related to Remote Boot are:
- Remote Boot Server End-User EULA Update Tool (Q816490), June 13, 2003
- Remote Boot Server installation for Windows 2003 Server (Q820683), May 19, 2003
When deploying Remote Boot, you typically use a secure, dedicated private network to connect a Remote Boot server to one or more client devices. Servicing of images is convenient, because all the images are maintained on the server.
Here are some typical applications:
- A Remote Boot server is used to serve runtime images to a network of client point-of-sale (POS) terminals in a retail department store. When the POS terminal is turned on or reset, the server automatically downloads the specific runtime image for that terminal. The POS terminal subsequently starts by using that image.
- A Remote Boot server on a factory manufacturing floor is used to deploy runtime images to assorted embedded devices used throughout the factory.
- In a home environment, thin client (minimal hardware), diskless computers are connected to a Remote Boot server and serve as remote terminals. When a diskless computer is turned on, it downloads its embedded runtime image from the server into its system memory. The image contains a Windows XP Embedded runtime that includes Windows Terminal Services Client and networking functionality. After the diskless computer completes the startup process by using the image, it starts Terminal Services Client, which connects to the server. This approach enables multiple users throughout the household to share the Windows operating system located on the server, while requiring very little hardware on the terminal side.
You also can deploy Remote Boot on client computers that already contain a hard disk as a startup device. When the client computer starts from the network, the RAM disk that is created appears as drive C. The original startup disk is typically assigned the next drive letter (D). Remote Boot can thus be used to service and/or update runtime images contained in the hard drive of each networked embedded device.
Network Card Hardware Requirements
For Remote Boot to function, client-side network cards must support Preboot Execution Environment (PXE) basic input/output system (BIOS) version 0.99j or later. There is no PXE BIOS requirement on the server side.
Remote Boot Performance
The following key factors principally determine how much time is required to download the image from the server to the client:
- The size of the runtime image. Configure your runtime image to the smallest possible size. You can learn more about this topic in Reducing the Windows XP Embedded Run-time Image Size.
- The choice of networking hardware. Choose hardware that offers acceptable performance for your application. For example, if you require quicker loading, and your client device uses a 10–megabits per second (Mbps) network card, consider upgrading the server and client hardware to 100-Mbps or 1,000-Mbps (1-gigabit) network hardware. You must upgrade each client in addition to each server.
- The performance of the file transfer service. As currently offered, Remote Boot uses Trivial File Transfer Protocol (TFTP) for downloading the image from the server to the client device, one session per device. However, original equipment manufacturer (OEM) developers can programmatically deploy their own custom means of downloading an image from the server to the client. For more information, see RAM Boot Using SDI in Windows XP Embedded with Service Pack 1.
Deploying Remote Boot Service on a Corporate Network
In general, it is desirable to use a secure, dedicated separate private network to connect a Remote Boot server to one or more client devices. However, if you deploy Remote Boot on a corporate network:
- Take the appropriate measures to prevent Dynamic Host Configuration Protocol (DHCP) server conflicts. DHCP usage guidelines are available in the Microsoft MSDN® Library; search for the title "Dynamic Host Configuration Protocol for Microsoft Windows 2000."
- Take the appropriate measures to ensure that the Windows XP Embedded Remote Boot service does not introduce compatibility problems with other PXE startup services that may already be deployed. For example, your network may already have Microsoft Windows 2000 Remote Installation Services (RIS)—which also uses PXE—deployed. If a network has multiple PXE servers, and a computer attempts to start by using PXE, the first PXE server that responds to the request will be the one that services the computer.
Designing a Fault-Tolerant Server Arrangement
By taking the following actions, you can configure a redundant (dual) server arrangement so that one Remote Boot server can continue uninterrupted if the other server fails catastrophically:
- Configure two server systems that share the same subnet and hence have the same access to your PXE client devices. The servers should be on separate power circuit breakers so that if a breaker fails, the power loss will affect only one of the servers.
- Configure Remote Boot and TFTP to be identical on both servers. Create and configure an identical folder that contains all your runtime images on both servers.
- Configure DHCP on both systems with the same scopes but with complementary exclusion ranges, to accommodate fault tolerance.
If you want one server to have precedence over others, you can set the response time value in Remote Boot Manager. A value of zero will give the server the highest precedence because PXE clients respond to the first PXE server that makes the offer.
You can extend the preceding methodology if you want to use more than two redundant servers. For each server, set the DHCP service so that the servers have the appropriate complementary DHCP address exclusion ranges.
Using Terminal Services to Remotely Access Remote Boot Manager
If your network is configured appropriately, you can use Terminal Services (Mstsc.exe) to run Remote Boot Manager, located on your Remote Boot server, from a different computer elsewhere on the network.
Mstsc.exe will start a new instance of the application for each Terminal Services client, and will allow these instances to coexist with an instance running on the local server console. However, each client is allowed to run no more than one instance of Remote Boot Manager. Remote Boot Manager is not designed to manage configuration changes that arrive from multiple instances of Remote Boot Manager; in such a situation, the final Device Policy List configuration is established by the last person to click Save.
You can use the System Cloning Tool component to create a single image that can be deployed as the boot image on multiple computers on the same network. As described in the release notes, the default behavior of this component in Windows XP Embedded with Service Pack 1 is to generate a random computer name at startup time. The purpose of this behavior is to guarantee unique computer-name identity for each client device on the network. For more information about the System Cloning Tool, refer to the Cloning Web page.
Using Diagnostic Messages
If you have a problem with remote startup, a diagnostic message may appear on the client console during client startup. The following table identifies each message and corresponding corrective action.
|Message on client console||Corrective action|
|Windows could not start due to an error while booting from a RAMDISK. Windows failed to open the RAMDISK image||This message indicates that the Remote Boot Server Pre-Boot Execution Environment (RBSPXE) server was unable to locate the file on the server. For example, the specified image file name is incorrect or the image file was not copied into the designated TFTP downloads path. Ensure that the file is named correctly and is present in the TFTP downloads path.|
|NTLDR: Fatal Error 21 reading BOOT.INI||This message indicates that Boot.ini was not found in the designated folder in the PXE Boot Images folder. Remote Boot Manager will attempt to use the Boot.ini file from the Boot Images folder if one of the following occurs:
If you want to create and use your own Boot.ini file, copy your Boot.ini file to the folder that contains your boot images.
|Windows could not start because the following file is missing or corrupt:
Please re-install a copy of the above file.
|This message can occur if you used the /rdpath=… parameter in either Boot.ini or the Boot Parameters field of the Policy List in Remote Boot Manager, and you specified a system deployment image (SDI) without including the following required switch in the boot parameters: /rdimageoffset=4096.
If you use the /rdpath=… parameter, you must also add /rdimageoffset=4096 to the boot parameters.
|Windows could not start because of a computer disk hardware configuration problem.
Could not read from the selected boot disk. Check boot path and disk hardware.
Please check the Windows documentation about hardware disk configuration and your hardware reference manuals for additional information.
|This message can occur if you did not specify an image name (either in the Device Policy List or in a manually created Boot.ini file).|
|TFTP download failed||Appearing on the PXE client screen at the beginning of the PXE startup phase, this message can indicate that the NTLDR file does not exist on the right place on the server, or that the file has been renamed and now contains a file name extension. Ensure that NTLDR is present and has not been renamed.|
Checking the Health of Remote Boot Services
By using Remote Boot Manager, you can verify that the Remote Boot and TFTP are installed and started on the Remote Boot server. A shortcut to start Remote Boot Manager is to click Start, click Run, and then type services.msc in the Run dialog box.
Identifying the MAC Network Address of a Client Device
You can use any of the following methods to obtain the physical network address (media access control [MAC] address) of a computer:
- View it during PXE BIOS startup. The PXE client's MAC address is visible on the screen for a few seconds during the PXE BIOS startup phase, if the client is connected to the PXE server.
- Type the following command in a Windows XP command prompt:
- Use a network monitor tool, observing network activity to obtain the MAC address.
Using the Kernel Debugger on the Target System for Troubleshooting Remote Boot Problems
If you want to debug a network-booted client device by using the kernel debugger, add the appropriate kernel debugger switches to the Boot Parameters field in the Policy List in Remote Boot Manager (or add this information to the Boot.ini file, if used). The following is an example of a kernel debugger switch:
/debug /debugport=com1 /baudrate=57600
For more information, visit the Microsoft Windows XP Embedded website.