Deploy XPe to multiple targets (using SDI and EWF)

[dan]

Hi all,

I'm trying to deploy XPe on multiple platforms that each contain
different hardware using a single SDI. To do this, I intend to build an
image that will contain a superset of all the device drivers, so that
every target will be supported.

Our problem is that SDIs are stateless. This causes trouble when the
SDI is run on a platform that contains different hardware to the
original hardware configuration in the SDI. When this occurs, the OS
updates itself to support the new devices, but then prompts for a reset
for the changes to take effect. Because the SDI is read-only, no
information is recorded to say that the new hardware was found on the
last reset and as a consequence, every time we reset, the new hardware
will be found all over again.

I'd like to know if it is possible to deploy an SDI that creates a disk
EWF overlay to store the hardware changes? Ideally, we'd be able to
deploy this SDI and have it write to this EWF overlay *only* on the
*first* boot after deployment (the boot where hardware is found). On
every boot after this point, the EWF overlay should still exist, but be
read-only (or perhaps a 2-overlay EWF that always restores the first
overlay on reboot could also work?).

I understand this would be easier if I wasn't using an SDI (you could
just commit the EWF overlay to the protected volume after the first
boot and then disable it from then on), but the single-file, read-only
nature of the SDI makes it for a nice, robust way to deploy an OS.
Any thoughts on this would be greatly appreciated.

Dan

 

[KM]

Dan,

Hi all,

I'm trying to deploy XPe on multiple platforms that each contain
different hardware using a single SDI. To do this, I intend to build an
image that will contain a superset of all the device drivers, so that
every target will be supported.

Our problem is that SDIs are stateless. This causes trouble when the
SDI is run on a platform that contains different hardware to the
original hardware configuration in the SDI. When this occurs, the OS
updates itself to support the new devices, but then prompts for a reset
for the changes to take effect. Because the SDI is read-only, no
information is recorded to say that the new hardware was found on the
last reset and as a consequence, every time we reset, the new hardware
will be found all over again.

How about running the same image on all the supported hardware (just copying image and let PnP do the job with allreboots
necessary).
And then, after the last piece of hardware was found you capture the final image in SDI.

This is of couse with assumption that you know now all the hardware you are going to run the image on.

I'd like to know if it is possible to deploy an SDI that creates a disk
EWF overlay to store the hardware changes? Ideally, we'd be able to
deploy this SDI and have it write to this EWF overlay *only* on the
*first* boot after deployment (the boot where hardware is found). On
every boot after this point, the EWF overlay should still exist, but be
read-only (or perhaps a 2-overlay EWF that always restores the first
overlay on reboot could also work?).

I could not understand this. What the connections between SDI and EWF?
You probably realize the SDI boot is assuming RAM boot.

I understand this would be easier if I wasn't using an SDI (you could
just commit the EWF overlay to the protected volume after the first
boot and then disable it from then on), but the single-file, read-only
nature of the SDI makes it for a nice, robust way to deploy an OS.
Any thoughts on this would be greatly appreciated.

I am getting a feeling that mentioning "read-only nature of the SDI" you don't actually realize what the SDI is.
SDI is nothing more that just an image captured in a special formatted file.
You can use NT loader to load SDI in RAM and have OS then boot from RAM.
So, the SDI is "read-only" because as soon as ntldr loads the SDI in RAM you are running from RAM as "normal ramdisk storage" and OS
does not know about the original SDI.
But you can certainly update the SDI file itself from your apps if you have it on re-writeable media and know the SDI firmat
(undocumented but you can use SDIMgr to update the file content).

 

[Dan]

Hey KM, thanks for the quick reply.

How about running the same image on all the supported hardware (just

copying image and let PnP do the job with

allreboots necessary).
And then, after the last piece of hardware was found you capture the final image in SDI.
This is of couse with assumption that you know now all the hardware

you are going to run the image on.

Ideally, I'd like to only support a single read-only image without
having to maintain differences between platforms in separate images.
Over time, it is likely that software on the images will also need to
be updated (software that is installed during the FBA process, before
the reseal phase). As I support more platforms, I would need to
maintain that software on more images and this could become time
consuming. I may investigate updating this software remotely later on,
if I cannot come up with a reasonable single-image solution to my
problem.

I could not understand this. What the connections between SDI and EWF?
You probably realize the SDI boot is assuming RAM boot.

You're right, there's no real link between those two things. I did not
think to write back to the SDI from the RAMDisk. I was wondering if it
would be possible to boot the SDI into RAM and still have an EWF disk
overlay that would be used to permanently store the hardware device
configuration, essentially giving the SDI state between boots (and
hopefully somehow making that overlay read-only after the first boot).
Committing the hardware device configuration changes made during the
first boot back to the original SDI seems like a much better solution.

