Alternative mass deployment question

[Guest]

OK,

I've read all the Microsoft online docs, perused the newsgroups, and looked
at several other websites for info on how one builds and mass deploys XPe (in
my situation, the target device is a thin client, and all clients are
configured *exactly* the same). The way I understand it is as follows:

1) Get the Windows XP Embedded Toolkit (which I did). I got the evaluation
version from the MS website. I *tried* to get a non-evaluation version via my
MSDN Universal subscription, but couldn't find it anywhere. A call to the
MSDN help line (and 10 min on hold *after* asking where I could get a
non-eval copy of XPe SP2) resulted in the rep saying the person she asked
thought it was available only as an eval copy, but the guy who would *really*
know didn't come in for another 45 minutes. She said she'd call back in about
an hour. It is now more than 24 hours later, and no return call (sigh).
Further probing by me on the MSDN Library site led me to the Windows Embedded
Developer Center, which revealed that the official process is to get the eval
version, do your evaulation, then "you should engage with a distribution
partner. The distribution partner will assist you in purchasing the full
packaged product (FPP) for either Windows CE or Windows XP Embedded tools."
Seems odd, but OK...

2) Install it on your development machine (XPe SP1, then SP2, blah, blah).
It makes things simpler if the dev machine has XP running on it.

3) Run TAP.EXE on the target device (via WinPE, which is on the 1st CD of
the Toolkit), which creates "Devices.pmq", which is an XML file containing
the configuration. Then (somehow) get this on your development machine.

4) Run Component Designer, which uses Devices.pmq from the previous step to
create a new component in a file called "Devices.sld". Save Devices.sld to
the Component Database.

5) Run Target Designer, using the component saved to the Component DB in the
previous step.
- Add other components (NTFS, etc.)
- Add System Cloning Tool (this is a key step for mass deployment)
- Update the configuration settings (menus, target disk)
- Check dependencies
- Generate the XPe image (in the run-time images build directory)

6) Somehow copy the image from the build directory to the target device

7) Run First Boot Agent (FBA) on the target device, but stop it before it
reboots

8) Run FBRESEAL.EXE on the target (IIRC, using, again, PE)

9) Save the image that now resides on the target device (which is referred
to as the "Master Runtime Image"), to a boot server enabled machine. We
accomplish this by booting WinPE & running the SDI Manager.

10) Deploy the image to other client target devices by using PXE to download
WinPE from the bootserver (to memory, and run it in memory), then use the SDI
Manager to download the XPE image to persitent storage on the target (flash
memory, in my case).

11) Reboot the client. FBA will now finish running (PnP, SID replacement,
computername, etc), and will reboot the system. When it reboots this time, it
will be running XPe, with an unique SID and computername. (Whew!).

I realize that, with thin clients, there will be issues with enabling and
disabling the write filter (EWF) to the flash memory. I'm not saying I
*fully* understand when to enable/disable, just that it has to be done. 8^)


So, why did I go through all this?
First, to see if I have the concepts down right. (Fire away...)

Next, allow me to describe what I'd like to do, and see what alternatives
others think may be possible.

What I'd really like to do:

A) Take a thin client that has a running version of XPe. This could be the
result of:
1) having gone through all of the above, or
2) having done a single "normal" installation without the extra steps
(add cloning, stop FBA, reseal, save, deploy) and just let FBA generate a
running XPe on the target thin client, or
3) using the config that came installed on the box from the factory.

B) Save that image to disk on another machine.
- I figure the 2 options are boot PE into memory and use SDI Manager, or
boot Linux into memory and use dd(1) and curl(1)

C) Reset all the "uniqueness" info (SID, computername, etc.). How? Good
question.

D) Put the resultant "golden" image on a boot server.

E) PXE boot the target client to either PE or Linux (into memory), which
would then lay down the golden image into the flash memory.

F) Reboot, and let FBA fill in the "uniqueness" info.

