quote:

---

Automating Windows 2000 Installations with Sysprep and KiXtart Across Varying Hardware Platforms

Why Sysprep?
The process of deploying computers can be a lengthy process taking well more than an hour to install, setup, and customize a Windows 2000 installation. By using disk duplication (also called ‘cloning’) a standard configuration a deployment can take as little as 5-10 minutes per computer.

Cloning computers is fairly straightforward with using this process for identical or nearly identical hardware configurations. However, it is possible to use Sysprep and Windows 2000’s ability to identify plug-and-play hardware. I will discuss how to accomplish this later.

Adding KiX to the mix allows us to extend functionality to the unattended process. Using KiX one can automate virtually all of the tasks to ‘customize’ a user’s profile.

The downside to cloning is that you can only distribute the ‘image’ as a clean install; imaging won’t work for upgrades. Also, some applications installed on a standard configuration may not perform properly when imaging is used. Thus, planning, designing, and testing must be done.

Planning
When planning for a Sysprep Image you should consider it a project. Projects have phases that are performed in order to ensure the success of the overall goal. There are five phases in any deployment of an image:

· Data gathering
· Planning and design
· Testing
· Piloting
· Production deployment

Data Gathering
Before you plan and design your image, you need to understand the environment in which it will operate. Problems will arise if you don’t consider your environment. For this guide, we’ll focus on the last three of the following list.

At a minimum, assess and document the following:

· Business organization and geographical requirements
· Network and application standards-both current and future
· User types-who will be using the image?
· Support processes
· Naming conventions
· Hardware configurations and standards
· Application configurations and standards
· User settings and user data

Analyze Hardware and Software
Before you build an image you should have a clear understanding of the hardware and software deployed in your environment. For example, there may be some hardware restrictions that will affect how your image is deployed. Analyzing your software will help in understanding how users use software, potential compatibility issues, or licensing considerations.

Consider the target workstations Hardware Abstraction Layer (HAL). The types of mass storage, drive controllers, and number of processors will play an important role. Check your hardware against Microsoft’s hardware compatibility list at:

http://www.microsoft.com/windows2000/server/howtobuy/upgrading/compat/default.asp

Analyzing your software is important as it shows you what your users have installed, how they are using their computer, where their data is stored, and how the environment is managed.

Planning and Design
Here is where we use the data we so fastidiously gathered and analyzed to plan and design our image. We will create the ‘master’ that when finished will be prepped for imaging with the Sysprep utility.

It is beyond the scope of this document to provide a complete reference for building a master image. Use your own experience, corporate guidelines, and best practices for setting up your Windows 2000 build. In general, the steps for creating your master will include:

· Installing Windows 2000
· Updating Device Drivers
· Applying service packs, hotfixes, and updates
· Setting up system and networking components
· Installing utilities and software
· Configuring desktop ‘look and feel.’
· Apply security policies
· Install post-configuration tweaks
· Etc.

Using your ‘master’ image across varying hardware platforms
One of the more challenging aspects of designing a master image is getting it to work on computers that are dissimilar to the computer on which the master was built. If not done correctly you will find yourself staring blankly at a lovely blue-screen-of-death. We can overcome the majority of these limitations by utilizing the Sysprep utility.

Get the Sysprep 1.1 utility here:

http://www.microsoft.com/technet/treeview/default.asp?url =/TechNet/prodtechnol/windows2000serv/downloads/syprep11.asp

The Sysprep 1.1 download will include all the needed files, documentation, and some sample sysprep.inf files. I’d encourage you to become familiar with the documentation.

I won’t go into a lot of details on customizing the sysprep.inf file. See the documentation (Microsoft Windows 2000 Guide to Unattended Setup (unattend.doc)) for details. Essentially, you configure your customized sysprep.inf file to import your customized settings, run sysprep.bat with the appropriate switches to execute sysprep.exe, and make an image of the ‘prepped’ computer.

Suffice it to say, that using Sysprep you can do anything from displaying your company’s logo during setup to setting up user data information. I will display some examples of working around some of the more troubling issues.

The infamous “Stop 0x0000007B” error after cloning an image to a dissimilar PC
Ok, here is the scenario; you’ve just created your master image (created on a Dell GX150), tweaked it out, run Sysprep, ‘imaged’ your master, and have successfully tested it on other Dell GX150’s. Great! Now you go to clone the image onto a Latitude C610 reboot and…blue screen of death.

