Deployment Solution

I have made several full rdeploy images of our Windows 7 systems (DS 6.9) and have always had a small anomaly restoring them.  Once restored, the system fails booting up, and suggests to reboot from the original OS install CD and run repair.  If I do that, the repair corrects the problem in like 2 seconds and all is well.   I'm guessing it's a partition problem or partition not active???   Is anyone else seeing this and is there a fix?  Note these are Dell and HP systems, full drive images and restores of which there are three partitions consisting of OEM diag, OEM recovery & OS...

 

Further investigation finds that "Rdeploy" apparently has a problem with "Windows 7 Boot Manager" as the image that is restored on the target system is missing this information.  A work around, for me anyway, was to create a "USB Windows PE Boot Disk" and boot the target system off of that disk right after the image is restored.  Then type the following commands in WinPE:

     bcdedit /store c:\boot\bcd /set {bootmgr} device boot
     bcdedit /store c:\boot\bcd /set {default} device partition=d:
     bcdedit /store c:\boot\bcd /set {default} osdevice partition=d:

So now I'm trying to figure a way to automate the running of the above in DS.  Problem I have is we are using  "DOS" instead of "WinPE" in our PXE boot process and "bcdedit" seems to only run in WinPE.  I'm hoping not to have to switch our PXE to using WinPE.

Anybody found a workaround for this?  DOS version of "Bcdedit" anybody?    I hear that these problems are supposed to be solved in Altiris 7.1 but we will not be deploying that until September.   Kinda hoping to find fix in the mean time. 

Thanks for any help or ideas...

Is there a switch to be used in Altiris 6.8 or 6.9 for imaging Windows 7?  I created the image both with and with out the little partition and had the same results. I've used Ghost to image to a server and back down again and it worked flawless.  Why can Ghost do it but Rdeploy fails?

DS 6.9 Sp3 and SP4 provides imaging support for Win7.

Moving forward symantec will use ghost but keep rdeploy because ghost doesn't have support for multicast.

I'm not sure if something's changed, but Ghost always had support for MultiCast.  It used what is call "GhostCast Server".  I doubt they would have removed that feature that has been part of Ghost for the past decade.

DS 6.9 SP3 does not support the BCD with Rdeploy.  One website says the BCD stores the hard drive signature and sector offsets of the OS.  It is actually a registry hive.
I've also seen people set the devices to 'boot' instead of 'device=c:' beforehand. 

Sysprep would also solve the bcd problem, but it has a lot of other baggage.

Not to beat a dead horse or anything, but is there in fact a fix for this issue? We are in the same boat (using DOS over WinPE for various reasons) and are having the same issue with Windows 7.

The proposed fixes in this thread are

• a BCD editor that can be run from DOS
• use Ghost since that fixes the BCD problems natively.

As for Ghost, we have no issues switching to it as an imaging tool, so long as it supports multicast since unicasting to 30+ computers at a time is obviously inadvisable.

If anyone could shed some light on whether a DOS BCD fix exists or how to use Ghost's multicast within an Altiris Deployment Solution scenario, that would be awesome.

Try this in windows before saving the image:

bcdedit /set {bootmgr} device boot
bcdedit /set {default} device boot
bcdedit /set {default} osdevice boot

Interesting. I didn't realize we could do this from Windows before pulling the image.

All the same, the command returns "The boot configuration data store could not be opened. Access is denied."

Never mind. If you run CMD as an administrator it works fine.

I'm going to try running those, pull an image tonight, and push it in the morning, see if the results are any different.

Thanks for your help

I'm just getting started on Win7 imaging, comparing Ghost to Rdeploy to ImageX.  I have seen several posts about Imagex and issues with the boot files - because ImageX is a file-based image.  Rdeploy is also a file-based image, so solutions proposed for ImageX may also work for Rdeploy.

Either the Vista WAIK (Windows Automated Installation Kit) 1.0 or the Win7 WAIK 2.0 should have a 32-bit and a 64-bit copy of bootsect.exe.  If you are running 16-bit dos on your boot disks, then I doubt this will help.  But you say you are using DOS over WinPE which I assume is 32-bit CMD dos not 16-bit COMMAND Dos.