Problem with this is that FBA won't be on the image (having been removed
after creating the final (runnable) image on the device we are now using as a
source for the image), so I guess I'd have to put it on the image between
steps A) and B). Another problem is that Microsoft says that you can't run
FBA a second time, or you're likely to hose up some things. Has this proved
true in practice? If so, what does it mangle?

So, a second option would be to change step C) to "Put a tool like
Sysinternal's 'newsid' on the image, and do some sort of 'runonce' setup so
that it runs in step F), then goes away". But I've read that "newsid" hoses
up some registry setting for COM. True?


So much for what I'd really like to do. What may be acceptable:

I) Go through the "standard" process I outlined at the beginning of this
message, through step 8).

II) In my case, there may be advantages to using Linux in place of WinPE, so
I'd still do steps 9) through 11), but instead of using PE and the SDI tools,
I'd use Linux and dd(1)/curl(1).


So, other than "Am I nuts/full-of-beans?", I have a few questions (in
addition to the ones imbedded above):

Q1) Does the SDI Manager (either when saving a golden image or laying one
down on a client) do anything more just a straight bit copy of the "disk"
image to a file, or vice versa (like dd(1) under Linux)?

Q2) From a description of the Sytem Cloning Tool, it looks like the
following are the items that are "reset":
Computer SID
Computer Name
Automatic Logon Settings
Domain Participation
Network Settings
User Specific Settings
Mounted Devices (substituted drive letters, etc.)
Is this list complete? Also, since all my devices are identical, and all
the stuff after Computer Name will likely be identical in my case, it seems
like the only stuff that *has* to be changed are SID and computername. Right?


Note: I've also read that Norton Ghost and Altiris do SID/compname reset,
but they're not options for me.

Phew. OK. Fire away...

Regards,

Gerry Green
Win XPe Newbie

 

[Slobodan Brcin \(eMVP\)]

Gerry,

Feeww I read this and forgot what were the questions. But it look for me
that you know exactly what must be done if you don't want to use third party
alternatives.

Q1) Does the SDI Manager (either when saving a golden image or laying one
down on a client) do anything more just a straight bit copy of the "disk"
image to a file, or vice versa (like dd(1) under Linux)?

For successful image copy they should dismount all volumes that belong to
source disk. I must say that I do not use it so I can't tell whether they
did job correctly. But you can test this easily while doing disk copy open
some volume first or second and see if it can be done. If you are successful
then fill bug report to MS and let us know here. (And do not use sdi manager
any more). If it dismount all volumes then let us know and in this case it
should be ok to use it.

Q2) From a description of the Sytem Cloning Tool, it looks like the
following are the items that are "reset":

Fortunately these are things that it can do. (They are optional). Go to
component advanced properties for System Cloning Component and play with
values.
Also I think that most people set there cmiResealPhase to 0 (manual) so that
after FBA they have a chance to set things manually and then call fbreseal
when you are done.
Next time when you boot copied image your image will be reset to specified
values.
Also you can specify cmiResealDll and entry so that after cloning is done on
copied device your function is executed that can enable EWF do some stuff
and shutdown or reboot computer.

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Forgot to ask something:

Note: I've also read that Norton Ghost and Altiris do SID/compname reset,
but they're not options for me.

I have read this also but I have not seen it in work.
Has anyone used these SID reset options? When SID change occur? Do they just
provide tool like fbreseal or have some better approach?

Regards,
Slobodan

 

[KM]

Gerry,

1) Get the Windows XP Embedded Toolkit (which I did). I got the evaluation
version from the MS website. I *tried* to get a non-evaluation version via my
MSDN Universal subscription, but couldn't find it anywhere.

You won't find it there. Microsoft Embedded OSes are not in MSDN subscriptions (probably because of runtime licencing).
You will need to order the Toolkit from one of MS XPe distributors or MS directly.

