Hardware Independent Imaging (HII) And LANDesk ... - Community

Hardware Independent Imaging (HII)AndLANDesk ® Management SuiteRev 9.1A whitepaper by:Mike YbarraJan BuelensLANDesk Softwarejan.buelens@landesk.comJuly 10, 2009Hardware Independent Imaging Rev 9.1 Page 1 of 47

Table of Contents1. Introduction................................................................................................................. 51.1. Desktop imaging is a complex process............................................................... 51.2. With LANDesk Management Suite, HII is not just a dream .............................. 51.3. It just makes sense .............................................................................................. 51.4. Process Overview................................................................................................ 62. The quick “how to” guide........................................................................................... 93. More about handling drivers..................................................................................... 183.1. The CopyDrivers program ................................................................................ 183.1.1. Wildcard matching...................................................................................... 203.2. Using a driver extraction tool ........................................................................... 203.3. Enumerating drivers.......................................................................................... 213.4. Drivers with a setup program............................................................................ 234. More about Mass Storage Drivers ............................................................................ 244.1. Third party sources for drivers.......................................................................... 274.2. Injecting Mass Storage Drivers at deployment time......................................... 274.2.1. Using MSDINST to inject a mass storage driver........................................ 274.2.2. The do-it-yourself method to inject a mass storage driver. ........................ 285. The Hardware Abstraction Layer (HAL). Making your image HAL-independent .. 315.1. Which HAL is my computer using? ................................................................. 315.2. LANDesk OSD features for HAL handling...................................................... 335.3. Automating HAL detection............................................................................... 355.3.1. The old process: downgrade to "baseline HAL"......................................... 355.3.2. The new process: copy HAL files............................................................... 365.3.3. HalConfig: advanced use ............................................................................ 386. Using Provisioning.................................................................................................... 397. Reference .................................................................................................................. 417.1. HalConfig.exe ................................................................................................... 417.2. ldprep.exe.......................................................................................................... 427.3. CaptureMsd.exe, InjectMsd.exe ....................................................................... 437.4. CopyDrivers.exe ............................................................................................... 447.5. Diagnostics........................................................................................................ 467.6. Files that come with this document: ................................................................. 47Hardware Independent Imaging Rev 9.1 Page 2 of 47

Revision HistoryRev 4 – Original ReleaseRev 5 – Changed OEMPNPDRIVERSPATH value. (Removed C: - caused invalid path in the registry)Rev 6 – Added Build Mass Storage Devices to Sysprep process.Rev 7 – Major rewrite. DrvDirs utility eliminates the need to pre-create empty directories. LdPrep utilityeliminates the need for a sysprep.inf file with an OemPnpDriversPath baked into the image.Rev 8 (March 27, 2007) – Major rewrite. Updated for WinPE and LDMS 8.7. Provisioning not included.HAL independence included. No provisioning. No Vista.Rev 8.0.1 (May 13, 2007), Rev 8.0.2 (June 1, 2007), Rev 8.0.3 (July 3, 2007) , Rev 8.0.4 (Sep 15, 2007) –Minor edits.Rev 8.0.5 (Oct 14, 2007) – Previous versions had prettified word processing characters in the samplescripts (long dash, rounded quotes), causing scripts to fail when copied & pasted. Moved the ldiscn32. Itshould be after the tokreplw that inserts the machine name in sysprep.inf, otherwise machine ends up beingcalled MININT-xxxx when “use existing machine name” option is enabled.Rev 8.0.6 (Apr 10, 2008) – A sleep was needed after the inventory scan to give the core server time toprocess the incoming inventory data. Info was added on handling mass storage drivers.Rev 9. (Dec 16, 2008) Major changes.Stopped using ldiscn32 (the inventory scanner) to detect machine type. As of LDMS 8.8 SP2,ldiscn32 no longer works under WinPE. Most likely it's only a matter of a missing DLL or so. Butin view of other issues, I decided to design out all dependencies on the inventory.I am now advocating Autoit instead of vb scripts. Autoit is similar to vb script and anybody whofeels comfortable editing a vb script is likely to feel equally comfortable editing an Autoit script.But in contrast with vb, an Autoit script can be compiled and run as a small self-containedexecutable, with no need for run-time DLLs. If you need to change one of the Autoit scripts, justdownload Autoit from http://www.autoitscript.com (it is freeware), edit the script and recompile.Example: see HalConfig. Before: 170 lines of vb scripting, requiring a run-time of 12 DLLstotaling 2.4 MB. After: 46 lines of AutoIT script, compiled as a stand-alone 256 KB executablerequiring no run-time.Developed a methodology to inject mass storage driversAdvocating the use of a driver extraction tool.As before, no attempt is made to cover Vista or WinXP-64.The document remains mainly OSD oriented, but provisioning is also discussed.Rev 9.1. (July 10, 2009)Hal configuration. The process described in previous versions was based on the assumption thatall "reasonably modern" machines could boot from the ACPI HAL, which could therefore serve asa "lowest common denominator". This assumption broke down with the advent of the Montevinachipset. A different approach is therefore described, no longer based on downgrading the HAL.See section 5.3.2.Hardware Independent Imaging Rev 9.1 Page 3 of 47

Enhancements to the copydrivers program: progress bar, wildcard matching.Minor enhancements and bug fixes to each of the tools.Logging is enabled by default in all tools except CaptureMsd. When following the conventionsused in the document, the log files are created in c:\drivers.AcknowledgementsSadly, Mike Ybarra, who started this whitepaper, is no longer with us. That motorcycleride he took one fine day in August 2008 became his last one... May this document beone small monument to his many talents.One chapter in this document (“The Hardware Abstraction Layer (HAL). Making yourimage HAL-independent”) is largely based on earlier work by Bart Venema of Axle-IT inthe Netherlands.Many thanks also to Bryan Hadzik of NCSi for his contribution about mass storagedrivers.The CopyDrivers program is largely inspired on an earlier program of the same name bySergio Ribeiro of LANDesk France.DisclaimerThis is not a document approved by LANDesk Software. The utilities that come with thisdocument are not supported by LANDesk Software customer support. The authors (orrather, the one surviving author) welcome comments and suggestions and will providesupport on a best-effort basis. Direct any comments to jan.buelens@landesk.com.Hardware Independent Imaging Rev 9.1 Page 4 of 47

1. Introduction1.1. Desktop imaging is a complex processLANDesk® Management Suite is a very powerful desktop and server imaging andprovisioning tool. It simplifies the deployment of Windows 2000* and Windows XP*and Windows Vista* by providing both PXE and Virtual Boot image deployment. Thepost-image configuration and Windows* setup process is completely managed byLANDesk Management Suite. What’s more, all the desired applications and userpersonality settings can be applied to desktops after the imaging process is complete. Thislevel of automation offers incredible control and ease for a normally very complexprocess.One of the challenges of image deployment is the number of images that administratorsneed to manage. New hardware frequently means new drivers, requiring master images tobe rebuilt and retested.Hardware Independent Imaging (HII) is a process that allows one generic image to bedeployed to many different platforms.1.2. With LANDesk Management Suite, HII is not just a dreamWhen LANDesk Management Suite deploys images, it has the ability “inject” files intothe newly restored partition. This is the newly restored partition just restored by theimaging tool used in the LANDesk process. Before Windows* boots for the first time,LANDesk injects the new device drivers into the image, so that Windows candynamically load the devices as it boots for the first time. It’s this ability that frees theadministrator from having to rebuild images every time their PC OEM updates themodels they ship. It enables the administrator to create one ‘master’ image that willdeploy to all the different platforms. Many IT departments support 20 or more differentdesktops in their organization. Imagine all the testing put into each image deployed...1.3. It just makes senseThink of the actual difference in images taken between 2 different systems both loadedwith Windows* XP. The difference may only be a few megabytes of driver files.Example:Dell Precision 340*Image 1:Windows XP system filesDriver filesspecific tocomputer modelHardware Independent Imaging Rev 9.1 Page 5 of 47

Dell Latitude c400*Image 2:Windows XP system filesDriver filesspecific tocomputer modelLANDesk® Management Suite allows you to keep one master image, and simply appendany new OEM plug and play drivers, right after the image is deployed, but before the OSboots. Example:Master Image:Windows XP system files1.4. Process OverviewPreparation Overview1. Build your master workstation.2. Add mass storage drivers.3. Run sysprep.4. Use the imaging tool of your choice to create an image.5. Create a WinPE based OSD script or a provisioning template.6. Insert commands in the post-imaging phase of the OSD script or provisioningtemplate to do the following:a. auto-detect and configure the HALb. copy drivers to the client’s hard drivec. enumerate the drivers in the client’s DevicePath registry keyHardware Independent Imaging Rev 9.1 Page 6 of 47

