Building a Single Image for Dell PowerEdge Servers using Altiris Deployment Solution

Submitted by Eric Szewczyk on 23 January, 2007 - 10:33.

Talk about covering all the bases. Eric Szewczyk (one of our most popular writers) has created this amazing document (complete with helper files) that walks you through the creation of a hardware independent image for Dell PowerEdge Servers. The 2nd Edition of this paper has been updated to include support for Dell's 9th Generation Servers. You'll want to bookmark this gem!

Contents

Building a Single Image for Dell PowerEdge Servers using Altiris Deployment Solution (2nd Edition)

White Paper: PDF Version.

Condensed Article: PDF Version. New

Introduction

This paper focuses on the creation of a hardware independent image for Dell PowerEdge Servers running the Windows Server 2003 operating system, but includes methodologies that can be applied to all versions of Windows Server 2003, Windows XP, and Windows 2000 operating systems as well. Accompanying this white paper is a ONEDELLIMAGE.ZIP file containing supporting files required to successfully build a hardware independent image for Dell PowerEdge Servers, including but not limited to: a checklist, the Microsoft Sysprep utility, a sample SYSPREP.INF file, the Deployment Solution AClient (for scripting the install of the management agent), current Dell drivers (as of the updating of this white paper) including support for Dell's 9th generation servers, etc.

This paper provides step-by-step instructions, best practices, and considerations for building a hardware independent image from beginning to end for all currently shipping Dell PowerEdge servers and later. This image can be used as part of a comprehensive build process in which Altiris management solutions can help provision a server from bare metal including, but not limited to: configuring the BIOS, DRAC, BMC, and RAID components, deploying a scripted or image based deployment of the operating system, remotely deploying popular server applications such as OpenManage Server Administrator (OMSA), SQL 2005, Oracle 10g, VMware ESX Server, etc., and patching the hardware using Dell Update Packages (DUP), all as part of the complete bare metal provisioning process. For more information, browse to the Dell Alliance page of the Altiris website at www.altiris.com/dell and refer to the Deployment Solution for Dell Servers add-on product.

Fortunately, all 3rd generation and later Dell PowerEdge servers share a common Hardware Abstraction Layer (HAL) based on the Advanced Configuration and Power Interface (ACPI). One of the benefits of having a common HAL architecture is the fact that this eliminates the need to maintain multiple images per hardware model and helps significantly reduce the time required to deploy the Windows OS, service packs, security updates, hotfixes, software, etc. because all of this can be included in the base image if desired. Image based deployments are just one way to deploy an OS to a bare metal computer; scripted installs are another way. There are pros and cons to performing image based vs. scripted OS deployments which will be discussed as part of this paper. One deployment method may be more suitable than the other based on the network environment, which is in turn dictated by complex IT policies, diverse network architectures, opinionated IT staff, etc. Whichever method you choose, Altiris can help with your IT needs.

Common IT Obstacles

The following are some common "pain points" experienced by Information Technology (IT) staff when dealing with the deployment and on-going management of computer systems:

Dedicated IT teams must build and maintain at a minimum one image per hardware vendor, hardware model, and operating system when dealing with image based deployments.
Hours of effort required to provision hardware from bare metal, deploy operating systems, deploy software apps, patch the OS and hardware, etc.
Software version control maintenance is required to keep versions up to date loaded on "static" images as well as post production computers. This also includes service packs, security updates, and hotfixes as well.
Inconsistencies with computer builds from various IT staff members (such as versions of drivers installed, configuration methods, look and feel, etc.)

As you will see in the next section, maintaining and deploying a hardware independent image in the environment can help with most of the pain points listed here.

Benefits of a Hardware Independent Image

The following are advantages when maintaining and deploying hardware independent images:

Use one image for ALL of your Dell PowerEdge servers.
Significantly reduce the time from hours to minutes when deploying operating systems from a "bare metal" state.
Hands free deployment – In addition to deploying with the Altiris Deployment Solution, self extracting images can also be created and deployed via a bootable CD/DVD, network share, thumbdrive, SAN, etc. Refer to the section, "Deploying the Image Independent of Deployment Solution" for more information.
Current service packs, security updates, and hotfixes can be included in the image at the time of creation and then maintained automatically through the Altiris Patch Management Solution in a postproduction environment.
Flexible software version control and licensing – Rather than pre-install applications in a "static" image and increase your image maintenance intervals, consider repackaging all of your applications with Altiris RapidInstall (included with Altiris Deployment Solution) or use a more robust solution such as Wise Package Studio (acquired by Altiris). This will allow you to keep your hardware independent image cleaner by not including applications that are subject to go out of date easily and allows you to keep a tighter control over the software licenses (deploy when needed and keep track of the deployment of apps). Now you can deploy to your targets via Altiris Deployment Solution or Altiris Software Delivery Solution and always install the latest and greatest applications through push methodologies while reducing the time spent on updating your images.
Efficiency – The availability of a hardware independent image and automation reduces the need for dedicated IT staff to maintain multiple images per hardware model and in general deploy computers.
Consistency with builds – All new or repurposed deployed computers will have the same drivers installed, configurations, look and feel, etc. as the foundation to continue building from.

Pros and Cons to Image vs. Scripted OS Deployments

Pros

Image based OS Install	Scripted OS Install
Minimal deployment times: Approx 6-8 mins for a 2GB image file in DOS (16-bit) Approx 2-3 mins for a 2GB image file in WinPE or Linux (32-bit)	Service packs and hotfixes can be slipstreamed during the install process to ensure the latest and greatest Microsoft updates are applied when Windows is started for the first time, making it less susceptible to viruses and network attacks
A single image can be created for all Dell PowerEdge Servers eliminating the need to create and maintain separate images per OS/PowerEdge model	Drivers can be slipstreamed during the install process to ensure that your Dell PowerEdge Servers are always running the latest versions during the provisioning process
Consistency of the operating system build can be achieved by configuring the "look and feel" of the desktop, policies enabled, software installed, etc. without requiring user intervention or some sort of script to perform after deployment	Flexibility can be achieved by customizing the installation and configuration of Windows components during the install
Images can be multicasted which help by reducing network bandwidth and bottleneck constraints based on broadcast methods

Cons

Image based OS Install	Scripted OS Install
The image file is static. Once the image has been captured, the software and drivers contained in the image become outdated over time and require updates. In most cases the master image has to be deployed, updated, and then recaptured to be ready for mass distribution or management agents can be loaded in the image and updates are deployed post-OS through policy based distribution.	The operating system install can not be multicasted and can take anywhere from 2-4 hours depending on the number and size of updates being slipstreamed.
	The process of maintaining the latest service packs and hot fixes released from Microsoft and slipstreaming into the OS install can be a tedious process. The alternative is to leverage a patch management solution such as Altiris Patch Management Solution for Windows and allow the management agent to identify vulnerabilities of the OS shortly after deployment and then push out the updates as part of a policy based distribution.
	There are some initial one time preparatory tasks that need to be completed on the Deployment Server before you can use the predefined sample scripted OS jobs (i.e. copy media files and drivers, edit the answer files, etc.)

Setting Up Your Environment

The following are considerations when building hardware independent images:

Deploy an Altiris Deployment Solution

Having a Deployment Solution installed in your environment will allow you to easily capture and mass deploy your image once created. It will also serve as the environment to snap in products such as the Deployment Solution for Dell Servers add-on for bare metal provisioning your Dell Server hardware and managing the systems post-OS such as deploying software, patching the OS and hardware, capturing light inventory, etc. See the Deployment Solution Product Guide for installation instructions.
Identify Hardware Abstraction Layer (HAL) compatibilities
The HAL on the master computer must be compatible to the HAL on the destination computer. For example, an image captured from a system that is non-ACPI compliant and deployed to a system that is ACPI compliant will usually fail or get caught in a continuous boot cycle. Fortunately, most Dell PowerEdge Servers (from the 3rd generation through current hardware) have the same HAL.
Identify a reference computer from which the image will be created
Select a standard PowerEdge Server model with a recommendation of non-superfluous hardware or configurations to be the reference computer from which the image will be created from. This would include using SCSI over RAID, no DRAC cards, other add-in cards, etc. If you're not using the Altiris Deployment Solution for Dell Servers add-on to provision your hardware or using a PowerEdge model not supported by the Dell Tool Kit (DTK) and thereby not supported by the Dell add-on, you can initially provision the hardware and deploy the OS using the Dell Server Assistant (DSA) CD. This CD is included in the box of every Dell server that leaves the manufacturing plant or it can be downloaded from http://support.dell.com.

Many hardware components are embedded on the motherboard and can either be disabled from the system's BIOS or the case can be opened and the modules can be manually removed thereby disabling its functionality. Consult your hardware manual and warranty before attempting to do this yourself. For example, a server with an embedded PERC controller can be disabled in the system's BIOS which would then default to SCSI. This would then allow the image to be built from one SCSI drive with a small OS partition, rather than three from a typical RAID 5 configuration. The object here is to reduce complexity when building the image in order to have a higher success rate when mass deploying the image to your target hardware.