version, do your evaulation, then "you should engage with a distribution
partner. The distribution partner will assist you in purchasing the full
packaged product (FPP) for either Windows CE or Windows XP Embedded tools."
Seems odd, but OK...

You are better off calling an XPe distributor and they will be happy to explain you all the details.
Just general licencing FAQ you can read here: http://www.bsquare.com/licenses/resourcecenter/faqswinxpembed.asp

8) Run FBRESEAL.EXE on the target (IIRC, using, again, PE)

What do you mean "using PE"?
You should run the fbreseal.exe at run time of the XPe image.

I realize that, with thin clients, there will be issues with enabling and
disabling the write filter (EWF) to the flash memory. I'm not saying I
*fully* understand when to enable/disable, just that it has to be done. 8^)

Yup.. EWF and Cloning need to be "corrected" a bit.
http://msdn.microsoft.com/library/d...esignconsiderationsforusingewfwithcloning.asp

Or you can use the Ghost (some known issues there can also be overcome).

A) Take a thin client that has a running version of XPe. This could be the
result of:
1) having gone through all of the above, or
2) having done a single "normal" installation without the extra steps
(add cloning, stop FBA, reseal, save, deploy) and just let FBA generate a
running XPe on the target thin client, or
3) using the config that came installed on the box from the factory.

Either of these has Pro's and Con's.

B) Save that image to disk on another machine.
- I figure the 2 options are boot PE into memory and use SDI Manager, or
boot Linux into memory and use dd(1) and curl(1)

One more useful option here - you own small XPe image there.
You can (as with Linux) do any customizations, optimization and etc. there.

C) Reset all the "uniqueness" info (SID, computername, etc.). How? Good
question.

Couldn't quite get this one. Reset the "uniqueness" info where?
You golden image was already "reset" by running fbreseal.exe just before you shut it down.

D) Put the resultant "golden" image on a boot server.

E) PXE boot the target client to either PE or Linux (into memory), which
would then lay down the golden image into the flash memory.

Again one more option is XPe image. See above.

F) Reboot, and let FBA fill in the "uniqueness" info.

Problem with this is that FBA won't be on the image (having been removed
after creating the final (runnable) image on the device we are now using as a
source for the image), so I guess I'd have to put it on the image between
steps A) and B). Another problem is that Microsoft says that you can't run
FBA a second time, or you're likely to hose up some things. Has this proved
true in practice? If so, what does it mangle?

I never heard of that. Maybe you meant no second run for fbreseal.exe?

So, a second option would be to change step C) to "Put a tool like
Sysinternal's 'newsid' on the image, and do some sort of 'runonce' setup so
that it runs in step F), then goes away". But I've read that "newsid" hoses
up some registry setting for COM. True?

Yup. Search NG archive. Mark reported the problem a couple of times already.

So much for what I'd really like to do. What may be acceptable:

You forgot to list your own requirements (preferences) for the deployment process. E.g., having complex factory mode sometimes is
not acceptable or too expensive.
That will make a difference.

I) Go through the "standard" process I outlined at the beginning of this
message, through step 8).

II) In my case, there may be advantages to using Linux in place of WinPE, so
I'd still do steps 9) through 11), but instead of using PE and the SDI tools,
I'd use Linux and dd(1)/curl(1).

In you happen to like SDI Manager, you can go with the small XPe approach too.

So, other than "Am I nuts/full-of-beans?", I have a few questions (in
addition to the ones imbedded above):

Q1) Does the SDI Manager (either when saving a golden image or laying one
down on a client) do anything more just a straight bit copy of the "disk"
image to a file, or vice versa (like dd(1) under Linux)?

You better test this. What is the purpose of this question?
It is rather obvious that the data from the SDI disk comes without any changes (a bit copy). Only differences you may expect in boot
sectors.

For the image content it would be a matter of fbreseal parameters that will keep some image characteristics unique (reset) or
common.