PreparationDeploymentImagePreparationRestoreImage(WinPE)Post-Imaging(WinPE)Windowsmini-setup• Run sysprep• Create image• Create OSD script orprovisioning template• Inject sysprep.inf• Configure HAL• Inject drivers• Enumerate drivers• Reboot to windows• Mini-setup performsPnP discovery• Reboot• LDMS client setupHardware specificdrivers are copied atdeployment timeFigure 1. Process overview. Because computer-specific drivers are copied to the client’s hard drive atdeployment time, the image can be generic.Deployment Process Overview:1. PXE or virtual boot is used to boot the client to WinPE.2. The imaging tool restores the image.3. Post-imaging phase. While still under WinPE, the following actions areperformed:a. A sysprep.inf with customized settings for this client is injected into thenewly restored partition.b. If desired, a compiled AutoIt script called ConfigHal.exe can determinethe appropriate HAL for the client, copy appropriate files and adjustsysprep.inf accordingly. This will cause the mini-setup to install thecorrect HAL.c. Drivers are copied to the client’s hard drive.d. A program called ldprep enumerates the drivers copied during step 3c andadds them to the client’s DevicePath registry key.4. The client is rebooted. Because the image was syspreped, the OS launches a minisetupsession.Hardware Independent Imaging Rev 9.1 Page 7 of 47

5. The standard mini-setup performs PnP detection, installs drivers and uses thesettings in sysprep.inf to configure the client.6. After the mini-setup, Windows reboots itself.7. Upon reboot, the Management Suite agent is installed, either through an entry inRunOnce (OSD), or through a provisioning action.Mass storage drivers are different...The process outlined above, whereby we just copy driver files to the target’s hard driveand leave it to the mini-setup to find and install them, works great for display drivers,network card drivers etc. But not for the hard drive from which the OS is to boot.Figure 2. Mass storage drivers are different. The driver for the boot device must be installed beforethe system boots into mini-setup. Otherwise, the OS will blue screen rather than boot into mini-setup.The driver for the target system’s boot device must be installed before the client rebootsinto mini-setup (step 4 above), otherwise a blue screen will result (stop 0x0000007b,inaccessible boot device). Mini-setup can't install the driver for the boot device becausethe OS will blue-screen before it has a chance to start mini-setup. One typical situationwhere this problem will occur is when a Windows XP image built on a source machinewith IDE drives is deployed to a target machine with SATA drives.The recommendation is to include all necessary mass storage drivers for all your targetsystems in your master image. Still, if you need to include new or updated mass storagedrivers, it may not be necessary to update your master image. Tools supplied with thisdocument (CaptureMsd, InjectMsd) allow a mass storage driver to be injected 1 underWinPE, prior to the reboot into mini-setup. See below for more info on mass storagedrivers.1 This involves more than copying the driver files. InjectMsd also makes changes to the target's registry tomake it look as if the driver had been installed.Hardware Independent Imaging Rev 9.1 Page 8 of 47

2. The quick “how to” guideThis chapter describes in more detail the complete process outlined in the previouschapter. More advanced “variations on the theme” (such as adding HAL independence)and further background information are provided in later chapters.1. Set up your imaging share. The remainder of this document assumes a folderstructure similar to the picture below:Under Drivers, create one subfolder per machine type. For the purpose of thisdocument, we need to distinguish between 3 types of drivers, and we store each inseparate base folders: PnP: drivers that can be installed based on their .inf file only setup: drivers that require a setup program (see section 3, "More abouthandling drivers"). msd: mass storage drivers (see section 4, More about Mass StorageDrivers)Under images, store the images to be restoredUnder tools, store the tools that come with this document, includingcopydrivers,exe, ldprep.exe, halconfig.exe, injectmsd.Figure 3. Set up your imaging share as shown above.2. Build your master Windows XP workstation. Patch it and make all thecustomizations that you desire to be present in your master XP image. This version ofHardware Independent Imaging Rev 9.1 Page 9 of 47

the white-paper will describe the process only for XP. LANDesk Management Suitecurrently supports deploying Vista – it’s just not covered in this whitepaper.3. Create the sysprep folder. Create a folder c:\sysprep with the following files:sysprep.exesetupcl.exesysprep.infSysprep.exe and setupcl.exe are standard Windows tools. Sysprep.inf is a text file thatyou need to create. It can be as simple as this:[Sysprep]BuildMassStorageSection=Yes[SysprepMassStorage]Figure 4. Minimal sysprep.inf.In the case of OSD, there is no point in putting more info in sysprep.inf (exceptadditional mass storage drive into, see below). This is because the sysprep.inf thatyou put in the image is going to be overwritten at deployment time by a new filecreated dynamically based on parameters you specify in the OSD script wizard and inthe sysprep.inf template file (see below).In the case of provisioning, you can build a complete sysprep.inf at this time andinclude it in the image, but you probably prefer to use the "inject script" actioninstead. It will download a sysprep.inf at deployment time from the database, withparameter substitution.4. Add Mass Storage Drivers. As noted above, a driver for the target machine's bootdevice must be installed in the target OS before the machine boots into mini-setup,otherwise a blue screen will result (Figure 2). This requirement is automaticallysatisfied if the target's mass storage controller is the same as the source machine's(e.g. both machines are IDE based 2 ).But if the target's mass storage controller is different, an appropriate mass storagedriver must be added, either by including it in the image (SysprepMassStorage), or byinjecting it at deployment time (see section 4.2). Of these two methods, the latter issomewhat experimental, therefore the former (SysprepMassStorage) is recommended.SysprepMassStorage is a section of sysprep.inf that associates Plug&Play device IDswith drivers.Sysprep will populate the SysprepMassStorage section for you if you use the2 There may be exceptions to this rule, but in effect, for the purpose of this discussion, all IDE controllersare the same.Hardware Independent Imaging Rev 9.1 Page 10 of 47

BuildMassStorageSection 3 parameter as shown in Figure 4. However, this will onlyadd those mass storage drivers that came with the operating system. If you arebuilding a Windows XP image on a machine with IDE drives and your target hasSATA drives, you will need to take additional steps to add the SATA driver.Example: many machines use Intel SATA controllers. At the time of writing, if yourmaster workstation does not already have the appropriate driver installed (e.g.because it is IDE based), you need to take 2 steps to add it: Expand the driver files (the lines below assume they driver was unpacked toc:\drivers\intelsata) Add the following lines to the [SysprepMassStorage] section 4 :[SysprepMassStorage]PCI\VEN_8086&DEV_2681&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_27C1&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_27C5&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2821&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2829&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2922&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2929&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_3A02&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_3A22&CC_0106 = C:\drivers\intelsata\iaahci.infFigure 5. Insert lines similar to the above in sysprep.inf to include an additional mass storagedriver in the image.How did we come up with these lines? See section 4, More about Mass StorageDrivers for more info.5. Sysprep the workstation. The final step before creating your master image is to runsysprep. This will cause the OS to run a “mini-setup” the first time a computer isbooted with the image. The mini-setup will perform PnP hardware detection, installdrivers and apply customized settings 5 .3 BuildMassStorageSection=Yes is equivalent to the -bmsd command line parameter on sysprep. It willwork only if a SysprepMassStorage section – an empty one is fine – already exists in sysprep.inf. Preexistingcontent of the section, if any, will not be overwritten. The value of BuildMassStorageSection=Yesis debatable because most of the mass storage drivers that sysprep adds are for older devices unlikely to befound in reasonably modern machines.4 Adding a mass storage driver in this way only works if the [SysprepMassStorage] section is present atsysprep time. There is no point adding them at deployment time.5 Be sure to enable the Detect non-plug and play hardware checkbox. The labeling of this checkbox ismisleading. If it is left disabled, mini-setup will not do hardware detection at all.Hardware Independent Imaging Rev 9.1 Page 11 of 47

6. Create the image. Use LANDesk ® Management Suite’s PXE Boot Menu or virtualboot or a boot floppy to take an image of the client. Remember, Management Suitecomes with an imaging tool, but if you’ve already purchased an imaging tool likeGhost – use it. It’s your choice! LANDesk also supports the Windows imaging toolImageX.7. Create a sysprep.inf template file. When mini-setup runs, the sysprep.inf that itfinds will (usually) not be the one that you included in the image. Instead it is builtdynamically at deployment time. The way this happens depends on whether you useOSD or Provisioning.In the case of OSD, if you checked the Image uses Sysprep checkbox, thesysprep.inf in the image will be overwritten. A new one is generated atdeployment time from 2 sources: -1- the answers you gave to the OSD scriptwizard -2- the optional sysprep.inf template file.The wizard generates sysprep.inf parameters such as ComputerName, TimeZone,ProductKey and a few more based on the answers given in the wizard. If you needadditional parameters, you put them in the sysprep.inf template file, whose path isone parameter that you specify to the OSD wizard.Example: Regional Settings can't be specified through the wizard. If you want aHardware Independent Imaging Rev 9.1 Page 12 of 47