As part of my research for this white paper I used a very simple PowerEdge 400SC Server as my reference computer to build the hardware independent image from. As many know, this is simply a glorified Dell workstation, so just about any type of Dell computer will work in this example.
Select the minimum available hard disk or partition from reference computer
A rule of thumb when creating hardware independent images is that the source hard drive or partition in which you created the image from can not be larger than the target hard drive. For example, don't create an image from an 80GB drive or partition and deploy to a 40GB drive. In this day and age with standard hard drive sizes ranging anywhere from 60GB and up, it's hard to find small hard drives these days.

In this case, simply create a small partition in which the image will be built from. I usually like to create about a 6-8GB partition. This allows room to install the OS, copy the .\i386 directory from the Windows media CD, install any service packs, hotfixes, security updates, etc. and have a little bit of room left over if needed.
Select a target server to test the image
If possible, choose a different model of PowerEdge Server with different chipsets and hardware than your reference server to test the image on. This will be your true test and you'll know right away if you've configured the image properly after deploying by copying the appropriate plug-and-play drivers, creating the SYSPREP.INF file properly, etc. If this is not possible, you can plug in all the hardware components and configurations you removed from the reference server to test with if needed. Your results may vary because even though the Sysprep utility is supposed to strip out the current hardware devices installed on the reference computer, the drivers still linger in the system directories and could be re-installed when the system boots up again. Needless to say, this won't be a true test for your first image deployment.
Obtain the proper version of Microsoft Sysprep
Refer to the section, "Where Can I Get Microsoft Sysprep?" for more information. As a courtesy, there is a URL later in this paper that directs you to a supporting file (onedellimage.zip) which includes a copy of the Sysprep utility valid for the Windows 2003 and Windows XP operating systems.
Use a volume license key
It is recommended to use volume license keys and media for the operating system in which the hardware independent image will be built from. This will avoid Windows activation on the target systems.
Identify hardware inventory of target systems
To successfully build a hardware independent image, a little research is in order to properly identify the different types of hardware models, devices, peripherals, etc. that exist in the environment. For example: PERC, SCSI, DRAC, Modems, Network Cards, Video Cards, etc. Using Altiris Inventory Solution, Altiris Inventory Solution for Servers (soon to be released), Altiris Real-time System Manager Solution, or even the Altiris Deployment Solution for Dell Servers add-on is a great way to identify the hardware that exists in your environment. For example, Deployment Solution can capture "light" inventory through the Altiris AClient agent and report through the DS Console. The Deployment Solution for Dell Servers add-on can also capture and output detailed hardware inventory to a text file with the flexibility to run in a pre-OS environment without the need for an agent. The figure below shows a hardware inventory output from a PowerEdge 2950 Server.

Figure 1

Click to view.

For more information on the products mentioned, refer to the following links:

Altiris Inventory Solution

Altiris Real-Time System Manager Solution

Altiris Deployment Solution for Dell Servers

With this information gathered, you are now able to download the appropriate vendor specific or third party plug-and-play drivers required for each hardware device, chipset, etc. so that it may be properly installed in the Windows Server operating system of choice. Even though most of these drivers may be native to the operating system itself, it's best to download the hardware approved drivers from the specific vendor which in this case is Dell's support website at http://support.dell.com. Additional steps will be provided in the next section of this document.

Identify legacy devices

Legacy devices are devices that do not support Plug and Play (PnP) and may require manual installation and configuration after a disk image is deployed. Identifying these devices beforehand will save you future frustrations and possibly allow you to come up with some sort of automated workaround so manual intervention is not required. One very powerful feature of Altiris Deployment Solution is the ability to deploy any type of script in a pre-OS or post-OS environment. If something can be scripted to run unattended, chances are Altiris Deployment Solution can deploy it.
Properly build the SysprepMassStorage section of the Microsoft SYSPREP.INF file
One of the most critical and tedious part of this whole process is properly building the [SysprepMassStorage] section of the SYSPREP.INF file. This is where you identify items such as the PnP PCI Vendor ID's extracted from the vendor specific .INF files, the location of the drivers contained in the image, etc. so that they may be properly identified and installed when the computer goes through the post-deployment mini-setup process.

If not built correctly, you could experience several problems, including errors during the pre-deployment Sysprep process and ultimately a Blue Screen of Death (BSOD) if the OS can't properly identify and load the appropriate mass storage controller drivers. Refer to section, "Building the [SysprepMassStorage] Section of the SYSPREP.INF File" for step-by-step instructions for properly creating this section of the .INF file. As a courtesy, the contents of the complete SYSPREP.INF (including the 9th generation Dell PowerEdge Server support) can be found later in the body of this document as well as the actual file included in the onedellimage.zip containing the supporting files for this white paper. This will help expedite the entire hardware independent image process from start to finish if time is an issue or if you're not feeling very adventurous.

Gathering Dell Drivers for Inclusion in the Hardware Independent Image

After identifying the Dell Server hardware inventory in your environment, it's time to start gathering the drivers for each respective server model to be deployed in your environment. In the past, the DSA CD used to be a great starting point for gathering all the common PnP drivers for all the PowerEdge models. The drivers were listed in a .\PE714X directory and sorted by OS type (Windows 2000/2003) which you could then copy to a drivers directory embedded in the base OS for the hardware independent image. The DSA CD has gone through some architectural changes since then and this PnP directory no longer exists. The DSA CD still contains the drivers however, but they've been placed in a .\Drivers directory and named by each driver build (not type), thereby making it harder to identify the common drivers required for each PowerEdge model to be deployed in the environment. With the revising of this whitepaper, Dell has released a new DSA build (5.1) with a driver tool to gather and make the driver directories, thereby making it a little easier to support a scripted install of Windows or the deployment of a hardware independent image using Microsoft Sysprep methodologies.

This section will discuss 3 options for gathering the Dell PnP drivers required for the hardware independent image: Option 1 allows you to obtain the latest drivers from Dell's support website and Option 2 and 3 gathers drivers from the DSA CD. Downloading drivers from Dell's support website will always yield the latest drivers as opposed to using drivers from the DSA CD. This may be the preferred option if using the latest drivers is of the most importance to you. If you're OK with settling for the drivers contained on the latest DSA CD's, then the other options may be of interest to you. I can say from experience that using this option is the most tedious and cumbersome method for gathering and building out the driver directories due to the manual steps involved which could lead to human error, but allows you to always use the latest drivers (at the time of the downloading). Also depending on which option you choose, the gathering of the drivers can typically be accomplished on any computer and does not have to be the PowerEdge Server in which the base OS is created from (except for Option 3).

As mentioned previously, it's always recommended to use Dell approved drivers instead of using native Windows drivers. There have been several instances where a Dell driver or a third party Dell approved driver resolved a software dependency in which native Windows drivers could have never fixed.

Option 1 – Obtain Drivers from Dell's Support Website

Based on the hardware inventory gathered from the previously mentioned suggested products, you can now navigate to the http://support.dell.com website and start downloading the drivers based on the PowerEdge model and hardware components. Fortunately Dell standardizes on industry leading hardware vendors and gathering and categorizing these drivers are pretty straightforward. For example, Dell has typically standardized on only Broadcom or Intel for the NIC's, ATI Technologies for the Video Card, QLogic and Emulex for the Host Bus Adapters (HBA), etc. Organize the drivers into separate folders based on the device type and vendor if applicable. For example, storage controllers, management devices (DRAC), NIC's (Broadcom and/or Intel), etc. This will help you stay organized and allows for easier updating when new drivers are introduced.

Note: When downloading drivers from Dell's website, you'll find that drivers are grouped together by operating system and device. Drivers are also typically duplicated per hardware models within the same generation. For example, PERC 3/Di drivers for a PowerEdge 2650 (6th Generation) may be the same for a PowerEdge 4600 (6th Generation) using the PERC 3/Si controller. This is important to recognize to save efforts when downloading and gathering drivers to avoid duplication when applied to the image creation process later in this document. The figure below shows an example of a listing for all Windows Server 2003 drivers for a PowerEdge 2950 from Dell's support website to give you an idea of what to expect when navigating to this support website.

Figure 2

Click to view.

Creating the Dell Driver Hierarchy

When finished downloading the drivers, place them into a .\Dell folder in the root of the system drive of the base OS used for the hardware independent image (i.e. C:\Dell). Extract the drivers into their respective directories – leaving only the self-extracting install files in the folders will not work, they must be extracted to reveal the raw drivers. The figure below shows an example of a suggested driver hierarchy included with the supporting ONEDELLIMAGE.ZIP file which can be used for inclusion with the hardware independent image if desired to save time.

Legend
Directory	Description
audio	Audio Drivers
cs	Chipset Drivers
mgmt	Management (DRAC)
n	Network Card Drivers
non-raid	Non-RAID Controller Drivers
storage	RAID Storage Controller Drivers
9g	9th Generation Drivers
v	Video Card Drivers

Option 2 – Gather Drivers Using the Driver Tool from the DSA CD

One of the new features of the DSA 5.1 CD (released 9/11/06) is a "Make Driver Dir" tool. This is a command line interface (CLI) tool that will programmatically gather all the drivers from the DSA CD based on PowerEdge model, OS, and device type while creating the respective directory structures. The tool will also build out the "OEMPnPDriversPath" typically found in the Windows UNATTEND.TXT and SYSPREP.INF files so you can save time by copying and pasting. This path is required to search the appropriate driver directories when installing the hardware components through Windows PnP detection. If the path is not specified then the native Windows drivers will be used instead. Listed below are some examples of how to use this tool. For a full list of all the command line options and the user syntax for this driver tool, refer to the README.TXT file found on the DSA CD located here:

.\SERVER_ASSISTANT\DRIVER_TOOL

Example:

The following command will list all supported Dell servers, operating systems, and provide descriptions for all the driver build directories and output to a file called DRIVERS.TXT. This command can help you translate all the r714714 driver directories to something meaningful if you want to gather the drivers manually:

make_driver_dir.exe -i d:\ -d c:\drv --info > c:\drivers.txt

The following is an excerpt from the generated DRIVERS.TXT file:

OS Descriptions: 

suse10_64: "SUSE LINUX Enterprise Server 10 x86_64"
 suse9_64: "SUSE Linux Enterprise Server 9 x86_64 Service Pack 3"
  rh30_64: "Red Hat Enterprise Linux (version 3) x86_64 Update 6"
     rh30: "Red Hat Enterprise Linux (version 3) x86 Update 6"
 w2003sbs: "Microsoft Windows Small Business Server 2003 Service Pack 1" 
 w2003_64: "Microsoft Windows Server 2003 x64 Edition" 
    w2000: "Microsoft Windows 2000 Server Service Pack 4" 
    w2003: "Microsoft Windows Server 2003 Service Pack 1" 
   h40_64: "Red Hat Enterprise Linux (version 4) x86_64"
     rh40: "Red Hat Enterprise Linux (version 4) x86" 

Platform support matrix: 

pe6650: w2003 w2000 rh30 rh40 
pe6850: w2003 w2003_64 w2000 rh30 rh40 rh40_64 suse9_64 suse10_64 
pe1800: w2003 w2003sbs w2003_64 w2000 rh30 rh30_64 rh40 rh40_64 
pe0850: w2003 w2003_64 w2000 rh30 rh40 rh40_64 
pe4600: w2003 w2003sbs w2000 rh30 rh40 
pe1900: w2003 w2003sbs w2003_64 w2000 rh30 rh40 rh40_64 suse9_64 suse10_64 
pe2800: w2003 w2003sbs w2003_64 w2000 rh30 rh30_64 rh40 rh40_64 
pe2650: w2003 w2000 rh30 rh40 
pe1750: w2003 w2000 rh30 rh40 
pe0750: w2003 w2000 rh30 rh40 
pe2900: w2003 w2003sbs w2003_64 w2000 rh30 rh40 rh40_64 suse9_64 suse10_64 

Drivers: 
r123574 = sas_raid (SAS 5/iR Adapter)
r123575 = sas_non-raid (SAS 5/E Adapter)
r123581 = sas_raid (SAS 5/iR Adapter) 
r123582 = sas_non-raid (SAS 5/E Adapter)
r125801 = network (NetXtreme II Family of Adapters)
r125864 = network (NetXtreme Family of Adapters)

Example:

The following command will extract drivers for one PowerEdge model and one OS. I used the PE1950 as an example. You could easily extract drivers for all PowerEdge models and OS's, but make sure you have the room on your hard drive before doing so.

make_driver_dir.exe -i d:\ -d c:\drv -p pe1950 -o w2003 –extract

The figure below shows the output from screen when executing the previous command:

Figure 4

Click to view.

The figure below shows the output of the driver directory when executing the previous command:

Figure 5

Click to view.

The text below shows the output of PNPDRIVERPATH.TXT when executing the previous command:

oempnpdriverspath=drivers;c:\drv\pe1950\w2003\chip_set;c:\drv\pe1950\w2003\ide___eide;
c:\drv\pe1950\w2003\network;c:\drv\pe1950\w2003\sas_nonraid;c:\drv\pe1950\w2003\sas_raid;c:\drv\pe1950\w2003\scsi_nonraid;c:\drv\pe1950\w2003\video;c:\drv\pe1950\w2003\chip_set\r122802;c:\drv\pe1950\w2003\chip_set\r122802\sp;c:\drv\pe1950\w2003\ide___eide\r99970;c:\drv\pe1950\w2003\network\r120343;c:\drv\pe1950\w2003\network\r125879;c:\drv\pe1950\w2003\network\r126220;c:\drv\pe1950\w2003\network\r120343\ris_inf;c:\drv\pe1950\w2003\sas_nonraid\r122665;c:\drv\pe1950\w2003\sas_raid\r120960;c:\drv\pe1950\w2003\scsi_nonraid\r117179;c:\drv\pe1950\w2003\scsi_nonraid\r99849;c:\drv\pe1950\w2003\video\r122758;c:\drv\pe1950\w2003\video\r122758\b_29093

Once you have the drivers extracted, you could easily copy the drivers directory to the base OS for the hardware independent image and then copy the OEMPNPDRIVERSPATH to the SYSPREP.INF file.

Note: There are limitations to how many characters you can have in the OEMPNPDRIVERSPATH field. Refer to the last bullet in the "Considerations for Sysprep" section for more information.

Option 3 – Gather Drivers Using Altiris Deployment Solution for Dell Servers

One of the new features of the Deployment Solution for Dell Servers 2.0 add-on is the ability to programmatically extract the drivers from the DSA CD to the Altiris Deployment Server for purposes of scripting Windows Server installations. This functionality leverages the same toolset that is now publicly available on Dell's DSA CD mentioned above under "Option 2". This option is similar to Option 2 above in regards to extracting drivers, with the difference that this option uses a GUI interface instead of a CLI. The purpose of listing this as a viable option is that this interface will allow you to gather all drivers for your PowerEdge Servers, store them in a common directory, and build out the OEMPNPDRIVERSPATH as well. One difference from the option above is that instead of having a driver directory like the one shown above, you will have a common directory will all the PnP drivers for the PE model and OS type you choose without having duplicate directories per PE model (i.e. .\pe1950\w2003\sas_non-raid, .\pe1950\w2003\sas_raid, etc.). Once the drivers are extracted, you can copy to your baseline OS for the hardware independent image and copy the OEMPNPDRIVERSPATH from the UNATTEND.TXT file and paste into the SYSPREP.INF.

Follow the following steps to gather drivers using Altiris Deployment Solution for Dell Servers (the following steps assume the Deployment Solution for Dell Servers add-on has been installed. Refer to the product documentation for specific instructions pertaining to the installation and configuration of this product.)

From the Deployment Solution Console choose Tools > Dell Tools > Configuration Utility.
Click the "OS Deployment" tab as shown below.

Figure 6

Click to view.
Click the "Add" button.
Select the PowerEdge models applicable to your environment or select all if desired.
Select the OS in which you will be working with.
Insert the DSA CD into the Altiris Server and click the "Browse" button to browse to the CDROM location. The screen below should look similar to yours.

Figure 7

Click to view.
Click the "Add from DSA" button.
Browse to the following directory "C:\Program Files\Altiris\eXpress\Deployment Server\Dell\OSSup" and choose the Windows OS type (W2K or W2K3). The "Drv" folder can then be copied to your baseline OS to be used as the plug-and-play drivers directory for inclusion in the hardware independent image. The figure below shows the output of the driver directories for ALL PowerEdge models supported by the DSA for the Windows 2003 operating system.

Figure 8

Click to view.
If you browse to the root of the OS folder (i.e. "C:\Program Files\Altiris\eXpress\Deployment Server\Dell\OSSup\W2K3") you should have an UNATTEND.TXT file. Open the file and contained inside you should have the OEMPNPDRIVERSPATH populated with the same directories listed from step 8 as shown below.

Figure 9

Click to view.

You can now copy this path to the SYSPREP.INF file to the same respective field.

Note: If you use the same path shown above, make sure the drivers directory reflects the same path (i.e. C:\Drv\r57345;C:\Drv\r64211;C:\Drv\r70355). It's not necessary to specify the drive letter in the path, the SystemRoot (i.e. C:\) is assumed.

Note: There are limitations to how many characters you can have in the OEMPNPDRIVERSPATH field. Refer to the last bullet in the "Considerations for Sysprep" section for more information.

Updating the Hardware Independent Image with Altiris ImageExplorer

Once the Dell hardware independent image has been created, sysprepped, and captured using Altiris Deployment Solution, it's possible to use another Altiris utility called ImageExplorer to keep the image up to date or make changes to configuration files such as SYSPREP.INF, CMDLINES.TXT, ACLIENT.INP (AClient answer file), etc. ImageExplorer is an image editing utility included with Altiris Deployment Solution which enables you to update the image without the need for deploying and recapturing. This would enable you to add, replace, include, or exclude files and folders from an image, etc. This could be used to your especially handy for use with the hardware independent image because once the image has been Sysprepped and the computer boots, the image will need to be re-Sysprepped. This utility will save you considerable time and efforts. The figure below shows an example of this utility with the Dell hardware independent image opened.

Figure 10

Click to view.

Obtaining the ONEDELLIMAGE.ZIP Supporting File

As a courtesy, a .zip file containing supporting files for this white paper has been provided for you. This .zip file should contain everything you need to get started on building a hardware independent image including: a checklist, the Microsoft Sysprep utility, a sample SYSPREP.INF file, the Deployment Solution AClient (for scripting the install of the management agent), current Dell drivers (as of the updating of this white paper) including support for Dell's 9th generation servers, etc. Using this zip file will save considerable time and help expedite your hardware independent image build process. The .zip file can be downloaded from here.