Q2) From a description of the Sytem Cloning Tool, it looks like the
following are the items that are "reset":
Computer SID
Computer Name
Automatic Logon Settings
Domain Participation
Network Settings
User Specific Settings
Mounted Devices (substituted drive letters, etc.)
Is this list complete? Also, since all my devices are identical, and all
the stuff after Computer Name will likely be identical in my case, it seems
like the only stuff that *has* to be changed are SID and computername. Right?

Look at the fbreseal command line usage to see what settings can be kept on cloning:
http://msdn.microsoft.com/library/d.../en-us/xpehelp/html/xelrffbresealcommands.asp
Or you can set this up from TD with the extended properties of System Cloning Tool component.

Note: I've also read that Norton Ghost and Altiris do SID/compname reset,
but they're not options for me.

Why not? Any particular restrictions there?

Phew. OK. Fire away...

That was a long post

 

[Gerry Green]

Slobodan,

Thanks for your feedback. Please see follow-up question below...

Gerry

For successful image copy they should dismount all volumes that belong to
source disk. I must say that I do not use it so I can't tell whether they
did job correctly. But you can test this easily while doing disk copy open
some volume first or second and see if it can be done. If you are successful
then fill bug report to MS and let us know here. (And do not use sdi manager
any more). If it dismount all volumes then let us know and in this case it
should be ok to use it.

I assume you mean when saving a golden image from the target (thin) client
to a server, right?

Since the SDI Manager runs under WinPE, from your description I would assume
that WinPE automatically mounts any volumes described in the MBR on
persistent storage (in my case, flash memory). Is that correct?

 

[Slobodan Brcin \(eMVP\)]

Gerry,

I assume you mean when saving a golden image from the target (thin) client
to a server, right?

Since the SDI Manager runs under WinPE, from your description I would
assume
that WinPE automatically mounts any volumes described in the MBR on
persistent storage (in my case, flash memory). Is that correct?

Basicaly as long as you don't access volumes, FS on them should remain
relatively closed. I do not know exact time when FS will be open or if they
will be (if you don't access them).
But I always prefer to play safe by first closing all FS and then accessing
disk directly.
Whether SDIManager does that I do not know.

Keep one FS open and try using SDIManager and you will see if it will report
error and refuse to copy data.

Regards,
Slobodan

 

[Gerry Green]

KM,

Many thanks for the reply. See responses below.

Gerry

===================

Gerry, ...

What do you mean "using PE"?
You should run the fbreseal.exe at run time of the XPe image.

Oops. I should have gone back to review this before posting. You are, of
course, correct.
...

Either of these has Pro's and Con's.


One more useful option here - you own small XPe image there.
You can (as with Linux) do any customizations, optimization and etc.

there.

I'm not sure what you mean by this. I think you may have misunderstood what
I'm trying to do (sorry if I wasn't clear). Basically, what I'm trying to do
in steps A through F is to take an installed, running version of XPe on a
client (already gone through final FBA at the factory or wherever), and turn
*that* into a golden image which I can then mass deploy on a number of
exactly configured clients. I don't want to cutomize anything at this step.
I just want to (eventually) get an unique SID and computername, and maybe
set the network settings when it boots first time after installation.

Couldn't quite get this one. Reset the "uniqueness" info where?

The same places fbreseal would reset them.

You golden image was already "reset" by running fbreseal.exe just before

you shut it down.

But I'm not working with a golden image at this point: I'm working with a
"finalized" image (see above).

I think I may have mislead you again. The "target client" I was referring to
here would be a brand new thin client out of the box which may have
*nothing* on it (bare metal).

I never heard of that. Maybe you meant no second run for fbreseal.exe?

Oops (again). Sorry. I was thinking fbreseal, and typed FBA.

...

You forgot to list your own requirements (preferences) for the deployment

process. E.g., having complex factory mode sometimes is

not acceptable or too expensive.
That will make a difference.