specific Language code, put it in a sysprep.inf template file. You may want to useSetupMgr to create the sysprep.inf template file.The sysprep.inf template file doesn't need to be a complete sysprep.inf. It will bemerged with the one generated automatically by the wizard (with the parametersfrom the wizard taking priority).Save the sysprep.inf template file somewhere on the core server. In the following,we assume that the template file was saved as d:\images\template.inf (on the coreserver).In the case of Provisioning, the sysprep.inf included in the image may or may notbe overwritten at deployment time. You can include a sysprep.inf in your imagewith all the parameters that you will ever need. But you will probably want theflexibility provided by the inject script action, which can be used to download asysprep.inf at deployment time and substitute parameters in it. For the purpose ofthis document, we might call this file too a sysprep.inf template file 6 .You are entirely responsible for the contents of the sysprep.inf that you injectusing the inject script command 7 . Use the standard SetupMgr program that comeswith sysprep to build a sysprep.inf. Then, replace any values that you want to bedynamic with variables. You almost certainly want the ComputerName line toread something like ComputerName=%ldHostname%, where %ldHostname% is avariable that will be substituted at deployment time.Import your sysprep.inf template file into the database using the Install Scriptsicon in the console's Provisioning plug-in.Microsoft strongly advises against installing unsigned drivers. If you neverthelessneed to install unsigned drivers, include the following in the [Unattended] section ofyour sysprep.inf template file.[Unattended]DriverSigningPolicy="Ignore"NonDriverSigningPolicy="Ignore"Figure 6. If you must install unsigned drivers, insert these lines in your sysprep.inf template file.6 You will not find this terminology in the Provisioning documentation. From the Provisioning point offew, the file that we are calling a sysprep.inf template file here is just a "script" that you have imported intothe database using the Install Scripts button in the console and that you can then "inject" at deploymenttime, using the "inject script" action.7 This is in contrast with OSD, which generates a workable sysprep.inf for you, even if you don't specify asysprep.inf template file.Hardware Independent Imaging Rev 9.1 Page 13 of 47

8. Create the LANDesk OSD script or provisioning template. If you are usingprovisioning, use the sample template (see section 6, Using Provisioning).If you are using OSD, create a WINPE deployment script in the OS Deployment tool.Take care to specify the sysprep.inf template file created in the previous step. Savethe script and exit the OS Deployment tool.Figure 7. In the OS Deployment tool, specify the sysprep.inf template file created in the previousstep (see above).9. (OSD Only) Insert commands in OSD script to copy PnP drivers. Right-click theOSD script created in the previous step and select Advanced edit (Figure 8) to open itin notepad.Hardware Independent Imaging Rev 9.1 Page 14 of 47

Figure 8. Right click the OSD script and select Advanced edit to edit it in notepad.ImportantIf you use the console UI to modify the OSD script aftermanually editing it with Advanced Edit, your changes willbe lost and you will need to apply them again.Hardware Independent Imaging Rev 9.1 Page 15 of 47

BEGINWINPE=TRUEREMPING16=WINPE, TIMEOUT=1800REMEXEC17=diskpart /s X:\LDClient\rmvol.txtREMEXEC18=drvmap.exe core88a\administrator 107083226853FB47AB22B0C1B77 I: \\CORE88A\Provisioning, STATUS FACILITY=3513REMEXEC19=drvmap.exe core88a\administrator 107083226853FB47AB22B0C1B77 H: \\CORE88A\Provisioning, STATUS FACILITY=3513REMEXEC20=diskpart /s X:\LDClient\wipeDisk0.txtREMEXEC21=cmd /c format /Y /FS:NTFS /Q /V:C-DRIVE c:REMEXEC22=cmd /c RunBatch -1 h:\tools\imagex.exe /apply i:\images\WinXP.wim 1 C:, STATUS FACILITY=3513, SYNCREMEXEC23=sdclient /f /o /dest="X:\LDClient\diskinfo.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/diskinfo.exe", STATUSREMEXEC24=sdclient /f /o /dest="X:\LDClient\assvol.txt" /p="http://%CUSTJOBHOSTIP%/landesk/files/assvol.txt", STATUSREMEXEC25=tokreplw X:\LDClient\assvol.txt partition=1REMEXEC26=diskpart /s X:\LDClient\assvol.txtREMEXEC27=sdclient /f /o /dest="C:\sysprep\sysprep.inf" /p="http://%CUSTJOBHOSTIP%/landesk/files/DeployHII.inf", STATUSREMEXEC28=sdclient /f /o /dest="C:\ldsleep.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/ldsleep.exe", STATUSREMEXEC29=tokreplw C:\sysprep\sysprep.inf COMPUTERNAME=%Computer - Device Name%REMEXEC30=cmd /c copy /y X:\LDClient\guid.pds C:\LDISCAN.CFGREMEXEC31=tokreplw C:\LDISCAN.CFG DEVICEID=%Computer - Device ID%REMEXEC32=tokreplw C:\LDISCAN.CFG IMAGEPATH=\\CORE88A\Provisioning\images\WinXP.wimREMEXEC33=sdclient.exe /f /o /dest="x:\ldclient\fixvista.bat" /p="http://%CUSTJOBHOSTIP%/landesk/files/FixVista.bat"REMEXEC34=sdclient.exe /f /o /dest="x:\ldclient\fixntfs.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/fixntfs.exe"REMEXEC35=sdclient.exe /f /o /dest="x:\ldclient\bcdedit.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/bcdedit.exe"REMEXEC36=RunBatch -1 X:\LDCLient x:\ldclient\FixVista.batREMEXEC37=diskinfo extend_last_partitionREMEXEC371=h:\tools\copydrivers.exe /cREMEXEC372=h:\tools\halconfig.exe /cab=sp3.cabREMEXEC373=h:\tools\ldprep /path=c:\drivers\pnpREMEXEC38=reboot, timeout=2Figure 9. This shows a portion of a typical OSD script, as opened with Advanced Edit. We insert thelines shown in blue to copy custom drivers to the client’s hard drive during the OSD job’s postimagingphase. An equivalent provisioning template is shown in section 6, Using Provisioning.The lines inserted do the following: The REMEXEC371 uses the copydrivers program to copy machine dependentdrivers. Copydrivers requires a specific folder structure and a control file calledcopydrivers.ini. More info below, section 3.1. The REMEXEC372 line runs the halconfig program. Be sure to understand thefull implications, including the meaning of the /cab parameter. See section 5. The REMEXEC373 line runs the ldprep program. LdPrep enumerates the driversthat we just copied and adjusts the client’s DevicePath registry keyaccordingly. More info on why this is needed and how this works can be foundin section 3.3, Enumerating drivers.Notice the following when editing OSD scripts:• Give each REMEXEC line a unique number. The line numbers don’t need to be innumeric sequence, just unique.Hardware Independent Imaging Rev 9.1 Page 16 of 47

• The lines are executed in the order listed, not numerically.Section SummaryWith these steps, we have achieved our main goal. By copying the drivers at deploymenttime rather than including them in the image, we have achieved Hardware IndependentImaging.The next few chapters discuss ways in which the process can be optimized and extended: Drivers that require a setup program. The drivers shown in the above exampleall share the property that they can be installed without a setup program. Themini-setup can install the driver as long as it finds the driver’s .inf file. Somedrivers aren’t like that. Section 3.4, Drivers with a setup program, will discusshow to handle such drivers. HAL (Hardware Abstraction Layer). Different computers may not only requiredifferent drivers, but also different HALs. Chapter 5 “The Hardware AbstractionLayer (HAL). Making your image HAL-independent” discusses techniques tomake your image not only driver independent, but also HAL independent. Mass Storage Drivers. These can't be handled in the same way as PnP drivers forother devices. See More about Mass Storage Drivers.Hardware Independent Imaging Rev 9.1 Page 17 of 47

3. More about handling driversThe previous chapter has outlined a process to keep images generic. Instead of puttingdrivers inside the image, we copy them from a server at deployment time. The commandsthat we inserted in the sample OSD script (Figure 9) use a program called copydriversthat retrieves the machine type from WMI, then uses this info to copy drivers specific tothat manufacturer / model.This chapter will provide some additional background information on the techniquesinvolved.3.1. The CopyDrivers programCopyDrivers.exe is a compiled autoit script. CopyDrivers requires an ini file(copydrivers.ini) that associates WMI model names with driver folders. Below is asample copydrivers.ini:[Config]DriversSource=\\Core88a\Provisioning\DriversDriversTarget=c:\drivers[Models]Precision Workstation T3400=Dell Precision T3400VMware Virtual Platform=VMWare_WorkstationPowerEdge 1950=Dell PowerEdge 19509071A1G=ThinkCenter M57p2007FVG=ThinkPad T6064575KG=Thinkpad T61pFigure 10. Sample copydrivers.ini. Each line of the [Models] section maps a WMI model name to asubfolder of the UNC path defined by the DriversSource line. The subfolder will be copied to a localfolder on the client, as defined by the DriversTarget line.The meaning of this is best illustrated by an example. My Lenovo T60 laptop has a WMImodel name of 2007FVG. Copydrivers reads the WMI model name and finds anassociated driver folder name under the [Models] section. In the above copydrivers.ini,that folder name is ThinkPad T60. CopyDrivers appends this folder name to the baseUNC path defined by the DriversSource line in the [Config] section and copies theresulting complete path (\\Core88a\Provisioning\Drivers\Thinkpad T60) to the a folder onthe target machine (c:\drivers in the example), as defined by the DriversTarget line.When you run CopyDrivers without command line parameters, a little GUI comes up thatallows the copydrivers.ini file to be created or edited. See below. This GUI does nothing,however, that you can't do by manually editing copydrivers.ini.Hardware Independent Imaging Rev 9.1 Page 18 of 47

Below is the usage info displayed when you type copydrivers /?The /s and /d parameters can be used to override the DriversSource and DriversTargetlines in copydrivers.ini.Hardware Independent Imaging Rev 9.1 Page 19 of 47

