More on Automating Windows Installations with Ghost and Sysprep

Overnight from Friday and during Saturday I multicasted two groups of PCs in our computer suite. This can be quite a tedious process getting all 8 or 11 (in this case) clients up and running and then the multicast itself can take up to several hours depending on how fast the slowest client is going. In this case the work took practically all Saturday to complete due to various problems. It can get very annoying when you discover a small omission in your image that means you have to load it to a PC, fix the problem and then make a new image on the server. Three of the group of 11 didn’t have the right disk partitioning and I tried running Diskpart from the XP recovery console, but the problem was that while this created the partition, it did not make it bootable – I don’t know how I would have done that, as normally Ghost doesn’t seem to have this issue. So when I chose to only load a partition on those 11 PCs, these three only got the partition contents and not its bootable status; lacking in the knowledge to fix that, I changed the Ghostcast server over to a full disk image and left them running overnight Saturday (and Sunday) on another multicast disk load.

As I chronicled in my previous article, I started this kind of thing initially on Ghost, way back in our Windows 98 days (I started working in my present job on 26 July 2003, and first used Ghost when we set up our original 30 PC suite at the start of 2004) and then experimented with RIS for a while; then we got Ghost Solutions Suite 1.0, 1.1 and 2.0, but I fell a bit behind with my knowledge of what Ghost can do. All my experience of imaging is based on what we used to do with Windows 98 PCs. We would run the Ghost Multicast Server (as it was then called) on one PC, and go around all of the other PCs with boot floppy disks starting the Ghost client which would then hook them onto the multicast session. When you had all the number, and it could be the whole thirty if you wanted it to, which had hooked onto the multicast server session, the multicast started and in perhaps a couple of hours all of those PCs would have the new image loaded onto them. Since we got XP I didn’t use Ghost much except for loading the console client onto all our new PCs and trying out what it could do, but this didn’t include any imaging; all the new PCs were loaded by the factory when they used Ghost themselves. When I did start to look at imaging again, I tried out RIS.

What changed it for me was RIS being updated to WDS, RIS not being capable of doing .NET installs, and the wider use of laptops when it became advantageous to use Ghost to image them in a batch. But most of that imaging was done one PC at a time using conventional techniques. When I found that the 16 bit DOS client would not boot on some laptops, I created a Windows PE boot CD from our Vista license installation and used that to boot the laptop then start up Ghost32. Hurrah for the end of the NIC hardware specific DOS boot floppy or CD! It is only as we have got into the second half of 2008 that I have made a conscious decision to continue building on my existing Ghost knowledge and leverage that to continue imaging and updating our PCs into the future. In so doing I have learned that it is possible to image a machine without physically visiting its location using the Ghost console. This is a capability that will further enhance our use of this technology to maintain our PCs, much as Microsoft has moved to embrace concepts such as these with their Zero Touch install technology.

In another previous article I wrote about the need to undo the PushPrinterConnections printer deployment when moving from the use of printer deployment to printer preferences in Group Policy. This is actually the only way it can be done so far, attempting to automate this using Sysprep.inf GuiRunOnce section has not worked as expected. Basically there are several steps:

  1. While the PC is being imaged, move its account into an OU that runs PushPrinterConnections.exe with no deployed printers to remove all previously deployed printers
  2. After the PC is restarted, finishes Sysprep stages and comes up to the Windows logon for the first time, move the account to the preference based GPO
  3. Log in, run gpupdate /force /boot to force the new GPO to be implemented. This will restart the PC.
  4. The PC should now have implemented the preference based printer settings.

The important note about preference based settings is that the user can choose to remove them and they will not be reinstated the next time the user logs on. Preferences are a one time thing that run only when the GPO is created or updated. So, for pupil user accounts where preference based printer settings are used, you should disable the account’s ability to delete printers.