Uhh, I'm not following you here. Could you explain further?

In you happen to like SDI Manager, you can go with the small XPe approach

too.

I can see doing that for step 9) (saving the golden image). Thanks.
But I don't think that I can do that for downloading the image, as the
target client may be bare metal.

You better test this. What is the purpose of this question?

Basically, just want to see if I can use the dd(1) command in Linux.

It is rather obvious that the data from the SDI disk comes without any

changes (a bit copy). Only differences you may expect in boot

sectors.

Ah. From my reading, it wasn't obvious. What changes would SDI make in the
boot sectors? I read something about going from a 2-disk to 1-disk device,
with the result being a swap in device names. But that wouldn't hold for me.
Is that what you meant?

...

Why not? Any particular restrictions there?

Yep. Can't really explain, though.

That was a long post

Yeah, I know. Sorry. But I wanted to
1) see if I got the basic premises right (from start to finish)
2) show that I did my homework
3) explain my situation to suggestions could be tailored to it, if possible.

I'll try to make future posts shorter. 8^D
Many thanks for your patience...

 

[KM]

Gerry,

there.

I'm not sure what you mean by this. I think you may have misunderstood what
I'm trying to do (sorry if I wasn't clear). Basically, what I'm trying to do
in steps A through F is to take an installed, running version of XPe on a
client (already gone through final FBA at the factory or wherever), and turn
*that* into a golden image which I can then mass deploy on a number of
exactly configured clients. I don't want to cutomize anything at this step.
I just want to (eventually) get an unique SID and computername, and maybe
set the network settings when it boots first time after installation.

I think I perfectly understood you at first place but I should have moved my comment here to item E below.

The small XPe image I mentioned is the "deployment way" for you to use instead of the WinPE or Linux. Basically, you create a small
RAM-boot XPe image that supports required functionality (network, sdiaut.dll/sdi manager, etc.) and using Remote Boot Manager you
deploy the image to your target devices over PXe. Or you can create a bootable CD/DVD (or USB key or etc.) with the small image
running from it and give the CDs to technicians who install the targets.
From that working small image you can properly partition/format the target storage, download the big (main) XPe image off a server
and properly lay down it on the target media. Then you just reboot/shut down the device and you are done. All steps can perfectly be
automated (this is what I meant by the customizations). This approach have been adopted and used by many of us here.

If you don't have problems with Linux image it may appear to be even better solution since there won't be any limitations as you
would have with XP binaries (WinPE, XPe). This would be a matter of your own personall preferences to choose XPe or Linux as the
"deployment transport".

WinPE is obviously less customizable than others. Although this is changing now and Microsoft allows to do much more there than it
used to be.

Does this make sense?

The same places fbreseal would reset them.

you shut it down.

But I'm not working with a golden image at this point: I'm working with a
"finalized" image (see above).

You got the golden image at this pont (I see the next step D where you're already playing with the golden image )

Basically, your golden image has to be sealed with the fbreseal. So that booting the image next time (on all the target devices)
will produce unique characteristics as desired - computer name, SID, etc.

I think I may have mislead you again. The "target client" I was referring to
here would be a brand new thin client out of the box which may have
*nothing* on it (bare metal).

I understand that. That is usually the case when you deploy an image to a number of devices.
Basically my comment above about replacing WinPE/Linux with a small XPe image applies here.

Oops (again). Sorry. I was thinking fbreseal, and typed FBA.

Then.. Only "some" components may be a trouble for the second launch of fbreseal.exe. I only remember IIS being such component.
The proper info is that Microsoft has not tested (officialy) the fbreseal launching more than one time.
If you don't have IIS in your image you may consider having the fbreseal laucnhed as many times as you may need. But keep in mind
that you will be responsible for testing the image after cloning very much.

...
process. E.g., having complex factory mode sometimes is

Uhh, I'm not following you here. Could you explain further?

Never mind. I was basically referring to what deployment environments you will have. Do you need to have all the devices coming out
the factory ready for boot (this means you run cloning before they leave the factory), or do you let them out sealed (the cloning
happens on final site where technicians install the devices).
Also, at factory mode there may be some differences in the procedure depending on the staff level you are planning to use and number
of devices/time.

too.

I can see doing that for step 9) (saving the golden image). Thanks.
But I don't think that I can do that for downloading the image, as the
target client may be bare metal.