To build the copydrivers.ini file, you need to know the WMI model name of each targetmachine type. Here are 3 ways to find a machine's WMI model name:1. In the LDMS inventory info, look for System - Model.2. In Accessories / Systems Tools / System Information, look for System Model.3. Run the CopyDrivers GUI on the target machine. Click the Add button. In thenext dialog, click the WMI button.3.1.1. Wildcard matchingUnlike previous versions, CopyDrivers now does wildcard compares when looking formatching lines in copydriver.ini. This will be useful if you have multiple closely relatedmachines with "similar" model names. Example: HP DC5100 machines have modelnames like HP Compaq dc5100 SFF(PT001AW), HP Compaq dc5100 SFF(PT006AW)etc. It may make sense to catch these nearly identical models with a single line such asthe following:HP Compaq dc5100SFF*=DC5100Wildcard matching also implies that multiple lines in copydrivers.ini may match themodel name. CopyDrives will perform its copying operation for every matching line. Oneway you can exploit this behavior is shown in this example:[Models]*=commonPrecision Workstation T3400=xyz1VMware Virtual Platform=VMWare_WorkstationPowerEdge 1950=Dell PowerEdge 19509071A1G=ThinkCenter M57p2007FVG=ThinkPad T6064575KG=Thinkpad T61pHP Compaq dc5100SFF*=DC5100The first line will match any model name. Therefore, whatever the model, the firstsubfolder that CopyDriver will copy will be the one called "common". In other words, wehave a mechanism whereby we can have both "common" drivers that are copied to alltargets and model specific drivers.3.2. Using a driver extraction toolIn the above discussion, we have simply assumed that a per-machine type folder existsthat stores all the machine specific drivers. How might we build such a folder?An easy way to collect the hardware specific drivers for a given machine type is to use adriver extraction tool. A few tools exist that extract drivers from an existing, fullyHardware Independent Imaging Rev 9.1 Page 20 of 47