Why? IDE chipsets. In order for Windows 2000 to boot, it has to be able to load the proper driver for the IDE controller. The IDE controller (and driver) for the GX150 is not the same as the C610.

Now what? It is possible to enable the controllers that natively supported by Windows 2000. Include the following section in your sysprep.inf file:

code:

---

[SysprepMassStorage]
;***********(Standard IDE ATA/ATAPI controllers)*********
   Primary_IDE_Channel=%windir%\inf\mshdc.inf
   Secondary_IDE_Channel=%windir%\inf\mshdc.inf

   ;*********** Generic_ESDI_Hard_Disk_Controller **********
   *PNP0600=%windir%\inf\mshdc.inf

   ;*********** Aztech IDE Controller **********************
   *AZT0502=%windir%\inf\mshdc.inf
 
   ;*********** Device ID for generic Dual PCI IDE *********
   PCI\CC_0101=%windir%\inf\mshdc.inf

   ;************Acer Labs Inc ******************************
   PCI\VEN_10B9&DEV_5215=%windir%\inf\mshdc.inf
   PCI\VEN_10B9&DEV_5219=%windir%\inf\mshdc.inf
   PCI\VEN_10B9&DEV_5229=%windir%\inf\mshdc.inf

   ;************Appian Technology **************************
   PCI\VEN_1097&DEV_0038=%windir%\inf\mshdc.inf

   ;************CMD Technology *****************************
   PCI\VEN_1095&DEV_0640=%windir%\inf\mshdc.inf
   PCI\VEN_1095&DEV_0646=%windir%\inf\mshdc.inf

   ;************Compaq ************************************* 
   PCI\VEN_0E11&DEV_AE33=%windir%\inf\mshdc.inf

   ;*************Intel *************************************
   PCI\VEN_8086&DEV_1222=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_1230=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_7010=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_7111=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_2411=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_2421=%windir%\inf\mshdc.inf
   PCI\VEN_8086&DEV_7199=%windir%\inf\mshdc.inf

   ;*************PC Technology *****************************
   PCI\VEN_1042&DEV_1000=%windir%\inf\mshdc.inf

   ;*************Silicon Integrated System *****************
   PCI\VEN_1039&DEV_0601=%windir%\inf\mshdc.inf
   PCI\VEN_1039&DEV_5513=%windir%\inf\mshdc.inf

   ;*************Symphony Labs *****************************
   PCI\VEN_10AD&DEV_0001=%windir%\inf\mshdc.inf
   PCI\VEN_10AD&DEV_0150=%windir%\inf\mshdc.inf

   ;*************Promise Technology ************************
   PCI\VEN_105A&DEV_4D33=%windir%\inf\mshdc.inf

   ;*************VIA Technologies, Inc. ********************
   PCI\VEN_1106&DEV_0571=%windir%\inf\mshdc.inf

---

There are drivers for SCSI devices as well, and an example of the entries to use for SCSI devices are included in the Sysprep examples. I have not tested whether or not both IDE and SCSI entries can be used in the [SysprepMassStorage] section of the sysprep.inf. Feel free to experiment.

How to add Plug and Play drivers to the Windows 2000 installation
Ok, using the same scenario as above. You’ve created your master on a GX150 and you’ve cloned the image to a C610. You managed to get the mass storage problem fixed, but now when you boot up the C610 plug and play kicks in and starts to install drivers for the ‘new hardware’ found. The problem is that the drivers for the new hardware aren’t included with the image.

How do we add the third-party drivers to the Windows 2000 installation, you ask? Use the following procedure to add your OEM-supplied drivers:

quote:

---

1. On the root of the volume where the %windir% folder is located, create a folder structure to hold the OEM-supplied drivers. For example:

code:

---

C:\Drivers
.....\NIC
.....\VIDEO
.....\SOUND
.....\ETC.

---

2. Copy the OEM-supplied drivers to their appropriate sub-folders.
3. Add the OemPnPDriversPath entry in the [Unattended] section of the Sysprep.inf file. You can list multiple paths in this key by separating them with a semicolon, as shown in the following example:

code:

---

[Unattended]
OemPnPDriversPath = Drivers\NIC;Drivers\Video;Drivers\Sound;Drivers\ETC. 

---

Note: The %SystemDrive% environment variable is automatically inserted before each of the listed search paths.

---

