Category: Desktop

There are several different tools for installing drivers in Windows 7. This blog aims to describe them and show how they differ.

Driver installation tools for Windows 7:

• DISM
• DPInst
• DrvInst
• PnpEnum
• PnPUnattend
• PnPUtil

DISM

Deployment Image Servicing and Management (dism.exe) is the new tool for modifying Windows images. It replaces the individual tools that were introduced for Vista images. There is plenty of documentation about DISM.

DISM is a "framework" tool that gives access to different "providers". The DISM host itself controls things like logging and rebooting. The different providers do the work with their own command line options, called by the DISM host.

• CBSProvider (Component Based Servicing)
• OSProvider (OS updates)
• WIMProvider (handling the WIM file)
• SMIProvider (Settings Management)
• DMIProvider (Driver Management)

DISM is a tool for servicing both Online and Offline images. Dism /image:[path] refers to a mounted offline image. Dism /online refers to the current running image. However, you can not use DISM to add or remove drivers from an online Windows 7 image. The facility to do this does not exist. The commands /add-driver and /remove-driver apply only to offline images. When the image is Online:

• you can add and remove updates
• you can enable and disable features
• you can not add and remove drivers.

Servicing in Audit mode, with the image online, uses PnPUnattend, not DISM.

DPInst

Driver Package Installer (DPInst.exe) is part of the Driver Installer Framework (DIFx) provided to vendors to enable them to distribute drivers. DIFx gives vendors three tools of varying complexity to install drivers. The intention is that the user just clicks Run and is insulated from the method used.

• DPInst
• DIFxApp
• DIFxAPI

1. DPInst is a very simple installer. Put the inf and sys files together in a folder with a copy of DPInst.exe. Execute DPInst and the driver is imported into the Driver Store. By default, the tool searches the current directory and tries to install all driver packages found.
2. DIFxApp is a plug-in or extension to Windows Installer or InstallShield. It provides the actions that enable, for example, a Windows Installer msi to install drivers.
3. DIFxApi enables the vendor to write custom installers.

So by using DPInst you would effectively be authoring a driver installation package on behalf of the vendor. Why does Microsoft provide DPInst at all? Because it has simple features to enable a vendor to distribute a driver, including:

• localisation
• customisation of text, icons and bitmaps
• an option to add an EULA

It might be fun to use this to add drivers during deployment, but it is not what it is for.

DrvInst

DrvInst.exe is the Driver Installation Module of Windows 7. When Windows detects new hardware, DrvInst is the module that selects drivers from the Driver Store and sets up the driver for the hardware.

PnpEnum

PnPEnum.exe is a Microsoft utility that enumerates the Plug and Play hardware ID’s in a system. It is not part of the operating system. It is supplied as part of the Microsoft Platform Support Reporting tools. It is also part of Microsoft Deployment Toolkit (MDT).

In MDT 2010 it is used by the ZTIDrivers.wsf script as part of the task of importing drivers:

• PnpEnum.exe outputs the hardware ID’s in pnpenum.xml
• this is matched against the list of MDT Out-of-Box Drivers in drivers.xml
• matching drivers are copied to c:drivers
• c:drivers is defined as the Driver Path in the PnPCustomization component of WinPE or auditSystem.

PnPUnattend

PnPUnattend.exe is part of the operating system. During the auditSystem pass of setup (if there is one configured to run) it automatically imports drivers in the path defined in the unattend.xml PnpCustomizationsNonWinPE component.

This is specifically to install drivers from a path, unattended, as part of the Audit pass of setup. The command line options are: /s to search the driver path without importing; and /l to show logging information.

PnPUtil

PnPUtil.exe is part of the operating system. PnPUtil is a command-line tool to add and remove third party plug and play drivers. After Windows 7 is deployed, you can use PnPUtil to add or update specific drivers.

• PnPUtil -a imports the specified driver or drivers
• PnPutil -e lists the third party drivers that have already been added (but it does not provide a facility to pipe the output to a file)
• PnPUtil -d deletes the specified third party driver.