Introduction to Microsoft Sysprep

Microsoft Sysprep is a setup utility that provides the following functionality:

Ensures the uniqueness of the Security Identifier (SID) for each deployed system. Without a unique SID, you may encounter network issues between deployed computers. The best analogy I can describe for this type of scenario is a courier trying to deliver a package to a specific house address, but all the homes on the street have the same house number. How could a courier possibly deliver the package in a situation like this?
Strips the hardware devices from the device manager in Windows before shutting the computer down for the image capture. This is how the image becomes hardware independent.
Processes sections of the SYSPREP.INF before the computer shuts down. For example, if you have specified various mass storage controllers in the SysprepMassStorage section of the SYSPREP.INF file or configured the SYSPREP.INF file to build this section automatically, this is the information that is processed during this time.

Note: There is a string of text you can place in the SYSPREP.INF file to have Sysprep build the [SysprepMassStorage] section for you automatically:

  [Sysprep]
  BuildMassStorageSection = Yes

This is not recommended for several reasons of which will be discussed in the "Building the [SysprepMassStorage] Section" of this paper.

Issues a default shut down command to Windows once Sysprep has successfully performed its initial tasks (this is optional for all Sysprep versions). Other options include rebooting and quitting the Sysprep utility when complete. It's recommended to accept the default of shutting the computer down so you know the process has completed and to avoid having the computer reboot into Windows again. If the computer boots back into Windows without capturing the image first, you've reverted back to where you started and the computer will have to be re-Sysprepped. There are also limitations to how many times you can Sysprep an image so before you Sysprep the image, it's recommended to capture the image as-is for future editing.
Note: Sysprep 1.1 for Windows 2000 will shut down automatically after executing. A command line must be invoked to Sysprep to not reboot after completing. Sysprep 2.0 for Windows Server 2003 and Windows XP includes a GUI interface with the options to shut down, restart, or quit the Sysprep utility after completing.

There are currently three versions of Sysprep available from Microsoft:
- Version 1.0 included with the Windows 2000 Product CD. This version will not support other Mass Storage Devices.
  
  Version 1.1 is the current version for use with the Windows 2000 operating system and supports the changing of the Mass Storage Devices.
- Version 2.0 is the current version for use with the Windows Server 2003 and Windows XP perating systems. Sysprep 2.0 offers new options such as resetting the grace period for activation. A copy of this Sysprep version is available in the ONEDELLIMAGE.ZIP file.
Note: Microsoft provides valuable information for using Sysprep. One of the best resources is the "Microsoft Windows Corporate Deployment Tools User's Guide" (DEPLOY.CHM) bundled with the Sysprep utility contained in the DEPLOY.CAB file on the Windows media CD. It's recommended to consult this documentation to learn more about Sysprep's functionality and available options.

Using Sysprep as Documented

This section is intended to be informational as well as a prelude to some of the steps required to build a hardware independent image from the reference computer. Please take the time to read this section to prepare for the image build process.

A brief description to some of the files in which you will be using directly and indirectly:

Sysprep.exe – A utility that prepares the Windows operating system for mass distribution.

SYSPREP.INF – An answer file that is used to automate the mini-setup process of the deployed imaged computer.

Setupcl.exe – A tool that regenerates new security identifiers (SID) for the computer. This tool cannot be invoked directly and must reside in the same folder as Sysprep.exe. Both Sysprep.exe and Setupcl.exe are required and are mutually dependent.

Setupmgr.exe – A GUI based utility to help build the foundation of the SYSPREP.INF file in which you can later add or remove various sections to fully customize the image deployment experience.

Deploy.chm – The "Microsoft Windows Corporate Deployment Tools User's Guide" is a great start to learning more about the functionality of Sysprep and how to effectively deploy systems.

Ref.chm – The "Microsoft Windows Preinstallation Reference" contains all the options available when building the various sections of the SYSPREP.INF file.

Considerations for Sysprep

Keep these items in mind when installing and running Microsoft Sysprep:

A CMDLINES.TXT file can be used to run commands during the mini-setup portion of the Sysprep process. One example could be to kick off a scripted install of the Altiris Deployment Solution agent (ACLIENT.EXE) to manage the system from a post-OS environment. The main purpose is to include a command line to clear the critical device database used by the [SysprepMassStorage] section in the SYSPREP.INF file. The critical device database is a registry listing of devices and services that must start in order for Windows to boot successfully. An example of the CMDLINES.TXT file included with the ONEDELLIMAGE.ZIP file has been provided below:

  [Commands] 
  "c:\sysprep\sysprep -clean" 
  "c:\sysprep\aclient.exe c:\sysprep\aclient.inp -install -silent"

Note: Refer to the section, "Installing Altiris Agents" for more information regarding the various options for supporting a remote install of the Altiris Deployment Solution Client (AClient) and how to configure.

Upon completion, the devices not physically present in the system are cleared out of the database and the critical devices present are left intact. Depending on the situation, the "–PnP" switch can also be added to force a complete enumeration of all devices in the system. This will add approximately 5 to 10 minutes to the duration of the mini-setup process. This switch is NOT required for PnP devices but is useful when ISA or other non-PnP devices (that cannot be dynamically detected) exist on target systems. Use this switch only when you need to detect and install legacy devices. Do not use "Sysprep -PnP" on computers that only use PnP devices. Doing so will increase the time required for the first-run user experience without providing any additional benefit.

It is advised, but not necessary to "tokenize" the SYSPREP.INF file with embedded Altiris Deployment Solution tokens to provide greater flexibility when mass deploying computers. There are about 45 different built-in Deployment Solution tokens ranging from %COMPNAME% (NetBIOS Computer Name) to %SERIALNUM% (Dell Service Tag) to %ASSETTAG% (Asset Tag), etc. This enables the SYSPREP.INF file to be unique in nature and act as a template by replacing tokens with values from the Deployment Solution eXpress database. For example, instead of having this line of text in the SYSPREP.INF, "ComputerName=*", you could use this instead: "ComputerName=%COMPNAME%". This would prevent the mini-setup from randomly creating a Windows hostname based on the registered user and organization name listed in the [UserData] section of the SYSPREP.INF file and inject the desired Windows hostname from the database. You may be wondering how this works when the computer is not currently managed by the Deployment Solution. Another powerful feature of Deployment Solution is the ability to pre-provision computers in the Deployment Solution console before they ever connect to the network. When the computers are connected to the network and booted to PXE or a Deployment Solution automation disk or partition, the Deployment Solution jobs queued up for that computer(s) are automatically deployed without requiring an Altiris administrator to launch the Deployment Solution Console. For more information refer to the "Introducing Deployment Solution Tokens" section of this paper and also refer to the Deployment Solution Reference Guide.
Sysprep should automatically delete the ".\SYSPREP" folder contained in the image after it's been deployed by removing all of its contents after the mini-setup process completes. This removes the Sysprep utility and avoids the possibility of a production computer being re-Sysprepped. Sometimes when you initiate tasks from this folder such as scripting the Altiris management agent to install as part of the mini-setup process, the deletion of the folder may not fully complete. There are workarounds that can be accomplished such as executing the DOS utility, DELTREE as part of the [GuiRunOnce] section of the SYSPREP.INF file to ensure the deletion of this folder and its contents. It's strongly advised to keep a copy of the Sysprep folder containing the original SYSPREP.INF file somewhere on the network to save time with future image building efforts.
If you are not comfortable leaving the local admin password in clear text format in the SYSPREP.INF file, there are alternatives:
For example, it's possible to encrypt the local administrator password in the SYSPREP.INF file and apply it during the mini-setup process. Make sure there is no password set for the local administrator account in the image before using this approach. If not, you will receive an error message during the mini-setup process when it tries to apply the password. If you choose to not set a password, you will lose the AutoLogon functionality of Sysprep. If you must use the AutoLogon feature and do not want to reveal the administrator password in any form, you can set the local administrator password in the image and leave the password blank in the SYSPREP.INF file by using the null value represented by an asterisk (*).

By choosing this option, the AutoLogon feature will function properly and will allow you to set a value for the "AutoLogonCount" in the SYSPREP.INF file. This may not be a preferred option if you are rapidly changing passwords in your environment. Altiris has a policy based solution for randomly generating passwords for local accounts at user defined intervals once the computer has been deployed and the Altiris agent has been loaded. Refer to the Altiris website for information on the Altiris Local Security Solution. There are also numerous third party utilities on the market (such as Hyena) that will allow you to change local admin passwords on the fly after the image has been deployed.
Leaving domain admin accounts and passwords in clear text format in the SYSPREP.INF file is a much higher security risk. Unfortunately, there is no option to encrypt these credentials as part of the Sysprep Setup Manager process.
One option is to create a domain account that only has rights to add a computer to the domain when requiring computers to join the domain from Sysprep. That way, if the SYSPREP.INF file is compromised, the only action a user will be able to do is to add a computer to the domain. The majority of the computer domain additions can take place as a post configuration task through Deployment Solution via the Deployment Agent (AClient). Be sure to add the domain admin credentials to the "Domain Accounts" tab of the Deployment Solution options to enable this functionality. Refer to the Deployment Solution Reference Guide for more information.
To make the image hardware independent, you must have a [MassStorageSection] in the SYSPREP.INF file that can identify the diverse mass storage controllers that exist in the environment. Sysprep 1.1 and later can work in conjunction with the native operating system storage controller drivers listed in the INF directory of the Windows System root. These files include MACHINE.INF, SCSI.INF, PNPSCSI.INF, and MSHDC.INF.
The contents of these files list everything that is natively supported by Windows with respect to mass storage controllers. If you are using Windows Server 2003 or Windows XP and the Sysprep 2.0 utility, the [SysprepMassStorage] section of the SYSPREP.INF file can be populated automatically. When the SYSPREP.INF file is parsed, it will automatically add the list of mass storage controllers natively supported by Windows from the contents of the files listed above.

