Run batch files as administrator user

Unfortunately this question only just showed up today in my RSS reader, so even though it's a couple years old I thought I'd offer what is probably the right answer for future readers.

I'm not familiar with the particular model you describe as affected, but this does sound rather similar to a problem which occurred in certain models of ThinkPad (my memory says T60) which used a non-standard multisector MBR that occupied several sectors of the boot track rather than the usual one, with the results being identical to what you describe.

Ghost's classic imaging format prior to the introduction of the -IB switch stored only the original single MBR sector; this means that images of systems which actually have nonstandard, multisector boot track content only have half of the necessary boot code in them.

In almost all situations where the source image was not taken with the -IB switch, if Ghost detects boot code in the target disk you are restoring to, it tends to leave the original boot code intact and just manipulates the partition table within the boot sector. This is by design to deal with systems that did use special boot code (such as those with boot-sector hooks to replace the BIOS), and means that in most cases if the target system needed such custom boot code it would be left alone and would continue to boot.

However, if the target disk is completely blank, Ghost will use the boot code from the image for the MBR sector. If, as with the ThinkPad case we found in our QA labs, you have taken the image with no extra switches then the sector it restores tries to load the rest of itself from later sectors in the boot track that by default Ghost leaves alone.

So, you have several options; you can use gdisk /mbr after restoring to force the use of a standard "safe" MBR instead of a manufacturer custom MBR, or you can use the -IB switch with Ghost when capturing the source image to force Ghost to image all the sectors in the boot track rather than just the MBR.

The above is what we discovered in our labs in Auckland where we developed Ghost (until 2009, when Symantec closed the site and cancelled development of the Ghost Solution Suite product); Krish Jayaratne who was our QA manager discovered this and did the main investigation as to the workarounds and it just then took a little inspection to confirm the presence of the extra boot code.

While your situation may not be the same, it certainly sounds exactly like that case and I suspect the resolution should be the same. I did walk customers through this a couple of times on the official Symantec forums and it was documented fairly thoroughly, but since the Ghost Solution Suite product was cancelled Symantec lost most of the institutional knowledge around this stuff.

Edit to add: as I noted above, Ghost on restore by default for "normal" images leaves boot code in the MBR totally alone if an existing MBR is present. However, if the -IB switch was used to capture an image that fact is recorded as part of the image file meta-data (in fact, this is true of quite a lot of the switches; part of the obfuscated file header has a big 'ol bit array in it populated from the global variables - yes, really - that the argument parser extracts the command-line switches into). So not only do images taken with -IB have a subtly different structure to accomodate the extra boot sectors, the restore side of the process "knows" that -IB was used to take the image.

My recollection of the process (although I don't have the source code any more to confirm it) is that if -IB was used to capture an image, by default the boot code and extra boot sectors would then always be restored, making the restore process have the opposite default handling of boot code to the regular images. Part of the logic behind that is that the restore UI doesn't have the boot code stored in the image in a selectable container - you don't have a way of expressing the choice of whether to restore it or not easily (adding that would be a bit of a usability complication; UI is never "free" if people don't grasp what it means). The other is that some of the most important users of Ghost were computer manufacturers who licensed it for their OEM restore disks; if a computer manufacturer's factory restore image contained custom boot code for some reason, then normally by default they'd want it put back and having -IB also imply that slight difference in behaviour on restore seemed like the "right" default.

It was always a delicate balancing act with these fancy special cases deciding whether to make the fiendishly complicated command line even more complicated or adding a new piece of UI to make things more explicit, versus trying to do the "Right Thing" by default for most people and not making the default UI complicated. There's no argument that we didn't always choose right, but we did always agonize over that balance, especially since we had millions of customers with scripts that we wanted not to break.

My preferred method, two applications. The main app you already have. The second is a launcher/updater. Make a shortcut to the launcher, it checks a config setting (encrypted gibberish, xml, plain text, hard-coded directly into the launcher, whatever) for the path of the executable to launch then launches it. Once the main app is launched, the loader will terminate.

Whenever you get a new version, you update the config file of the launcher and future program launches will then open the new version.

It is the "boot loader" style process. Have a tiny assistance app that points to the full sized app. Clients launch the tiny app and it then directs them to the proper full app.

Bonus points if you have your launcher check hash fingerprints or signatures on the full sized apps to ensure no one gets creative and tries to link to another app from the launcher.