Importing a block of drivers into an image takes quite a bit of time. This is not important before deployment, but during deployment it can add many minutes to the imaging process. During deployment you really want a process to inspect the target computer and obtain just the drivers required for it. For this we need specialist tools. Microsoft Deployment Toolkit (MDT) 2010 does this. It is interesting to see how it does it.

In Microsoft Deployment Toolkit (MDT) 2010, open the Deployment Workbench and import drivers into the Out-of-Box Drivers folder.

You can also filter the drivers into Selection Profiles

In the Task Sequence, select the Preinstall action Inject Drivers

When we study the Setup methods and the unattend.xml syntax, there is no such thing as "Preinstall", and no component to "inject" drivers, so what is going on?

Here is what happens when you use the MDT Preinstall task sequence to inject drivers:

1. MDT uses its own tool PnpEnum.exe in the WinPE pass to:
• enumerate the hardware devices on the computer
• identify drivers for these devices in the Out-of-Box Drivers folder on the server
• copy them into a folder in the offline image, C:Drivers
2. Setup performs an Offline Servicing pass
• The folder C:Drivers is specified as the DriversPath In the PnPCustomizationWinPE component of the Offline Servicing Pass
• Deployment Image Servicing and Management (DISM) does its stuff to import the drivers
3. During the Specialize pass, Setup selects and installs drivers from the Driver Store as normal.

The DISM import process took 1 minute on a test VM, because only the required drivers were imported, not all the drivers in the Out-of-Box Drivers folder. Apart from that, the process is the same as the DISM process performed in Offline Servicing.

Here are the details of the process:

• The MDT scripted installation process running in WinPE executes the ZTIDrivers.wsf script
• ZTIDrivers runs PnpEnum.exe from the Deployment Share on the server. PnpEnum is an MDT tool that enumerates the hardware devices in the computer. The script pipes the output to a local file PnpEnum.xml.
• ZTIDrivers looks at the Selection Profile for this Task Sequence and finds the folders on the network with the drivers matching the profile.
• ZTIDrivers processes each hardware device in PnpEnum.xml and checks if there is a matching driver.
• If there is, the driver is copied to C:Drivers.
• The ZTIDrivers script ends.
• By default there is an offlineServicing pass, and if there are drivers in C:Drivers they will be imported.

So the trick that MDT has performed is to find only the required drivers, instead of a large block of drivers. The process of importing and selecting the drivers is exactly the same as if you had used Windows Deployment Services (WDS) with an unattend.xml file built with Windows System Image Manager (WSIM).

If you have only a few standard models of computer in the organisation then you can maintain specific Windows 7 images for each. But if you have many models you may want to be able to add or update drivers without capturing a new image.

This piece looks at the different ways you can add drivers, and what happens when you do.

You can add or remove drivers in two main ways:

1. Servicing the image as a file
2. Running Windows 7 in Audit mode.

You can do either of these at two different places in the deployment workflow:

1. On a base image, recapturing the image as an updated or customised version of the base before it is deployed anywhere
2. While deploying an image to a specific production computer.

This gives you four potential methods:

1. Servicing the image before deployment
2. Servicing the image during deployment
3. Running in Audit mode before deployment
4. Running in Audit mode during deployment.

First, a bit of background about how Windows 7 manages drivers. Windows 7 keeps a database of approved drivers in a special folder called the Driver Store. This folder has Full Control permissions only for System and Trusted Installer. Therefore the interactive sesson cannot write to it and a system process is needed to import drivers into it.

The processes involved in using a driver from the Driver Store are:

• Windows detects new hardware
• Windows selects the best match drivers in the Driver Store and sets up the hardware with the drivers.

The default Driver Store in Windows 7 has in the order of 650 sets of drivers.

1. Servicing before deployment

Before deployment the Windows 7 image exists as a file. The file can be opened and manipulated. Deployment Image Servicing and Management (DISM) is the new tool to do this. DISM is supplied as part of the Windows Automated Installation Kit (WAIK), which you set up on any deployment workstation or server. DISM mounts the image file (.wim) as a folder in Windows, giving you the opportunity to add files or edit the registry.