But you can certainly update the SDI file itself from your apps if

you have it on re-writeable media and know the SDI firmat

(undocumented but you can use SDIMgr to update the file content).

This sounds interesting. I have had a play with this since I read your
email and now I am having trouble getting SDIMgr to read the SDI in RAM
back to the SDI file. I get the error "reading from volume C:\ -
SDIAUT.SDIFILE.1 Access is denied". This seems to be to do with SDIMgr
having trouble obtaining read-access to the RAMDisk (which makes
sense). Any workarounds? All I can think of is to copy the contents of
the RAMDisk to a partition of the same size as the RAMDisk (or a little
bigger) and get SDIMgr to read from that instead.

Also, is there a way to reseal an image without it rebooting
automatically?

Thanks,

Dan

 

[KM]

Dan,

....
Ideally, I'd like to only support a single read-only image without
having to maintain differences between platforms in separate images.

Please take a read through this thread:
http://groups-beta.google.com/group..._frm/thread/18f886794b5ed5ff#b0ce27f178e84b4e.
You will get some good ideas from Slobodan input on how to support multiple platforms from on image.

Over time, it is likely that software on the images will also need to
be updated (software that is installed during the FBA process, before
the reseal phase). As I support more platforms, I would need to
maintain that software on more images and this could become time
consuming. I may investigate updating this software remotely later on,
if I cannot come up with a reasonable single-image solution to my
problem.

Makes sense.

You're right, there's no real link between those two things. I did not
think to write back to the SDI from the RAMDisk. I was wondering if it
would be possible to boot the SDI into RAM and still have an EWF disk
overlay that would be used to permanently store the hardware device
configuration, essentially giving the SDI state between boots (and
hopefully somehow making that overlay read-only after the first boot).
Committing the hardware device configuration changes made during the
first boot back to the original SDI seems like a much better solution.

I am sorry but I am again not clear on how you were planning to use EWF and store hardware device configuration on the HDD if you
boot from an SDI image (RAM disk)?
You entire OS partition is in RAM including registry, etc. What exactly you're planning to have/store on HDD? And how you're going
to use EWF?

you have it on re-writeable media and know the SDI firmat

This sounds interesting. I have had a play with this since I read your
email and now I am having trouble getting SDIMgr to read the SDI in RAM
back to the SDI file. I get the error "reading from volume C:\ -
SDIAUT.SDIFILE.1 Access is denied". This seems to be to do with SDIMgr

No, I actually did not mean to update the SDI file online. There is no way to do that unless you read raw data off the OS disk
(RAMDisk) and somehow write it back to the SDI file. I am afraid you would need to know the exact SDI file format since you are not
going to use SDIMgr this way.

having trouble obtaining read-access to the RAMDisk (which makes
sense). Any workarounds? All I can think of is to copy the contents of
the RAMDisk to a partition of the same size as the RAMDisk (or a little
bigger) and get SDIMgr to read from that instead.

I guess you could use HDD as a temporary storage to expand and then capture the SDI file on the fly.
In other words, from the running RAM boot image you:
- prepare the target HDD partition
- launch SDIMgr /writepart on that partition
- changes any binaries/applications/etc on that partition (offline image)
- if necessary, load up the offline image registry hives (use reg.exe /LOAD) and change required reg.entries
- launch SDIMgr /readpart to update the SDI file content

But I really failed to see why you need to update the SDI file online?
And even more, why do you need to SDI/RAM boot at all if you have disk-based devices?

Could you expand a little bit more on the device usage scenerio?

Also, is there a way to reseal an image without it rebooting
automatically?

http://msdn.microsoft.com/library/d.../xpehelp/html/xeconcustomizingresealphase.asp
Take a look at the cmiResealDLLEntry (set OnResealComplete =FALSE).

KM

 

[Slobodan Brcin \(eMVP\)]

Hi Dan,

I wanted EWF that will support simultaneous RAM and Disk Overlay, so I can use read-only medium for boot and then move OS updates to
HDD overlay. RAM overlay would allow me stateless operation as usual.
In case that I need to update OS I would be able to commit changes from RAM overlay to "virtual disk" consisted of read-only disk
and HDD overlay.
If there is error or virus strike I could be able to discard disk overlay and to do factory boot from read only disk.

You case sound similar to what I want but you instead of RAM EWF want to use SDI RAM disk for OS, right?

This can be done but it would require tweaking of ntldr that we can't do. (Or we can change int 13 calls that ntldr use but this is
too complicated to implement with all changes that would be required.)

