More fbreseal strange behavior

[Desi]

I agree - The UI mods are gone because the user account is not the same
one that I made the mods in. That's no problem, but the fact that I
have a new user account is definitely a problem. The other thing is
that I could not log in as the original "Administrator" after sealing
the image. This seems like fbreseal messed up the SID changing to
me...

I'm working on the setupapi.log - I'll report later.

Regarding wmp.inf - I rebooted the pre-fbreseal image many many times,
but did not receive the message about wmi.inf. I suspect that the "New
Hardware" has to do with either video or sound, and it tries to
reference wmp.inf to update the media player...


Desi

 

[Slobodan Brcin \(eMVP\)]

Desi,

I was thinking about your problem and if you are using NTFS I know what problem you experience:
If it is following problem switching to FAT will solve it.

You have not accurately described problem and I did not paid enough attention :-(
You don't have exactly new account aren't you?

If you can use same user name but you have new folder as you described it.
"UserName.ComputerName" this mean that during the logon procedure with user (that you try to log on) credentials windows can't
access its regular folder since you do not have permissions any more.
In that case both SP1 and SP2 will create new folder based on default credentials with name that you saw.

So before you do cloning (after fbreseal) make sure that your local administrators can access that folder. And that you account is
administrator.

Best regards,
Slobodan

PS:
Do whole test on FAT it should work since there are no securuti attributes on folders.

 

[Desi]

Slobodan,

I am using NTFS - FAT is a poor substitute and I'd like to avoid it if
at all possible.

I think that you are right about the permissions, but what are you
suggesting I do?

Here's what I think you are suggesting: After running fbreseal, do not
shut down right away. Instead, open up explorer and grant permissions
(Or ownership) of the directories (Or entire hard disk?) to give the
user "Administrator" permissions when the image is restarted. Is that
it?

For my testing, I have only logged in as "Administrator", both before
and after fbreseal. What I end up with is "\Documents and
Settings\Administrator", and "\Documents and
Settings\Administrator.NSXXYYZZ". After reseal, I am logged in as
"Administrator.NSXXYYZZ".

Your hypothesis sounds like it is accurate, but does that mean that
fbreseal cannot be used with an NTFS partition? YIKES!!! Or is it just
a bug in fbreseal (Which I think it is - It should handle this issue
for us).

Desi

 

[Slobodan Brcin \(eMVP\)]

Hi Desi,

One more thing just for records: This is winlogon image, right?

Anyhow make sure that you assign full access to group "Administrators". So that any administrator account can have access to this
folder regardless of name.
Also you might try granting Everyone full access on all subdirectories just for test.

"\Documents and Settings\Administrator", and
"\Documents and Settings\Administrator.NSXXYYZZ".

After reseal, I am logged in as "Administrator.NSXXYYZZ".

How do you know that you are logged as "Administrator.NSXXYYZZ"?

XP(e) just create new folder and redirect access to that folder. But you still have one account with Administrator name.

After successful/unsuccessful cloning try checking security right attributes on "\Documents and Settings\Administrator".
What do you see?

Regards,
Slobodan

 

[Mark K Vallevand]

Ugly work-around for the new Administrator account after reseal.
I added this batch file to autorun whenever someone logs in. (The only
valid account for login is Adminstrator.)

echo off
del /q /f "c:%HOMEPATH%\Start Menu\Programs\Outlook Express.lnk"
mkdir "C:%HOMEPATH%\Start Menu\Programs\Administrative Tools"
if not exist "C:%HOMEPATH%\Start Menu\Programs\Administrative
Tools\Console1.msc" copy "C:\Documents and Settings\All Users\Start
Menu\Programs\Administrative Tools\Console1.msc" "C:\%HOMEPATH%\Start
Menu\Programs\Administrative Tools\Console1.msc"

It tweaks the start menu to get the few things that don't show up in the new
Administrator account that were in the old one. Most of the start menu
changes we make are in the "All Users" area and end up in all accounts, but
we still needed to tweak.

BTW, this is SP1.

 

[Mark K Vallevand]

Do you have reseal phase set to 0? (I assume you do, but it doesn't hurt to
check.)

This was my problem moving to SP2. When the SLX was upgraded to SP2, the
component settings were not carried forward. You need to make those setting
changes to the upgraded SLX again. (I hope you documented everything!) I
missed the reseal phase.

 

[Desi]

Yes, it is a Winlogon image.

I know that I am using the profile Administrator.NSXXYYZZ because:
- The command prompt defaults to "C:\Documents and
Settings\Administrator.NSXXYYZZ>"

Before reseal, the command prompt defaults to "C:\Documents and
Settings\Administrator"

Note: <CTRL><ALT><DEL> shows "You are logged in as
NSXXYYZZ\Administrator" in BOTH cases.

Both before and after reseal, rights show that for the \Documents and
Settings\Administrators directory Administrator (The user) and
Administrators (The group) have full access.

I believe that the issue is due to the fact that the C:\ and D:\ drives
are being switched after fbreseal.

The volumes are reverting back to Disk 0 = C: and Disk 1 = D:, which is
the reverse of what is configured in the pre-fbreseal image. Since my
"\Documents and Settings" directory is on the D: drive (Physical disk
0) before fbreseal, the profile is not at that location after fbreseal
because the drives are switched (That directory is on C: now), and a
new profile directory is created (Administrator.NSXXYYZZ).

 

[Desi]

Mark,

Reseal is set to 0.

The shortcuts are just the surface of the problem. There is a huge
amount of missing functionality too. Again, I suspect that this is a
result of the C: and D: drives being switched. Windows can no longer
find things on the drive that it needs, and so it tries to limp along
as best it can...

 

[Slobodan Brcin \(eMVP\)]

Hi Desi,

- The command prompt defaults to "C:\Documents and
Settings\Administrator.NSXXYYZZ>"

Ah yes, but account is still named Administrator.
If you log out and then try to log in your user name will be Administrator. Also is security attributes this name should be also
seen.

Regarding the disks: WOW you did not mentioned this before and this is probably a cause for problems you see.

What can you tell us about your disk configuration?

Your XPe should be on C:.
Also if MountedDevices are deleted then you must ensure that XPe after reseal is executed on only one HDD is system or you might
have problems that you experience.

BTW:
You have two disks can you write us how many partitions and their types are on each disk.
Where is boot.ini located and where is XPe?
Don't forget to put logical volume letters that you see after the FBA.


Also please read my article: Also make sure that you fully understand how this work and how to test your image so you do not make a
mistake.
http://msdn.microsoft.com/embedded/community/community/tips/xp/rtpartin/default.aspx

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Desi,

How it is possible that you found about this just now? This should be obvious and primary problem that you should have reported.
Anyhow:
1. You must make XPe to work on C: during and after FBA.
2. You must make sure that on cloned target computer your XPe if on first disk. so it is autoassigned C:

Regards,
Slobodan

 

[KM]

Desi,

Yes, it is a Winlogon image.

I know that I am using the profile Administrator.NSXXYYZZ because:
- The command prompt defaults to "C:\Documents and
Settings\Administrator.NSXXYYZZ>"

Most likely but you can know for sure if in CMD you type "set USERPROFILE".

Before reseal, the command prompt defaults to "C:\Documents and
Settings\Administrator"

Note: <CTRL><ALT><DEL> shows "You are logged in as
NSXXYYZZ\Administrator" in BOTH cases.

Check [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders] for exact profile path.

Both before and after reseal, rights show that for the \Documents and
Settings\Administrators directory Administrator (The user) and
Administrators (The group) have full access.

I believe that the issue is due to the fact that the C:\ and D:\ drives
are being switched after fbreseal.

I have seen similar problems with creation of new profile directory because of the switched drives.
We have even discussed this problem a few times in this NG.

If you want to keeep original drive letter configuration you will need to prepopulate
[HKLM\SYSTEM\MountedDevices] registry key with the drive setup you need to on the final hardware.

However, I think it would be easier for you to stick with the Windows default assigned lettrs: Disk0=C:, Disk1=D:.

The volumes are reverting back to Disk 0 = C: and Disk 1 = D:, which is
the reverse of what is configured in the pre-fbreseal image. Since my
"\Documents and Settings" directory is on the D: drive (Physical disk
0) before fbreseal, the profile is not at that location after fbreseal
because the drives are switched (That directory is on C: now), and a
new profile directory is created (Administrator.NSXXYYZZ).

Another solution maybe if you change settings under [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders] offline
after fbreseal.
But I think at final it may be a mess.

KM

 

[Desi]

Question for the group:

Due to physical placement of the CF (The Secondary Master location is
accessible and Primary is not), I have the following configuration:

My target has two CF drives.
- Drive C: is on the Secondary Master IDE location (Physical Drive 1)
- Drive D: is on the Primary Master IDE location (Physical Drive 0)

This works fine until I fbreseal the image. The boot after fbreseal is
run causes this configuration:
- Drive C: is on the Primary Master IDE location (Physical Drive 0)
- Drive D: is on the Secondary Master IDE location (Physical Drive 1)

Of course, this wreaks havoc with the registry settings all over the
place. Files cannot be referenced by drive letter anymore (C: is now
D:, and vice-versa)

Why would fbreseal cause the drive mounting information to change? Is
there a way to make it stay in place when fbreseal runs? I am already
using "fbreseal -keepall", and I have set the advanced properties of
the System Cloning Tool component to FALSE for cmiRemoveAutoLogon,
cmiGenerateComputerName, cmiUnjoinDomain, cmiRemoveNetSettings,
cmiRemoveUserSettings, and cmiRemoveMountedDevices.

I strongly suspect that this drive swapping is the root of the problem..

 

[Desi]

However, I think it would be easier for you to stick with the

Windows default assigned lettrs: Disk0=C:, Disk1=D:.

This is not the best option, since we want the C:\ drive to
be accessible, and the accessible CF socket is the one on
the Secondary Master (Which makes C: = Drive 1)
.... But I may not have a choice.

 

[Desi]

I DID report this above, in post #17 of this thread.

Quote:

- Drive letters are rearranged. Drives C & D are swapped.

At the time, I thought it was an issue with user accounts and the
reseal process. It now appears to be an issue with fbreseal rearranging
the drive mounting from what is in the pre-fbreseal image.
Why would fbreseal think that it is OK to clear out drive mappings?

 

[KM]

Desi,

The problem is not in fbreseal.

If the volume GUID changed or was duplicated (by hard drive cloning software), the original drive letter may not be re-assigned to
the boot volume.
This is what you are seeing.

Follow the link Slobodan provided to get more understanding on how the volume are assigned by letters in XP/XPe.

Again, without a hard-to-implement universal algorithm to assign the drive letters on any hardware you are going to deploy the
post-reseal image to, your only option would be to stick with the default drive letter in your XPe image - C: (with your boot.ini)

 

[Slobodan Brcin \(eMVP\)]

Hi Desi,

I strongly suspect that this drive swapping is the root of the problem..

Well you should not suspect certain facts. It is the root of the problem!

You can easily solve this problem with volume letters by preassigning volume letters from TD to match your post fbreseal volume
letters. But for now I strongly sugest you not to do that.
Let us figure this out completely first:

First of all only removable disks can have volume letters assigned to them under Win XP(e).
Fixed disks have partitions and each partition is auto assigned with volume letter based on some semi-complex algorithms of which
one part that interest you is described in my tip that I gave you link on.

So you need toi give us informations about how many partition you have on each disk.
Whether CF is fixed or removable.
Where is XPe located.
Where is boot.ini located. (boot.ini content would be nice.)

Also if XPe is on CF how did it get there since I doubt that you have run FBA on CF?

This info are vital fos us to know.

Regards,
Slobodan

 

[Desi]

The target has two compact flash modules. Both are 1GB.

Drive 0:
- Partition 1 = 1GB
- - This mounted to drive D: before fbreseal, and C: after

Drive 1:
- Partition 1 = 384 MB
- - This mounted to drive C: before fbreseal, and D: after
- Partition 2 - 550 MB
- - This mounted to drive E: before fbreseal, and E: after

FBA was done on the target, on the CF. All drive mountings stayed
consistent until the boot that followed fbreseal.

For now, I am going to make the CF that is in the Primary Master IDE
location the boot drive, and be done with it.

 

[Slobodan Brcin \(eMVP\)]

Hi Desi,

It is good to know that you have two CF in one target computer and that you did FBA on CF.
Although I hoped to know location of boot.ini and XPe, but never mind I'm confident that you will figure this out.

Regards,
Slobodan

 

[Desi]

Sorry, I'm re-imaging target devices to test out the solution as I type
this ... I left out the information you asked for.

Both boot.ini and XPe are located on the first partition of physical
drive 1.
This equates to C: before fbreseal and D: after fbreseal.

 

[Desi]

I should add that both compact flash modules are marked as fixed.

There are registry keys defined for:
HKLM\System\MountedDevices\\DosDevices\C:
HKLM\System\MountedDevices\\DosDevices\D:
HKLM\System\MountedDevices\\DosDevices\E:

prior to fbreseal. I have not compared the values before and after,
but I will later to make sure I understand what is going on fully. It
is my understanding that these should change if the drive mountings
change after fbreseal - am I correct?

From your article, though, I received the impression that if they are

defined
in the registry they should not change... Did I miss something?