After mounting the image with dism /mount-wim, you add drivers to the driver store with dism /add-driver. You then commit the changes and unmount the image. Obviously you could do something like add a set of Dell drivers to a default image and commit it as a customised image for Dells.

Dism /add-driver reads each driver INF file provided in the command line and does the following:

1. Imports the driver package into a new folder in the Driver Store
2. Indexes the INF file as oem#nnn in the %SystemRoot%inf folder
3. For boot critical drivers only:
   • creates the registry keys in the offline registry hive
   • copies files into %SystemRoot%System32 and %SystemRoot%System32Drivers
   • copies files into %ProgramFiles%[Vendor].

Dism /add-driver does not run the DrvInst process to select the driver. This only happens online.

For three devices from one vendor this took 11 minutes. Now these drivers will be loaded on boot or evaluated by Plug and Play on hardware detection the same as if they had been shipped with Windows.

You can also use DISM to:

• enable or disable Windows features
• apply Windows updates (but not service packs)
• add or remove a language pack, and configure international settings

2. Servicing during deployment

You can modify the Windows 7 image after it is copied to the computer but before it boots by performing an Offline Servicing pass in Setup.

To add drivers during the Offline Servicing pass you need to configure the sysprep unattend.xml file.

To configure the file with Windows System Image Manager (WSIM), which is also part of the WAIK:

1. Open the Distribution Share.
2. Right click the Out-of-Box Drivers folder and select Insert Driver Path to Pass 2 offlineServicing. The required component is added to your unattend.xml file.
3. The path can be the Distribution Share, or it can be a folder in the image like C:Drivers, or both. If a network share, you can specify credentials.

Note that WSIM is just a GUI for editing the unattend. The Out-of-Box Drivers folder shown in the Distribution Share is a way of adding the correct path.

Here is what happens when you perform Setup with an offlineServicing pass:

• WinPE, after partitioning the disk and laying down the image file, moves into an offlineServicing pass and calls Deployment Image Servicing and Management (DISM)
• DISM imports the driver package from the Driver Path you specified into a folder in the Driver Store, in the same way as it does before deployment.

After the offlineServicing pass, Windows boots as normal into the Specialize pass where DrvInst is called to select matching drivers from the Driver Store based on driver ranking.

3. Audit mode before deployment

Another way to add or update drivers before deployment is to perform an Audit pass. The Audit pass is a way of booting Windows without completing the normal Windows Welcome to complete the setup. The difference between servicing an offline image and an Audit pass is that in Audit mode the OS is actually running. DISM before deployment will install drivers and updates, but it will not install user applications or service packs. You can do these things with an Audit pass.

Specifying an Audit pass instead of OOBE during capture of the base image

To add drivers automatically during the Audit pass you need to configure the sysprep unattend.xml file:

1. Open WSIM.
2. Right click the Out-of-Box Drivers folder and select Insert Driver Path to Pass 5 auditSystem. The required component is added to your unattend.xml file.
3. As with Offline Servicing, the path can be the Distribution Share, or it can be a folder in the image like C:Drivers, or both.

Here is what happens when you select an auditSystem pass and specify the Driver Path:

• Windows 7 boots into Audit mode
• Setup launches PnPUnattend.exe
• PnpUnattend imports the driver package into a folder in the Driver Store
• Indexes the INF file as oem#nnn in the %SystemRoot%inf folder
• Prompts the user for unsigned drivers
• At the end of the import, DrvInst runs to install drivers for detected hardware.

On a test VM this process took 9 minutes. You then need to run sysprep to generalize the image again before re-capturing it.

Note that in the Audit pass we used a similar component in the unattend as we did for offlineServicing but:

• In Offline Servicing setup used DISM
• In Offline Servicing setup does not run DrvInst to set up the hardware with the driver
• In Audit mode setup used PnpUnattend
• In Audit mode setup does run DrvInst to set up the hardware with the driver.

