Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

(DS6.9) Deploying Windows7 sysprepped image - not booting or obeying answers file

Created: 21 Sep 2012 | 1 comment

I've been tearing my hair out here for the past couple of days and not making much headway.

I'm attempting to create an image for a lab full of computers, such that I can just push the image back out if they break etc.  Fairly basic stuff, have been doing it for a while with XP but now the new machines are running Windows 7... All machines are identical hardware so shouldn't need anything too clever.

The machines in question are all Dell Optiplex 9010s, with Windows 7 Professional pre-installed.  On the base machine, we've done the initial OOBE and installed any Windows updates.  Computer gets networking details via DHCP.  Everything beyond that will be done post-imaging.

Created an image with sysprep enabled in Altiris (6.9SP5-MR2) using ghost.  If I deploy that back to another machine, it fails to boot (Boot error 0xc000000f).  In Altiris, this is at the 'Configuring computer' stage of the 'Distribute disk image' task, so the task never completes.

I found, via trial and error and the Internet, that from PE I could fix the booting via bcdedit:

BCDEDIT /set {bootmgr} device partition=c:
BCDEDIT /set {default} device partition=d:
BCDEDIT /set {default} osdevice partition=d:

The website that I found info about this on suggested that it was because Windows 7 creates a second smaller partition.  However, surely Altiris/sysprep are aware of this and configure things accordingly?  It could also be to do with Dell creating an additional diagnostic partition, although that is hidden and doesn't appear to be getting in the way.  Either way doing this made it boot.  I added that as a script after the image distribution task, but since that task never completes it won't move on to the bcdedit script without manual intervention which isn't helpful for automating a deployment!

Next I tried disabling the option in the distribution task to boot to production to complete configuration, reasoning that it can't boot to production until the BCD is fixed.  That appeared to work in that it completed the distribute task and ran the BCD script.  However, it doesn't appear to be completing the sysprep action.  It goes through a cycle on first boot of sorting out the hardware, but then runs the OOBE wizard on first proper boot, wanting someone to configure user accounts (in addition to the user account that was created when the OOBE wizard first ran when we set up the base machine), language settings and accept the EULA again.  Again, not helpful with automated deployment.

The distribute task is configured to use sysprep, and to use the default answer file.  I've looked at the file (standardwes7.xml) and in the oobeSystem section, SkipMachineOOBE is true.  On the target machine, the unattend.xml in \windows\panther is basically the same as the standard, but with Altiris' variables expanded, and datestamp of the file matches the date the image was rolled out.  The only thing I noted was that throughout the file, processorArchitecture was 'x86', when the OS on the machine is x64.  That might be because the configuration task is presumably being run inside PE (x86) rather than in production?

So - what am I doing wrong?  Is there a way to create the image so that it can be properly deployed straight from Altiris without needing to mess with the BCD?  Is there a way to do the BCD bits after the imaging but before the configuration task?  Should I wipe the base machine and perform a fresh install from our regular Windows 7 media and wipe out the Dell diagnostic partition?

Given that all machines are identical and will be joined to the domain which, as I understand it, generates a new SID for the machine and therefore eliminates a problem with two machines with the same SID, can I just use the un-sysprepped image and use a configure task to set machine name and join the domain as usual and just forget the whole thing?

Comments 1 CommentJump to latest comment

Thomas Baird's picture

First, no, the product is NOT going to be aware of any other partitions out there that you, or the manufacturer, or Windows, created, and no, it's not going to disable those.  You can have them removed if you want, but there are so many variants on that song that it's impossible to keep up with.

There is however one trick you can do.  If you use the Altiris product to CREATE the source system via a Scripted OS Install, then that other partition is NOT created, and when we capture, you don't have to worry about it.  The other partition is a recovery partition that, if you're using our product, you don't need.  It's similar to what most OEM's place on their systems that we often have the exact same problem with.  Removing them is a great idea.

Do NOT skip the Sysprep process.  A new SID is NOT always generated when you join the domain.  I've read articles that suggest that Sysprep is no longer important, but I'll be perfectly honest - I've also heard customers spend days online with Microsoft Support cleaning up completely messed up Domain environments because they did not Sysprep first and "assumed" all would be fine.  I really wish they'd call the guys that wrote those articles frankly, so they might be inspired to pull down their pages.  Sysprep is the only "supported" way to duplicate images per Microsoft.  If you don't run it, don't blame us if it doesn't work.  It's the only way Symantec will support you.

My personal suggestion is to try removing that (those) extra partition, running capture (with sysprep), deploy (use defaults, including that the image was prepared with sysprep, default file, etc), and see if all your problems magically go away.  Assuming not, then come back here, let us know where you stand, and we'll go from there.

Keep us posted either way!

Thomas Baird
Enthusiast for making things better!