Category: Deployment

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.

This article covers the first stage of using Altiris Deployment Solution to deploy Vista: creating the image with a 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.

On the Altiris Deployment Server, you specify your Vista volume license keys in the Global Options. Then, when you come to create an image, you check the box to use Sysprep and you have to select the OS and the product key. This is interesting. When you install Vista you do not need to supply a product key. The install DVD has a generic key that can be used for the build, or you can use none. However Altiris requires a key in order to create (not deploy) an image of the computer that is already running with a key.

When you run the Create Disk Image job, an unattend.xml file is copied to the computer and Sysprep is run, very quickly. Then the disk image is copied up to the server. The computer itself restarts and performs a silent Vista setup. So you now have two things: an image on the server and a re-setup imaging computer.

To see what has happened, you need to look first in %windir%system32sysprep at the unattend.xml file used to Generalize. In the Generalize pass there is only one option specified, PersistAllDeviceInstalls=false. This is the default setting anyway. This means that the driver selections are removed, and a new Plug and Play will be done in the Specialize pass when you deploy the image. In 6.8 SP2 Altiris flirted with an option to Persist the drivers, but this option has been removed in the current version 6.9.

In %windir%Panther you will see the unattend.xml file used to re-setup Vista on the imaging computer after being Generalized. It is the same as the unattend file in the sysprep folder. Altiris has hard coded into the xml the properties of the imaging computer: the name; network card MAC address and networking properties; registered organization and registered owner. This puts the imaging computer back to what it was, but is obviously going to have to be changed before you deploy the image to a different computer.

There is a new option in the Altiris Create Disk Image job, under Sysprep, to add drivers and to specify a path. When you check this box Altiris first copies the specified files into c:drivers on the imaging computer. Then it runs Sysrep but in Audit mode to install the drivers. Then it shuts down again to create the image with the new drivers.

Audit mode runs setup again, but without Windows Welcome, to enable you to add drivers and install software. There are two phases of Audit mode. In auditSystem the Administrator account is enabled and the system can run tasks. In auditUser the Administrator account is disabled again, and a user can log on to run tasks. The logic is that a deployment shop will create a generic image of Vista. They can then run it in Audit mode to add drivers for a specific model or for additional hardware. They can shut it down again and specify that the next restart will open in Windows Welcome for the end user.

The parameters for the Audit pass are in the unattend.xml file. Sysprep will add the path c:drivers as a Plug and Play path for the auditSystem pass. It has also asked the system to create an account called %RANDOMUSER% and set it to autologon once to do the work.

In the %windir%Panther setupact.log you can see what happened in Audit mode. First the random account. Next PnPUnattend.exe runs and installs the drivers that are in c:drivers. Then the system reboots for an auditUser pass, but there is nothing to do so Audit is complete. Sysprep runs again to shut the system down and Altiris creates an image.

Altiris Deployment Solution is an effective and versatile tool for OS deployment on a large scale. However it can be a confusing product to evaluate. This piece is about why and how to use Altiris for your Vista deployments.

If you just want to create and deploy images manually, you don’t need to buy anything at all. Windows Deployment Services (WDS) will do this. WDS is a powerful tool provided with Windows Server, and it has siblings like the Windows Automated Installation Kit (WAIK) and Business Desktop Deployment (BDD).

Microsoft provides a lightweight OS, WinPE, to manage the computer during imaging jobs. WinPE 2.1 is based on the kernel of Windows Server 2008, but it is only about 200MB in size. This means it can be loaded into memory and run from there to manipulate the hard disk where the full OS will be stored. Because it is in memory and not on the disk, it can partition and format the disk, create disk arrays and so on. The tasks do not have to be anything to do with imaging. It is just an OS running in RAM Disk. It has network drivers. It has a firewall. You could use it to surf the internet with Firefox. You could install it as a dual boot operating system on your PC or server.

ImageX (imagex.exe) is the tool Microsoft provides to create and deploy images: imagex.exe /capture to create, and imagex.exe /apply to deploy. Diskpart (diskpart.exe) is the tool Microsoft provides to manage partitions on the disk. So basically you have a collection of tools that can be used to manipulate images of the hard disk.

You could just run the tools manually. For example, you could have a USB stick with these tools on it. You could boot WinPE from the USB, run diskpart and imagex from the command line, and connect to a server on the network to download or save the image file.