You can also use Audit mode to:

• install software
• apply service packs
• check that the image fully works.

4. Audit mode during deployment

You can also perform an Audit pass while deploying the image to its final destination computer, after Windows boots, but before OOBE. Once in Audit mode you can install drivers and software. The computer will remain in audit mode until you run sysprep /oobe /restart.

Obviously during deployment you want this all to be automatic. You can configure this in the unattend.xml:

• use the PnpCustomizationsNonWinPE component of the auditSystem pass to specify a Driver Path
• use the Deployment component of the auditUser pass to reseal at the end of Audit and reboot into OOBE

Setup will call PnpUnattend.exe to import the drivers in c:drivers into the Driver Store and then use DrvInst.exe to install them.

Summary

1. You can install drivers (and customize the Windows 7 image in other ways) before or during deployment.
2. You can use Offline Servicing or Audit mode at either time.
3. Offline Servicing uses DISM. Audit mode uses PnPUnattend.
4. The process of importing drivers into the Driver Store and selecting a driver to match a Plug and Play hardware device is the same in either case.
5. Importing drivers takes a significant amount of time. This does not matter before deployment. But during deployment you will want to minimise the number of drivers you import.
6. Offline Servicing and Audit mode use the same PnPCustomization xml in the unattend.xml file to specify a driver path for the additional drivers.

Time to deploy Windows 7. You take a look at your desktop and laptop inventory. Is it going to be easier to create an image for each model, or to create one image and to add the different drivers and components required for each model? Adding drivers sounds more efficient, but creating different images is more straightforward. What are the trade-offs? And what tools do you need? The more you think about it the less clear it can seem.

If you have a limited range of models, and you decide to create one image for each model, you can use Windows Deployment Services (WDS) alone to create and deploy the image. You will:

• Build your reference image
• Run Sysprep to generalize it
• Capture it
• Add an unattend.xml to automate the deployment
• Deploy it to the same make and model of computer.

However the default sysprep /generalize command during image capture strips out computer-specific information. This includes the device detection and driver selection information. In the sysprep /specialize pass during image deployment the computer re-runs the device detection and driver selection, and re-installs the drivers.

This adds minutes to each deployment. It can be a few minutes for a simple VM image, up to twenty minutes or more for a laptop. You can save a lot of time by using the sysprep option PersistAllDeviceInstalls in your Unattend to avoid stripping out and reloading the same drivers.

Here is the Unattend:

<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="generalize">
      <component name="Microsoft-Windows-PnpSysprep" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">
         <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
      </component>
   </settings>
</unattend>

This has to go into an Unattend file used during image capture, not image deployment. Using WDS you will need to add the custom unattend.xml file to the reference image and run sysprep at the command line instead of the GUI before shutting down and capturing the image.

Customizing the Generalize pass in WDS

This command line translates into the following:

• Run the Generalize pass now
• Run the Out of Box Experience when the computer next starts
• Shutdown instead of restart, so the image can be captured with WinPE
• Use the provided xml

This is just a small tweak to your workflow when using WDS to deploy images to the same make and model of computer. Don’t forget, you need to sysprep and capture an image that has not been joined to the domain.

In Microsoft Deployment Toolkit (MDT) 2010 the process of creating the reference image and capturing it is automated in a Task Sequence. However there is no opportunity to interrupt the task sequence to change the unattend.xml. Instead you modify the unattend file for the task sequence beforehand in the Workbench.

Select the OS Info in the Task Sequence

Edit the unattend.xml and save it

There is an option in the WDS Client (aka Windows Deployment Wizard) to Prepare to capture the machine, but stop before running sysprep. This would give you an opportunity to customise the image, including the unattend file.

But there is no option to resume the capture, so you would choose this option if you want to hand the image over to a different capture process.

If you want to perform completely unattended imaging, you need to change the computer so that it boots from the network when there is an imaging task. There are two ways you can do this:

