HP e-PC c10/s10 User manual

remote booting
for the hp e-pc and
e-vectra
whitepaper
remote booting
for the hp e-pc
www.hp.com/go/desktops
whitepaper

2
The processes contained in this document are also
applicable to the HP e-Vectra.
HP does not endorse any particular software. Any
software referred to in this document is used purely as
an example
What is a remote boot?
To work, all computers need an operating system.
When an e-pc powers up, the operating system is
usually loaded from a local storage device such as a
floppy disk, a hard drive or a CD-ROM. This process is
known as a local boot.
However, a local boot is not always possible. Some
PCs do not have local storage devices or may have
damage that make a local boot impossible. In these
cases it is possible to boot the PC by loading the
operating system files from another network computer
or server. A process known as remote boot.
Advantages of remote booting include:
•increased security and manageability
•improved image consistency
•no need for local storage devices.
When starting a remote boot, a LAN device is selected
by the PC’s BIOS program as a boot device. The BIOS
then gives control to a piece of software called the
LAN Boot ROM. It is the LAN Boot ROM that performs
the remote boot.
When the remote boot is performed, the PC enters a
remote boot pre-OS mode that uses a “light operating
system” with network support. The remote boot pre-OS
mode will then be used to perform either PC
management tasks (such as computer setup) or start a
full operating system boot for immediate use.
Server Client e-pc
Server discovery
Download pre-OS files
Start pre-OS
3Pre-OS PC
management
tasks
3Full OS boo
t
LAN or WAN
Current remote boot state-of-the-art technology requires
a local server to be present on the LAN or IP subnet.
WAN remote boot is allowed by some protocols but
the security issues involved must be checked carefully.
Remote boot applications
Remote boot can be used for:
•Software deployment
•Operating system installation or upgrade (see
Appendix A)
•Automated desktop backup or restoration
•Virus checking or system consistency checks
•Enforcement of security or other general policies
•Third party client management products that
support remote booting (e.g. OnTechnology,
Win2K Remote Installation Services, CA Unicenter,
Altiris or Symantec Ghost).
Remote booting is also especially useful on HP
PCs or e-pcs that do not have CD-ROM drives.
However, while remote booting can be useful, it is also
difficult to configure. Remote booting must be
configured on the server side first, and then on the
client side.
Server selection and configuration
The possible boot protocols are:
•Preboot Execution Environment (PXE)
•Dynamic Host Configuration Protocol (DHCP)
•BOOTP
•Netware
•Remote Program Load (RPL).
Note: This list is not extensive. The server side boot
protocol must match the boot protocol chosen for the
client PC.
PXE
PXE is part of the industry standard Wired for
Management initiative and the PC99 Microsoft®
System Design Guide.
PXE is HP’s preferred remote boot protocol because:
•HP PCs and e-pcs are PXE enabled
•PXE is an industry standard aimed at reducing the
total cost of ownership
•There is a large number of PXE servers and
applications available
•Scalability of PXE solutions available, from
complete PC park administration to custom
application design

3
•PXE application maintenance is optimized. PXE
applications rely on the Universal Network Driver
Interface (UNDI) which is hardware embedded.
•PXE applications are independent of network
hardware. A single PXE application package will
support all PXE clients - even with different brands of
networking hardware. When new networking
hardware is introduced, PXE applications do not
require network drivers (see Appendix B for more
details).
PXE is supported by the following servers:
•Windows 2000 RIS
Contact your Microsoft® representative for more
information
•Rembo Software
More information can be found at:
www.rembo.com
•3Com DynamicAccess Boot Services
More information can be found at:
www.3com.com/bootservices
For more information go to:
developer.intel.com/ial/wfm/tools/index.htm
RPL, Netware, BootP and DHCP
•BootP is a UNIX legacy protocol that provides a
subset of the services provided by DHCP
•RPL is a legacy protocol developed by IBM
•Dynamic Host Configuration Protocol is an Internet
protocol for automating the configuration of
computers that use TCP/IP. DHCP can be used to
automatically assign IP addresses, to deliver TCP/IP
stack configuration parameters such as the subnet
mask and default router, and to provide other
configuration information such as addresses for
printer, time and news servers. For more information
go to: www.dhcp.org
The services listed above are more complex to install
but function in similar ways. These solutions exist on the
market and are generally used by Management
Information Services managers in big corporate
environments. The PXE method should be preferred
when deploying remote boot for the first time in a
corporation or in a small office.
For more information, please refer to:
www.3com.com/bootservices
Local client configuration
Local configuration is very simple. The e-Vectra and
e-pc have an integrated Boot ROM (3COM Managed
PC Boot Agent - MBA) that supports various boot
methods and protocols (see Appendix C).
The boot method should be chosen in accordance with
the boot protocol that is installed on the server.
Booting over a network
1Configure network remote boot protocol
The e-pc integrates a built-in 3COM Managed Boot
Agent Boot ROM that supports the four boot
protocols. By default, HP PCs are configured for PXE
remote boot. If another protocol exists on the server
you should change the network boot protocol.
To do this:
a Restart your e-pc.
b Press F12 during the POST screen and select
LAN as the boot device.
c Press Ctrl + Alt + B when prompted (this must
be done within three seconds). You will then be
able to select the other boot methods and
protocols.
d Once you have chosen the correct
configuration, press F10 to save and exit.
Note: The e-pc Boot Agent parameters can be
managed through the HP Toptools manageability
console, either locally or remotely on a group of PCs or
e-pcs. 3COM DMI agent must be installed on the
client PC or e-pc. For more information on Toptools go
to:
www.hp.com/go/toptools
The e-pc MBA also supports MS-DOS®-based
configuration using MBACFG.EXE. This tool supports
both menu configuration and unattended configuration
from a file. Please read the Dynamic Access Managed
PC Boot Agent (MBA) User Guide for more
information.
For more information go to:
www.support.vectra.hp.com/e-pcsupport/indexes/
manual3.html
2Determine what remote boot scenario is suitable
There are two ways to initiate a remote boot:
aUser-initiated remote boot: The PC will remote
boot when the user presses F12 during the
BIOS Power On Self Test. If F12 is not pressed
the e-pc will attempt to boot using local storage
devices.
bServer-controlled remote boot: In this scenario,
the e-pc always remote boots. The network
server application takes control and checks
whether the client PC is supposed to perform an
administrative task (software deployment for
instance). If a task is scheduled, the task is
performed in the remote boot environment. If
not, the task is scheduled and the PC will boot
on local storage devices.

