What does this button do?
Desktop imaging lessons learned
Blog All software is designed to deal with a specific problem. In the case of the current set of articles that problem is desktop deployment.
If multiple different developers attempt to solve the same problem, then chances are good that they will run into the same obstacles. Different developers will have different approaches regarding overcoming these obstacles, and differing levels of success.
Some developers create workarounds so seamless that you only notice that an obstacle needed to be overcome in the most exceptional of circumstances. In other more unfortunate cases visible and ugly problems affect all software in a given field. This article will expand on some of these gotchas - both those endemic to individual desktop imaging applications, and those to which all desktop imaging apps fall prey.
In the previous articles on this subject I examined the desktop imaging applications PING (Partimage Is Not Ghost), Windows Deployment Services (WDS) and Symantec Ghost. Ghost was head and shoulders above the other offerings, with PING offering a rather lackluster showing for open source imaging applications. On the advice of a colleague, and wanting to give open source another go, I promised to take a look at both FOG (Free Open-source Ghost) and Clonezilla, having wrongfully neglected them in my implementation article.
Fog and Clonezilla both serve as fantastic examples of the two standard types of imaging options available, PXE multicast and boot CD. FOG is a PXE multicast solution: create an image, send it to the FOG server, and from there you can stream it to multiple target computers simultaneously.
Clonezilla is a boot CD: put it into a computer, boot from the CD, and you can make an image of that computer onto another hard drive, a flash drive or a network share. Alternately, you can boot from the Clonezilla CD and deploy an image to that computer. It is theoretically possible to use a PXE/TFTP setup to deploy Clonezilla in a manner that would allow it to run on multiple computers simultaneously, but frankly FOG just does it better.
Both Clonezilla and FOG do their jobs remarkably well; they are complimentary programs that in tandem offer all of the major features of either WDS or Symantec Ghost. While I don’t feel that either FOG or Clonezilla are of themselves a complete solution to the desktop imaging problem, combined they are a very serious challenger to Symantec Ghost, and a viable option for business desktop deployment in their own right. For those wanting to give FOG a try without the hassle of setting it up yourselves, a VMWare appliance is available. Clonezilla is available as a livecd.
As a server-based multicast imaging solution, FOG is designed to help systems administrators roll out collections of customised images to large numbers of desktops. As such, FOG is designed largely with corporate setups and demands in mind. One of the most notable features is that of partial Active Directory (AD) integration. FOG can be configured to rename any copies of Windows it deploys and join them to the domain. Fog does this by relying on the image it is deploying having the Windows Support Tools installed, specifically netdom.exe. Without it, any attempt to join the imaged computer to the domain will fail. Fog scales well, with real-world uses managing deployments to tens of thousands of computers.
Like any application though, FOG is not without its foibles, however they are very well documented in the site’s wiki. Be very certain to correctly tell FOG which operating system you are imaging. I have found it is far touchier about this than other imaging applications. As with WDS or Clonezilla, you will need to Sysprep systems before you image them, there is no built-in SID regenerator.
Ghost on the other hand does have an SID regenerator built in. You can configure your multicast sessions such that a given image has its SID wiped on the fly during deployment. Ghost is packed full of these sorts of features, faced with heavy competition from all corners, adding features is the only way to survive. When you buy Ghost you are buying not only the features but the constant updates and bug fixes.
The more complex an application (and Ghost is immense), the greater the chance that some new piece of hardware can trip it up. As such it is a good idea to keep your copy of ghost up to date. In my years of using it, there are many times where a Ghost CD wouldn’t work with a particular computer’s combination of hardware, yet a Liveupdate and a burned CD later and Ghost is working just fine on that very same computer.
The downside to these “neat features” can be their quirkiness. Take as an example Ghost’s ability to save images as a VMDK. As might be expected with the ability of Vista (or newer) operating systems to sysprep themselves into a hardware-agnostic “genericised” version, these operating systems convert into virtual machines quite well. Older operating systems that lack this ability (such as Windows XP) are far more hit-or-miss. Ghost tries hard - its ability to defang the XP HAL, or even to genericise Linux boxes is quite good, but it doesn’t work all the time, or worse yet sometimes it works but not quite all the way.
Ghost does the best job of all the desktop deployment solutions I’ve examined at taking an image from one computer, genericising it and deploying it to computers with completely different hardware. Still, it can and does fall prey to some nasty field-wide bugs. Perhaps the most annoying bug has to do with AHCI mode and SATA drives.
Most Windows XP systems administrators will by now have run into at least one situation whereby Windows XP uses one set of drivers for a given motherboard when AHCI is on, and one set of drivers if AHCI is off. This can cause real problems when deploying desktop images. You can be deploying an image onto identical hardware, yet if AHCI is not configured identically on the target system compared to the donor system, then bad things ensue.
A large number of errors encountered with imaging applications are errors of procedure rather than technology. Imaging solutions such as Ghost or Clonezilla offer you the opportunity to image a partition to a file. (For example your boot drive onto a file residing on a larger data drive in the same system.) It is painful how many times I have seen administrators try to ghost an image of a partition into a file on the partition they are trying to image.
Forgetting to enable compression is another mistake. When you are imaging a 500GB hard drive, of which only 10GB is occupied, compression is a very good idea. A 500GB raw image containing 490GB of empty space will make your storage admin cry. Multicasting images to multiple desktops brings its own risks. Never forget the nature and topology of your network when working with multicast. Unless you have some very nice switches (ones that will not forward multicast packets unless there are listeners on that port), turning on a multicast desktop deployment can absolutely flatten a network.
The worst example I have heard was a smaller business using an appliance iSCSI server as both a central file storage device and as a back-end for some virtualization. This was not on a separate storage network but on the main LAN with everything else. A multicast desktop imaging deployment to five PCs was attempted, the image files for which were also stored on this iSCSI server. The results were rather unpleasant, and saw the corruption of several very important files that the virtual machines were running, as well as some very badly-imaged desktops.
Desktop imaging is one of the most useful and important tools in a system administrator’s tool bag. It can be used for backing up a system prior to making some major or experimental change, to lighten our workload by deploying a standard image to multiple computers or even just to deal with a system where “someone, not me” got a virus. It is however a complex technology - easy enough to understand the basics of, but mature and feature-rich. Considering the kind of damage that you can do with imaging applications, I thoroughly recommend taking the time to research the options available and test them out in a lab environment. Most importantly, do not use any of these tools in the field until you understand fully how they work, and more importantly how they can go wrong. ®