Imaging Windows 2000
Deployment of a new client
operating system is obviously a significant change for a network. The smoothest
path to Windows 2000 is to upgrade your existing workstations using
Microsoft’s extensive unattended setup options. In this way, you can keep the
applications and settings in place that will ease the change on users. However,
for many the upgrade to Windows 2000 is an opportunity to start fresh.
Years of installations, upgrades, removals and fixes leave a workstation in a state prone to various problems. Deploying a new drive image to workstations may be the answer to crushing the mess that has become of your workstations and at the same time allow you to standardize your new Windows 2000 baseline. Here we will cover some tips and things to watch out for when imaging Windows 2000.
You may not be able to use the same image on all of your workstations. The hardware abstraction layer (HAL) for one computer will not work on a machine of a conflicting hardware configuration. Microsoft managed to reduce the number of scenarios where this would be an issue to two cases: Advanced Configuration and Power Interface (ACPI) and non-ACPI HALs are not compatible.
Not long ago, there were issues
between uniprocessor and multiprocessor computers as well. An image may now be
created on a multiprocessor computer, and then by implementing options available
in SysPrep, the Windows 2000 installation will determine if a one or more
processors are running and automatically use the correct kernel files following
the Mini-Setup stage of the installation.
As for the ACPI and
non-ACPI compatibility issues, it is reportedly
acceptable to image the lowest common denominator. An image with no power
management (non-ACPI) can be applied to all workstations, but those workstations
with power management features (ACPI) will loose those benefits. The opposite is
not true; you cannot image a machine that does not have power management
features (non-ACPI) using an image created on a machine that had such features (ACPI).
The conversion from APM to ACPI is possible only through a reinstallation of
Windows 2000.
The image may be a bit larger than expected, and there are a couple of reasons for this. The main culprit is the new Windows File Protection (WFP) feature in Windows 2000 that stores copies of system files in a “DLLcache” folder on the boot volume. When any of these protected files are removed or replaced, WFP will take the copy from the DLLcache and put it back again to ensure these desired files are always in place. The problem is that this DLLcache folder is hundreds of megabytes in size (the default setting is 400mb or approximately 2700 files.) This problem is compounded further by the fact that when a Windows 2000 service pack is applied, instead of updating the files in the DLLcache, a second copy of the files are placed on the system. The System File Checker (SFC) tool checks the service pack location first and then the main DLLcache folder to find the desired files enforced by WFP. This second copy means that this feature may consume even more space.
This default setting may be adjusted by changing the size of the “SFCQuota” value in the registry (See knowledge base article Q222193 for details.) If by reducing the size of the cache, WFP detects a deletion or replacement of a file that it does not have a copy of in its DLLcache, it will look to the installation point for this file. If the installation were performed from a CD, the user would be prompted to insert the CD. However if the source were a network location available to the workstation, the files would be obtained from that point without prompting the user for media. This is a trade off that will have to be considered prior to deployment, if the space is available locally, it is best to keep these system-protected files locally.
Another reason the image may be so
large is that the page file is part of the image. SysDiff contains an option
called, “KeepPageFile” and by default this value is set to zero, which tells
SysPrep to regenerate the page file. It does not however remove the page file
from the image as indicated in the documentation. You can however, use the
"Clear Virtual Memory Page File When System Shuts Down" policy in
Windows 2000's Local Computer Policy to zero both the pagefile and the
hibernation file (hiberfil.sys) which will free considerable space.
SysDiff for Windows 2000 is much more robust than its NT predecessor. SysPrep now supports a new “-pnp” switch that informs the Mini-Setup to rerun the full PnP device enumeration and installation on the computer. If plug and play does not detect all components on a networks range of hardware, it can be further manipulated to do so. Non-plug and play devices must have their drivers contained within the image.
SysPrep requires that the mass storage controller on the master computer be identical to the controller on the destination computer. To support other mass storage devices for your image, they may be identified manually in the Sysprep.inf file before creating the master image. A section named, “SysprepMassStorage” must be added to the Sysprep.inf file listing each hardware id and its associated device INF file. One of the drawbacks of this is that the devices will be present on all machines the image is applied to. This may be cause for some confusion for some inventory software. The undocumented SysPrep switch, “-clean” may be used to remove unused mass storage devices. Those who worked with Windows NT unattended installs will be familiar with commandlines.txt, which is essentially a batch file executed following an unattended installation. This feature is now available to SysPrep itself and can be used to automate any number of scripted actions following the application of a new image. In this case adding “sysprep.exe –clean” will automatically remove unused mass storage devices following the Mini-Setup.
Support for the imaging of Windows 2000 is greatly improved, but as with any process there are always hurdles to overcome. Be sure to check back to AppDeploySM for more information on this and related issues in the future. Share your problems and solutions on imaging at our imaging forum!
Bob
Kelly
9.3.2000
AppDeploySM
Comments