4
The most suitable remote boot scenario depends on
the remote boot server application and the
particular needs of the company’s MIS.
3Configure network remote boot scenario
Again, there are two possibilities:
aUser-initiated network remote boot: The e-pc is
configured by default for this scenario. Restart
your e-pc. When the HP invent logo appears,
press F12. This will launch the remote boot
process.
bServer-controlled network remote boot:




BIOS setup program must be configured to set
the LAN device as the first boot device. When
the HP invent logo appears, press F2 to enter
setup. In the Boot menu, put LAN before HDD
in the device boot order.
Setup is complete. If the user-initiated scenario has
been selected, press F12 to initiate a remote boot. The
process will start, the client e-pc will auto-detect the
server and remote boot. If no server has been
configured the remote boot process will not take place.

5
Appendix A: Re-installing the operating system using a remote server boot
Re-installation of the operating system after a remote server boot must be done in several steps.
1Create a software image from a known working PC. Different applications - such as Norton Ghost (Symantec) or
Drive Image Pro (Powerquest) - can be used for this purpose. Symantec offer integrated support for 3COM
DynamicAccess Boot Services in the latest Norton Ghost 6.5 Software. Symantec and Powerquest also both offer
support for Microsoft® RIS technology in their latest software. More information can be found at the following web
sites:
www.symantec.com/product
www.powerquest.com/products
2Once the image has been created, store it on the server.
3Remote boot on the server, download the software image and re-install it on any computer that is the same as the
one used to create the image.
This is the most efficient and effective way of managing computer software in a small business environment.
Note: The HP Image Creation and Recovery CD cannot be used to re-install the operating system from a remote
server. The only way to re-install the operating system using the HP Image Creation and Recovery CD is to perform a
local boot from a PC with a CD-ROM drive.
Appendix B: PXE remote boot overview
The PXE service must be configured in “Proxy DHCP” mode. PXE also supports single server configurations. Refer to
3rd Party PXE vendor documentation for more details.
3Pre-OS
manageability tasks
3Full OS boot
Server with PXE and
DHCP
Client e-pc
1Client e-pc retrieves an IP address using DHCP.
2Client e-pc discovers PXE server.
3Client e-pc downloads boot image from PXE server.
4Client e-pc runs image.
LAN
Local IP Subnet

6
Appendix C: Boot methods and protocols
Appendix D: PXE optimizing PXE application maintenance
PXE applications may be built on UNDI network drivers. UNDI is hardware embedded. Accordingly, PXE network
applications are independent of networking hardware. Building networking applications that are hardware
independent can save a lot of application maintenance.
Note: This example shows an NDIS2 based network stack. Other implementations, such as packet drivers, are also
possible.
Boot method Protocols and
technologies
Typical networking operating
system booted
Boot mode
   !
"
#$%&$'()
%*
(++*
, && )() (++*%*
  --. #$%&$'/0"++&$ 
"
(++*%*
1 1 #$%&$'/0#$" (++*
Network Application
e.g. Software deployment
Network Stack
NDIS2
UNDI to NDIS2
driver
UNDI
Hardware dependent driver
Universal networking application
PXE Server
Any PXE PCI
LAN card