Home Library Learn Downloads Support Sign in | United States - English |

Community Preferences
Deploying Windows XP Embedded Remote Boot
Windows XP Embedded
Â

Mark Chamberlain
Microsoft Corporation

February 2004

Applies to:
   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.

Contents

Introduction
Remote Boot Applications
Implementation Considerations
Troubleshooting
For More Information

Introduction
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:

1. On the Setup menu, click Remote Boot Setup.

2. When installation is complete, run Remote Boot Manager.
3. 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

Remote Boot Applications

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.

Implementation Considerations
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.

Cloning

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.

Troubleshooting
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:

• Remote Boot Manager is not provided with

a boot image name in the Device Policy List.
• The physical address of the PXE client is
not included in the Device Policy List, and the
Use default settings to boot unspecified
 clients checkbox is selected.

Windows could not start because the
following file is missing or corrupt:
Windows_root\system32\hal.dll.
Please re-install a copy of the above
file.
Windows could not start because of a
computer disk hardware configuration
problem.
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.
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.
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).

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.
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:
ipconfig /all
• 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

For more information, visit the Microsoft Windows XP Embedded website.

© Microsoft Corporation. All rights reserved.

© 2011 Microsoft Corporation. All rights reserved.

Terms of Use | Trademarks | Privacy Statement | Feedback