A particular problem for businesses or homes with multiple PCs is differences between them:
Hardware - as purchased and/or what may have been added or attached;
Operating System (OS) - Service Pack
(SP) level, security updates, etc;
Software - what has been installed where and licensed for use by whom.
Business wide, such differences can be costly in inefficiency and support, while even at home, they can be
inconvenient. These initial sections describe generally - detail will be decided by a
given situation and, of course, the devil will be in the detail - a systematic approach to
managing such differences, and, as one would expect, a central aim is to minimise them.
Hardware
Most businesses of any size, and many smaller ones, try to minimise the models of PCs they allow -
say a lower and a higher specification
(spec)
each of a laptop and a desktop, four models in all - and actually this approach makes perfectly
good sense in a home environment as well - an average home might be expected to function on at
most two models.
However, there are two particular things to check with the target
PCs chosen:
They must have the same Windows system kernel (NTOSKRNL.EXE) and the same, or at least compatible,
Hardware Abstraction Layers (HALs),
see Device Manager, Computer:
HAL
Compatible
Hal.dll
Description
Advanced Configuration Power Interface PC
Halacpi.dll
ACPI single CPU motherboard
ACPI Uniprocessor PC
Yes
Halaacpi.dll
ACPI multi-CPU motherboard with 1 CPU
ACPI Multiprocessor PC
Halmacpi.dll
ACPI motherboard with multiple CPUs
MPS Uniprocessor PC
Yes
Halapic.dll
Non-ACPI APIC multi-CPU motherboard with 1 CPU
MPS Multiprocessor PC
Halmps.dll
Non-ACPI APIC motherboard with multiple CPUs
Standard PC
Hal.dll
Most legacy PCs up to and including Pentium III
Windows installs boot drivers specific to PC hardware, so an image built on one PC may not have the
right ones for another. Those most likely to differ are:
Graphics port driver - the driver for, say, the AGP port itself, not the card
plugged into it;
Mass storage drivers - the chipset and/or
SCSI drivers to access Hard Disks
(HDs).
Preferably, target PCs should all have the same, though, in practice, the latter are the most important,
for if after imaging the former are on the build's driver search path, Plug 'n' Play
(PnP) will install them, while if the latter are missing, a
newly imaged PC may fail to boot with a 'Blue Screen Of Death'
(BSOD) error such as 0x0000007B "Inaccessible
Boot Device".
The differing boot drivers on my PCs are (all have pciide, mass storage drivers in
bold):
Description
Service
PC
Intel(R) 82865G/PE/P/GV/82848P Processor to AGP Controller
agp440
P4 #1
Adaptec AIC-7892 Ultra160/m PCI SCSI Card
adpu160m
P4 #2
LegacyDriver
SiSide
P4 #2
SiS 180 IDE UDMA Controller
SiSSATA
P4 #2
SiS Accelerated Graphics Port
SiSAGP
P4 #2
Adaptec AHA-2940U/AHA-2940UW PCI SCSI Controller
aic78xx
PIII
LegacyDriver
viaide
PIII
VIA CPU to AGP Controller
viaagp1
PIII
The easiest, but possibly most expensive, way to ensure compatibility with respect to these two issues is
to ensure that all your PCs have the same motherboards, or at least motherboards with the same chipsets,
and also the same types of HD. Given identical chipsets but not identical types of HD, a rough guide
for compatibility would be:
All (E)IDE
(aka
ATA and
PATA),
most likely no problem;
All SATA, or a mixture of IDE and
SATA, probably no problem unless to install Windows from CD on one or more of the SATA PCs you
need a driver diskette with a TXTSETUP.OEM file - if that is the case for one PC only,
do the new build on that same PC;
All SCSI, no problem if all the controller cards are identical;
Any other mixture, most likely a problem.
There is a cheaper but more time consuming alternative of using the SysPrep
utility with a suitable SYSPREP.INF file to install mass storage drivers as PCs are
imaged.
If you possibly can, create a very basic image and test it by copying it using imaging software to
each target PC, if necessary backing the PC up beforehand by the same method, and ensure that your
image can always boot!
It is also important to rationalise the hardware that may be attached to PCs. It can be highly
inconvenient if devices such as cameras and scanners can only be plugged into one PC because that is the
only one with the associated drivers and software installed, yet it can also lead to instability if
the build contains drivers for anything and everything that might ever be plugged into any PC, and further
there may be licensing issues involved in installing software on multiple PCs, even if there are enough
licences to cover associated hardware. Clearly a compromise is required, and it must take account
of the time involved in creating a universal build as against repeatedly installing drivers and software,
as well as the likelihood of introducing instability, and the software licensing arrangements.
Operating System
Both Windows and Linux, although the latter is not really covered here, have significant differences
between versions and distributions - consider the differences between any two of Vista, XP,
2000, Win9x, etc. As far as possible use one OS.
Software
It is also important to rationalise the software that may be installed. Again businesses usually
control this closely, so that, say, a large financial concern may have for every PC the same core build
of hardware support, operating system, and basic software such as browser and office suite,
but this is variously extended to create specialist builds containing software needed by Taxation or
Insolvency departments, and so on. Even in the home environment, you are likely to want the same
core build on every PC, perhaps you may even want exactly the same build on every PC.
Build Procedure
I was once responsible for creating W9x/W2k builds to be used on thousands of workstations, and this is a
generalised summary of the procedure I devised. The procedure for any other version of Windows is
likely to be closely similar, and for other OSs such as Linux closely analogous. In what follows, you
are prompted to back up many times. Mostly this can be done using imaging software in a
grandfather-father-son system, that is keeping always the most recent three versions of the build.
You may also wish to keep other milestone backups as certain staging posts are reached.
Decide on a rational installation directory structure for an installation HD or DVD. It will need
to contain the most up-to-date files (full executables, not just wrapper executables that launch an
internet installation) for:
OS Installation;
OS Service Packs and Updates;
Drivers for your rationalised hardware set;
Security Software Installation;
All other software installations.
Obtain all these files and copy them into the structure.
IMPORTANT! Divorce data from OS and software. Time spent well now will
repay the investment many times over in avoiding lost work, post imaging tweaks, etc.
Systematically go through your current systems examining what changes are needed to OS and software
to keep all important data in a rational structure on a separate drive or partition. For
example, there is probably not much to be gained in keeping temporary files such the internet cache
on the data drive, but you definitely want your bookmarks there, and probably your cookies as well.
Do this for every bit of software you use. Mostly the changes will be found in
utilities such as TweakUI, or Options or Preferences dialogs from software menus, while occasionally
a different registry or configuration file setting may be required.
On the chosen PC, do a clean install of the OS, SPs, and updates. Only create an Administrator
profile at this stage. Back up the image.
Install the security software.
Connect to the internet and get the latest updates to the OS and your security software.
Back up the build again.
Connect in turn each external device, installing the associated drivers and software. After each
device, it would be good idea to back up, though it's a bit of a judgement call. Most
particularly, if any have given problems in the past, leave them until last, and back up before trying
to install them, and once they are successfully working. Once complete, back up the image and
keep it as a milestone.
Now start on the software, again backing up frequently, and particularly before and after problem
software. Do the big stuff such as the office suite first, getting all the updates.
(Office itself is a pain, because programs like Excel by default leave many useful tools, utilities,
libraries, etc on the CD to be installed the first time they are used; one way around this is just to
install absolutely everything - disk space is comparatively cheap these days). Back up the image and keep it as a
milestone.
If you haven't already as you went along, apply the settings changes so that the build will store all
data on a separate drive or partition.
Copy the Admin profile into the Default User profile and then create any remaining user profiles.
Before doing this, you may wish to clear all history lists, get sensible window sizes for those apps
that remember them, choose colour schemes, etc. All users will then inherit these settings.
Once complete, back up the image as your final milestone.
Use SysPrep to prepare the image for duplicating. This is an important step as SysPrep will cause
each new clone to be given a unique Computer Name, Network Address, and
Security Identifier (SID).
With some versions of Windows it can also rebuild the PnP hardware tree and install mass storage boot
drivers. A comprehensive guide to SysPrep is beyond the scope of this article, but here are some
points to note (these apply to v1.1 for Windows 2000, other versions may differ -
ignore any line wrap in quoted lines):
Rather than use OemPnPDriversPath in SYSPREP.INF,
it's better to edit directly in the image before running SysPrep ... HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Path
... but ensure that the path starts %SystemRoot%\inf;<etc>
Tasks to be run between MiniSetUp and the first reboot can be put in the [commands]
section of the file ... %InstallFilesPath%\$oem$\Cmdlines.txt
... the first command of which may well be ... "C:\Sysprep\Sysprep.exe -clean"
... (note the quotes), whereas [GuiRunOnce] commands are run after the first reboot
(and also should be quoted).
The %SystemRoot% variable can not be used in the
[Unattended] section of SYSPREP.INF, but can be in the
[SysprepMassStorage] and [GuiRunOnce] sections!
To install mass storage drivers and reboot successfully, you must have ... [Sysprep] BuildMassStorageSection=Yes
... and possibly ... [Data] UseBIOSToBoot=1
... as well as the mass storage section itself. For example: [SysprepMassStorage] ; Adaptec AIC-7892 Ultra160/m PCI SCSI Card PCI\VEN_9005&DEV_0080="%systemroot%\inf\scsi.inf" ; SiS 180 IDE UDMA Controller PCI\VEN_1039&DEV_0180="<path>\SISSATA.INF",\,"GA-8S655FX-L","\SISSATA.INF"
Once SysPrep has completed, take your final image without letting the PC boot back into Windows (inserting a floppy will prevent this).
Useful links (no endorsement of external sites intended nor responsibility taken for their content):
<a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=3E90DC91-AC56-4665-949B-BEDA3080E0F6" title="Windows XP Service Pack 2 Deployment Tools">Sysprep Download - Windows XP SP2</a> (link now dead)
<a href="http://support.microsoft.com/kb/282191" title="UseBIOSToBoot Entry in Unattend.txt Is Enabled Regardless of the Set Value">Sysprep - UseBIOSToBoot</a> (link now dead)
<a href="http://service1.symantec.com/SUPPORT/ghost.nsf/d87bb6ce0bde286d88256d6a00452701/dce97bd94cf42e0088256c2f007dd7db?OpenDocument&ExpandSection=2" title="How to use Sysprep with Ghost">Ghost and Sysprep</a> (link now dead)