So this might help, I'll be testing it also so please post results back.

SMP7 deployment 6.9 ships with the Vista (WAIK 1.0) version of the PEtools, so you already have the vista version in your deployment share.  deployment\Task Handler\WAIK\Tools\PETools\x86\bootsect.exe.  Download WAIK 2.0 for the Win7 version.

It looks like the switches are the same for either version

to write NTloader boot files to drive c: (for XP image)
bootsect.exe /nt52 C:

to write BootMGR boot files to drive c: (for Vista, and hopefully Win7 image)
bootsect.exe /nt60 C:

bootsect options:
http://technet.microsoft.com/en-us/library/cc749177(WS.10).aspx

I think the problem is the bcd is hardware dependent.  It either points to the drive signature and boot sector of the os, or points to a windows object that does.

here is another way to fix bcd errors.

1. boot to winpe (the architecture matters so boot to winpe x64 if you have windows 7 x64)
2. type bcdedit.  Look at the bcd entries if you see a value = unknown then u know the issue is bcd
3. type bcdedit /delete {default} /f
4. find out where the boot files are. if you installed windows 7 from a DVD then more than likely drive c: (in winpe) is the hidden boot partition
5. type bcdboot or browse to d:\windows\system32\bcdboot.exe and execute the following command:
bcdboot d:\windows /s c:

Let me explain this. d:\windows is where the OS files are, /s species the target for the boot files c: iswhere the boot file are located.
NOTE. this is done in WinPE and the architecture matters :) and the c: drive with boot files is available only in winpe no on the OS boot.

hope this helps.

if it works help a brother out and tell me so ;)

Nelson V.

This was my first test, but the method above appears to work.

Test drive was Windows7 x64 default install (with separate bootmgr partition and os partition)
Capture Image method was Rdeploy disk-to-disk copy (including both partitions)
Apply image method was simply to swap drives from the original to the copy.

I was surprised that this image method also exhibited the no-boot symptom.  I would have assumed it would boot since it was basically a copy of the other drive.  But it did not boot.

Booted to WinPE x64 and followed the instructions above:
1. bcdedit      - showed "value = unkown"
2. checked diskpart - list volume           - boot partition was c: , OS partition was d:
3. bcdedit /delete {default} /f               - command completed successfully
4. bcdboot                                   - this showed the bcdboot help file, so I'm not sure if running this also did something 
5. bcdboot d:\windows /s c:           - success.  I did not browse to the d:\windows directory first, I just ran the command
6. removed WinPE disk and booted to Win7.  Worked fine.

My next test is a single partition Win7 with the boot files on the same partition - that's probably the scenario we will be using to image rather than the default split-partition setup.

I am aware that WinPE's bcdedit command fixes the error, but both the original poster and I were seeking a fix which didn't require booting into WinPE.

bmalt, as far as the drives being identical, even on systems where I send an image onto a drive containing the source of the image , I get the boot error, which to me was also surprising.

I read somewhere that a system booting from sysprep will build a new BCD file, which seems like it would solve the boot issues, so I'm testing using Altiris' sysprep support to see if I can build an image which functions straightaway upon pushing.