Although they are bare metal, what is there on the target initially? Can they be booted to a CD image? Or is the PXE support there
in BIOS or NIC ROM? Etc.

Basically, just want to see if I can use the dd(1) command in Linux.

Yes, you can use the dd command.

changes (a bit copy). Only differences you may expect in boot sectors.

Ah. From my reading, it wasn't obvious. What changes would SDI make in the
boot sectors? I read something about going from a 2-disk to 1-disk device,
with the result being a swap in device names. But that wouldn't hold for me.
Is that what you meant?

No.
The point was that it doesn't do more than just a straight bit copy.
I just recall some bug reports about the boot sectors that appear after using sdi2hd tool.
But you won't have problems if you partition the target storage first and the SDI file has only PART BLOBs in it.

Regards,
KM

 

[Gerry Green]

KM,

Thanks. See responses below.

Gerry

========================

Gerry,


I think I perfectly understood you at first place but I should have moved

my comment here to item E below.

The small XPe image I mentioned is the "deployment way" for you to use

instead of the WinPE or Linux. Basically, you create a small

RAM-boot XPe image that supports required functionality (network,

sdiaut.dll/sdi manager, etc.) and using Remote Boot Manager you

deploy the image to your target devices over PXe. Or you can create a

bootable CD/DVD (or USB key or etc.) with the small image

running from it and give the CDs to technicians who install the targets.
From that working small image you can properly partition/format the target

storage, download the big (main) XPe image off a server

and properly lay down it on the target media. Then you just reboot/shut

down the device and you are done. All steps can perfectly be

automated (this is what I meant by the customizations). This approach have

been adopted and used by many of us here.

If you don't have problems with Linux image it may appear to be even

better solution since there won't be any limitations as you

would have with XP binaries (WinPE, XPe). This would be a matter of your

own personall preferences to choose XPe or Linux as the

"deployment transport".

WinPE is obviously less customizable than others. Although this is

changing now and Microsoft allows to do much more there than it

used to be.

Does this make sense?

Ah. Yes. Now I understand what you mean. Thanks.

You got the golden image at this pont (I see the next step D where you're

already playing with the golden image )

Basically, your golden image has to be sealed with the fbreseal. So that

booting the image next time (on all the target devices)

will produce unique characteristics as desired - computer name, SID, etc.

Ah, I think I see the confusion here. I was using the term "golden" the same
way the Microsoft online docs used them. That is, just after going through
(the first, and only) fbareseal, and *before* ever having gone through final
FBA on the target client. Since the image I referenced has more than likely
gone through the whole cloning process already (including, obviously, the
reseal phase), I did not consider it golden.

From your comments here and below (regarding a second reseal), I think you
are using "golden" in a more generic sense. That the image I mentioned in
steps A & B is kind of a golden image, since you know I can still reseal it,
even though it has been resealed previously.

I understand that. That is usually the case when you deploy an image to a number of devices.
Basically my comment above about replacing WinPE/Linux with a small XPe

image applies here.

Ah. Yes. I understand.

Then.. Only "some" components may be a trouble for the second launch of

fbreseal.exe. I only remember IIS being such component.

The proper info is that Microsoft has not tested (officialy) the fbreseal launching more than one time.
If you don't have IIS in your image you may consider having the fbreseal

laucnhed as many times as you may need. But keep in mind

that you will be responsible for testing the image after cloning very

much.

