Vista and Symantec Ghost 8.x
Ever since build 5231, I've found myself unable to use Ghost (8.0 or 8.2) "as I've always been able to". By which I mean with 5219, XP, 2000, etc., I can just create a partition backup, restore a partition backup, no muss, no fuss, all successful.
(I have an XP-compatible boot manager, have four independant partitions that are always hidden from one another, and I restore just one partition based on what OS/test/scenario I need to create.)
Now with 5231 and later, creating a Ghost image of a partition always results in the "unable to access \windows\winload.exe" (or whatever that exact full-screen message from the Vista boot manager is). Regardless of whether I'm restoring back to exactly the same partition as I backed up from, etc.
If I perform a DISK backup and then perform a DISK restore AND use the -FDSP switch, I can bring back my Vista 5270 image successfully. But still cannot just bring back Vista into a single/specific partition.
What is the "unable to access \windows\winload.exe" error actually trying to tell me? I've been scrolling through all the BCDEDIT data and options trying to put together a scenario that makes sense. Is SysPrep going to get me out of this, or is there something more simple I could do given that I'm not restoring to a different machine or anything; just trying to bring back a partition that was working for me previously.
FWIW, I guess since Ghost has it, there is some scenario where -FDSP was necessary even previously. In my own experience, I've never had to modify Ghost's default behavior. I just perform a partition backup, restore the partition backup, without any special/additional switches, and this works great for XP, 2000, NT 4.0, etc.
Thanks for any insight. Yes, I've been playing with XIMAGE too, but only concerned with what approach might work with Ghost in this thread.
-Alan
Answers
An update on where things currently stand.
Indeed this appears to be a condition specific to the new BCD-based boot manager. i.e. It's the boot manager failing to find and execute the Windows boot files under circumstances where Windows itself can otherwise successfully boot, and not a change to the boot configuration/dependencies of Windows itself.
(Windows of course also keeps partition and disk information of its own, even prior to Vista. But in my experience this never resulted in a boot issue for the situation described, and Windows automatically updated and corrected if a different partition / disk signature was used.)
The cause of the Vista load failure previously described, to the degree I understand it, is that by default all of the BCD entries use "PARTITION"-type device references where applicable. In the BCD data stored for these "PARTITION"-type device references (visible in the BCD section of the registry, and in a BCDEDIT /EXPORT), both the drive signature and the partition number appear to be part of the information stored. And based on the results, both must match the current environment else the boot manager will declare the OS loading application cannot be found.
(Even if I force the drive signature to be the correct signature, if I'm restoring to a different partition than the image was previously using, the restored partition will still fail to boot because the partition number stored in the BCD still doesn't match the current environment.)
The solution that appears to be most suitable (at least for the situation I previously described and was intending to solve) is to change the BCD entries to use "BOOT" device references rather than explicit "PARTITION"-based references. Presumably thereby implying "whatever device/partition I booted from, that is the device/partition I want to use".
Preparing a Vista installation prior to creating the Ghost image then becomes a task of setting the DEVICE and OSDEVICE entries of the BCD entries you intend to use:
Logon as Administrator and from a command prompt invoke the following changes:
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice bootNote you can "fix" a previously restored (and currently failing to boot) installation using a PE boot disc and executing these same actions against the restored partition's BCD entries.
There may be more entires that you need to fix if you intend to use them ({memtest}, {legacy}, etc.). The above is just the minimum for my own scenario where there is just a clean Vista-only OS installation on the partition.
Once the BCD entries are no longer referring to specific disk signatures and partition numbers, there is no need to use -FDSP with Ghost anymore, either. The disk signature can be reset as it is by default with a Ghost disk restore, and "nothing special" is required during image creation or restore (from a Ghost perspective).
Presumably this could have also been corrected by resetting/updating the "PARTITION"-type device entries with current information (current partition number and disk signature) post-Ghost restore, if for any reason the use of "PARTITION"-type references is needed. For the purposes of making an image that can be restored via Ghost to any partition on my test box, the "BOOT" device reference appears most desirable by not being fixed to any one partition or disk signature.
Happy booting.
-Alan
All Replies
There are certainly bootloader (hence bcedit) and NTFS changes with windows vista either of which could lead to something like this. Unfortunatly, I think we have to wait for Symantec to have a version that supports Windows Vista. If I hear any different I will let you know
Josh
Thanks for the response. I was not aware that there were any NTFS changes in Vista. (At least not yet.) And its still reporting as NTFS version 3.1 in 5270, for what its worth.
Agreed that obviously there are changes in the boot loader. And perhaps one day Ghost will do something to take this into account, if taking this into account even ends up being required.
But as described, Ghost 8.x actually does work; restoring a disk image without -FDSP fails (as does a partition image), but restoring the same disk image with -FDSP works. So the disk signature appears to be a factor, but still the question of whether there is something that could be done to "prepare" Vista for the fact that its going to be restored to a different (zeroed, or at least different) disk signature.
Since Ghost has had the -FDSP and -FDSZ for quite some time, yet I've never found the occasion to need or use them, my question was perhaps whether someone who understands more specifically what this would affect and/or what Vista is going to require to successfully find the boot partition (that is apparently being affected by -FDSP, based on the results) might be able to explain what these clues are more specifically pointing to.
Or, someone who is successfully using Ghost 8.x for partition backups/restores of Vista 5270 confirming no issue, such that I'll know there is some other factor I need to be chasing down.
-Alan
An update on where things currently stand.
Indeed this appears to be a condition specific to the new BCD-based boot manager. i.e. It's the boot manager failing to find and execute the Windows boot files under circumstances where Windows itself can otherwise successfully boot, and not a change to the boot configuration/dependencies of Windows itself.
(Windows of course also keeps partition and disk information of its own, even prior to Vista. But in my experience this never resulted in a boot issue for the situation described, and Windows automatically updated and corrected if a different partition / disk signature was used.)
The cause of the Vista load failure previously described, to the degree I understand it, is that by default all of the BCD entries use "PARTITION"-type device references where applicable. In the BCD data stored for these "PARTITION"-type device references (visible in the BCD section of the registry, and in a BCDEDIT /EXPORT), both the drive signature and the partition number appear to be part of the information stored. And based on the results, both must match the current environment else the boot manager will declare the OS loading application cannot be found.
(Even if I force the drive signature to be the correct signature, if I'm restoring to a different partition than the image was previously using, the restored partition will still fail to boot because the partition number stored in the BCD still doesn't match the current environment.)
The solution that appears to be most suitable (at least for the situation I previously described and was intending to solve) is to change the BCD entries to use "BOOT" device references rather than explicit "PARTITION"-based references. Presumably thereby implying "whatever device/partition I booted from, that is the device/partition I want to use".
Preparing a Vista installation prior to creating the Ghost image then becomes a task of setting the DEVICE and OSDEVICE entries of the BCD entries you intend to use:
Logon as Administrator and from a command prompt invoke the following changes:
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice bootNote you can "fix" a previously restored (and currently failing to boot) installation using a PE boot disc and executing these same actions against the restored partition's BCD entries.
There may be more entires that you need to fix if you intend to use them ({memtest}, {legacy}, etc.). The above is just the minimum for my own scenario where there is just a clean Vista-only OS installation on the partition.
Once the BCD entries are no longer referring to specific disk signatures and partition numbers, there is no need to use -FDSP with Ghost anymore, either. The disk signature can be reset as it is by default with a Ghost disk restore, and "nothing special" is required during image creation or restore (from a Ghost perspective).
Presumably this could have also been corrected by resetting/updating the "PARTITION"-type device entries with current information (current partition number and disk signature) post-Ghost restore, if for any reason the use of "PARTITION"-type references is needed. For the purposes of making an image that can be restored via Ghost to any partition on my test box, the "BOOT" device reference appears most desirable by not being fixed to any one partition or disk signature.
Happy booting.
-Alan
- Thanks Alan...
I was so excited when I can across your comments on using the BCDEDIT command to change the BCD entries.
One problems though, when I try to run the command "bcdedit /set {bootmgr} device boot" I recieve a message that states "data store could not be opened, Access is denied"
I am logged in as the Administrator, so I am not sure what is going on.
I do get a pop up windows when I try to do administrative tasks from within windows wanting me to verify to continue.
Is there something I am missing, or is there away to do adminstrative tasks withing the command prompt like Linux (aka Sudo).
I did notice that if you do a "whoami" command it comes up with your user ID.
***UPDATE***
I got it figured out, all I had to do was un-check the UAC functionality.
Sorry, my statement of "log on as Administrator" is definitely vague and misleading in a current context. (It was the right thing in build 5270, but not currently with Beta 2 / 5384.)
To run BCDEDIT.EXE, indeed you need to have your full Administrators rights in effect. You can do this with any Administrators-member account (not specifically "Administrator"), but you will need to right-click the Command Prompt shorcut and select "Run as Administrator" in order to subsequently run BCDEDIT.EXE successfully within that Command Prompt session.
(Or, as alluded to, if UAC is simply disabled altogether that would give you full Administrators right in any Command Prompt session too. But simply right-clicking the Command Prompt and selecting "Run as Administrator" will suffice for the default UAC-enabled mode of Vista.)
-Alan
Alan, thank you for the information. This is exactly the problem that I have been having for the last three days and I was finally able to solve it with your suggestion.
Cheers
Hi,
Is there any new vGhost ersion yet that supports Vista?
Hlee
Hi,
Since the 12th of juli this can be found on the Symantec site. The statement that it's MS recommanded deployment system si very interesting. I have already send a question to MS about it.
Symantec Ghost Solution Suite:
· Symantec is committed to ensuring compatibility in imaging Vista machines withour Ghost Solution Suite 2.0 release. This will include full Microsoft Vista support and enhancements, such as imaging and deployment, software distribution, PC "personality" migrations, and secure retirement of end-point devices. This version supports the 64-bit version of Windows Vista.
· Symantec Ghost Solution Suite enables deployment and management of Vista beta software in the short-term, and it is the Microsoft-recommended Vista image deployment and management solution following the official Vista release.
· The targeted Ghost Solution Suite 2.0 Beta availability date is October 3, 2006. Other key milestone dates include: Release to Manufacturing (RTM) date: November 16, 2006 and First Customer Shipments (FCS) date: November 30, 2006.
http://www.symantec.com/vista/Ent_Vista_FAQ.pdf <http://www.symantec.com/vista/Ent_Vista_FAQ.pdf>- Cheers Alan.
This works a treat!!!!!
I can now Image RC1 knowing that my efforts were not in vain, unlike before when after a couple of hours ghosting x64 and x32 versions of vista I found my images wouldnt work :`(.
Adam I found even ghost 7.5 to work.
just run the following commands from a cmd box in vista under an admin account :
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice bootthen make a ghost image as you normally would. (ghost 7.5 doesnt even understand the -fdps switch)
also i got ghostwalker to work (we only use it to change the computer name). ghostwalker looks for msdos.sys & boot.ini, it uses the content of boot.ini to locate windows. tho vista uses bcd instead of those files you can just copy them from windows xp. (havent tried changing the sid tho)
- This means the Beta should be available since 2 weeks. Does anybody know how to get it?
On the commands - what goes in the brackets - just like it says?
BD
- Yup, just like it say's, copy it word for word.
Dear Sir:
Thank you for your good information.
Have you ever try on VISTA RTM edition yet?
I am asking because the solution you provide looks like NOT working on VISTA RTM.
Any more updates? Thanks.
Hi Everybody
I have received the final Version of Vista, but i need test how to clone it. (i will try with ghost 7.5 and BCDEDIT parameters)
i don´t want to use XIMAGE. (work perfectly)
Does somebody know where I can get the beta of the Symantec Ghost Solution Suite 2.0 ?
Thank´s
jsans@datalogic.es
Y.S.L wrote: Have you ever try on VISTA RTM edition yet?
I am asking because the solution you provide looks like NOT working on VISTA RTM.
This approach with Ghost 8.0 has been working successfully for me with every build release since I originally posted, including the Vista RTM release. I am successfully Ghosting partitions and restoring them to alternate partitions and maintain the ability to successfully boot from them post-restore.
So if there is something you can see that isn't working, I'm not immediately suspicious that it's "failing for RTM" versus just failing for some other reason, regardless of Windows Vista build.
-Alan
Hi, Alan, I've visited a lot of forum posting my problem that maybe i'ts so simple for you, I'll appreciate if you can give my a hand with my issue. here it is:
The machine that I want to ghost is 5GB data and booted and running ghost, the destination is my laptop on the network running XP. I have peer to peer connection already, but when I select the mapped drive and I start the ghost process I got the error message of not enough space (Ghost says my Destination is only 2GB). For sure is a problem with the FAT, but I don't have this limitation when I use the Ghost Slave and Master Connection, works fine BUT! a friend told me that I can ghost using XP in the destination machine with no limitations at all...is it true?
I don't understand, It's not the first time I read about that "Win98 boot solution" THERE IS NO DIFFERENCE is even worse, because al least with the ME boot I can see my FAT32 Local Disk
Thanks
Thanks to all of you for the above info.
I had already done a fresh install of Win XP SP2 to drive c: , fresh install of Vista to drive d: and ghosted to a USB drive using ghost 8. This was done on a spare 40gb drive and was to be transferred to a 250gb drive. After ghosting the 250gb drive, neither XP or Vista would boot and said I had to use the install disk to repair. Of course that did not work... Did not want to redo the ghost image...so I played with bcdedit. (Wish I could code, would like a gui version of this to make life easy.)
I noticed that the guid for the legacy system changed to {ntldr}. However the default value assigned originally still works to make changes to the legacy OS loader ({466f5a88-0af2-4f76-9038-095b170dc21c} is the predefined GUID for NTLDR). I had used bcdedit to export the contents of my system store before the ghost. So I imported that (while booted with a BartPE disk) and still could not boot.
The first two commands: BCDEDIT /set {bootmgr} device boot and BCDEDIT /set {default} device boot (I had set the legacy to be default before ghosting), both worked to get Win XP running but Vista would not start. What finally worked is:
BCDEDIT /set {"Vista guid"} device partition=d:
BCDEDIT /set {"Vista guid"} osdevice partition=d:I am now up and running and all seems well.....
Tom
I am sorry for the inconvenience. I faced the same problem as you, but instead of solve it i still have it.
I follow the instructions you provide and i made the following changes through CMD as administrator:(remind that my own OS is on c hdd)
bcdedit /set device partition=c:
bcdedit /set osdevice partition=c:
I took the ghost (using ghost 8.0), and after i restore it to a new disk (different capacity and model than the original one) i face the black screen again with the mysterious "unable to access \windows\winload.exe".
What did i do wrong?
The original value you gave was:
BCDEDIT /set {"Vista guid"} device partition=d:
BCDEDIT /set {"Vista guid"} osdevice partition=d:What {"Vista Guid"} means? Should i have to put something like this on my own?
What is the following that Alan provides:
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice boot{bootmgr} and {default} values must be placed or not?
Thanks in advance, Kostas.
has anyone used the latest ghost with sucess ?
please let us know
Mark
I copyed word for word
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice bootand I get an error on the BCDEDIT /set {default} osdevice boot
so only my xp boots now not vista
Mark
There are two versions - store bought and Enterprise - 8.x is an Enterprise version - I haven't seen the newer versions - I did try getting it from a rep but he didn't have a copy - store bought has a gui interface. Is this where the confusion lies?
When I did the Vista ghost I used the TCP/IP boot cd and imaged it to my server -
I also installed XP Pro first into 1 partition and Vista Ultimate into another partition on the same drive - 4gb machine dual core however I couldn't get Gparted to work on the Dual core machine. Thought I would share this - I thought I would see all 4gb of ram but I only see 3.5gb - limitation of the system and I guess I could run some switches. Anyway - this is what I have experienced.
BD
I am having extremely frustrating problems with this and cannot get restoring an image to work based on everyones posts here.
-I am running ghost 8.0
-Not using any switches in ghost
-I can always create an image w/no problems
-I can restore it successfully
I have 2 images with multiple or just 1 vista installation. Both images different versions of XP installed to.
When I do:
BCDEDIT /set {bootmgr} device boot
Everything works fine.
When I do:
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice bootIt will not boot into vista anymore. This is even before creating the image. I also change the device and osdevice to "boot" for all other vista installations and get the same problem.
before imaging: If I change the device/osdevice on all vista installs back to their appropriate "partition=x:" they boot back into Vista fine.
Now here is the biggest problem:
No matter how I configure the BCD table before imaging, it NEVER works after restoring the image. I have tried all recommended configurations on this thread with no sucess.
What I do is restore the image and neither vista's or XP installs will boot (which is fine). I then boot off the Vista DVD, skip the option where it asks if I went to let it automatically fix the boot problems. I open a CMD prompt and change the bcd table back to the appropriate partitions.
I reboot and I can boot into XP installs w/no problems. I can actually boot into all Vista installs with no problems. The problem occurs when I type in the password and it tries to load the profile. Instead of just saying "Welcome" as it loads, it follows with "Preparing your desktop." It shouldn't have to prepare the desktop since everything was already setup beforehand.
Multiple errors then popup such as missing tons of exe's, dll's, configuration is corrupt, blah blah. Also says it couldn't load the profile because it is "missing."
The partitions I assign in the BCD table are correct for I have verified dozens of times.
I have wasted, pretty much, days on this. ANY help would be GREATLY appreciated it. I'm already putting in an order request for Ghost 2.0 but I need to find a temporary solution to avoid this headache.
Please help.
Thank you,
-Jordan
There is a tool available that will prepare your Vista installation for cloning. It can be found at:
Vista with ghost 11 works a treat, still havent tried any earlier versions with it though..
Allthough, i get that error "unable to access \windows\winload.exe", so I ran the repair from and vista cd, and it fixed it in almost 5 seconds, re-booted, and problem solved..
Alan - You mention a "PE Boot Disk" - am green in this specific area, but have several ghost images in my lab that have already been made without the 'fix'. (And therefore won't boot.) I could recreate them, but your method sounds a lot easier. Is this 'boot disk' ou speak of something online (Bart's comes up in google searches) or a Vista-made disk?
Gratzi!
Mike.Follow up - Using the Vista install disk, it has a 'Repair' option that you can access a command promopt with. To get there, do this:
- On the system that won't boot due to the error, put your install disk in, and boot off of it.
- When it asks you for your language, select the language options you want, and then click "Next".
- On the following dialog, there should be an link at the bottom that says "Repair...". Click that.
- A dialog will come up where it will say "Scanning for Windows Installations..", let it finish.
- It *MAY* tell you that it found an installation that is corrupt, and offer to fix and reboot. Select "No", do not fix.
- That dialog will go away and you'll have another with a list of things you can do. Near the bottom will be "Command Prompt". Select that.
- In the command prompt that pops up, type 'bcdedit' and hit enter. It will give you a list of items.
- Note the "designation" part of each section. For each section, set the 'device' and 'osdevice' (if it is listed) to 'boot' for each section you see. For example, on all of my systems, I have two items - a designation of 'bootmgr' with "device" in it, and a section of 'default' with "device" and "osdevice" on it. So, I run the three commands:
bcdedit /set {bootmgr} device boot
bcdedit /set {default} device boot
bcdedit /set {default} osdevice boot
And yes, type the lines exactly like that - unlee you have something else in the "designator" section on output of bcdedit.
- After finished, type 'bcdedit' again, and it'll show your changes.
That's it - if you need to make a ghost image, then reboot and make it there.
Cheers,
Mike.
Alan, I've been looking for this information since mid-May 2007. If you will post this information on my thread in the TechNet forum at http://forums.microsoft.com/technet/ShowPost.aspx?postid=2165436&isthread=false&siteid=17 , I will mark it as the answer that I was looking for, so that you can have the points for this information.
Thank you for sharing your knowledge!!
give me symantec ghost free download plz.
Works like a charm..thanks
- So why couldnt you guys just insert the vista disk and do a repair and let vista do a repair of the startup...
Seems like an overkill.
Or just install a trial version of Symantec Backup Exec System Recovery (assuming the new hard disk is going back into the same computer with the same motherboard and CPU) and then image it. - J_R_W,
The answer to that would be simple, many msdn users are developers from various fields, that deploy windows products over many desktops, and
it is easier to make one image with everything you need on it, set up with information it needs to run, rather than repeating the procedure 100+
times. From my perspective, all of the desktops i deploy images to are buildings away, and with testing they can re provision themselves 30 times
every few days with various operating systems.
Im just hoping Alan's method will work for windows 7 deployment too. That is giving me a headache.
So Thanks Alan.