To automate this, Microsoft provides a Pre-boot Execution service, PXE. If you tell the computer to boot from the network (press F12 at startup), it will connect automatically to the PXE service. This will display a list of options. It will first download WinPE, then boot into it and perform whatever task was selected. You still need to be physically at the computer to press the F12 key and to select the option.

The next tool is Sysprep (sysprep.exe). Sysprep is required to remove the unique identity of the computer when creating an image, and give the computer a new unique identity when the image is deployed. When creating the image you need to Generalize, and when deploying the image you need to Specialize.

Altiris Deployment Solution builds on or provides alternatives to all of these tools.

When a new computer first arrives, with WDS you would need to start it up, press F12, select the image to use from PXE, let it build and then take it to the user’s desk. You would need to give it a name manually, either as part of imaging or afterwards, otherwise it will have a randomized name that will be difficult to identify. This may be two or three hours of work.

With Altiris, the machine can go straight to the desk. When you press F12, the machine will connect to the Altiris version of PXE. It will download a small OS, install the Altiris agent for that OS, look to see if there is a job to run for this specific machine and run it. The machine is built. It joins the domain, renames itself with whatever name it has been given, installs the full Altiris agent in the new OS and is ready to go.

The Altiris PXE service is capable of providing several different OS’s to do the imaging work: DOS, Linux or WinPE. This is significant because WinPE is around 200MB, but a Linux kernel is about 10MB. Linux will download much faster to run the imaging job. Unlike DOS, Linux will run modern 32-bit network drivers and so pull down the image much faster. Neither WinPE nor Linux will multicast to a large group of machines, but Linux being much smaller will download to a large group of machines like a training room much more quickly.

After downloading a small OS, Altiris will install an agent in it. The Altiris agent is capable of telling the server who it is, and seeing if there is a job to run. There is one agent for the lightweight OS and another for the full OS. When the agent runs, it can tell the server what MAC address or what machine serial number it is. The server can see what job has been scheduled for this specific machine and download it to run. With new computers, the MAC addresses or serial numbers can be pre-loaded onto the server from a shipping note, and the appropriate job scheduled. Alternately Altiris can have a job defined that is run on any newly arrived machine.

Altiris provides their own tools for imaging. RDeploy (rdeploy.exe) will create or deploy an image file. It has versions for DOS, Linux and WinPE. The image file itself (.img) can be manipulated in the ImageExplorer, so you can add or remove files from the image offline. The agent (aclient.exe or dagent.exe) communicates with the server. FIRM is a file system independent resource manager that gives you access to the file system regardless of type (e.g. NTFS).

You can still use ImageX if you wish, but it will only run under WinPE. ImageX creates a wim file, which is the standard format on Vista and Server 2008 DVD. A wim file is a file-based image, which is to say that instead of sectors and bits from the disk it records the files. A 60GB disk with a 4GB OS will make a 60GB sector-based image but only a 4GB file-based image. The Altiris img format is also a file-based image, although you can choose to make a sector-based image. Wim does have one advantage. You can mount it (make it look like drive) and do offline servicing to add patches and service packs to the image without having to rebuild it.

Because the Altiris agent is communicating with the server during the imaging process, you can use variables to change the tasks according to the computer. For example with WDS, where you define the machine name, you have limited choices and in practice need to rename the computer manually afterwards. With Altiris you can use a variable in the sysprep xml file, and the server will put the correct machine name into the sysprep file before it runs.

With Sysprep you can set commands to execute during the build. For example you could run a task to install a utility or a driver. However with WDS this is hard coded into the sysprep file. With Altiris you could substitute different tasks for different models of computer. During the image deployment you could use FIRM to download the specific software to that machine.

When it comes to re-imaging a computer, with Altiris you don’t need to visit the desk at all. You can schedule a job for the computer on the server. The agent will connect in to the server, see there is a job and run it.

There are some other ways you can speed things up. You can create another partition on the computer and store the mini-OS there. As it is already local, this may as well be WinPE. Then when you come to run an imaging job there is no OS to download at all. It will boot to WinPE in the hidden partition. While you are at it, on some machines like in a training room you may as well store the image of the production OS on that partition. Then to rebuild there is nothing to download. It just boots to WinPE locally and deploys the image.