Yeah, I remember Microsoft explicitly mentioning IIS. I took it as "this is
just one of a number possible (probable?) issues". Thanks for the
clarification. I will keep this in mind.

Never mind. I was basically referring to what deployment environments you

will have. Do you need to have all the devices coming out

the factory ready for boot (this means you run cloning before they leave

the factory), or do you let them out sealed (the cloning

happens on final site where technicians install the devices).
Also, at factory mode there may be some differences in the procedure

depending on the staff level you are planning to use and number

of devices/time.

Ah. I think I undrstand now.

Although they are bare metal, what is there on the target initially? Can

they be booted to a CD image? Or is the PXE support there

in BIOS or NIC ROM? Etc.

PXE support in NIC. I think your clarification of "the small XPe approach"
applies here also. I can now see how that would work.

Yes, you can use the dd command.

That's good to hear. Thanks.

No.
The point was that it doesn't do more than just a straight bit copy.
I just recall some bug reports about the boot sectors that appear after using sdi2hd tool.
But you won't have problems if you partition the target storage first and

the SDI file has only PART BLOBs in it.

Ah. I think I see. Thanks.

Regards,
KM

Many thanks again for your patience and assistance.

Regards,

Gerry

 

[KM]

Gerry,

booting the image next time (on all the target devices)

Ah, I think I see the confusion here. I was using the term "golden" the same
way the Microsoft online docs used them. That is, just after going through
(the first, and only) fbareseal, and *before* ever having gone through final
FBA on the target client. Since the image I referenced has more than likely
gone through the whole cloning process already (including, obviously, the
reseal phase), I did not consider it golden.

From your comments here and below (regarding a second reseal), I think you
are using "golden" in a more generic sense. That the image I mentioned in
steps A & B is kind of a golden image, since you know I can still reseal it,
even though it has been resealed previously.

I see now what you meant by the "finalized" image. And I understand your question C) now too.
I don't think I have any more information than you already know.
For the second reseal you obviously have a choice of using either fbreseal or newsid/SetComputerName/etc. tool. Both choices may
lead to some issues with your finalized images. You showed you already know that. So, I guess only much testing will give you the
answers you are looking for.

KM

 

[Gerry Green]

KM,

Well, I guess it's a good news/bad news situation.
Good news is that I have the concepts correct. 8^)
Bad news is that I'll have a lot of testing to do if I go that route. 8^(

Thanks again for the help.

Gerry

Gerry,


I see now what you meant by the "finalized" image. And I understand your question C) now too.
I don't think I have any more information than you already know.
For the second reseal you obviously have a choice of using either fbreseal

or newsid/SetComputerName/etc. tool. Both choices may

lead to some issues with your finalized images. You showed you already

know that. So, I guess only much testing will give you the

 

[KM]

Gerry,

Another good thing for you is this NG (+ archive). Post more when you are done with the testing and something is unclear/doesn't
work. I bet there is a lot of people here who's gone through the same "pain"

 

[Gerry Green]

Any idea on how/where I can access/download this NG's archive? I looked for
clues on MS's web page access to the group, as well as my company's news
server (via Outlook Express), and came up empty.

Gerry

Gerry,

Another good thing for you is this NG (+ archive). Post more when you are

done with the testing and something is unclear/doesn't

 

[KM]

Gerry,

http://groups-beta.google.com/group/microsoft.public.windowsxp.embedded?hl=en&lr=&ie=UTF-8

(there is a couple of more archives but the Google one is most up-to-date and always on the top)

OE will show you the posts for last few (couple) months only.

 

[Gerry Green]

Woo hoo! Archives back to 2001!

Thanks!

Gerry

Gerry,

http://groups-beta.google.com/group/microsoft.public.windowsxp.embedded?hl=en&lr=&ie=UTF-8

(there is a couple of more archives but the Google one is most up-to-date and always on the top)

OE will show you the posts for last few (couple) months only.