installed machine. One such tool is Driver Magician (http://www.drivermagician.com).Another one is Double Driver (http://www.boozet.org/dd.htm).As an example, when I run DriveMagician Lite (the freeware version) on a LenovoThinkpad T60 and let it "back up" the machine's hardware specific drivers, I get thefollowing result (see the PnP folder):Figure 11. Machine specific drivers as extracted by Driver Magician Lite.In my testing, the extracted drivers installed correctly, with the exception of a few minorglitches:Mini-setup complained that some of the drivers were unsigned. I'm not surewhether or not they really were unsigned to begin with, or whether the extractionprocess made them appear so. I used the sysprep.inf lines shown in Figure 6 toavoid the unsigned driver prompt.Both driver extraction tools flatten drivers. Most drivers don't have subfolders butone that does is the ATI video driver. This caused mini-setup to ask for the path tothe installation files. It wasn't difficult to recreate the original folder structure, butthere is an obvious alternative: run the driver's setup program (as shown in Figure13).There was one driver (fingerprint reader) that was not extracted by either of theextraction tools. Solution: run the driver setup program as shown in Figure 13.3.3. Enumerating driversSimply copying drivers to the client’s hard drive is not enough. Mini-setup needs to betold where to find them. In the traditional sysprep/mini-setup process, this is achieved asfollows:Hardware Independent Imaging Rev 9.1 Page 21 of 47

1. You enumerate all the driver paths in the OemPnpDriversPath line in the[unattended] section of sysprep.inf. Every folder that contains a driver’s .inf fileneeds to be listed individually.2. You run sysprep. Sysprep adds the paths listed in OemPnpDriversPath to theDevicePath key in the registry (HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath) 8 .3. At deployment time, the mini-setup runs and uses the DevicePath key in theregistry to find device drivers.This process is inconvenient in that it expects us to know the paths of all the drivers inadvance (at sysprep time). In the process advocated in this document, we only decide atdeployment time what drivers to copy. Therefore, we want a method that allows us toenumerate drivers at deployment time.A program called LdPrep that comes with this document was written for this purpose.Use LdPrep V1.5 or later. Figure 12 shows how the ldprep program can be used underWinPE. Full information about ldprep can be found in section 7.2.……REMEXEC30=diskpart /s X:\LDClient\assvol.txt……REMEXEC37=diskinfo extend_last_partitionREMEXEC371= h:\tools\copydrivers.exe /cREMEXEC372= h:\tools\halconfig.exe /cab=sp3.cabREMEXEC373=h:\tools\ldprep /path=c:\drivers\pnpREMEXEC42=reboot, timeout=2Figure 12. Insert this line to dynamically enumerate the drivers at deployment time. The commandline parameter specifies the path to be searched for drivers (c:\drivers\pnp).The LdPrep program recursively searches the folder specified by the /path command lineparameter and adds the paths of all .inf files that it finds to the DevicePath key in theregistry (HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath).Of course, since we are running LdPrep under WinPE, “the registry” is the wrongregistry. We need to modify the DevicePath key in the freshly restored image’s registry,not in WinPE’s registry. LdPrep assumes that the image's HKLM\Software registry hiveresides in a physical file c:\windows\system32\config\software, as it will be in a default8 It is important to understand that OemPnpDriversPath is used at sysprep time only, not at mini-setup time.Mini-setup uses the DevicePath key in the registry, not OemPnpDriversPath. There is no point ingenerating a OemPnpDriversPath line in sysprep.inf after creating the image.Hardware Independent Imaging Rev 9.1 Page 22 of 47

Windows XP installation. If this assumption is incorrect, you will need to specifyadditional command line parameters (see section 7.2).3.4. Drivers with a setup programFor the purpose of this document, we need to distinguish between 3 kinds of drivers:1. Drivers that can be installed based only on their .inf file only. All that needs tohappen for the driver to be installed by the mini-setup is the driver’s .inf file mustbe listed in the DevicePath registry key. The technique for enumerating .inf fileshas been explained above, see section 3.3 “Enumerating drivers”.2. Mass Storage drivers.3. Drivers that require a setup program. For the purpose of this document, we'll callthese setup based drivers.When a driver comes with a setup program, the first question to ask is whether the setupprogram is really needed. You will often find that, although the driver comes with a setupprogram, it installs perfectly well without it. Indeed, many driver setup programs donothing more than copy the files and adjust the DevicePath registry key to make sure thePnP subsystem can find them.Sometimes, however, it may be necessary or desirable to run the manufacturer’s setupprogram.Windows mini-setup provides two mechanisms to accommodate such drivers:cmdlines.txt - see InstallFilesPath keyword in sysprep documentation. Commandlines contained in cmdlines.txt will be run during mini-setup, after the PnPdetection but before the reboot.GuiRunOnce - see GuiRunOnce section in sysprep documentation. Commandlines contained in GuiRunOnce will be run during the first login (maybe anautomatic login, if so configured).Usually, if you have a driver that must be installed with a setup program, it will notmatter whether it is installed by the cmdlines or by the GuiRunOnce mechanism. In raresituations, however, things have been known to go wrong unless a particular driver isinstalled before or after the first reboot following mini-setup.Therefore, the CopyDrivers.exe program provides support for both mechanisms.CopyDrivers provides support for setup based drivers in two ways:Hardware Independent Imaging Rev 9.1 Page 23 of 47

1. In GUI mode (launch copydrivers with no command line parameters), CopyDriverslets you create or edit the two lists of driver setup commands (see Figure 13).CopyDrivers keeps these lists in 2 files (cmdlines.txt, GuiRunonce.ini) at the root ofthe machine specific driver folder. Figure 3 shows a cmdlines.txt sitting in the rightplace.2. At deployment time (launch copydrivers with a /c command line parameter),CopyDrivers plugs the cmdlines.txt and GuiRunonce.ini files into "the right places"as required by mini-setup, merging them with existing content if there is any in theimage.Figure 13. How to use CopyDrivers to create or edit lists of driver setup commands. There are 2 lists,one to be run before the first reboot (cmdlines mechanism), a second one to be run after the firstreboot (GuiRunOnce mechanism).When using provisioning, you are not limited to these two mechanisms. As under OSD,you probably want to use the cmdlines mechanism for drivers that must be installed atmini-setup time, before the reboot initiated by mini-setup. But for additional drivers, youmay prefer not to use RunOnce. Instead, you would adhere to a convention whereby eachmachine specific driver folder has a batch file that always exists (although it may beempty), and that is run by provisioning action (e.g. cmd /c c:\drivers\setup\setupdrv.bat).4. More about Mass Storage DriversThis topic was discussed in previous chapters (see p. 8 and p. 10). This section providesHardware Independent Imaging Rev 9.1 Page 24 of 47

more info. Let’s revisit the sample [SysprepMassStorage] section first shown on p. 10:[SysprepMassStorage]PCI\VEN_8086&DEV_2681&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_27C1&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_27C5&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2821&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2829&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2922&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_2929&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_3A02&CC_0106 = C:\drivers\intelsata\iaahci.infPCI\VEN_8086&DEV_3A22&CC_0106 = C:\drivers\intelsata\iaahci.infHow did we come up with these lines?The mass storage driver that we used for this example is the intel SATA driver, V8.7. Wefollowed the steps described below:1. Downloaded the “intel matrix storage driver” (iata87enu.exe) from the intel website.2. We don’t want to install the driver, just to expand the files to a folder of ourchoice (c:\drivers\sata). For this driver, the command line looks as follows:iata78_enu.exe -a -p c:\drivers\intelsata3. Examining the expanded files, found an inf file: c:\drivers\intelsata\winall\Driver 94. Opened the inf file, looked for a section called [Manufacturer], which is arequired section:[Manufacturer]%INTEL%=INTEL_HDC,ntamd645. The first string after the equal sign (INTEL_HDC) is the name of a further sectionthat we need to look for (comments and blank lines left out): 10[INTEL_HDC]%PCI\VEN_8086&DEV_2681&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_2681&CC_0106%PCI\VEN_8086&DEV_27C1&CC_0106.DeviceDesc% = iaStor_Inst,PCI\VEN_8086&DEV_27C1&CC_0106%PCI\VEN_8086&DEV_27C5&CC_0106.DeviceDesc% = iaStor_mobl_Inst,PCI\VEN_8086&DEV_27C5&CC_0106%PCI\VEN_8086&DEV_2821&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_2821&CC_0106%PCI\VEN_8086&DEV_2829&CC_0106.DeviceDesc% = iaStor_mobl_Inst, PCI\VEN_8086&DEV_2829&CC_0106%PCI\VEN_8086&DEV_2922&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_2922&CC_0106%PCI\VEN_8086&DEV_2929&CC_0106.DeviceDesc% = iaStor_mobl_Inst, PCI\VEN_8086&DEV_2929&CC_0106%PCI\VEN_8086&DEV_3A02&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_3A02&CC_0106%PCI\VEN_8086&DEV_3A22&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_3A22&CC_0106The second string after the equal sign on each line (highlighted in blue) is the9 In the case of this driver, there is a 2 nd inf file (iastor.inf). We have ignored it here because it is only usedfor RAID. If there is a chance that you might need it, handle it the same way as the first inf file.10 The ntamd64 string indicates that there will be a further section called [INTEL_HDC.ntamd64] for x64based systems. This need not concern us here.Hardware Independent Imaging Rev 9.1 Page 25 of 47

plug&play ID of a device supported by this driver 11 .6. We now have all the info required to add this driver to the [SysprepMassStorage]section. Take each of the plug&play IDs and add it to the SysprepMassStoragesection in the format as seen in the example: =.7. In addition to the .inf file, the .sys and .cat files that we found in the same folderafter expanding the files also need to be present on the master workstation atsysprep time. In the example, we "flattened" the driver's folder structure, puttingall the files needed (.inf, .cat, .sys) at c:\drivers\intelsata.You can double check on a live system using the device whether its PnP ID is indeedincluded in the list. See Figure 14.Figure 14. Verifying the PnP ID of a device. When you add a mass storage driver to the[SysprepMassStorage] section, it is a good idea to double check on a live system that the device’s PnPID is indeed included.11 The VEN_xxxx part of the PnP ID described the manufacturer (VEN_8086 = intel). The DEV_xxxx partdescribes the device.Hardware Independent Imaging Rev 9.1 Page 26 of 47

4.1. Third party sources for driversAs an alternative to locating mass storage drivers on manufacturer sites, consider usingone of the third party web sites that specialize in collecting drivers. Here is one placewhere you can find a comprehensive set of mass storage drivers, convenientlyconsolidated into one archive:http://www.driverpacks.net/DriverPacks/DriverPack.php?pag=mHave a look also at http://forum.driverpacks.net/viewtopic.php?pid=11639#p11639.There you will find a script that can help to populate the [SysprepMassStorage] section.Give it a folder name and it will recursively find all the inf files and generate content thatyou can copy to [SysprepMassStorage].With a mass storage driver package as comprehensive as this, you probably don’t needthe BuildMassStorageSection parameter (see p 10).4.2. Injecting Mass Storage Drivers at deployment timePrevious versions of this whitepaper claimed that this is not possible. Well, as it turns out,there are 2 methods of doing it 12 :1. Using MSDINST.2. "Do-it-yourself" method, perhaps using the capturemsd and injectmsdprograms that come with this document.4.2.1. Using MSDINST to inject a mass storage driver.MSDINST.EXE is a Microsoft tool designed for this purpose. It is part of the "OEM Pre-Installation Kit" (OPK). One problem with it is that it is not clear how the end user canget hold of this tool. If you have msdinst.exe, you will also have the documentation thatgoes with it and you should not run into any particular difficulty using it in an LDMS 8.7or 8.8 OSD or Provisioning context.This document will not attempt to provide full details on how to use msdinst, but here is asummary:Copy the driver files (typically a .inf, .cat and .sys) to a folder on the target system.Append the path to the driver to the target system's DevicePath registry key12 Here is one method that might be expected to work but doesn't. Remember how we added a mass storagedriver in section 2 using a [SysprepMassStorage] section. Why not try the same thing here, i.e. copy thedriver files into place and insert appropriate SysprepMassStorage lines into sysprep.inf? That will not workbecause SysprepMassStorage is processed by sysprep, not by mini-setup.Hardware Independent Imaging Rev 9.1 Page 27 of 47

Prepare a sysprep.inf file with a [SysprepMassStorage] section that links the PnPdevice IDs supported by the driver with the inf file. The format is the same asillustrated in Figure 5. No other content is needed in the file. You probably don'twant to use your existing c:\sysprep\sysprep.inf file for this. In the below, we haveassumed c:\sysprep\sysprep1.inf.Run following command line: msdinst.exe c:\sysprep\sysprep1.inf c:\windowsAll of this happens under WinPE in the post-OS installation phase of the OSD orprovisioning task.4.2.2. The do-it-yourself method to inject a mass storagedriver.If you can't get hold of msdinst.exe, fear not. What msdinst does is straightforwardenough to achieve without the help of a specialized tool. Here is a summary of whatneeds doing:Copy the .inf file to the inf folder (c:\windows\inf)Copy the .sys file (and any DLLs that go with it) to the drivers folder(c:\windows\system32\drivers).Add the driver service to the target's registry. A driver is similar to a service in that itis described by a subkey of HKLM\System\CurrentControlSet\Services. We canexport this subkey to a file, then import it into the target OS.Add the driver to the target's critical device database. The critical device database is alist of boot device PnP IDs and their associated drivers. It is stored in a registry key(HKLM\CurrentControlSet\Control\CriticalDeviceDatabase). Again, we need toexport the correct subkey to a file, which we can then import into the target OS.The driver may have a subkey under HKLM\CurrentControlSet\Services\EventLog.Again, export this subkey to a file, then import it into the target OS.Two tools are provided with this document to automate these steps:1. CaptureMsdRun this program on a machine that has the desired Mass Storage Driver installed. Ittypically outputs a .inf, .sys and .reg file 13 , which you can then use with the InjectMsdprogram to inject the driver in an OSD/Provisioning task.2. InjectMsdRun this program at image deployment time. It will use the files captured by CaptureMsdto inject the mass storage driver. See also section 7.3, CaptureMsd.exe, InjectMsd.exe.13 It has been reported that CaptureMsd sometimes does not find a .inf file. This will not stop the driverfrom being installed correctly - just run InjectMsd without a .inf file. It is only "good practice" to have the.inf file. If you know where to find it, you can always add it manually.Hardware Independent Imaging Rev 9.1 Page 28 of 47

Example: when I run CaptureMSD on my Lenovo Thinkpad T60, which uses an intelSATA driver, CaptureMSD collects the following 3 files:iaAHCI.infiaStor.sysiaStor.regThe first two of these file are copies of existing driver files. The 3rd file (iaStor.reg) wasmanufactured by CaptureMsd.To conform to the conventions used in this document, these 3 files need to be copied tothe msd subfolder of the machine-specific driver folder:Figure 15. Copy the mass storage driver files, as captured by CaptureMsd, to the msd subfolder ofyour machine-specific driver folder. The InjectMsd program will pick them up from there atdeployment time and inject them into the image.……REMEXEC30=diskpart /s X:\LDClient\assvol.txt……REMEXEC37=diskinfo extend_last_partitionREMEXEC371=h:\tools\copydrivers.exe /cREMEXEC372=h:\tools\halconfig.exe /cab=sp3.cabREMEXEC373=h:\tools\ldprep /path=c:\drivers\pnpREMEXEC374=h:\tools\injectmsdREMEXEC42=reboot, timeout=2Figure 16. This extract from a sample OSD script shows the line that you would insert to inject the massstorage driver previously captured with CaptureMsd. If you use the pathnames and conventions of thisdocument, InjectMsd will find the msd folder without the need for a command line parameter.Hardware Independent Imaging Rev 9.1 Page 29 of 47

Notes and limitations:1. Note: do not use capturemsd/injectmsd unnecessarily. If your source machine isIDE, there is no need to use capturemsd/injectmsd for IDE based target machines. Fortarget machine types that do not need a mass storage driver injected, don't create an msdsubfolder in their machine specific driver folder.2. Limitation: CaptureMsd will only add the PnP ID of the source system's mass storagecontroller to the critical device database. If the same drive supports similar devices with adifferent PnP ID, they will not be recognized. You may want to manually edit the .reg filecreated by CaptureMsd and add more PnP IDs. Use the inf file to know which ones.Example: when I run CaptureMsd on my Thinkpad T60, the .reg file that it generates willinclude the following 3 lines:[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c5&cc_0106]"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}""Service"="iaStor"This adds one PnP ID to the critical device database. But we know from above that thesame driver supports several more PnP IDs. To add all supported PnP IDs to the criticaldevice database, duplicate the above 3 lines for each of the supported PnP IDs, as shownbelow:[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c5&cc_0106]"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}""Service"="iaStor"[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_2752&cc_0106]"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}""Service"="iaStor"... etc for each of the PnP IDs3. Limitation: CaptureMsd will not capture any additional files that go with the driver's.sys file. Most desktop mass storage drivers are composed of just a .inf and a .sys file. Ifmore files are needed (e.g. a DLL that needs to be copied to the target's system32 folder),you can manually create a windows subfolder in the msd folder. InjectMsd willrecursively copy it to the target's windows folder.4. Note: You can use InjectMsd to inject multiple mass storage drivers. If the samemachine type can use one of two possible mass storage drivers, put both drivers in themsd folder, i.e. install both drivers on all systems.Hardware Independent Imaging Rev 9.1 Page 30 of 47

