Unmountable Boot Volume after Sysprep

[Steven L Chan]

I am using Deployment Workbench to deploy images to a Dell Latitude E6400
series. I am able to deploy and capture with no problems, prior to Sysprep.
But once I execute Sysprep and use Mini-Setup, that's when Windows would
B.S.O.D. with a "Unmountable Boot Volume".

If I only execute Sysprep without the Mini-Setup, it goes thru the process
with no issues.

So what is in the Mini-Setup that overwrites the storage drivers causing it
to Blue Screen and why?

Steven

 

[Peter Foldes]

http://aumha.org/a/stop.php#0xed

 

[Zaphod Beeblebrox]

I am using Deployment Workbench to deploy images to a Dell Latitude
E6400 series. I am able to deploy and capture with no problems,
prior to Sysprep. But once I execute Sysprep and use Mini-Setup,
that's when Windows would B.S.O.D. with a "Unmountable Boot Volume".

If I only execute Sysprep without the Mini-Setup, it goes thru the
process with no issues.

So what is in the Mini-Setup that overwrites the storage drivers
causing it to Blue Screen and why?

AIUI, specifying Mini-setup also causes Windows to use sysprep.inf to
control portions of the OOBE phase. Off the top of my head I don't
know what entry might be causing the issue, but if a review of your
sysprep.inf doesn't point you in the right direction, post the
contents here and maybe we can see what is causing it.

--
Zaphod

Arthur: All my life I've had this strange feeling that there's
something big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.

 

[Steven L Chan]

This is the contents on my sysprep.inf file:

;SetupMgrTag
[Unattended]
InstallFilesPath=C:\sysprep\i386

[GuiUnattended]
AdminPassword="XXXXpassword"
EncryptedAdminPassword=NO
OEMSkipRegional=1
TimeZone=35

[UserData]
ProductKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
FullName="XXX"
OrgName="XXXXXXXXXXXXXXXXXXXXXXXXXX"
ComputerName=*

[SetupMgr]
DistFolder=C:\sysprep\i386
DistShare=windist

[Identification]
JoinWorkgroup=WORKGROUP

[Networking]
InstallDefaultComponents=Yes

Steven

 

[Zaphod Beeblebrox]

AIUI, specifying Mini-setup also causes Windows to use sysprep.inf
to control portions of the OOBE phase. Off the top of my head I
don't know what entry might be causing the issue, but if a review
of your sysprep.inf doesn't point you in the right direction, post
the contents here and maybe we can see what is causing it.

This is the contents on my sysprep.inf file:

;SetupMgrTag
[Unattended]
InstallFilesPath=C:\sysprep\i386

[GuiUnattended]
AdminPassword="XXXXpassword"
EncryptedAdminPassword=NO
OEMSkipRegional=1
TimeZone=35

[UserData]
ProductKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
FullName="XXX"
OrgName="XXXXXXXXXXXXXXXXXXXXXXXXXX"
ComputerName=*

[SetupMgr]
DistFolder=C:\sysprep\i386
DistShare=windist

[Identification]
JoinWorkgroup=WORKGROUP

[Networking]
InstallDefaultComponents=Yes

The only thing I see is that you are specifying InstallFilesPath and
using the [SetupMgr] section. I don't use these, but then I don't use
the Deployment Workbench either so I don't know if one is required for
the other. Anyway, I've seen it mentioned in other articles that if
you specify InstallFilesPath that you need to place a copy of the i386
folder from the XP CD in that location so Mini Setup can find them.
Others have said that they change InstallFilesPath to point to
C:\WINDOWS\ServicePackFiles\I386, presumably because the files there
are more up-to-date than what is on the Windows CD. As I understand
it, if you change InstallFilesPath you need to be sure to change
DistFolder as well.

So as I see it, you can try several things - one, remove
InstallFilesPath and the [SetupMgr] section entirely unless it is
required for your situation, two, be sure a copy of the i386 folder
from the Windows CD is in the InstallFilesPath location, and 3, change
InstallFilesPath (and DistFolder) to point to
C:\WINDOWS\ServicePackFiles\I386 if it contains newer files than what
is on the Windows CD.

Hope this helps.

--
Zaphod

Arthur Dent, speaking to Trillian about Zaphod:
"So, two heads is what does it for a girl?"
"...Anything else he's got two of?"

 

[Steven L Chan]

Hi.

After reviewing and testing the solution that you've provided, I still ran
into the same issue.

After reading a few post on the Google, I was wondering if the Sysprep tool
(SP2) on a XP SP3 image would have been the issue.

So I extracted the Sysprep from a XP SP3 CD, recreated the sysprep.inf and
resealed it.

Viola!

It went thru it's process, rebooted and came back up to Windows with no
B.S.O.D.

wOoHoo!!!

I've prepped it again, saved it as a image and deploy that image to 2 other
Latitude E6400 laptops with no B.S.O.D.!!!!!!

Thanks for your help and pointing me in the right direction.

Steven

I am using Deployment Workbench to deploy images to a Dell Latitude
E6400 series. I am able to deploy and capture with no problems, prior
to Sysprep. But once I execute Sysprep and use Mini-Setup, that's when
Windows would B.S.O.D. with a "Unmountable Boot Volume".

If I only execute Sysprep without the Mini-Setup, it goes thru the
process with no issues.

