Remote Boot
First click on the following links to review the on-line MSDN documentation:
Remote Boot
Deploying Windows XP Embedded Remote Boot
Configuring the Remote Boot Service using Remote Boot Manager
Installing the Remote Boot Server
Creating a Remote Boot Image
Preparing a Remote Boot Image for Deployment
Starting and Stopping Remote Boot Services
Configuring DHCP for Remote Boot Services
Using a Boot.ini File in a Remote Boot Environment
Remote Boot Response Time
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, since 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 powered up or reset, the server automatically downloads the specific runtime image for that terminal. The POS terminal subsequently boots up off of that image.
A Remote Boot server in a factory manufacturing floor is used to deploy runtime images to assorted embedded devices used throughout the factory.
Thin client (minimal hardware), diskless PCs are connected to a Remote Boot server, in a home environment, serving as remote terminals. When the diskless PC powers up, it downloads its embedded runtime image from the server into its system memory. The image contains a Standard 2009 runtime that includes little more than a Windows Terminal Services Client (MSTSC) and networking functionality. After the diskless PC completes booting from the image, it launches MSTSC, 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 boot device. When the client computer boots up from the network, the RAM disk that is created will appear as drive C: The original boot disk is typically assigned the next drive letter (D:). This offers the capability of using Remote Boot to service and/or update runtime images contained in the hard drive of each networked embedded device.
Accessing hard disk volumes on a Remote Boot client
When you boot off a RAMDisk, RAMDisk will mask your underlying hard disk's first partition. RAMDisk always assigns itself drive C. This allows you to boot from the same image regardless of how many drives you have on the embedded device.
Inspect the following registry key of your target image:
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
Free up \DosDevices\C: for use by RAMDisk by renaming\DosDevices\D: to \DosDevices\E:, \DosDevices\C: to \DosDevices\D:, and so on.
If the signature matches, drive D will be assigned to the drive that was drive C, and so on.
Using Remote Boot as a means of servicing devices that are booted by using Compact Flash
If you want to use the Remote Boot server to deploy a Standard 2009 image onto a Sandisk Compact Flash storage device (or any IDE storage device marked as Fixed type), on the target embedded device, and the Compact Flash storage device is set as fixed media and not as removable, the deploying image may not install the Compact Flash storage device, with error code 39. Consequently, the deploying image cannot copy the final image to the Compact Flash storage device.
This behavior occurs because the disk driver, Disk.sys, is automatically loaded when the system boots, and it remains loaded in memory even when no disk drives, including Compact Flash, exist on the embedded device. This condition causes the problem because when you install the Compact Flash storage device or the disk drive, the system tries to load the Disk.sys driver for the Compact Flash storage device or drive. However, because this driver still exists in memory with a null driver object, the installation process fails with error code 39.
To work around this problem, delete the disk driver entry from the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\gendisk
This prevents the disk driver from loading at boot time and allows the image to boot off of a RAMDisk. Delete this registry key in the post-FBA image or alternatively run an FBA command at the end of the FBA process that deletes the key.
See also:
You cannot see the local disk drives after you start a Window XP Embedded image by using Remote Boot Server (KB943838)
Maximizing performance of Remote Boot clients
The following factors affect performance:
Size of the image: smaller is better.
Network bandwidth: faster is better.
Number of devices that are booting simultaneously. Booting more embedded devices than your bandwidth can carry will clog your network.
There is a size limit on the image itself: 500 MB.
RAM boot and WinPE
Boot into RAM with Windows PE
RAM boot using SDI
The following MSDN article is intended for developers who want to deploy their own programmatic means of copying and executing a real mode image using PXE in order to boot from the network:
RAM Boot Using SDI in Windows XP Embedded with Service Pack 1
How to stop a computer or laptop from booting from the network (PXE) and to load normally
You need to change the setting in the BIOS. Disable the LAN boot or change the boot order.
Remote Boot Services health checking
You can verify that the Remote Boot Service and Trivial File Transfer Protocol services are installed and started in the Remote Boot Server; use the Service Manager to confirm this. A shortcut to launch the Services Manager is to type services.msc in the Start>Run dialog box.
Use the kernel debugger on the target system for troubleshooting Remote Boot problems
If you wish to debug a network booted client device using the kernel debugger, add the appropriate kernel debugger switches to the Boot Parameters field in the Remote Boot Service Manager’s Policy List (or add this information to the boot.ini file, if used). An example follows:
/debug /debugport=com1 /baudrate=57600
Diagnostics messages
If you have a problem with remote boot, a diagnostic message may appear on the client console video display during client boot. The table below identifies each message and corresponding corrective action.
Message on client display
|
Corrective action
|
Windows could not start due to an error while booting from a RAMDISK. Windows failed to open the RAMDISK image
|
This indicates that the RBSPXE server was unable to locate the file on the server, i.e. 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
|
Indicates 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 either:
The Remote Boot Manager was not provided with an Boot Image name in the Device Policy List, or
The PXE client physical address is not included in the Device Policy List and the check box named “Use default settings to boot unspecified clients” is checked.
If you wish to create and use your own BOOT.INI, copy your BOOT.INI to the folder containing your Boot Images.
|
Windows could not start because the following file is missing or corrupt:
\system32\hal.dll.
Please re-install a copy of the above file.
|
This message can occur if you used the /rdpath=… parameter in either boot.ini or in the Boot Parameters field of the Remote Boot Service Manager’s Policy List, and you specified an SDI image 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 PXE boot phase, this can indicate that the NTLDR file does not exist on the right place on the server or it has been renamed so it contains a file extension. Ensure that NTLDR is present and has not been renamed.
|
System Cloning Tool / Fbreseal
System Cloning Tool on-line MSDN documentation:
Mass Deployment
If you are using SCCM (which uses SysPrep), do not use the System Cloning Tool component, since SysPrep will be used to reseal the image instead:
System Center Configuration Manager (SCCM) Cloning the runtime to multiple target devices
Standard 2009 includes the System Cloning tool component. If you add this component to the configuration, by default it adds steps to the First Boot Agent (FBA). After the system completes FBA phases 0 through 8,500, the system reboots on your master system and enters the "Reseal" phases 8,501 through 12,000. After the Reseal phase, you must shut down the system and copy this image to disk. Propagate this image to the multiple cloned embedded devices. The next time this image boots, the cloning phase begins, and the computer's security ID (SID) from the master device is replaced with a unique SID.
Note that the procedure above offers no point in time when you can manually update the image and/or test the image prior to resealing.
The recommended procedure is to hold off reseal completion from occurring at the end of FBA. Edit the System Cloning Tool component so its Advanced parameter cmiResealPhase is set to 0 (or under Settings, set Reseal Phase to Manual). Then use the FBRESEAL command after you have finished manual updates and testing, when you are ready to perform reseal completion. Then you can mass duplicate your image.
Note: Refer to the Standard 2009 Help files topics on the special settings that are required if you need FBA to process anything after cloning. Refer to the FBA Generic Command topic.
The System Cloning tool that is included in Standard 2009 does not support cloning an image more than one time. After you use the System Cloning tool to reseal an image, the Fbreseal.exe and Setupcl.exe core files are deleted from the image the next time the cloned client starts up. This behavior is by design to prevent end users from accidentally starting Fbreseal.exe in the deployed run-time image and changing the current configuration of the client image.
Cloning an image more than one time with the System Cloning tool can lead to data loss and image corruption of user settings, Internet Information Services and database settings, domain memberships, and local and group policies.
|