5. The Hardware Abstraction Layer (HAL). Making yourimage HAL-independentIn the previous chapters, we have outlined techniques to decouple images from devicedrivers. But device drivers aren’t the only obstacle to hardware independence. We alsoneed to consider the Hardware Abstraction Layer (HAL). Different computers needdifferent HALs. If we restore an image with the wrong HAL to the wrong computer, theusual result is a black screen early in the boot sequence. Unless we can find a way to takecare of the HAL, we still have the overhead of creating and maintaining multiple images.As technologies such as Hyper-threading and multi-core become mainstream, thisoverhead is becoming more of a burden.This chapter discusses two techniques to make images HAL-independent. One techniqueuses native OSD features, see section 5.2, LANDesk OSD features for HAL handling. Asecond technique goes one step further, see section 5.3, Automating HAL detection. Butfirst, let’s look at the background.5.1. Which HAL is my computer using?To find out which HAL is used by a computer, go to device manager and click onComputer. A single device will be listed (Figure 17). The name of this “device” is thename of the HAL, such as “ACPI Multiprocessor PC” in the example. ClickingProperties, Driver, Driver Details, we see the files that make up the HAL. WhicheverHAL is installed, we always find the following 3 filenames: hal.dll, ntkrnlpa.exe andntoskrnl.exe, all in %windir%\system32. However, looking at the properties of hal.dll, wefind the file’s “true identity” under Version, Original Filename (Figure 18). On thiscomputer, hal.dll is a renamed copy of halmacpi.dll.Figure 17. We find the name of the HAL in Device Manager. There will be one device listed underComputer. The name of this “device” is the name of the HAL.Hardware Independent Imaging Rev 9.1 Page 31 of 47