Note: It's strongly recommended to NOT allow Sysprep to automatically create the [SysprepMassStorage] section and to use vendor specific drivers. It's also normal for the Sysprep resealing process to vary drastically in time depending on the length of the mass storage section in the SYSPREP.INF file. For example, if you populate the [SysprepMassStorage] section following the guidelines in this document and then reseal the computer, times can average anywhere from 13 minutes. If you allow Sysprep to automatically create the [SysprepMassStorage] section, times can be in the upwards of 20 minutes. This is due in fact to the Sysprep process extracting the driver details from the .INF files mentioned earlier in this section.

Note: It's also important to note that the guidelines and driver support included in this document are intended for Dell servers configured with RAID, SCSI, and SAS controllers using SCSI hard drives. For example, if the target hardware includes any of the PowerEdge SC models utilizing IDE controllers and hard drives, the [SysprepMassStorage] section would need to be populated with the PnP PCI Vendor ID's for the respective IDE controllers or other types of controllers that may exist in the system. This needs to be completed BEFORE running Sysprep and capturing the image.
The OEMPNPDRIVERSPATH field of the SYSPREP.INF file has a limitation with the amount of characters that can be included depending on which OS you use. For example, Sysprep intended to run on Windows 2000 has a limitation of 2047 characters while Sysprep intended to run on Windows XP and Windows 2003 has a limitation of 4096 characters. This is important to understand when building out your driver directories. There are workarounds to this limiation however. For example, it is possible to write the OEM PNP drivers path directly to the registry of the base OS in the DEVICEPATH key found here: HKLM\Software\Microsoft\Windows\CurrentVersion. This will allow you to enter up to 64KB of data to avoid this limitation. If you don't use this workaround then the OEMPNPDRIVERSPATH that you specify in the SYSPREP.INF file is automatically entered in the DEVICEPATH registry. I always use the workaround by entering my own drivers path to the registry to avoid any potential problems. For example:
```
%SystemDrive%\Dell\audio;%SystemDrive%\Dell\cs\1;%SystemDrive%\Dell\cs\2;%SystemDrive%\Dell\cs\3;%SystemDrive%\Dell\cs\4;%SystemDrive%\Dell\cs\5;%SystemDrive%\Dell\cs\6;%SystemDrive%\Dell\cs\7;%SystemDrive%\Dell\cs\8;%SystemDrive%\Dell\m\bc;%SystemDrive%\Dell\m\ch;%SystemDrive%\Dell\m\co;%SystemDrive%\Dell\m\cy;%SystemDrive%\Dell\mgmt\;%SystemDrive%\Dell\n\bc\1;%SystemDrive%\Dell\n\bc\2;%SystemDrive%\Dell\n\intel\1;%SystemDrive%\Dell\n\intel\2;%SystemDrive%\Dell\nonraid\bp\1;%SystemDrive%\Dell\non-raid\bp\2;%SystemDrive%\Dell\nonraid\gem;%SystemDrive%\Dell\storage;%SystemDrive%\Dell\storage\9g\fiber;%SystemDrive%\Dell\storage\9g\perc5;%SystemDrive%\Dell\storage\9g\sasnonraid;%SystemDrive%\Dell\storage\9g\scsinonraid;\%SystemDrive%\Dell\v\ati;%SystemDrive%\Dell\v\int;%SystemDrive%\Dell\v\
rn5;%SystemDrive%\Dell\v\vol;%SystemDrive%\Dell\misc;%SystemRoot%\inf 
```
Leaving the default "%SystemRoot%\inf" at the end of the devicepath will allow Windows to use native drivers if the setup process can't find a vendor supplied driver in the specified path. You may choose to leave this in or remove it. If you gather and build out the drivers directories properly for the hardware components in your environment, you shouldn't have any native drivers installed.

Creating the SYSPREP.INF File

The Sysprep utility is located in the ".\Support\Tools\Deploy.cab" file on the Windows 2000, Windows XP, and Windows Server 2003 media CD's. Verify that you are using the correct version for the operating system in which the base image will be created from.

Extract the contents of the DEPLOY.CAB file into the "C:\Sysprep" folder. When finished, the Sysprep folder will be transferred to the base OS in which the hardware independent image will be created in the steps to follow.

The following steps are intended as prerequisites before preparing the base OS of the reference computer and can be completed on any system. Two options will be listed in creating the SYSPREP.INF file. Option 1 will demonstrate how to create from the Sysprep Setup Manager (SETUPMGR.EXE). Option 2 will demonstrate how to create manually by using the SYSPREP.INF from the Samples section of this document. It is recommended to combine both options when initially creating the SYSPREP.INF file. This will allow you to create the foundation, and then add the other various sections as needed.

Option 1: Creating the SYSPREP.INF Using the Sysprep Setup Manager

Launch the Setupmgr.exe file from the C:\Sysprep folder. Click Next when prompted.

Figure 11

Click to view.
Select Create New and click Next.

Figure 12

Click to view.
Select Sysprep setup. Click Next.

Figure 13

Click to view.
Select the version of the operating system. Click Next.

Figure 14

Click to view.
Select Yes, fully automate the installation. Click Next.

Figure 15

Click to view.
Type the name of the User and Organization. This information is not relevant to the image building process and can be easily replaced through the use of Deployment Solution System Tokens. Click
Next.

Note: The information provided here is used by the Sysprep mini-setup process to randomly generate a computer name if Deployment Solution tokens are not used.

Figure 16

Click to view.
Accept the default of this screen. Click Next.

Figure 17

Click to view.
Select your time zone. Click Next.

Figure 18