(as a side note, running bcdedit on Windows as per tamahome's previous idea yields the same error upon imaging)

You're running Rdeploy over DOS pxe boot disks as I understand?  I would assume that's 32-bit rDeploy, as I'm unaware of a 16-bit version or Rdeploy.    But I could be totally wrong about that.  I'm just wondering if there are some 32-bit .exe's you could add to your boot disks / scripts to accomplish the same thing.

I'm fairly certain it's a 32-bit DOS environment, because I'm also unaware of a 16-bit version of Rdeploy.

But on a totally different note, sysprepping a system then imaging it totally worked without any extra BCD action on my part. So in an environment where it's ok to sysprep, that's some kind of fix.

At this point I'm wrestling with the fact that sysprep can only be run 3 times unless you turn on skip-rearm. Which you can do, and rather easily, a la this guide but Altiris uses its own unattend.xml to do the sysprepping and it appears to turn skip-rearm back off, which is sort of a nuiscance. I'm testing whether just turning it on again via registry allows you to image indefinitely. If it does, it's not an optimal solution but it will work.

We have always used Sysprep with XP, I'm not sure if we'll continue that with Win7 but I assume we will.

What we do to avoid the re-sysprep issue is that we keep a backup single image of our XP base system.  We only ever sysprep once.  When it's time to update the base image, we restore the pre-sysprep image to the base system, do our updates, make our changes, etc.  Then we take a new pre-sysprep backup image of the base system, reboot the base system back to windows, do a sysprep, and deploy the sysprepped image.

Edit: Oh wait. That would work.

I misread your solution, and come to think of it, that'd be fine. But I think we can skip one imaging step if you can just sysprep the original base image as often as you like.

So I would like to share that manually resetting the SkipRearm key to 1 in the registry (found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform) does appear to allow me to run sysprep as often as I like.

It's just important that before sysprep'ing/ imaging that this does happen, or else you do run out of re-arms, and Altiris will not issue those sysprep/image jobs correctly. Ever again, in my experience. It gets stuck in a weird IMAGE_STATE_UNDEPLOYABLE spot which altogether is better to avoid if you can. It's all starting to seem eerily familiar to me.

I've never tested the SkipRearm registry setting.  If you are using sysprep with any additional MassStor drivers ([SysprepMassStorage] entries in the sysprep.inf)  - you might want to note the sysprep seal time.  I've noticed sysprepping the same system twice that the second sysprep tends to go really fast, which makes me wonder if it's actually loading the massStorage drivers or not.  We have about 800+ lines in our MassStorage section, so it normally takes 20-30 mins for that sysprep seal to run on our base system.

I sysprep, but avoid any kind of pre-configuration by altiris.

Hey bmalt, earlier you suggested experimenting with bootsect.exe, since it sort of looks like what we might need. So on a whim, I tried a script with it, and unfortunately I have to report that it doesn't work in DOS.

OK.  I have to correct my earlier comment anyway - it looks like a minimum 2 commands are required to boot a windows 7 image:

bootsect /nt60 c: /force /mbr

bcdboot c:\windows

So bcdboot won't work just by itself, anyway, you still need bcdboot.  So you're back to where you started with the bcdboot DOS issue.



 

I've posted a blog on Windows 7 deployment,
http://www.symantec.com/connect/blogs/windows7-untangling-scripted-installs-sysprep-and-configuration-passes

I'm afraid you'll have to bite the bullet on the WinPE issue. DOS does have advantages I admit, but Altiris have de-emphasised it for some time, and it's not even an option in the DS7 branch.

Any scripts you have shouldn't be too much of a problem to port, and if boot speed is your problem you can always embed automation, or use flash drives for automation boot.

I left DOS now over 18 months ago, because the waterloo stack tcp connections were not being terminated properly, so in our scripted installs the multiple TCP SYN connections (from multiple automation boots) without a FIN inbetween were seen as suspect and dropped. The TCP source port recycling makes this problem worse.

It's sad, but DOS I'm afraid is dead. Linux has limited support, which leaves WinPE as the best option in terms of full support by Altiris/Symantec.

Kind Regards,
Ian./

Hey, thanks for linking me to this. I suspect I'll be able to use your insights on Windows 7 / Sysprep to solve most if not all of the problems we're currently having.

At this point, all I needed was to know how to use a different answer file to configure the computer after imaging, since we lost like our Administrator account, as well as some settings we would have liked not reset. But knowing that you use the answer file when distributing and not creating was kind of an eye-opener. It makes sense really. But I'll play around with those and hopefully come up with a solution

Best of all, I suspect that I'll still be able to use DOS :P

Hi pfesznguyen,

I'd recommend you start looking into weaning yourself away from DOS. Its something we all have to do if we are to stand a chance with our migrations to  DS7.

DOS is superior for boot speed, is great for mass-storage support and of course we can use UNDI on PXE boot, but all the same it seems to have become an imaging environment of the past -whether we like it or not.

If you've got anymore thoughts on the sysprep side, just add them to my blog entry so we can keep Konalo's thread clean.

Kind Regards,
Ian./