Some info on SDI and Remote Boot

I've been doing some work for a customer or two involving Remote Boot Services (RBS) and SDI, and have found a few things of interest.

First, SDIMGR.WSF does run under XPE runtimes.  As with most everything XPE-related, however, there are a few caveats:

• You need to add SDIMGR.WSF and SDIAUT.DLL to the runtime (either manually or in a custom component you create - we don't have an SDI component).
• You need to register SDIAUT.DLL before proceeding (manually on the runtime using regsvr32, or as an FBA resource in a custom component).
• The runtime has to have the Windows Script Engines component in it (this is a "duh" info point).
• The runtime has to have the Primitive: Mlang component in it (this was new, and has been bugged).

Second, you can use RBS and SDIMGR.WSF as a deployment mechanism.  Basically, this involved remote booting your device with the media you intend to ship in the device (use the workaround posted earlier), then use SDIMGR.WSF to write the image you wish to ship onto that media.  Note that this means you need two SDI images - one to Remote Boot from, and one to write to the underlying media.  There are some things to be careful of:

• If you use /WRITEDISK, the size of the disk you created the deployment image from will be reflected on the shipping media.  For example, if you created the SDI from a 128Mb flash drive using /READDISK, you will have a 128Mb partition on whatever flash you deploy to, even if it's much larger.  The rest of the space will be unused.
• If you use /WRITEPART to overwrite an existing partition, there will be a disconnect between the partition table and the BIOS parameter block (BPB).  Because /WRITEPART doesn't overwrite the partition table, it will still have the original partition size, but the BPB will have the partition size from the SDI file.  Using the above example, if you use /READPART to create a 192Mb SDI, then use /WRITEPART to write it over an existing 256Mb partition, you should still have a 256Mb partition when you're done.  This doesn't seem to affect the runtime, although CHKDSK may complain about it.  To be honest, I haven't tested it yet.

That's about it, although there is one benefit that is strictly personal.  By engaging in these recent RBS issues, I reconfigured the test machines in my office a little - I now have a private network with a Win2K3 server acting as my remote boot server, one machine acting as a gateway straddling the private and corporate networks, and have trashed an older test machine and replaced it with a better one from the lab (actually, it's an XBox Development Kit machine).  In short, I'm in a much better testing position than I was a month ago, and even have a private network to play around with - no more explaining to our IT department why I need rogue DHCP server on the corporate net!