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
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
http://windowsconnected.com
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 boot
Note 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
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
hlee at 2007-10-11 >
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 boot
then 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.