Regards,
Slobodan

 

[Dan]

KM,

Please take a read through this thread:
http://groups-beta.google.com/group..._frm/thread/18f886794b5ed5ff#b0ce27f178e84b4e.
You will get some good ideas from Slobodan input on how to support

multiple platforms from on image.

That is an interesting read, but does not solve my current problem. At
the moment, I'm not too worried about having to add more components to
my image every time I need to support a new device, but I think what
Slobodan suggests in that thread is a great idea.

I am sorry but I am again not clear on how you were planning to use

EWF and store hardware device configuration on the HDD if you

boot from an SDI image (RAM disk)?
You entire OS partition is in RAM including registry, etc. What

exactly you're planning to have/store on HDD? And how you're going

to use EWF?

Slobodan's reply to my message explains it nicely. I want disk EWF for
an SDI. Sorry for not explaining myself properly.

No, I actually did not mean to update the SDI file online. There is

no way to do that unless you read raw data off the OS disk

(RAMDisk) and somehow write it back to the SDI file. I am afraid you

would need to know the exact SDI file format since you are not

going to use SDIMgr this way.

That is unfortunate For a second there, I was thinking this was
going to be easy.

But I really failed to see why you need to update the SDI file online?
And even more, why do you need to SDI/RAM boot at all if you have disk-based devices?

Could you expand a little bit more on the device usage scenerio?

Ok, the main reason that I am using SDI, even though we have disk-based
devices to store an XPe image on, is packaging. SDI is a single file
and is easier and more reliable to deploy than a bunch of directories.

The platforms I develop for contain (amongst other devices) both CDROMs
and HDDs. Applications installed on the image require the use of HDD.
Here are the general requirements for my XPe platform:

- easy to maintain
- easy to deploy
- stateless operation

To answer your question, the reason I'd like the SDI to update online
is automation. It would be nice to be able to deploy a single SDI to
multiple platforms and for each platform the SDI is deployed on, the
SDI would:

- automatically update hardware via PnP

then, using a timer (is there an easy way to detect when PnP is
finished?), perform the following tasks:

- seal itself (it would be deployed as unsealed, to enable cloning)
- update the SDI file on disk, from the sealed and configured online
image on the RAMDisk
- restart

From this point on, each deployed SDI would be up-to-date with its

platform's hardware and operate in a stateless mode. Is anything like
this possible? I think this would be a lot easier to accomplish if I
was deploying XPe images as files and directories and not SDIs:

- deploy non-SDI image with EWF RAM overlay currently set to "disabled"
- automatically update hardware via PnP
- using a timer (?) seal itself (it would be deployed as unsealed, to
enable cloning)
- restart
- enable RAM overlay via startup/run

Sound reasonable? It would still allow the deployment of a single image
across multiple platforms with stateless operation, but just not as an
SDI.

http://msdn.microsoft.com/library/d.../xpehelp/html/xeconcustomizingresealphase.asp
Take a look at the cmiResealDLLEntry (set OnResealComplete =FALSE).

Cool.

Thanks again,

Dan

 

[Slobodan Brcin \(eMVP\)]

Dan,

then, using a timer (is there an easy way to detect when PnP is
finished?), perform the following tasks:

Look at:
CMP_WaitNoPendingInstallEvents
http://groups-beta.google.com/group...tallEvents&qt_g=1&searchnow=Search+this+group

Regards,
Slobodan

 

[KM]

Dan,

EWF and store hardware device configuration on the HDD if you
exactly you're planning to have/store on HDD? And how you're going

Slobodan's reply to my message explains it nicely. I want disk EWF for
an SDI. Sorry for not explaining myself properly.

Well.. I can understand the use of RAM and Disk based overlays simulteniouly but not RAMDisk.
Anwyay, I got your point now that you want to have a stateless OS boot and EWF disk overlay for updates.
Then SDI would not be a good choice here.

Ok, the main reason that I am using SDI, even though we have disk-based
devices to store an XPe image on, is packaging. SDI is a single file
and is easier and more reliable to deploy than a bunch of directories.

For the easy deployment (no EWF) option you can choose any archive (e.g., zip). How and when you "expand" the file on target storage
would be up to you.

When EWF comes in the picture and you want to have disk based overlay (meaning that you will need the EWF configuration partition)
you can choose Ghost or etc.

The platforms I develop for contain (amongst other devices) both CDROMs
and HDDs. Applications installed on the image require the use of HDD.
Here are the general requirements for my XPe platform:

- easy to maintain
- easy to deploy
- stateless operation

To answer your question, the reason I'd like the SDI to update online
is automation. It would be nice to be able to deploy a single SDI to
multiple platforms and for each platform the SDI is deployed on, the
SDI would:

- automatically update hardware via PnP

then, using a timer (is there an easy way to detect when PnP is
finished?), perform the following tasks:

Search Google/MSDN/DDK for CMP_WaitNoPendingInstallEvents.

- seal itself (it would be deployed as unsealed, to enable cloning)
- update the SDI file on disk, from the sealed and configured online
image on the RAMDisk
- restart

platform's hardware and operate in a stateless mode. Is anything like
this possible? I think this would be a lot easier to accomplish if I
was deploying XPe images as files and directories and not SDIs:

- deploy non-SDI image with EWF RAM overlay currently set to "disabled"
- automatically update hardware via PnP
- using a timer (?) seal itself (it would be deployed as unsealed, to
enable cloning)
- restart
- enable RAM overlay via startup/run

Sound reasonable? It would still allow the deployment of a single image
across multiple platforms with stateless operation, but just not as an SDI.

The problem with any approach you take I see in automation. You don't want to be watching on and interfering with the deployment and
update process, right?
Since you want to deploy/capture the OS image you must do that offline (unless, again, you copy the raw disk data).
So you can consider a scenario when you use another SDI (Mini) image for Remote Boot or local boot off a CD. This image will include
all the logic you may need:
- Copy the Full image off the network or local media (like CD/DVD-ROM)
- Reboot and boot in to the full image (easy with the initial CD-ROM boot but harder with the initial PXe boot as you have to
somehow abort the PXe program on this next boot)
- Allow the Full image to boot completely, run PnP to find all the hardware, update everything it needs to update, etc. Then
Full image reseal itself and shuts itself down.
- Here you must force the Mini image boot again. The Mini will capture the Full image off the HDD and transfer the captured
file(s) over network to whatever server share you supply.

If you have a way to partition HDD first, you can have a small bootable partition there with the Mini image in place. Then playing
with boot.ini to boot either to Mini or Full image you can easy switch back and force to allow any updates on the Full image. You
don't even necessarily have to have a separate partition for the Mini image but rather a separate Windows folder (you just don't
have to copy it over network to the final server share).
Does this make a sense?

I have implemented something similar a while ago.

 

[Dan]

Thanks for the replies KM and Slobodan. I think I'll just go with a
non-SDI image solution with EWF RAM for the time being. KM, the 2 SDI
solution does sound interesting and it did make sense, but for now it
will be a lot easier to just use a plain XPe image.

Cheers,

Dan

 

[KM]

Absolutely.

Actually you can always go back to revisit and review possible solutions for automating deployment and the whole image update
processes later.

 

[Dan]

Does this seem like an inherently bad way to support multiple platforms
with one image? Here goes:

- Run TAP.exe on each targetted platform

- Merge the differences in each resulting .PMQ file to create a .PMQ
file that contains a superset of the devices for all targetted
platforms

- Create device components as necessary

- Create superset device component from superset .PMQ

- Include superset device component in image

I've had success with this in the past, but it does seem pretty dodgy?
Thoughts or better solutions? I'll have a think about the link you
posted earlier, KM.

Cheers,

Dan

 

[Dan]

Does this seem like an inherently bad way to support multiple platforms
with one image? Here goes:

- Run TAP.exe on each targetted platform

- Merge the differences in each resulting .PMQ file to create a .PMQ
file that contains a superset of the devices for all targetted
platforms

- Create device components as necessary

- Create superset device component from superset .PMQ

- Include superset device component in image

I've had success with this in the past, but it does seem pretty dodgy?
Thoughts or better solutions? I'll have a think about the link you
posted earlier, KM.

Cheers,

Dan

 

[KM]

Dan,

I don't see problems with your approach. In case of any possible conflict you can always resolve it manually.

Instead of messing up with PMQ you can copy/paste between component SLDs that you got by importing each PMQ.

KM

 

[Dan]

Hey KM,

I always just assumed slds were binaries. That sounds like a plan.
Merging PMQs is pretty messy.

Dan

 

[KM]

Dan,

SLD is XML based format.
But I was not talking about changing the SLDs with notepad. Use CD (Component Designer). Just open Cd with a few SDLs in it (or a
few CDs ) and use drag and drop (or Copy/Paste) to copy resources or dependency items (this is what you need to merge now).

KM

 

[Dan]

Quick reply! Right after I typed that I had a think about what you'd
said and came back to correct myself I guess you could also just add
each PMQ component into the image being created in TD. Or a more
organised way might be a macro component of PMQs?

Dan

 

[KM]

Dan,

I always prefer macro components (created with CD) over the import in TD.

KM