Click to view.
Enter the volume or retail product key. (If you don't know the product key or have unidentified volume media, steps will be provided later in this document to extract the key from the Dell Server Assistant install process.) Just enter X's for now. This can be manually changed later.

Figure 19

Click to view.
Select the appropriate licensing mode based on your licensing agreement. Click Next.

Figure 20

Click to view.
Select Automatically generate computer name. This will place an asterisk (*) in the "COMPUTERNAME" field of the SYSPREP.INF file which tells Sysprep to randomly generate a NetBIOS computer name based on the Organization name, also specified in the SYSPREP.INF file. There are alternatives for configuring a computer's NetBIOS name (as well as other configurations) through the use of Altiris Deployment Solution. This includes the use of system tokens or through AClient's post configuration process. These alternatives will be discussed later in this document. Click Next.

Figure 21

Click to view.
Enter a password for the local administrator, or leave it blank. There is no wrong or right way in completing this step. You can either set the local administrator password in the image and leave this field blank in the SYSPREP.INF file or include it in the SYSPREP.INF file and choose to encrypt it. Click Next.

Figure 22

Click to view.
Accept the default Typical settings. Click Next.

Figure 23

Click to view.
Accept the default WORKGROUP. Click Next.

Figure 24

Click to view.
Enter the area code. Select Next.

Figure 25

Click to view.
Accept the default. Click Next.

Figure 26

Click to view.
Accept the default. Click Next.

Figure 27

Click to view.
Enter any printers to be installed after a user logs on for the first time. Click Next.

Figure 28

Click to view.
Enter any commands to run after a user logs on for the first time. Some suggested commands to enter are as follows (these commands will be discussed throughout this paper):

  "c:\windows\system32\deltree /Y c:\sysprep"
  "regedit.exe /s c:\dell\script\srcpath.reg"

Click Next.

Figure 29

Click to view.
In the open field, type "c:\sysprep\sysprep –clean" and click Add followed by clicking Next. If you choose to install the Deployment Solution AClient as part of the mini-setup process, add the following command: "c:\sysprep\aclient.exe c:\sysprep\aclient.inp -install -silent".
Note: If you choose to add this command, make sure you have the ACLIENT.EXE and ACLIENT.INP files located in the .\Sysprep folder of the base OS before sysprepping the computer. These files can be found in the root of the eXpress share of the Deployment Server and are also included in the ONEDELLIMAGE.ZIP file. Refer to the Deployment Solution Reference Guide for properly configuring the ACLIENT.INP answer file and scripting AClient.

Figure 30

Click to view.
Enter an optional identification string to identify the image after installation. Click Finish.

Figure 31

Click to view.
Accept the default Save location. Click OK.

Figure 32

Click to view.
Click Cancel to finish.

Figure 33

Click to view.
Save the Sysprep folder and SYSPREP.INF file you just created. It will be transferred to the base OS of the reference computer in later steps.

Option 2: Creating the SYSPREP.INF File from the Sample Provided

Extract the contents of the DEPLOY.CAB file located in the .\Support folder of the Windows Media CD to the C:\Sysprep folder of the base OS of the reference computer.
Inside the Sysprep folder create an i386 folder. Inside of this folder create another folder named "$oem$" as shown below.

Create a file named "cmdlines.txt" in the $oem$ folder.
This file should contain the following text:

[Commands]
"C:\Sysprep\Sysprep –clean"
"c:\sysprep\aclient.exe c:\sysprep\aclient.inp –install" –silent (Optional)

Create a file called SYSPREP.INF. Copy and paste the contents of the SYSPREP.INF file from the "Samples" section of this document and paste into the SYSPREP.INF file. (This file will have to be edited based on information pertaining to your environment.)

Building the [SysprepMassStorage] Section of the SYSPREP.INF File

Once you have created the .\Sysprep folder and SYSPREP.INF file from the, "Creating the SYSPREP.INF File" section, you may proceed to build the [SysprepMassStorage] section of the SYSPREP.INF file.

This section defines the mass storage controllers and paths of its drivers contained in the hardware independent image for all of the storage controller hardware in the environment in which the image will be applied. All other PnP devices such as network cards, video cards, etc. will be picked up automatically as long as the PnP drivers and paths are properly defined.

This section is the most exacting process with editing the SYSPREP.INF file and also the most important contributor to a successful hardware independent image. This is the section where you enter the PnP PCI Vendor ID's, paths to the drivers (INF files), disk directories, device descriptions, and source disk names. If this information is not entered correctly, you will generate a Sysprep error message preventing you from continuing on with the sysprepping of the image. Refer to the section, "Troubleshooting Sysprep" for more information.

Note: While the majority of PowerEdge drivers are native to the Windows Server 2003 operating system, it is strongly recommended that you use the vendor provided drivers from the Dell Support website.

With the newer versions of Sysprep, it is possible to automatically populate the entries in this section automatically. The entries are populated from the PnP hardware ID's specified from the MACHINE.INF, SCSI.INF, PNPSCSI.INF, and MSHDC.INF files located in the .\INF directory of the Windows folder. If you open these files you will see a list of IDE and SCSI devices that are natively supported by the Windows Server OS. This also applies to the NT based Windows OS's for clients as well.

Although automatically building the [SysprepMassStorage] section from the native Windows drivers may seem like the easiest and more logical approach, it is strongly recommended that you build this section from scratch for these reasons:

Sysprep will only include the devices and drivers that are native to the Windows operating system.
The vendor specific drivers required to truly make the hardware independent image based on the various supported hardware in your environment will not be included in the image.
By generating the [SysprepMassStorage] section automatically, you add a considerable amount of time to the prepping and deployment processes for the overall user experience.
By tailoring the [SysprepMassStorage] section for the mass storage controllers in your environment, you create a much cleaner SYSPREP.INF file. You will also save time during the prepping and deployment processes for the overall user experience.
By downloading current and up to date vendor specific hardware drivers, you know they have been tested specifically for the hardware model and OS in which the image will be applied rather than using canned native Windows drivers.

The building of this mass storage controller section is crucial because these drivers are the first to be installed during the mini-setup Sysprep process. If the entries are not correct or the wrong driver is specified, you will end up with a blue screen of death once the system tries to boot to Windows. Also these mass storage drivers are typically packaged in a format to be installed from floppy disks during the scripted Windows install process.

If you are familiar with the process of installing an NT based system from scratch, you will know that you are prompted to press F6 during setup to install specific mass storage controller drivers before the Windows setup process can recognize the computer's hard drives in which the OS will be installed to. In building this [SysprepMassStorage] section properly, you are tricking the Windows setup process into thinking the storage controller drivers are being installed from the floppy disks when in actuality they are being installed from within the hardware independent image itself.

Dissecting the OEMSETUP.INF File

If you open one of the Dell driver directories for a mass storage controller, you will find an OEMSETUP.INF file. This is the Original Equipment Manufacturer's (OEM) setup file. This file defines the PnP Device ID's of the storage controllers, source disk names, etc. This section will illustrate how to manually build an entry in the [SysprepMassStorage] section of the SYSPREP.INF file for a PERC 4/SC storage controller.

The steps identified below are universal for building all entries of this section and apply to all types of controllers whether they are SCSI, SAS, IDE, etc. The following listing is an excerpt from the OEMSETUP.INF file of the MegaRAID family of RAID Controllers in which the PERC 4/SC controller is listed. Note the color coded sequential steps in the next section and scroll to the end of this listing for step by step descriptions and instructions:

; -- This file contains descriptions of the MegaRAID family; of RAID Controllers 
;
; Copyright ® 2001, LSI Logic Corp.,
[version]
Signature="$Windows NT$"
Class=SCSIAdapter 

ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}
Provider=%Dell% 
CatalogFile=mraid35x.cat
DriverVer=12/11/2003,6.41.2.32 

[DestinationDirs]
DefaultDestDir = 12 ; DIRID_DRIVERS 

[Manufacturer]
%Dell%=Dell 

[Dell] 

;PERC 4/DC (Dell 518)
%Dell518.DeviceDesc% = mraid35x_Inst, PCI\VEN_1000&DEV_1960&SUBSYS_05181028 

;PERC 4/SC (Dell 520)
%Dell520.DeviceDesc% = mraid35x_Inst, PCI\VEN_1000&DEV_1960&SUBSYS_05201028

;PERC 4/Di 013B%DellROM.DeviceDesc% = mraid35x_Inst, PCI\VEN_1028&DEV_000F&SUBSYS_013B1028 

;PERC 4/Di 014A%DellROM.DeviceDesc% = mraid35x_Inst, PCI\VEN_1028&DEV_000F&SUBSYS_014A1028 

;PERC 4/Di 014C%DellROM.DeviceDesc% = mraid35x_Inst, PCI\VEN_1028&DEV_000F&SUBSYS_014C1028 

;PERC 4/Di 014D%DellROM.DeviceDesc% = mraid35x_Inst, PCI\VEN_1028&DEV_000F&SUBSYS_014D1028 

;PERC 4e/Si%Dell16C.DeviceDesc% = mraid35x_Inst, PCI\VEN_1028&DEV_0013&SUBSYS_016C1028 

[SourceDisksNames]
1 = %SOURCE_DISK%,\mraid35x.sys,,

[SourceDisksFiles]
mraid35x.SYS = 1,,11136,,,,,, 

[Strings] 

;---------------------Dell-----------------------------
Dell="Dell" 
Dell467.DeviceDesc = "Dell PERC 2/DC RAID Controller"
Dell.DeviceDesc = "Dell PERC 2/SC RAID Controller"
Dell471.DeviceDesc = "Dell PERC 3/QC RAID Controller"
Dell493.DeviceDesc = "Dell PERC 3/DC & PERC 3/DCL RAID Controller"
Dell511.DeviceDesc = "Dell CERC ATA 100/4ch RAID Controller"
Dell475.DeviceDesc = "Dell PERC 3/SC RAID Controller"
DellROM.DeviceDesc = "Dell PERC 4/Di RAID On Motherboard Driver"
Dell518.DeviceDesc = "Dell PERC 4/DC RAID Controller"
Dell520.DeviceDesc = "Dell PERC 4/SC RAID Controller" 

Dell16C.DeviceDesc = "Dell PERC 4e/Si RAID Controller" 

Dell16DE.DeviceDesc = "Dell PERC 4e/Di RAID Controller"
Dell002.DeviceDesc = "Dell PERC 4e/DC RAID Controller"
Dell001.DeviceDesc = "Dell PERC 4e/SC RAID Controller" 


DriverMfgr = "LSI Logic Corporation"
DriverVersionID = "6.41.2.32" 
DriverOEM ="Dell" 
DriverFamily ="Storage"
DriverProduct ="PERC 4/SC; 4/DC; 4/Di; 2/SC; 2/DC; 3/SC; 3/DC; 3/QC; CERC ATA100/4ch - Device Drivers"
DriverDescription ="PERC Controller Support"
DriverOEMVersion ="A01" 
BaseDriverFileName ="mraid35x.SYS" 
BaseDriverFileVersion="6.41.2.32" 
SOURCE_DISK ="Dell PERC RAID Driver" 
Service = "mraid35x" 
ClassGUID = "{4D36E97B-E325-11CE-BFC1-08002BE10318}" 

;*******************************************
;Handy macro substitutions (non-localizable)
SPSVCINST_ASSOCSERVICE = 0x00000002 
SERVICE_KERNEL_DRIVER = 1 
SERVICE_BOOT_START = 0 
SERVICE_ERROR_NORMAL = 1 
REG_EXPAND_SZ = 0x00020000 
REG_DWORD = 0x00010001

Identify the controller(s) that are common to your environment. In this example, I'll use the PERC 4/SC controller. This is how the line appears in the example above:
```
;PERC 4/SC (Dell 520)
%Dell520.DeviceDesc% = mraid35x_Inst, PCI\VEN_1000&DEV_1960&SUBSYS_05201028 
```
Identify the device description of the controller as it appears in the OEMSETUP.INF file.
1. First, identify the device description header. This can be found from the controller line as indicated above. This is how the line appears in the example above:
```
%Dell520.DeviceDesc% 
```
2. Identify the device description of the controller from the respective location of the INF file. This is how the line appears in the example above:
```
Dell520.DeviceDesc = "Dell PERC 4/SC RAID Controller"
```
Identify the disk tag. This is how the lines appear in the example above:
```
[SourceDisksNames]
1 = %SOURCE_DISK%,\mraid35x.sys,, 
```