• You can change the boot device order so that a network boot is tried first. This is changed in the BIOS setup.
• You can leave the boot order as it is but, when required, edit the boot configuration of the hard disk so there is no bootable partition. Then the boot sequence will fail through to the network.

Change the BIOS

Normally when the computer boots there is a BIOS option F12 to break out of the boot sequence and perform a network boot. The computer then looks for a PXE server on the network to download an OS into RAM disk and boot from that. Obviously you have to be at the computer to press the F12 key.

However if you press F2 to enter the BIOS setup you can change the boot device order to put the network boot first. When this is done, the computer will always first attempt a network boot. It will register itself with a PXE server and download a boot loader. This only takes a few seconds. The computer is then under the control of the boot loader program and can be told what to do next. It can:

1. Wait a few seconds for user input before continuing with a normal hard disk boot
2. Automatically proceed to download and boot from a boot image.

Being under the control of the PXE server provides the opportunity to automate the imaging task. However you need a server deployment tool that can make use of this. WDS and MDT do not do this.

To change the boot order you need to visit the computer. But if you are going to visit the computer you may as well do it when you re-image. And then you have no further need to change the boot order. So changing the boot order is really only relevant if you want to be able to perform unattended imaging of clients in the future. There are two ways you can set the boot order remotely.

You can push out a BIOS update to the computers. If the computers are one or two years old this may not be a bad idea. You can use the vendor’s tools to do this.

Here is an example of the HP BIOS update tools provided by Altiris.



And the equivalent for Dell.



Or you can use Intel vPro. The Active Management Technology (AMT) feature enables you to create a security context between computers at the BIOS or firmware level. Once this security context is created you can use it to manipulate the BIOS remotely. AMT is a seriously heavyweight feature that enables secure management of the computer before the OS is booted, "Out of Band". You can power on, take an inventory (e.g recognise which computer it is) and perform operations on the disk without booting. To do this you need an AMT Management tool.




Change the Boot Configuration

In Windows 7 the Boot Configuration is stored in the Boot Configuration Data Store. It is edited with BCDEdit. For fully automated imaging your deployment server can edit the boot configuration and then restart the computer to boot into an imaging task.

With Windows Deployment Services (WDS) and Microsoft Deployment Toolkit (MDT) 2010 we can deploy images to our target computers with minimal interaction. We can automate selecting a different image for different makes and models of computer. We can optionally add drivers, applications, updates and features. What more could we need?

WDS and MDT are free components from Microsoft. You can have an almost fully automated deployment service with just these tools. If you have a small number of makes and models of computer – say a standard desktop model and a few different types of laptop – then you can build a dedicated image for each. The technician presses F12 at boot, and selects the image to apply. The rest is automatic. If you have a diverse range of makes and models, you can use the driver detection in setup to select and install drivers.

You can use Group Policy to install applications and configurations; or you can install an agent and pass the computer on to the control of a software distribution system. The only constraint is that someone has to be at the computer to initiate the process.

However you can avoid visiting the computer at all if the BIOS is set to perform a network boot first in the boot order. You set this by entering the BIOS setup, and changing the boot order.

But:

• You need to have visited the computer to make this change
• You must already have a toolset that enables fully automated imaging.

When you set the computer to do a network boot first, it contacts the PXE server to obtain a Network Bootstrap Program. This tells the computer what to do next. By default it should time out if there is nothing to do and continue to boot from the hard disk. Otherwise it will begin the re-imaging job. With the WDS PXE Server:

• pxeboot.exe offers a prompt to press F12 again to continue
• pxeboot.n12 bypasses the second F12 and continues into a network boot
• abortpxe.com aborts the network boot and continues into a normal boot.

But to make use of this you need a deployment toolset that is capable of telling the computer what to do, based on an inventory of computers and jobs. If your computers are performing a network boot at present you already have this tool. And if they are not you would need to visit them anyway, to change the boot order.

The question then is whether as an organisation in future you want to be able to perform unattended imaging. If you do, then you need to both change the boot order on existing PC’s and adopt a deployment solution that enables it. If not, then you do not need a more complex deployment solution than WDS and MDT.