If you do not want the OEM-supplied drivers to remain on the HDD after the mini-wizard is finished, you can place the folder structure you created under the Sysprep folder. You will need to adjust the OemPnPDriversPath appropriately. The Sysprep folder (along with its sub-folders are automatically removed after Setup is finished.

Save the Sysprep.ini file in the Sysprep folder and run the Sysprep.bat. Any Plug and Play devices (including the ones you added) are automatically installed during the mini-setup wizard on the target computers. Note that you will not need to specify the –pnp command line switch in your Sysprep.bat file unless there are legacy (ISA) devices on the target computers. Using the –pnp switch will force a full Plug and Play re-enumeration of all devices. This will add 5-10 minutes to the Setup mini-setup process.

Note: If the OEM-supplied drivers are unsigned, the mini-setup postpones the installation of the device until an administrator logs on to the computer. See the following ‘Q’ articles in Microsoft’s Knowledge Base for more information:

Q236029 Setting Driver Signing Policy for Windows 2000 Unattended Setup
Q256204 Unsigned Drivers Not Installed During Sysprep Mini-Wizard Without –pnp Switch

Incorporating KiXtart with Sysprep
The Sysprep process includes several techniques for added customization. However, there are limitations with these options; for example, installing and configuring a sound card or installing a service.

Follow these steps to include a KiX script during the mini-setup:

quote:

---

1. Copy KiXtart (and any other utility you use to administer computers) to the appropriate locations. Also, register any DLL that needs registered (i.e. KixGUI, AutoItX, etc.)
2. Create a file name Cmdlines.txt with the command-line information to run your script at the top of the file. Example:

[Command]
”C:\Sysprep\i386\$oem\kix32 kix_prep.kix”

3. Copy the script to the proper location in your Sysprep folder.

---

The included script will run at the very end of the mini-setup wizard process. Here is a sample script:

Kix_prep.kix:

code:

---

$model=WMIQuery("Model","Win32_ComputerSystem")
$model=rtrim($model)
Select
Case $model="OptiPlex GX150" goto "GX150_Drivers"
Case $model="Latitude C610" goto "C610_Drivers"
EndSelect

? "Your model of computer ($model) is not directly supported by this image."
exit

:GX150_Drivers
; copy your drivers here, remember that the Sysprep folder will be deleted when done.
goto "Next"

:C610_Drivers
; copy your drivers here, remember that the Sysprep folder will be deleted when done.
goto "Next"

:Next
; do other stuff here. Like...set a runonce key to run another script during the 
; Autologon section you set up in your sysprep.inf file.
? "KiXPrep finished..."
exit

FUNCTION WMIQuery($what,$where,)
	dim $strQuery, $objEnumerator, $value
	$strQuery = "Select $what From $where"
	$SystemSet = GetObject("winmgmts:{impersonationLevel=impersonate}!//@WKSTA")
	$objEnumerator = $SystemSet.ExecQuery($strQuery)
	For Each $objInstance in $objEnumerator
		If @Error = 0 and $objInstance <> ""
			$=execute("$$value = $$objInstance.$what")
			$WMIQuery="$value"+"|"+"$WMIQuery"
			EndIf
		Next
	$WMIQuery=left($WMIQuery,len($WMIQuery)-1)
	exit @error
ENDFUNCTION

---

Follow these steps to run a KiX script as a post-setup script:

quote:

---

1. Setup your Sysprep.inf file to Autologon as administrator. Example:

code:

---

[GUIUnattended]
Adminpassword=password
Autologon=Yes
Autologoncount=1

---

2. Use the steps outlined above to create a Cmdlines.txt file.
3. Include in your KiX script the code to write into the Runonce key of the registry. Example (extended from above):

quote:

---

:Next
$=writevalue(“hkey_local_machine\software\Microsoft\windows\runonce”,”Kix_Post”,”kix32 %temp%\kix_post.kix”,”reg_sz”
exit

---

4. Copy your ‘Post Setup’ script to the appropriate directory.

---

Now you have created a method for running a script that will run after the mini-setup has rebooted your computer. Use your “Post Setup” script to automate tasks that cannot be accomplished by Sysprep like; installing machine specific drivers or software (i.e. touchpad drivers, chipset installations, changing computer name, add workstation to the domain, etc.). Use your imagination.

Testing, Piloting, and Deployment
Use the Testing and Piloting phases of your ‘Sysprep Image’ project to work out bugs and gain end-user acceptance. When that is done, you can begin Deployment.

---