OS Preinstallation for Microsoft Windows
An overview and explanation of the process of Preinstallation for NT-based Windows operating systems (NT4.0, Windows 2000, Windows XP and the Windows.NET Server family), including common deployment strategies and tools.
Not discussed: SMS based and RIS (PXE) based deployment solutions (these methods share technology with the OPK but due to technical limitations are used almost exclusively in corporate deployment).
Image: A pile of OS bits, either collected into a Blob or File-based format.
Blob-based: Blob-based images are produced by imaging software such as Ghost, PQDI or any other imaging software.
File-based: A file based image is simply a collection of files that you have produced by installing the OS onto a Target machine and then copying the resulting files and
directories off, usually to a network share to be accessed by your deployment scripts and tools.
Reference machine: The system on which you will prepare the OS for duplication onto Target Machines, and on which you perform any and all customization of the OS or addition of Software as your deployment scenario requires.
Target machine: The destination for the image created on your Reference machine.
There are 2 commonly used approaches to installing large numbers of systems with identical OS images.
: Image based and setup based. Below we will discuss the pro's and cons of each strategy as well as giving an overview of what's involved in the creation and maintenance of each procedure.
This process can apply to either a blob-image (such as those created by imaging software (Symantec's Ghost, Powerquest's PQDI, etc) or file-based image
Pros: Typically has the lowest per-machine deployment time from applying the image to booting the OS. The less downtime you have the quicker you can put your drone's back to work, or box that system for the customer.
Cons: Requires the greatest amount of prep work; must run tools to prepare images for deployment (sysprep, etc), there can be conflicts between the machine that prepared the image and the one to which it is deployed (see note on dissimiliar HAL's). Cost of the Imaging software can also be a consideration: frequently the charge is per-seat.
Assess target machine(s):
For image-based deployments: select a machine that is representative of the machines that you intend to deploy too. The Perfect world scenario here would be that you
are deploying to identical hardware boxes (same model, same bios revision, same HAL support, etc). There is some wiggle-room here; the important part of the
equation is to match your reference machine's HAL to the target machine's HAL.
The most effective way to prepare your reference image for duplication is to start with a clean slate, so after placing the CD of the Windows flavor that you intend to deploy into the drive (and "Pressing any key") clean the disk and recreate the partition structure that you intend to deploy to (ie: "X" number of primary/logical/extended partitions formatted with "X" file
system(s)). Note that your selection of a File System is an important choice here: If you have a DOS-based imaging software do not format your partition(s) as NTFS, since
you will not be able to access the disk from the imaging environment. Complete the setup process, selecting (best practice here) only those components that you want deployed to the consumer. From inside of the OS install any [patches}, service packs, QFE's or software packages that you want automatically deployed with the OS.
Once you've configured the system to your liking run the Sysprep tool that matches your release of the OS (ie: the Windows XP Sysprep releases are not compatible with Windows 2000 or vice-versa). If you are a System Builder you should get a copy of the OPK with every 3 pack of the OS. Any prep work you want to do for the end-user should be done before running Sysprep. If you want to configure networking to install in a particular fashion, or join a particular domain then this should be configured in your Sysprep.INF or Winbom.INI files (consult the OPK.CHM file in the \DOCS directory of the OPK Tools CD for specifics). Once you've run the Sysprep tool the system will shut down; it is now prepared for duplication
and deployment to your target systems. Save off your image using either a commerically available imaging software (Ghost, PQDI, etc) or a simple Xcopy to a network share.
A note on deploying to dissimiliar HAL's: Don't do it. Any image based installation from an ACPI reference machine (for instance) to a non-ACPI target (or vice versa)
will result in an unsupportable OS state.
Automating the Windows Setup process (usually through a customized unattend.txt file) so that it completes on the target machine without end-user input.
Pros: less up-front preparation and research required; no restrictions on HAL deployment, little long-term process maintenance required.
Cons: much slower than the Image based deployment method; if end-users are allowed to watch this process (as in corporate deployments) they may be tempted to touch something during the installation and could conceivably break in, causing unexpected results. Especially precarious is the process of automating the installation(s) of software packages during the first-boot of the target machine: the default configuration will login to the local machinein an administrator's context, providing an opportunity for extensive mischief if the end-user is watching.
Best practice: In controlled software environments restrict access to the target machine(s) during deployment by:
A. Dispatching a technician to safeguard the procedure at the end user's site.
B. Removing the target machine to the lab, preventing the poking and prodding the end user would provide.
C. Use an image-based approach to limit the exposure of the soft underbelly of the system.
D. None of this matters if you're an OEM, since your end
For a very thorough examination of the complete deployment process refer to the Resource Kit published by Microsoft and released with each Operating System. Each contains suggestions for evaluating the deployment solutions available and creating a process to deploy in a variety of environments.
Use the SetupManager tool (setupmgr.exe) located inside the DEPLOY.CAB file (you can find this in the support\tools directory off the root of your product cd) to create an Unattended answer file that is unique and appropriate for your environment. Once you've created the file you can use the same wizard to edit it, or you can simply open the resultant file in notepad.
You can feed the file that you have created to the setup process with a simply command line parameter. If you are running setup from inside a 32 bit OS you should use Winnt32. Ex:
Winnt32 /unattend:(location of unattend file)
If you are running setup from DOS you should use Winnt.EXE. Ex:
Winnt.exe /u:(location of unattend file)
Note that the Setup Manager program is capable of producing a batch file that includes all necessary parameters for an unattended Winnt32.exe-based installation if you do not wish to script this manually. Just look for the checkbox on the last page of the wizard.