Plugging Values into the [SysprepMassStorage]

Once you have identified the sections of the OEMSETUP.INF file for the specified controller, you can now plug them into the [SysprepMassStorage] section. Each section of this entry is broken out in the following section to put this all in perspective. The entry below illustrates the final product for the PERC 4/SC controller:

[SyprepMassStorage]
;PERC 4/SC (DELL)
PCI\VEN_1000&DEV_1960&SUBSYS_05201028="%systemdrive%\dell\storage\oemsetup.inf","\","DELL PERC 4/SC RAID Controller","SOURCE_DISK"

;PERC 4/SC (DELL) – <remark> This is simply a remark and is used for identification purposes only.
Anything that follows a semi-colon in the SYSPREP.INF file is assumed a remark and is not functional.

PCI\VEN_1000&DEV_1960&SUBSYS_05201028= – <hardware ID> This is the PnP PCI Vendor ID for the PERC 4/SC controller pulled from Step 1 above.

"%systemdrive%\dell\storage\oemsetup.inf" – <path to device inf> This is the path to the .inf driver file that contains the PnP PCI Vendor ID of the controller to be installed from Step 1 above. This path is straight from the Dell drivers hierarchy as mentioned earlier in this paper.

"\" – <disk directory> This is the path of the disk directory from the virtual floppy disk that contains the storage controller driver. Since we've identified the path on the line above, we can simply put a backslash for this section indicating the drivers are in the root of the "C:\Dell\Storage" directory in this example.

"Dell PERC 4/SC RAID Controller" – <device description> This is the device description used during the traditional Windows setup process when identified on the setup screen prompting the user to confirm the driver that is about to be loaded. This is pulled from Step 2b above.

"SOURCE_DISK" – <disk tag> This is the disk tag of the floppy disk provided by the vendor. This can be a file or descriptive name which allows the traditional Windows setup process to recognize the disk has been inserted and allows the setup process to continue on. Since we're tricking the Sysprep mini-setup process into thinking it already has the disk inserted containing the drivers, we're never prompted during the Sysprep process. This is pulled from Step 3 above.

This entire section would be duplicated for every mass storage controller supported in the environment.

Installing Altiris Agents

There are several installation options available when installing the Altiris agents. 1) They can be installed and registered in the base image 2) Pre-installed in the base image to be installed via command line after the base image has been laid down 3) Pushed through the Remote Agent Installer included with Deployment Solution and 4) Pulled from the root of the Deployment Solution's eXpress share. This section will discuss the pre-installed option by installing via command line after the base image has been deployed as this is the most commonly used method when mass deploying the OS via an image based deployment.

Note: Extra steps must be taken to avoid duplicate GUIDs when installing the Notification Server Client in the base image. See the Altiris Knowledgebase article# 19323 titled "How to prepare a workstation for imaging that includes the NS Agent".

Pre-installing AClient in the Hardware Independent Image

This option is best used if you're in a diverse environment where multiple Deployment Servers may be used to manage the environment. AClient can be pre-installed in the base image and automatically installed via command line after the base image has been laid down. The basic steps involve bundling the ACLIENT.EXE (install file) and ACLIENT.INP (answer file) in the hardware independent image. The files can be placed in the .\SYSPREP directory so that when AClient is properly installed, the .\SYSPREP directory will be automatically deleted once the Sysprep mini-setup process completes, leaving no trace of the source install files.

The actual command to kick off the AClient scripted install can either be placed in the CMDLINES.TXT file located in the .\SYSPREP\I386\$OEM$ directory and installed during the Sysprep mini-setup process or installed once Windows logs in for the first time. This is accomplished by providing the command line in the [GuiRunOnce] section of the SYSPREP.INF file. Either way will work.

The benefit of scripting AClient to install as part of the image process is that you can easily open the Altiris ImageExplorer utility and edit the ACLIENT.INP file if desired to change the Deployment Server IP address, configure it to use multicasting to automatically register itself with the first Deployment Server the agent finds, etc. Refer to the section, "Updating the Hardware Independent Image with Altiris ImageExplorer" previously in this paper for more information. In addition, you can also use Deployment Solution tokens to replace values contained in the ACLIENT.INP file if desired. For example, the ACLIENT.INP file can be configured to always include the IP address of the actual Deployment Server that is deploying the hardware independent image rather than allowing multicasting to find and register with the first Deployment Server it finds. Refer to the section, "Introducing Deployment Solution Tokens" later in this paper for more information.

Note: Corporate IT policies may prevent multicasting in your environment and prevent the AClient from ever connecting to a Deployment Server.

Note: This option is the most widely used and yields the greatest results. By pre-installing AClient in the base image and deploying via Deployment Solution, you're always able to pre-provision the computer in the Deployment Solution Console and automatically configure the desired settings (NetBIOS name, IP address, etc) as part of a post-OS task.

Follow these steps to pre-install AClient in the base image:

Copy the ACLIENT.EXE and ACLIENT.INP files from the root of the eXpress share to the .\SYSPREP staging folder or directly to the reference computer.
Modify the ACLIENT.INP file with Notepad.
Set the desired options for AClient to be installed.
Modify the CMDLINES.TXT file located in the .\SYSPREP\I386\$OEM$ folder to reflect what is shown below. If this folder or the CMDLINES.TXT file does not exist, create it now.

  [Commands] 
   "c:\sysprep\sysprep -clean" 
   "c:\sysprep\aclient.exe c:\sysprep\aclient.inp -install -silent"

Locate a copy of DELTREE.EXE from MS-DOS and copy to the Windows System32 directory (i.e. .\WINDOWS\SYSTEM32) A copy of this file has been included in the ONEDELLIMAGE.ZIP file.

Note: This utility will force the .\SYSPREP directory to be deleted once Windows logs in for the first time. It is possible for the .\SYSPREP folder to linger around after the Sysprep mini-setup process completes due to the AClient being scripted to run from this directory. The AClient install files could be placed elsewhere in the base image, but by including them in the .\SYSPREP folder, the source install files are guaranteed to be deleted after they've been used.
Add the following section to your SYSPREP.INF file. This section can be placed anywhere in the SYSPREP.INF file in-between the major header sections.
```
   [GuiRunOnce]
   Command0="c:\windows\system32\deltree /Y c:\sysprep" 
```
Note: Make sure you reflect the actual Windows directory installed on the reference computer with the Windows directory specified in the [GuiRunOnce] section. For example, if Windows 2003 was installed to the .\WINDOWS directory, make sure the "Command0" line reflects this same directory as well.
Make sure the following line is included in the [Unattended] section of the SYSPREP.INF file. If it's not, the command lines located in the CMDLINES.TXT file will never be executed.
```
   [Unattended]
   InstallFilesPath="C:\Sysprep\i386" 
```
Note: Now when the reference computer is Sysprepped and mass deployed, AClient will automatically install.

Configuring the Reference Server

As mentioned previously, choose a standard PowerEdge server model with no unique or custom configurations to be the source for the base image. For example, my reference computer was a PowerEdge 400SC Server with an IDE drive configured with the bare essentials. Once the hardware has been identified and configured, the following steps have been provided as a guideline (your steps may vary):

Boot the server with the Dell Server Assistant (DSA) CD. DSA is a Linux based GUI utility to assist in the unattended OS install. DSA by default will create a 32MB utility partition on the PowerEdge Server which can be used for hardware diagnostics. DSA is simple to use and easy to follow with step by step prompts. It's recommended to use the latest version of the DSA CD when creating the base image. Listed below are some of the highlights during the DSA process and suggestions on how to configure the options:
1. It's recommended to set a partition size anywhere from 6GB to 8GB in size (6 GB should be ideal depending on what will be included in the base image). The idea is to keep your base image bare and to deploy your software remotely using a management solution such as Altiris Deployment Solution. Also, a rule of thumb when imaging – it's recommended to go from a smaller to larger partition, but not recommended to go larger to smaller.
2. Enter the registered user's full name and organization. This is the same information that was asked earlier during the building of the SYSPREP.INF file. The user data you enter here is not relevant to the hardware independent creation process. The data specified here can be overridden with the data you specify in the [UserData] section of the SYSPREP.INF file and applied during the Sysprep mini-setup process. By specifying this data in the SYSPREP.INF file you can offer flexibility for what user data gets replicated to all deployed Windows instances.
  By default the registered name and company are considered static fields, meaning this data does not typically change once configured. When using Altiris Deployment Solution, it's possible to dynamically customize this information per target system through the use of system tokens. For example, rather than entering "OEM User" for the registered name, you can personalize this by automatically replacing the static data with the actual user's or department's full name per deployed system.
  
  Customizing the user's full name is helpful when installing and registering software. For instance, MS Word has the ability to report which user has a document open and locked on the network. The registered name for the software is usually pulled straight from the Windows OS registered name. This may not be relevant to a server image, but is definitely possible and easy to implement. Refer to the section, "Introducing Deployment Solution Tokens" for more information.