Windows XP supports 6 out-of-the-box HALs:HAL name hal.dll original filename HAL name in hal.infACPI Multiprocessor PC halmacpi.dll ACPIAPIC_MPACPI Uniprocessor PC halaacpi.dll ACPIAPIC_UPAdvanced Configuration and halacpi.dllACPIPIC_UPPower Interface (ACPI) PCMPS Multiprocessor PC halmps.dll MPS_MPMPS Uniprocessor PC halapic.dll MPS_UPStandard PC hal.dll E_ISA_UPOnly the first 3 of the 6 out-of-the-box HALs are likely to be found on reasonably up-todatecomputers. The other 3 are legacy HALs, e.g. the “Standard PC” HAL (hal.dll) wasused on Pentium, Pentium II and early Pentium III. Starting with Pentium III 450 MHz,most computers use halacpi.dll. Some older computers can be forced to use halacpi.dll bychanging a BIOS setting.We will ignore the legacy HALs in this document. We will also ignore manufacturerspecific HALs. The rules for which of the 3 commonly used HALs is appropriate forwhich computer are shown in Figure 19 (ACPI is Advanced Configuration and Power Interface,APIC is Advanced Programmable Interrupt Controller).halacpi (“ACPI HAL")Single processor, no hyper-threadingon-chip APIC: Nohalaacpi ("Uniprocessor HAL")Single processor, no hyper-threadingon-chip APIC: Yeshalmacpi ("Multiprocessor HAL")Multiprocessor or hyper-threadingon-chip APIC: YesFigure 18. Checking the properties of%windir%\system32\hal.dll, we find thathal.dll is a renamed copy of a different file.Figure 19. Rules for which HAL goes with whichcomputer.Additional HAL filesGoing back to Figure 17, there are 2 more files that, like hal.dll, may be renamed copiesof HAL-dependent files: ntkrnlpa.exe and ntoskrnl.exe. Two versions exist of these files:halacpi and halaacpi use the “true” ntkrnlpa.exe and ntoskrnl.exe. On halmacpi systems,ntkrnlpa.exe and ntoskrnl.exe are renamed copies of ntkrpamp.exe and ntkrnlmp.exe.Hardware Independent Imaging Rev 9.1 Page 32 of 47

5.2. LANDesk OSD features for HAL handlingThis section is applicable only to OSD. For provisioning, move on to the next section.As you step though the console dialogs to create an OSD script, you will notice someoptions that will “often” 14 allow a uniprocessor image to be deployed on a multiprocessordevice, or vice versa. See Figure 20 and Figure 21.Figure 20. Enable Configure advanced multiprocessor options if the source is a uniprocessor machineand the target is a multiprocessor machine or vice versa. Leave disabled if source and target use thesame HAL (all the options in Figure 21 will be grayed out).14 Why “often” and not “always”? Because the source and the target machines still need to have sufficientlycompatible hardware. The procedure should work if both machines have on-chip APIC (halmacpi andhalaacpi HALs).Hardware Independent Imaging Rev 9.1 Page 33 of 47

Figure 21. Assuming that all machines involved are APIC based (halmacpi or halmaacpi HAL), usethese settings to deploy a multiprocessor image to a uniprocessor target (use settings as shown) orvice versa (set “uniprocessor” radio button). As explained in section 5.1, you are unlikely to meetMPS based machines.The effect of enabling the uniprocessor / multiprocessor radio buttons in the dialogshown in Figure 21 is as follows (assuming the OS is Windows XP and APIC isselected):• Uniprocessor: the following line is inserted in the [unattended] section ofsysprep.inf:UPDATEHAL=ACPIAPIC_MP,%systemdrive%\sysprep\hal\hal.infThis causes the multiprocessor HAL (halmacpi) to be loaded on the target.• Multiprocessor: the following line is inserted in the [unattended] section ofsysprep.inf:UPDATEUPHAL=ACPIAPIC_UP,%systemdrive%\sysprep\hal\hal.infThis causes the uniprocessor HAL (halaacpi) to be loaded on the target.Caution: enabling Configure advanced multiprocessor options (see Figure 20) willalways change the HAL type, even if the source HAL is right for the target machine.Enable Configure advanced multiprocessor options when deploying a uniprocessorimage to a multiprocessor target or vice versa, but leave it disabled if the source HAL isright for the target machine.There is room for confusion here. If you deploy a uniprocessor image to a uniprocessortarget using an OSD script that has the Uniprocessor radio button set, the multiprocessorHAL (halmacpi) will be installed. This will probably work (provided the target has onchipAPIC), but there will be a performance loss.Hardware Independent Imaging Rev 9.1 Page 34 of 47

5.3. Automating HAL detectionIn the previous section, we saw that we can achieve HAL independence by enabling theConfigure advanced multiprocessor options checkbox in one of the OSD script dialogs(see Figure 20 and Figure 21). Under many conditions, uniprocessor images can bedeployed to multiprocessor machines and vice versa.One problem with the advanced multiprocessor options is that the responsibility fortargeting the correct OSD script to the correct targets is left with the user. If a set ofmachines require different HALs, the advanced multiprocessor options may allow us touse a single image, but multiple OSD scripts will need to be created and the user willneed to know which script to target to which machine.In this section, we go one step further. We automate the detection of the appropriateHAL. This will make it possible not only to use a single image for target machines thatneed different HALs, but also to use a single script or provisioning template, thusremoving the need for a human operator to know which script to target to which machine.5.3.1. The old process: downgrade to "baseline HAL"The process advocated in previous versions of this document was based on theassumption that all "reasonably modern" laptop and desktop machines can use the ACPIHAL (halacpi.dll), which could therefore be considered a "baseline HAL". Therefore, theprocess was to downgrade the source machine to this baseline HAL before you imaged it.The underlying assumption (all "reasonably modern" machines can use the ACPI HAL)has broken down with the advent of the intel Montevina chipset, currently found in someof the newest laptops.We will still describe the old process because some readers may be using it and may not(yet?) have a reason to change it.The old strategy was based on the following observations:1. Halacpi.dll is in effect a “baseline” HAL. It is "widely reported" that halacpi.dllworks on “all” desktop and laptop computers (except very old ones). As alreadypointed out, this is no longer true in the case of some of the newest laptops, basedon the Montevina chipset.2. Sysprep.inf provides a mechanism to upgrade from halacpi.dll to halaacpi.dll orhalmacpi.dll, using keywords UpdateHAL and UpdateUPHAL in the [unattended]section.Hardware Independent Imaging Rev 9.1 Page 35 of 47

To update to halmacpi (hyper-threading and multi-processor machines):UpdateHAL=ACPIAPIC_MP,%windir%\inf\hal.infTo update to halaacpi:UpdateUPHAL=ACPIAPIC_UP,%windir%\inf\hal.inf3. WinPE configures itself to use the correct HAL. If we can find out the HAL thatWinPE is using, we can insert the appropriate keywords in sysprep.inf.4. Every Windows system carries all the standard HAL files on-board, usually hiddenaway in CAB files under %windir%\Driver Cache\i386. There is no need to doanything special to make sure that the mini-setup finds the right HAL files.Based on these observations, we can define the following process:1. Before you image your source computer, downgrade it to halacpi (or use a computerthat already uses halacpi). See Figure 18: in device manager, right-click the deviceshown under Computer and select Update Driver. You run through 3 or 4 dialogs.First select "No, not this time", then "Install from a list or specific location", then"Don't search, I will choose the driver to install". The next dialog lists the HALs thatare compatible with the computer’s hardware. Select “Advanced Configuration andPower Interface (ACPI) PC”.2. Under WinPE, run ConfigHal.exe. This is a compiled AutoIt script that determinesthe HAL used by WinPE and inserts an appropriate line in sysprep.inf to configurethe target for the same HAL.The sample OSD script shown in Figure 9 shows ConfigHal.exe being invoked.5.3.2. The new process: copy HAL filesAs already pointed out, the "old process" described in the previous section, based ondowngrading the HAL, will no longer work for targets based on the intel Montevinachipset (typically newest generation laptops). A montevina based machine will not bootfrom an halacpi based image - it will hang ("black screen") early on in the boot sequence,before the Windows XP splash screen.Therefore, a new process is needed. The new process is based on copying the correctHAL files into place (i.e. c:\windows\system32) while under WinPE, before rebootinginto mini-setup.Before we explain how the process works, a little diversion is needed about the WindowsXP driver cache. When the OS needs the driver files for a driver that comes withWindows, it looks for them in a cab file in the driver cache folder (c:\windows\driverHardware Independent Imaging Rev 9.1 Page 36 of 47

cache\i386). For a Windows XP SP2 system, the cab filename is sp2.cab, for an SP3system, the filename is sp3.cab. For the purpose of this document, we'll call it the drivercab file. You will need to have the driver cab file in your image for the process to besuccessful 15 .So here's how the process works:1. Make sure your image has the appropriate driver cab file (sp2.cab / sp3.cab) atc:\windows\driver cache\i386. If the driver cab file is not in your image, add acommand to your OSD script or provisioning template to copy it.2. Put the following command in your OSD script or provisioning template:halconfig /cab=Example: halconfig /cab=sp3.cabThe HalConfig tool starts by determining which HAL is appropriate for the targetmachine (by querying the WinPE registry, i.e. by finding out which HAL WinPE isusing). It then extracts the correct HAL files from the driver cab file, copies them toc:\windows\system32 and renames them. Finally, it inserts appropriate UPDATEHAL /UPDATEUPHAL lines in sysprep.inf.Notes:1. Without the /cab command line parameter, halconfig works as before, i.e. it onlyinserts an appropriate UPDATEHAL / UPDATEUPHAL line in sysprep.inf.2. Even with the /cab command line parameter, halconfig still generates an appropriateUPDATEHAL / UPDATEUPHAL line in sysprep.inf. The reason will soon become clear.3. You no longer need to downgrade the source machine's HAL. Any HAL should work.4. Although HalConfig has already copied the right HAL files to the right places withthe right filenames, mini-setup will install them again (from the driver cab file in thedriver cache folder. This is because it looks at the PnP info in the registry to seewhich HAL is installed, not at the files.5. Does this process violate Microsoft's support policy? The stated policy is that the onlyvalid way to change the HAL is through UPDATEHAL / UPDATEUPHAL lines insysprep.inf. Think about note 4 above: true, HalConfig has replaced the HAL files.But that was only to get the target machine booted into mini-setup. Mini-setup takesno notice of whatever HAL files HalConfig has put in place. It does a proper install ofthe proper HAL. Therefore, the end result is not a wild replacement of the HAL filesbut a clean install by mini-setup.15 In the author's experience, if you install Windows XP from a source that has SP3 slipstreamed in, youwill not have an sp3.cab file in c:\windows\Driver Cache\i386. If you don't have sp3.cab, find it in anexpanded copy of the service pack. HalConfig is not the only reason why you need this file. If the file isn'tthere, mini-setup may prompt for installation media.Hardware Independent Imaging Rev 9.1 Page 37 of 47

5.3.3. HalConfig: advanced useEnabling/disabling HAL replacement depending on the modelIn the HalConfig process as explained so far, the HAL handling is the same for allmachine types. We put a halconfig /cab= command in the OSD scriptand template and no matter what the machine type, halconfig will replace the HAL files.Although this should work in all "known" situations, there may be unknown situations inwhich, for whatever reason, it is undesirable to have halconfig replace the HAL files. Forthis reason, it is possible to set up control files that specify, on a per model basis, forwhich models HAL files should be replaced and for which models they shouldn't.By default, halconfig will replace HAL files for all models. If, for a given model, youwant to inhibit HAL replacement, create a file called HiiParams.ini in the model specificdriver folder (as specified in copydrivers.ini), with the following contents:[HalConfig]ReplaceFiles=0You can also change the default: if you create a [HalConfig] section in copydrivers.ini,with a ReplaceFiles=0 line in it, then the default changes to no HAL files being replacedand you need to create an HiiParams.ini file with ReplaceFiles=1 in the model specificdriver folders for those models that should have their HAL files replaced.Enabling/disabling sysprep.inf handling depending on the modelSimilar exception handling is possible for HalConfig's sysprep.inf handling. By default,HalConfig will insert UPDATEHAL / UPDATEUPHAL lines in sysprep.inf for all models. Ifever there is a reason to do this for some models and not for others, this can be achievedthrough a ConfigSysprep parameter that lives in the same places as ReplaceFiles (i.e. inthe optional [HalConfig] section of copydrivers.ini and in the optional HiiParams.ini filein model specific driver folders).Model specific HAL filesIf you want to decide for yourself, on a per model basis, which HAL files should becopied to c:\windows\system32, put the HAL files in a hal subfolder on the modelspecific driver folder.halconfig /path=This is a (probably less convenient) alternative to the /cab command line parameter. TheHAL files will be copied from the specified path rather than from a cab file.Hardware Independent Imaging Rev 9.1 Page 38 of 47

6. Using ProvisioningUp to now, the entire solution presented in this document has been based on the OSDcomponent of LANDesk Management Suite. What if you want to use Provisioninginstead?Adapting the examples provided in this document to the LDMS 8.7 and 8.8 provisioningcomponent should be straightforward. Indeed, you will find provisioning more flexible inthat, unlike an OSD script, which loses any customizations every time you let the OSDwizard touch it, provisioning templates are meant to be customized.A sample template (HII.xtp) is supplied with this document. Below is a screenshot of it.First, let's look at some assumptions about where things are:1. The template assumes that you have a share on a server underneath which all drivers,tools and images can be found. There is template variable called %SHARE% thatrefers to this share.2. Underneath %SHARE%, the following folders exist (see Figure 3) :Hardware Independent Imaging Rev 9.1 Page 39 of 47

tools: this is where all the tools referred to by this document (copydrivers.exe,copydrivers.ini, injectmsd.exe, ldprep.exe, halconfig.exe) are to be found.images: this is where the image residesdrivers: this is the base folder underneath which all machine specific driverfolders are to be found3. The machine specific drivers will copied from the server (machine specific subfolderof %SHARE%\drivers) to a local folder referred to as %DRIVERS%. In the sampletemplate, this variable is set to c:\drivers. Change as appropriate.4. The tools folder (%SHARE%\tools) will be copied to a local folder referred to as%TOOLS%. In the sample template, this variable is set to %DRIVERS%\tools.Change as appropriate.Let's examine the actions in the Post-OS Configuration section:1. Inject sysprep.inf: this is an inject script action. It downloads a sysprep.inf(previously imported into the database) and copies it to c:\sysprep\sysprep.inf.Several of the actions below (HalConfig, CopyDrivers) modify sysprep.inf, thereforethis actions needs to precede them.2. Create tools folder: creates %TOOLS%3. Copy tools: copies tools from %SHARE%\tools to %TOOLS%4. Copy Drivers: runs following command line to copy machine specific drivers 16%TOOLS%\CopyDrivers /c5. Configure HAL: runs following command line 17%TOOLS%\HalConfig /cab=sp3.cab6. ldprep: runs following command line to enumerate drivers 18%TOOLS\ldprep /path=%DRIVERS%\PnP7. Inject mass storage drivers: runs following command line 19%TOOLS%\injectmsd8. Inject Provisioning Agent: this is the Configure Target OS action.If you are going to import and use this template, take note of the following:Configure the template variables as appropriate. The %SHARE%, %DRIVERS%and %TOOLS% variables are explained earlier in this section. You will also auser name and a password as variables.In the inject sysprep.inf action, specify a sysprep.inf that you have imported intoyour core server.This is a summary, not a cookbook. Read the relevant sections about theindividual tools before you start.16 Read section 3.1 on how to set up the file structure and control file (copydriver.ini) required bycopydrivers.17 Read section 5.3.2 before using halconfig.18 Read section 3.3.19 Injectmsd can only inject a mass storage driver previously captured by capturemsd. Read sections 4.2.2and 7.3 before using injectmsd.Hardware Independent Imaging Rev 9.1 Page 40 of 47

7. Reference7.1. HalConfig.exeHalconfig.exe is a compiled AutoIT script. Its help info (type HalConfig /?) is shownbelow.For further info, see section 5.3.3, HalConfig: advanced use.If you follow the conventions used in this document, HalConfig will create a log fileunder c:\drivers (see section 7.5). There is no need to specify the /log parameter unlessyou want the log created somewhere else.Hardware Independent Imaging Rev 9.1 Page 41 of 47

7.2. ldprep.exeLdPrep V1.7.1 by Jan Buelens, LANDesk SoftwareThis program automates driver enumeration in an OSD (OS Deployment) job.It removes the requirement to include an OemPnpDriversPath line in sysprep.inf,enumerating all the paths where the mini-setup is to look for drivers.There are 2 ways to use LdPrep:1. Run LdPrep (without command line parameters) after sysprep. LdPrep changesthe registry such that it will receive control again before the mini-setup.When using this mode:- Copy ldprep.exe to the sysprep folder- Include an LdprepDriversPath line in the [unattended] section ofsysprep.inf specifying the path to scan for drivers.2. Run LdPrep in WinPE. In the post-restore phase of the OSD job, run ldprepas per following example:ldprep /path=c:\driversCommand line parameters:/path=: path to be searched recursively for drivers; this must be thepath as visible to WinPE/h=: path to the file that stores the image's HKLM\Software file;default is c:\windows\system32\config\software/drive=: if the will have a different drive letter whenthe mini-setup runs, specify the drive letter as visible to mini-setup./test: show the paths that ldprep wants to add to DevicePath but don't writethem to the registry/s: silent/p: prepend rather than append inf paths/log=: change the default log fileIn contrast with previous versions, the /reg and /c are no longer required butthese parameters are still understood. If you use the new syntax (without /reg),don't use the reg load command.Previous versions of ldprep typically required the program to be used in a sequence ofcommands such as the following:REG load HKLM\Software c:\windows\system32\config\softwareldprep /c /reg=Software1 /path=c:\drivers\PnPREG unload HKLM\Software1This is no longer required. If windows is installed at c:\windows, ldprep can load theregistry hive without a prior reg load command. The 3 lines can now be replaced with thefollowing single line: ldprep /path=c:\drivers\PnP.If you follow the conventions used in this document, ldprep will create a log file underc:\drivers (see section 7.5). There is no need to specify the /log parameter unless youwant the log created somewhere else.Hardware Independent Imaging Rev 9.1 Page 42 of 47

7.3. CaptureMsd.exe, InjectMsd.exeCaptureMsd V1.1 by Jan Buelens, LANDesk SoftwareThis program collects info about the current machine's mass storage driver ina format that can be used in a Hardware Independent Imaging task. A companionprogram (InjectMsd), running under WinPE in the post-imaging phase of an OSD/Provisioning task, can use the files collected by CaptureMsd to inject thedriver.Command line parameters:/v : verbose (displays info about the drivers)/o= : to specify an output folder for the files collected; by default,files are written to the current directory.This program is not part of any LANDesk product and is not supported byLANDesk customer support. Consider it experimental.To conform with the conventions used in the document, copy the files collected byCaptureMsd to the msd subfolder of the machine specific driver folder (see Figure 15).Then, include an injectmsd command line in your OSD script or provisioning template.InjectMsd needs to know where to find the files captured by CaptureMsd (i.e. the "msdfolder"). If you use the conventions and pathnames of this document, InjectMsd will findthe msd folder without the need for a command line parameter 20 .20 The previous version of InjectMsd required a command line parameter. This version no longer does. Itwill find the msd folder if it is in its "usual" place, i.e. a subfolder called msd off the path specified by theDriversTarget parameter in copydrivers.ini (c:\drivers\msd if using the pathname conventions of thisdocument), whereby copydrivers.ini must exist in the folder from which InjectMsd was launched.Although you can specify the path as a command line parameter (e.g. injectmsd c:\drivers\msd), you areadvised not to. If you specify a path on the command line, injectmsd will complain if the path doesn't exist.If you don't specify a path and c:\drivers\msd does not exist, that is not considered an error.Hardware Independent Imaging Rev 9.1 Page 43 of 47

InjectMsd performs the following actions:1. If there are .inf files in the msd folder, it will copy them to c:\windows\inf.2. If there are .sys files in the msd folder, it will copy them toc:\windows\system32\drivers.3. If there is a subfolder called windows in the the msd folder, it will copy itrecursively to c:\windows.4. If there are .reg files, it will import them in the target's registry. This involves thefollowing steps for each .reg file:• A temporary copy is made of the .reg file• The temp file is modified; several substitutions are made, e.g.HKLM\Software is replaced with HKLM\Software1• The "reg load" command is used to mount the target's registry hives, e.g.the target's HKLM\System, which is assumed to reside inC:\Windows\System32\config\system, is mounted as HKLM\System1• The temp file is imported using the reg import command• The target's registry hives are unloadedAs you will understand from the above, you should run InjectMsd against a localfolder (probably copied by the CopyDrivers program), not against the master copyon a server.Although InjectMsd was designed to inject MSD drivers, it can also be used as a generalpurpose tool to import .reg files into the target OS while under PE.Note that InjectMsd can't inject a mass storage driver not previously captured byCaptureMsd 21 .If you follow the conventions used in this document, InjectMsd will create a log fileunder c:\drivers (see section 7.5). There is no need to specify the /log parameter unlessyou want the log created somewhere else.7.4. CopyDrivers.exeCopyDrivers uses the WMI model name to copy machine specific drivers from a sourcefolder on a server to a destination folder on the local machine.CopyDrivers reads out the local machine's WMI model name and uses a file calledcopydrivers.ini to map the WMI model to a machine specific driver folder.21 If you point injectmsd to a "raw" mass storage driver (typically a .sys + .inf + .cat file), it will copy theright files to the right places, but it will not make the registry changes necessary to install the driver. Thevital missing ingredient is the .reg file generated by CaptureMsd.Hardware Independent Imaging Rev 9.1 Page 44 of 47

[Config]DriversSource=\\Core88a\Provisioning\DriversDriversTarget=c:\drivers[Models]Precision Workstation T3400=Dell Precision T3400VMware Virtual Platform=VMWare_WorkstationPowerEdge 1950=Dell PowerEdge 19509071A1G=ThinkCenter M57p2007FVG=ThinkPad T6064575KG=Thinkpad T61pIn the [Models] section, each line associates one model name (left of the equal sign) witha subfolder name. Example: if the WMI model name is 2007FVG, the subfolder name isThinkPad T60. CopyDrivers appends this subfolder name to the base path defined by theDriversSource line in the [Config] section. CopyDrivers then copies this entire folder(\\Core88a\Provisioning\Drivers\ThinkPad T60 in the example) to a local folder on thetarget machine, as defined by the DriversTarget line (c:\drivers in the example).When matching WMI model names with lines in copydrivers.ini, CopyDrivers performswildcard comparsions. See section 3.1.1, Wildcard matching.When you invoke CopyDrivers without command line parameters, a little GUI programsopens that can be used to build or edit CopyDrivers.ini.Below is the usage info displayed when you type copydrivers /?Hardware Independent Imaging Rev 9.1 Page 45 of 47

The /s and /d parameters can be used to override the DriversSource and DriversTargetlines in copydrivers.ini 22 .CopyDrivers also provides support for drivers that require a setup program, as explainedin section 3.4. CopyDrivers looks for 2 files in the machine specific driver folder:cmdlines.txt and GuiRunonce.ini. These might have been built by the CopyDrivers GUI,or you might have built them manually.When you use the CopyDrivers GUI, there is no need to be aware of the format of thesefiles. Their format is as described in the sysprep documentation. Here is a smaplecmdlines.txt file:[cmdlines]"c:\drivers\setup\driver1\setup.exe""c:\drivers\setup\driver2\setup.exe"And here is a sample GuiRunonce.ini file:[GuiRunOnce]Command0="c:\drivers\setup\\driver1\setup.exe"Command1="c:\drivers\setup\\driver2\setup.exe"If your image is already using cmdlines and GuiRunOnce, the lines will be added to theexisting cmdlines.txt file or sysprep.inf [GuiRunOnce] section.If you follow the conventions used in this document, CopyDrivers will create a log fileunder c:\drivers (see section 7.5). There is no need to specify the /log parameter unlessyou want the log created somewhere else.7.5. DiagnosticsAll the tools discussed (with the exception of capturemsd) create a log file. If you followthe conventions and paths used in this document, the logs will be created in c:\drivers. Tobe more precise, they look for a copydrivers.ini file in the folder from which they arelaunched. If copydrivers.ini has a [Config] section with a DriversTarget parameter, thelogs are created in the folder specified by DriversTarget (which, in the examples given inthis document, is c:\drivers).If you want the logs created in a different place, use the /log command line parameters.22 If you used earlier versions of CopyDrivers, you may notice a syntax change. In the previous version,the syntax was /s (with a space following the /s), in this version it is /s=. Thechange was made for the sake of consistency with the other tools. The old syntax is still recognized.Hardware Independent Imaging Rev 9.1 Page 46 of 47

7.6. Files that come with this document:ldprep.exeCopyDrivers.au3: autoit source of CopyDrivers programCopyDrivers.exe: compiled version of aboveCaptureMsd.exeInjectMsd.au3InjectMsd.exeConfigHal.au3ConfigHal.exeHII.xtp: sample provisioning templateNeed to modify one of the compiled autoit scripts? You can download AutoIt fromhttp://www.autoitscript.com. It is freeware.Hardware Independent Imaging Rev 9.1 Page 47 of 47