So what is in the Mini-Setup that overwrites the storage drivers
causing it to Blue Screen and why?


AIUI, specifying Mini-setup also causes Windows to use sysprep.inf to
control portions of the OOBE phase. Off the top of my head I don't know
what entry might be causing the issue, but if a review of your
sysprep.inf doesn't point you in the right direction, post the contents
here and maybe we can see what is causing it.

This is the contents on my sysprep.inf file:

;SetupMgrTag
[Unattended]
InstallFilesPath=C:\sysprep\i386

[GuiUnattended]
AdminPassword="XXXXpassword"
EncryptedAdminPassword=NO
OEMSkipRegional=1
TimeZone=35

[UserData]
ProductKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
FullName="XXX"
OrgName="XXXXXXXXXXXXXXXXXXXXXXXXXX"
ComputerName=*

[SetupMgr]
DistFolder=C:\sysprep\i386
DistShare=windist

[Identification]
JoinWorkgroup=WORKGROUP

[Networking]
InstallDefaultComponents=Yes

The only thing I see is that you are specifying InstallFilesPath and using
the [SetupMgr] section. I don't use these, but then I don't use the
Deployment Workbench either so I don't know if one is required for the
other. Anyway, I've seen it mentioned in other articles that if you
specify InstallFilesPath that you need to place a copy of the i386 folder
from the XP CD in that location so Mini Setup can find them. Others have
said that they change InstallFilesPath to point to
C:\WINDOWS\ServicePackFiles\I386, presumably because the files there are
more up-to-date than what is on the Windows CD. As I understand it, if
you change InstallFilesPath you need to be sure to change DistFolder as
well.

So as I see it, you can try several things - one, remove InstallFilesPath
and the [SetupMgr] section entirely unless it is required for your
situation, two, be sure a copy of the i386 folder from the Windows CD is
in the InstallFilesPath location, and 3, change InstallFilesPath (and
DistFolder) to point to C:\WINDOWS\ServicePackFiles\I386 if it contains
newer files than what is on the Windows CD.

Hope this helps.

--
Zaphod

Arthur Dent, speaking to Trillian about Zaphod:
"So, two heads is what does it for a girl?"
"...Anything else he's got two of?"

 

[Zaphod Beeblebrox]

in message
I am using Deployment Workbench to deploy images to a Dell
Latitude E6400 series. I am able to deploy and capture with no
problems, prior to Sysprep. But once I execute Sysprep and use
Mini-Setup, that's when Windows would B.S.O.D. with a
"Unmountable Boot Volume".

If I only execute Sysprep without the Mini-Setup, it goes thru
the process with no issues.

So what is in the Mini-Setup that overwrites the storage drivers
causing it to Blue Screen and why?


AIUI, specifying Mini-setup also causes Windows to use
sysprep.inf to control portions of the OOBE phase. Off the top of
my head I don't know what entry might be causing the issue, but
if a review of your sysprep.inf doesn't point you in the right
direction, post the contents here and maybe we can see what is
causing it.

This is the contents on my sysprep.inf file:

;SetupMgrTag
[Unattended]
InstallFilesPath=C:\sysprep\i386

[GuiUnattended]
AdminPassword="XXXXpassword"
EncryptedAdminPassword=NO
OEMSkipRegional=1
TimeZone=35

[UserData]
ProductKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
FullName="XXX"
OrgName="XXXXXXXXXXXXXXXXXXXXXXXXXX"
ComputerName=*

[SetupMgr]
DistFolder=C:\sysprep\i386
DistShare=windist

[Identification]
JoinWorkgroup=WORKGROUP

[Networking]
InstallDefaultComponents=Yes

The only thing I see is that you are specifying InstallFilesPath
and using the [SetupMgr] section. I don't use these, but then I
don't use the Deployment Workbench either so I don't know if one is
required for the other. Anyway, I've seen it mentioned in other
articles that if you specify InstallFilesPath that you need to
place a copy of the i386 folder from the XP CD in that location so
Mini Setup can find them. Others have said that they change
InstallFilesPath to point to C:\WINDOWS\ServicePackFiles\I386,
presumably because the files there are more up-to-date than what is
on the Windows CD. As I understand it, if you change
InstallFilesPath you need to be sure to change DistFolder as well.

So as I see it, you can try several things - one, remove
InstallFilesPath and the [SetupMgr] section entirely unless it is
required for your situation, two, be sure a copy of the i386 folder
from the Windows CD is in the InstallFilesPath location, and 3,
change InstallFilesPath (and DistFolder) to point to
C:\WINDOWS\ServicePackFiles\I386 if it contains newer files than
what is on the Windows CD.

Hope this helps.

Hi.

After reviewing and testing the solution that you've provided, I
still ran into the same issue.

After reading a few post on the Google, I was wondering if the
Sysprep tool (SP2) on a XP SP3 image would have been the issue.

So I extracted the Sysprep from a XP SP3 CD, recreated the
sysprep.inf and resealed it.

Viola!

It went thru it's process, rebooted and came back up to Windows with
no B.S.O.D.

wOoHoo!!!

I've prepped it again, saved it as a image and deploy that image to
2 other Latitude E6400 laptops with no B.S.O.D.!!!!!!

Thanks for your help and pointing me in the right direction.

Thanks for the followup - it's good to know that the issue is
resolved, and what it took to fix it.