3. Enter the product key. If using volume licensing, DSA will not require the product key to be entered during the installation process and most Admins may not even know their volume license product key. If you don't know the product key of your volume media, DSA can identify this for you automatically. Refer to section 1.f for more information. If you know the media does not require a key, you can leave this field blank when using the DSA process. If you know the media requires a product key or is not volume media, enter it at this time. This is the same key asked earlier during the building of the SYSPREP.INF file using the Sysprep Setup Manager. Be sure to enter the same product key used for DSA in the ProductKey= field of the SYSPREP.INF file located under the [UserData] section. Without it, or if entered incorrectly, you will be prompted for the product key on every single image deployment you make and the deployment process will not be completely unattended.
4. Enter the computer name and specify a workgroup. The computer name is not relevant to the hardware independent creation process. The computer name can be anything as long as it does not conflict with another system on the network. Also, do not add the base image to the domain as this can cause problems with the Sysprep process. It's better to mass deploy the image and then add the computer to the domain after deployment. This can be accomplished by specifying the domain name and credentials in the SYSPREP.INF file to join the domain during the Sysprep mini-setup process or by allowing Altiris Deployment Solution to perform as a post-OS configuration task via the management agent.
  Note: If it's necessary to join the computer to the domain for whatever reason (download group policies, etc) you may do so, but under no circumstances should you leave it in the domain during the Sysprep process. Make sure the server is removed from the domain BEFORE Sysprepping.
5. Set the IP address manually or choose DHCP. Altiris recommends leaving the NIC(s) set to DHCP in the image. You should already have a DHCP server in the environment if running an Altiris PXE Server. Deployment Solution will allow you to set a static IP address as a post-OS configuration task after the image has been deployed to the target system. If for some reason your environment does not support a DHCP server, it is possible to set a static IP address during the Sysprep mini-setup process. This information will be specified in the [Networking] section of the SYSPREP.INF file. Refer to the Sysprep Reference Guide for more information. The use of Deployment Solution system tokens can also be used to replace the tokens in this section with IP addresses stored in a central database.
6. If you know the product key of the Windows media and you entered it during the DSA process, you may skip this step and continue to 1.g. If not, please read on! It's critical that you check the box in the DSA process to save the unattend.txt file. Without this file you won't know what product key is automatically entered during the OS installation process and you will not be able to include it in the SYSPREP.INF file. All the information you specify during the DSA process is being recorded to the UNATTEND.TXT file, very similar to how you created the SYSPREP.INF file using the Sysprep Setup Manager. This file could be used for the unattended scripted installation of a Windows OS if you desire. The file will be saved to the root of the system's drive.
  The product key will aid in an unattended deployment during the running of the Sysprep mini-setup process. Without this product key, the image will require user intervention and will halt during mini-setup requiring the user to enter a key before being able to continue (even if you have volume media). When you finally boot to Windows after deploying the base image using DSA, open the unattend.txt file located in the root of the system drive and write this product key on your Windows volume media for future reference. Also, enter the key in the appropriate section of the SYSPREP.INF file created earlier.
7. When prompted, remove the DSA CD and insert the Windows 2003 Server CD to start the copying of the source files for the scripted installation.
After the OS is deployed and you log into Windows for the first time, install any desired service packs, security updates, and hotfixes on the reference computer. This is not required, but highly recommended. This will save time during the deployment process by patching the OS to the current updates at the time of the image creation. Subsequent releases of updates can be pushed out as a scheduled event either through Altiris Deployment Solution, Altiris Software Delivery, or using Altiris Patch Management Solution after the target system has been deployed. By patching the image to the latest updates during the image creation process you can help save time and network bandwidth by including the major patches in the base image.
Copy the I386 directory from the Windows 2003 Server CD to the root of the system partition (e.g. C:\I386). Search the Windows Registry for the paths to the CDROM "I386" directory and replace them with the new path to the "I386" folder on the system partition. For example "D:\I386" would be changed to "C:\I386". By doing this you can avoid prompts for the OS media looking to the CDROM drive and redirect to the local drive as Windows Server software is being added after the deployment such as DHCP, DNS, WINS, etc. These keys are found under:
```
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\SourcePath 

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath 
```
Note: There is a SRCPATH.REG file included in the .\DELL\SCRIPT directory contained in the ONEDELLIMAGE.ZIP file. This registry file can be executed as part of the image deployment to automatically change the source paths to the C:\I386 directory. I usually initiate this command as part of the [GuiRunOnce] section of the SYSPREP.INF file and execute as soon as Windows logs in for the first time. This is why I have my "AutoLogonCount" set to 1 in the SYSPREP.INF file to take care of any commands I have listed in this section automatically. Your steps may vary.
Copy the drivers previously gathered to the root of the system partition (i.e. C:\Dell).
Specify the path of the drivers either by entering directly into the Windows Registry or specify in the OEMPNPDRIVERSPATH field of the SYSPREP.INF file. Execute only one of the options below:
1. Browse to the HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath key in the Windows Registry and add each directory and subdirectory of the Dell drivers hierarchy to the DevicePath key. For example:
```
%SystemDrive%\Dell\audio;%SystemDrive%\Dell\cs\1;%SystemDrive%\Dell\cs\2;%Sys
temDrive%\Dell\cs\3;%SystemDrive%\Dell\cs\4;%SystemDrive%\Dell\cs\5;%SystemDr
ive%\Dell\cs\6;%SystemDrive%\Dell\cs\7;%SystemDrive%\Dell\cs\8;%SystemDrive%\
Dell\m\bc;%SystemDrive%\Dell\m\ch;%SystemDrive%\Dell\m\co;%SystemDrive%\Dell\
m\cy;%SystemDrive%\Dell\mgmt\;%SystemDrive%\Dell\n\bc\1;%SystemDrive%\Dell\n\
bc\2;%SystemDrive%\Dell\n\intel\1;%SystemDrive%\Dell\n\intel\2;%SystemDrive%\
Dell\non-raid\bp\1;%SystemDrive%\Dell\non-raid\bp\2;%SystemDrive%\Dell\non-
raid\gem;%SystemDrive%\Dell\storage;%SystemDrive%\Dell\storage\9g\fiber;%Syst
emDrive%\Dell\storage\9g\perc5;%SystemDrive%\Dell\storage\9g\sas-
nonraid;%SystemDrive%\Dell\storage\9g\scsi-
nonraid;\%SystemDrive%\Dell\v\ati;%SystemDrive%\Dell\v\int;%SystemDrive%\Dell
\v\rn5;%SystemDrive%\Dell\v\vol;%SystemDrive%\Dell\misc;%SystemRoot%\inf 
```
  Note: Leaving the default "%SystemRoot%\inf" at the end of the devicepath will allow Windows to use native drivers if the setup process can't find a vendor supplied driver in the specified path. You may choose to leave this in or remove it. If you gather and build out the drivers directories properly for the hardware components in your environment, you shouldn't have any native drivers installed.
  
  Note: There is a DEVICEPATH.REG file contained in the ONEDELLIMAGE.ZIP file and when executed will automatically enter the device path listed above into the respective Windows Registry key to save you time and efforts.
2. Specify the path of the drivers in the OEMPNPDRIVERSPATH field located in the SYSPREP.INF file. Choosing this option provides the flexibility to easily change the path through the Altiris ImageExplorer utility if desired, but be warned of the character limitation as previously discussed in the "Considerations for Sysprep" section.
  Note: There is no wrong or right way to specify the path of the drivers, it's a matter of personal preference. I choose to specify the path in the Windows Registry as opposed to the SYSPREP.INF file to reduce complexity and alleviate room for potential errors during the Sysprep process.
Copy the Sysprep folder created earlier to the root of the system partition (e.g., C:\Sysprep).
Install and configure any applications that will be common to all computers that are likely to receive the image. We recommend leaving the base image as clean as possible. This reduces the amount of time required to maintain your images after they've been created. For example, software can be repackaged using Deployment Solution's RapidInstall or using W

Application Packaging

Asset & CMDB

Dell | Altiris

Deployment & Migration

Endpoint Virtualization

Ghost Solution Suite

Helpdesk Solution

HP | Altiris

Intel | Altiris

Security & Compliance

Workflow Solution

Active forum topics

Upcoming events

RSS :: Dell | Altiris

Building a Single Image for Dell PowerEdge Servers using Altiris Deployment Solution

Introduction

Common IT Obstacles

Benefits of a Hardware Independent Image

Pros and Cons to Image vs. Scripted OS Deployments

Setting Up Your Environment

Gathering Dell Drivers for Inclusion in the Hardware Independent Image

Option 1 – Obtain Drivers from Dell's Support Website

Creating the Dell Driver Hierarchy

Option 2 – Gather Drivers Using the Driver Tool from the DSA CD

Option 3 – Gather Drivers Using Altiris Deployment Solution for Dell Servers

Updating the Hardware Independent Image with Altiris ImageExplorer

Obtaining the ONEDELLIMAGE.ZIP Supporting File

Introduction to Microsoft Sysprep

Using Sysprep as Documented

Considerations for Sysprep

Creating the SYSPREP.INF File

Option 1: Creating the SYSPREP.INF Using the Sysprep Setup Manager

Option 2: Creating the SYSPREP.INF File from the Sample Provided

Building the [SysprepMassStorage] Section of the SYSPREP.INF File

Dissecting the OEMSETUP.INF File

Plugging Values into the [SysprepMassStorage]

Installing Altiris Agents

Configuring the Reference Server