You skipped Vista. Now you plan to start deploying Windows 7. You face a blizzard of jargon and you feel you should know how it all works. But what technologies do you really need, and how can you make rational decisions when everything is so muddled?

Here are just some of the terms:

• DISM
• Driver injection
• DS
• HII
• ISO
• KMS
• Lite Touch
• MAK
• MDOP
• MDT
• OOBE
• PE
• PXE
• Sysprep
• TFTP
• Unattend
• WAIK
• WDS
• WIM
• WSIM

And these are just the current terms. How about RIS, SIF, BDD, PKGMGR, INF in previous versions?

The first thing to note is that you need hardly any of this to perform consistent automated deployment. Deployment covers a vast spectrum of use cases, and it is important to focus on exactly what you need to do. A school re-imaging computers between lessons has very different requirements from a hardware vendor shipping PC’s, so a lot of the tools and techniques simply are not relevant to your own requirements. Here is a minimum automated deployment toolset:

1. A USB drive with a bootable copy of the utility OS WinPE, and the network drivers for your make and model of PC
2. The program imagex.exe stored on the USB, to capture and deploy the image of a reference computer
3. Windows Automated Installation Kit (WAIK) on a technician’s workstation, to use Deployment Image Servicing and Management (DISM) to manipulate images and Windows System Image Manager (WSIM) to create unattend.xml files. WAIK is free, and it is a set of workstation tools, not a server product.

What else could we possibly need?

Well, firstly it is a bit uncontrolled to maintain copies of WinPE on USB drives, and images stored somewhere on the network. This will lead to people using different or wrong versions. If you have only one or two engineers you might be able to live with this, but otherwise you can automate the use of correct versions with Windows Deployment Services (WDS).

WDS provides a networking infrastructure to copy images down to the PC and up to the server. This includes copying the version of WinPE that you use to perform the imaging process, as well as the Window Image (WIM) file that contains the image of Windows 7. Using WDS means that you don’t need to maintain USB drives containing WinPE. When the PC starts, if you press F12 the PC will boot into a Pre-Execution Environment (PXE) stored on the network card itself. This enables the PC to contact the WDS server, through a DHCP advertising process. The WDS server responds by using Trivial File Transfer Protocol (TFTP) to copy a boot manager and a small file, boot.sdi, to the PC and this in turn will download and run WinPE. WinPE will run entirely in memory, as a RAM Disk, so that you are free to erase and re-partition the hard disk (or the SCSI array or whatever mass storage devices you have). WinPE will capture an image of a reference computer, or deploy a selected image to the PC.

Select the boot option F12

<

Press F12 again to start the PXE boot, and select the version of WinPE to use

In WDS you first add a Boot Image (which is WinPE) from the installation CD or ISO. If you boot to this version of WinPE it will automatically connect to the Deployment Server and offer you the images to install. You can also select an option to create a Capture Image. This one is also based on the WinPE Boot Image but contains a wizard to capture the image of the PC and load it up to the server. After you capture an image, it becomes available as one of the images to deploy.

Capture an image using the Capture version of WinPE

Deploy an image using the Boot version of WinPE

The aim here is just to show that WDS is a self contained tool capable of easily creating and deploying images. WDS is a role of Server 2008. It also provides the multicast functions so you can deploy images to many PC’s at the same time. Server 2008 R2 has some improvements to multicast.

As before, when using WDS you can automate the answers provided during setup by creating an unattend.xml file. The answer file is edited using WSIM, part of the WAIK. To use WSIM you first need to open and catalogue a Windows 7 image file. Then you can build an unattend.xml file with the attributes you want.

The custom answer file can be put in the image when you run Sysprep before capturing the image. Or you can open the captured image offline using the command line tool DISM, also part of the WAIK, and insert the file then. DISM also enables you to add drivers, updates, features and language packs to the image file.

The setup process with unattend.xml is an immensely powerful and flexible process. Every process taking place during the setup is controlled by sysprep.exe and unattend.xml. Because it has the ability to run executables and scripts it can do almost anything that can be done.

