Ghost Solution Suite

All Ghost gurus,

What version of ghost is supported/compatible with Windows Server 2008 R2 64 bit ?

If Windows Server 2008 R2 is not supported please explicitly say so, since I have found no "whitepaper" explicitly stating that that it is nor that it is not supported.  It's clear that it's supported on Windows 7, but I am NOT using Windows 7.

I am ONLY interested in support for Windows 2008 Server R2 64 bit.

(I am NOT interested on ghost for Windows 7 nor Windows Server 2008 )

I've heard  that there are issues with dos batch scripts that doesn't work as well on 64bit compared to on 32bit?

If you got batch scripts that create ghosts, restore ghosts (clickable from the 2008 R2 Windows desktop)  etc. etc. you could share that works with 2008 R2 64 bit would be super!

Thank you,

Qa4Ever

You should forget DOS on any modern hardware as it just cannot handle SATA or large hard disks. Also, it does not run as a 64 bit process so cannot interact with true 64 bit apps.

Windows 7 shares a lot of the codebase of Win 2008R2, and since Ghost 11.5.1.2266 supports Windows 7 it should also support W2K8R2.  If you create a WinPE boot environment with the appropriate drivers for your NIC and SATA devices on the server, you can boot into WinPE and image from there.

EdT is correct. GSS 2.5.1 build 2266  supports imaging and deploying Windows 2008 R2 servers. please note that the console client is not supported for use on them, so you would want to use boot media (flash drive, CD/DVD, PXE) and NOT try to image via the console. EdT is also correct in that WinPE boot media is absolutely essential.

Thank you for your valuable answers Randal and EdT

Are there any plans to support console client in a near future on R2? (what build?)

The server rack is in a remote server lab, we want to have as litle physical access to it as possible, for obvious reasons.

Are there any (handmade/unsupported) scripts that you could share with me that avoids physical access to the computer, enabling clicking (or starting a cmd) on the R2 desktop to perform the process going back to a given ghost image?

I was maybe thinking of putting those scripts on a USB Stick?

The remote Server rack is re-imaged often, sometimes more often than ones a day.

Regards,

Qa4Ever

The Ghost development team was disbanded several years ago, although more recently there has been some talk of releasing an updated version of GSS. However, it is unlikely that there will be significant changes other than to update the WinPE version to V3 and update some of the scripts in line with new operating system releases. Search for past postings by Nigel Bree, one of the original Ghost developers, if you are interested in the history of Ghost.

If you are reimaging servers that often, then I imagine you would be looking for the best performance. I don't know of an "off the shelf" solution, but if you have a good KVM setup that allows you to remote into the systems even while they are booting, then the solution would be to set up a dual boot environment with WinPE as one of the boot systems. You could either dedicate a small partition on an existing disk in the server as an alternative bootable partition, and also to store the image, thus maximising performance, or you could use a WinPE bootable USB hard disk for imaging, which is selected at reboot time using the bios boot manager, which then keeps the server disks for nothing else than the server operating system.

One of my articles here: https://www-secure.symantec.com/connect/articles/readyadventures-winpe discusses how to create various WinPE boot solutions including a dual boot setup overlaid on an existing XP operating system. The technique used is readily adaptable to other combinations and other physical setups. Bear in mind that once WinPE has loaded, it runs entirely from memory, so you have total freedom on what you do with any connected disks.

Finally, WinPE happily runs HTA files, so giving you a mechanism for building a GUI in case you want to add various functionality such as disk reformatting, or choosing from different builds.

Are there any plans to support console client in a near future on R2? (what build?)

Note there's a difference between a "supported" platform where there's a cast-iron (and contractually backed if you get a maintenance agreement) guarantee that everything works, and the case where everything just works but the technical support people won't handle any problems that get raised. Asking whether it's supported is not the same thing as asking whether it works.

Actually, the console client should work just fine on R2. I wrote it, and I know of no reported problems with it on R2 in the GSS 2.5.1 release before I was laid off.

In actual fact, in the case of Windows Server 2008 R2, there is precisely one and only one GSS product feature that dosn't actually work, and that's not the console client - it's the "hot imaging" feature where the Ghost executable captures an image using the Volume Snapshot Services API. That feature would work just fine, but it's specifically blocked from working in the code by order of product management, because the  Symantec System Recovery (formerly Backup Exec System Recovery, formerly LiveState Recovery, formerly PowerQuest V2i) product charges something like $1,000 per server for the same feature. Thus our product team wasn't permitted to call that API on server systems lest we undermine that product.

In versions of genuine Ghost prior to GSS 2.5, we were expressly forbidden by the VP in charge of our team from writing code which called the Volume Snapshot Services API call at all, for no other reason than to prevent us from competing with the ex-PowerQuest product. Having "hot imaging" available for workstations in GSS 2.5 was only possible due to a management change, so that we briefly had a VP who would allow us to actually add features useful to our customers (before the next VP cancelled development of the product outright), but even during that brief period of sunshine the PM for the ex-PowerQuest product fought a spirited rearguard action and was able to block us from making the feature available on server platforms.