Remote Boot Windows XPE?

[Benjamintohc]

I need to boot 32 diskless clients on my test setup into Windows XP/E through
network boot. Is this possible?

I cannot install Windows into any of the 32 x86 clients due to space
contraints but I can have a PXE server available.

Is this possible? What charges ($$$) am I looking at?

Thanks in advance folks

 

[Sean Liming \(MVP\)]

Yes, XPe can boot from an network and load the image to run in RAM. The
tools come with a Remote Boot Service object ot install on Windows 2003
server with DHCP enabled.

The image will have to run on a hard drive first to get past FBA, and then
you can create the final downloadable carrier file. The amount of RAM in the
target must be twice the image size.

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[Benjamintohc]

Hi Sean,

Thanks for the reply.

I am totally new to Windows XPE, in fact I am a total idiot.

I do have some experience setting up PXE boots but is totally clueless when
it comes to XPE.

Is there some sort of step by step guides I can use?

 

[Sean Liming \(MVP\)]

There is the online help that comes with the tools, maybe something on MSDN,
and it is covered in my first book.
--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[Luke Alcatel]

You got the right answers from Sean however I want to warn you that PXE boot
for that number of clients, assuming you want to boot them simultaneously,
is dreadfully slow. I boot up to 72 clients from a 2GHz Pentium-M server
and the boot process saturates the server CPU after about the 5th client.
This leaves my gigabit link to the clients greatly under-utilized. I think
the TFTP server provided with the server package is the culprit and it would
be great if someone had the time and interest to improve that server. It
would also be nice if MS would improve remote boot support in other ways.
For example, your remote boot client requires the RamDisk component. I have
a fairly light 90 MByte image but I allow another 60 Mbytes for temporary
files (lots of log files) so the SDI image ends up to be 150 MBytes. Using
remote boot, the entire 150 Mbytes must be downloaded even though 60 MBytes
of space for file creation has nothing in it. If you require a swap file,
which you will if you want to do performance monitoring, then your empty
swap file also becomes part of the baggage that you must download. Maybe
this becomes less of a problem if the FS is NTFS and you use compression
(don't know) but I have reasons for using FAT.

There is a faster remote boot solution available from Ardence but there are
a couple of technical factors that made that solution unsuitable for me.

Luke

 

[Luke Alcatel]

At the risk of correcting Sean I believe that the RBS that comes "in the
box" is compatible with W2K and XP Pro but not W2003 Server. There is an
update that you can download for W2003.
http://www.microsoft.com/downloads/...6F-1F3A-4194-8E26-A4C9653ADBC5&displaylang=en

Luke

 

[KM]

You got the right answers from Sean however I want to warn you that PXE boot for that number of clients, assuming you want to boot

them simultaneously, is dreadfully slow. I boot up to 72 clients from a 2GHz Pentium-M server

Just to confirm. Current RBS is unicast based. More than 10 clients with a relatively large image and 100Mb network is a not a big
help. Even on 1G network it starts crawling.

The better implementation would be MTFTP (Multicast TFTP) or similar protocol (suggested and filed to MS as a feature request a
while ago). I am not sure if it is on MS radar though.

 

[Luke Alcatel]

The Ardence product that I mentioned uses MTFTP so maybe MS figures there is
a solution. I looked at this product and I found that remote boot of XPe
clients is only one of this product's capabilities and I learned that even
Ardence personnel were not very good at making that feature work.

Here's my complaint about the unicast excuse. My system consists of up to
72 XPe clients that I prefer to remotely boot. Once it is running each
client gets data in unicast mode from a (non-XPe, non-MS) server. That
server is based on an 800 MHz Power PC with an antiquated (15 year old, not
a zero-copy implementation) IP stack and ethernet driver yet it is capable
of maintaining 150 Mbits/S or more of sustained unicast throughput. The MS
RBS server running on a 2GHZ Pentium-M and on XP Pro or 2003 server doesn't
come close to that performance.

Luke

 

[Luke Alcatel]

Another thought came to me. Maybe the problem with a large number of
clients is not really unicast but disk access. 36 or 72 clients can all be
getting different packets at the same time and depending on the quality of
system disk caching this may lead to a lot of disk access. On the other
hand, disk access wait time should not count as CPU time and my server
should not exhaust a 2GHz CPU when downloading 5-6 clients.

Nonetheless it seems that it would be interesting to see if the RBS
performed a lot better if the image were in a ramdisk. Unfortunately
disk-based Windows doesn't have a ramdisk and I don't know the quality of
existing products. Has anyone tried this strategy? Can anyone point to a
(preferably free) suitable ramdisk? Hint to MS -- it might be a great idea
if there was an option for the RBS default image to be memory cached by the
the RBS application.

Luke

 

[Sean Liming \(MVP\)]

There are two versions that come with the XPe CD - one for W2K server and
the other for Win2003 Server. XP Pro is not supported because you need a
DHCP server

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[KM]

IIRC, you can use RBS on an XP Pro machine as long as you have access to a DHCP server (DHCP server could be running on WS2003 or
even linux box). Basically you only need to set up DHCP options to direct the clients to the right TFTP server on the network.

 

[Sean Liming \(MVP\)]

With RBS the image gets downloaded and executed in RAM (RAM disk), not to
disk.

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[Luke Alcatel]

Seems like my explanation was not clear. Certainly the XPe image gets
downloaded and executed in ramdisk but my discussion and concern is the
performance of the RBS server which gets the SDI image from a disk file. I
was wondering if putting that file in a ramdisk on the RBS might improve the
otherwise woeful performance of that server.

Luke

 

[Luke Alcatel]

Correct. Neither version of the RBS cares or knows anything about the DHCP
server except for needing to know whether it is on the same machine or a
different machine. In my system DHCP is not even a computer -- it is
provided by a board level switch/router. I am not aware that there are two
RBS systems on the CD -- if so maybe that occurred in a recent SP. I have
always used the RBS on the CD with XP Pro and my board-level DHCP but this
RBS has not worked with Win 2003 Server. When I first tried to use RBS on
Win 2003 I found that I needed to download from the link further down in
this thread.

One more thing about RBS performance. On newer "legacy free" hardware both
of the RBS servers for XPe fail. See
http://support.microsoft.com/kb/906425
for the fix required. Although this KB makes no direct mention of XPe the
fix does work for both XPe RBS systems. I lost a lot of time before finding
this solution and I am disappointed that the XPe team has not identified
this issue.

Luke

 

[Sean Liming \(MVP\)]

The article you are refering is RIS not RBS. There is a difference. RIS
installs the OS to the hard drive. RBS downloads the XPe image to RAM and it
runs from a RAM disk. I have never seen a delay in downloading a XPE image
to run on a thin client.

Other DHCP servers on the network are not support in the RBS model. DHCP has
to come from Windows Server since a modification to port 60 is required
during the RBS setup. There are some free DHCP server add ons to XP Pro, but
these don't allow for changes to port 60.

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[Sean Liming \(MVP\)]

Not really. You are just taking RAM away from the server. Large images being
pushed down a busy network are going t be slow to download. Creating an
isolated network dedicated to the thin clients is a better architecture.

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit

 

[Luke Alcatel]

I can only report on what problems I've had, how they were fixed, and how
deployed systems are working. I know the article refers to RIS but the
startrom.com and startrom.n12 are apparently the same as used by RBS,
however this hotfix seems to contain newer versions of those files than the
ones that come with RBS. We use Compact PCI blade computers. We recently
evaluated two different new dual-core cPCI machines from Diversified
Technologies and Kontron. After building XPe images for these machines we
found that RBS downloads were taking about 20 minutes for a single 150MByte
target and the downloads often aborted prematurely. We kicked this problem
back to the board vendors and one of them came up with this KB article. I
was also very skeptical at first but when we replaced the startrom.* files
with the ones from the hotfix, the problem was resolved. Perhaps the
problem is only manifested in a very specific class of machines -- it did
not occur in cPCI machines that we bought about 3 years ago.

The issue involving configuration of port 60 only applies if RBS and DHCP
reside on the same machine. I have never preferred such a configuration
because of robustness concerns and I have always been able to use virtually
any DHCP server including the ones resident in $19 cable routers. In the
cPCI environment there are good reasons to use the DHCP available in PICMG
2.16 switches that are resident in the cPCI chassis. One reason is that
these switches can do slot-specific address assignment. For example, I can
configure DHCP so that the blade computer in slot N always gets the
xxx.xxx.xxx.N IP address. This makes it simple for applications and
operators to correlate error messages to hardware chassis slots. Another
reason is I want a headless, diskless DHCP server for my enterprise-critical
application, not an over-weight Win2003 server. If MS claims that RBS is
only compatible with their DHCP server resident on disk-based machines then
they eliminate a huge class of real-world applications (not that I believe
that MS is concerned about MY real world).

Luke

 

[KM]

Just wanted to confirm that it is indeed ok for TFTP/RBS server to reside on a separate machine from DHCP server. In fact, this
scenario is supported and described in XPe docs (just need to make sure to set "Use DHCP Port (67)" option in RBM).
No need for heavy Win2003 Server if you want to use DHCP on a separate router. TFTP/RBS can run on a client 2K/XP machine.

Startrom.xxx (and other boostrap programs) are indeed interchangeable with RIS just because both servers use the same underlying
technology to deliver the image to the client machines based on PXE protocol and uncast transfers. I also happened to use the RIS's
versions of the boot programs when I was playing with RBS of early versions of XPe.

 

[stevemarfisi]

There is an alternative to diskless boot of XPe that does not use RBS,
nor uses Ardence. Diskless boot of XPe and WEPOS is possible (and
tested in conjunction with Microsoft EMEA) with iSCSI boot...using
emBoot's netBoot/i. The actual process is not any different than using
XP iSCSI boot, and has been proven in commercial implementations
running for 2 years to scale to near 200 clients per single boot
server without issue on 10/100 networks.

Regards,
Steve Marfisi
emBoot Inc.