So now we have WAIK and WDS and we have an almost fully automated deployment process. What more could we want?

If you have a well organized PC estate with one or two current standard models of laptop and desktop then you don’t need many images, and you don’t need to create or edit them very often. In this case WAIK and WDS may well be sufficient. But there are cases where you may need more flexibility, for example:

• You have many different makes and models and you need to re-image them. Perhaps you don’t even have a good record of what models you have.
• You want to automate server builds and have a guided installation for different models and roles of server.

Microsoft Deployment Toolkit (MDT) 2010 provides a way to automate the workflow when imaging a computer so you can both standardize and cover more variation. MDT is another "toolkit" that sits on the technician’s workstation, but this time with a Deployment Share on a server where the resources (images, drivers, applications) are made available to the deployment process. MDT provides:

• A wizard-style dialogue when you run WinPE, before the imaging process itself
• The ability to skip any or all parts of the dialogue and provide a pre-defined answer or task sequence
• A database to store configuration plans for different makes and models or computer, or for a given computer identity, or for a selected role (e.g. Web Server).

These components (dialogue, pre-defined answers etc) are used to generate an unattend.xml file dynamically, and setup then runs with this.

The scripts that operate the process

The dialogue in WinPE

The settings that control the dialogue

The pre-defined Task Sequences that automate sections of the process

The database to store configuration plans

MDT sits in a slightly confusing relationship to the other tools. You don’t need WDS to use MDT. You don’t need MDT to use WDS. MDT creates a deployment share, and you can use a USB Drive with WinPE to connect to it. WDS is just about the transfer process between client and server. If you do use WDS with MDT, you need to copy the MDT version of WinPE into the WDS directory, and then it uses the OS images in the MDT directory. You don’t need the WAIK with MDT, because the process of creating the unattend.xml at runtime replaces having a sophisticated editing tool for a static unattend.xml. You also don’t need the DISM because the MDT adds drivers, updates, features and applications also at runtime. But you can certainly use parts of all three components in the same imaging workflow.

This article covers the second stage of using Altiris Deployment Solution to deploy Vista: deploying an image with the default sysprep process.

Sysprep is the tool provided with Vista to enable you to prepare a new computer for deployment. It is the only supported way of doing this. Altiris Deployment Solution uses Sysprep. However it does it behind the scenes. If you want to change the process, you need to understand a bit about what Altiris is doing, and a bit about how Sysprep works.

First we do a simple Distribute Disk Image job and check the box "Prepared using Sysprep". This is a strange title for a checkbox. If the image was prepared using Sysprep there is nothing you can do about it now. You can’t un-sysprep it. It is going to open and perform the next step specified when it was sysprepped before imaging.

If you don’t check this box, the image will be deployed and Setup will run using the unattend.xml put there when the image was created. But this xml was intended to put the imaging computer back to where it started. It has the name of the computer hard coded into the xml. When you check this box, you tell Altiris to replace the xml of the imaging computer with custom xml for the target computer.

The computer starts, copies down the image and the new unattend.xml file, boots into Windows Setup and ends with a logon screen ready to go.

If you look in %windir%system32sysprep at the unattend.xml you will see that it has the computer name and networking properties of the computer the image came from. This is the unattend used for the Generalize pass. But if you look in %windir%Panther at the unattend.xml used to set up the new computer, you can see that the computer name and the networking properties (including MAC address on the network card) have been replaced with the properties of the target computer. The custom unattend file has been written into the image by Altiris using the imaging OS (Linux or WinPE) before the Vista setup runs.

By default in a Distribute Disk Image job the box is checked to "Automatically perform configuration task after completing this imaging task". The configuration task modifies the target computer to match what is given in the Deployment console. For example, if the new computer in the console is configured to be a domain member, the Altiris configuration task will join the computer to the domain. For Vista, Altiris recommend not checking this box. Instead, configuration is run as a separate task after the image deployment is complete.