Interesting title. I guess you can see my frustration with task sequences as they are used in BDD 2007. The Deployment Workbench is where the problem lies, especially in how it lets you screw up task sequences.
The task sequencing is a powerful feature of BDD 2007 (and SCCM 2007) and it definitely has its place. The problem comes with the way that DW lets you add items to it and how those items become "disconnected". Specifically, I'm talking about applications here.
I started out using the task sequence for my build to add in my custom applications that I wanted in my workstation/server images. The first application I tried would install just fine. It was only after I started to make changes that I noticed the issue. You see, I would make a change to the command-line in the Applications "table" in the Distribution Share section of the DW. Those changes would not get used by the task sequence. When DW adds the application to the task sequence, it copies the then-current command line to the TS.XML file and then that's it. Any changes to the application entry in DW do not get replicated over to the task sequences that use it.
The second issue comes with reboots. The application table allows you to specify that a particular application needs a reboot of the computer after installation. When you add this type of application to the task sequence, the reboot request is not part of that addition. If you need a reboot, you must manually add in a reboot task to the sequence. The task sequence quickly starts to lose some of its shine.
So, I took a giant step back and said to myself "what other way could I get applications to install on the system?" Well, the task sequence so conveniently has a call to the ZTIApplications.wsf script. This script processes that fancy applications table from the deployment share part of DW. It will correctly handle the reboots as well as command-line changes to application installs. Now, how to get my build computer to have applications assigned to it.
The applications are assigned via the CustomSettings.ini file. At first, I was adding them in manually. Unfortunately, you must know the GUID of the application that you want to install (which can only be found by manually reviewing the Applications.XML file in the CONTROL folder). Not fun.
I then moved on to using a database version of CustomSettings (where it looks everything up from a database). This way, I can use the DW GUI to manipulate the sequence of applications and pick from a list. I ended up creating a "role" that has the applications that I want installed in my image. I then assigned that role to my specific build computer. Now, when the computer is built, it gets the correct applications.
So, I recommend using roles wherever possible and avoiding making changes to the task sequence.
Okay, on with the continuing saga. So far, I've managed to get Windows PE 2.0 to recognize my "unique" network card. Now, when it boots into Windows Server 2003 after completing setup, I discover that the network card is no more. What happened?
Well, here's what happened. The script that copies drivers onto the hard drive has a unique method of operation that probably works fine in most cases, but not here. Here's how Microsoft's provided script works:
- On the destination computer, enumerate all plug and play device IDs into an XML file
- Enumerate through the PNP device IDs
- For each PNP ID, see if there is a match in the BDD Workbench list of Out-of-box drivers
- If there is a match, see if the driver belongs to one of the driver groups authorized for this computer (combination of the driver group specified in the Build configuration and the CustomSettings.ini)
- If all of that comes out positive, then copy the driver to the C:\Drivers directory on the destination computer and update the UNATTEND.TXT file.
So, here's my issue with that. As you may recall, my network card (the Broadcom NetXtreme II) uses multiple drivers. The first is a virtual bus driver which maps to a PNP PCI bus ID. Once loaded, this driver then establishes new "virtual" devices on the "virtual" bus which then would load the NDIS or iSCSI drivers. Since the PNP enumeration only happens once, it never sees these virtual devices and therefore never copies them down to the destination computer.
Another issue is what if I wanted to essentially pre-stage device drivers on the computer (such as when I'm making a multi-platform source image to be captured and then deployed)? BDD will copy down a named directory and add it to the computer (you must specify the directory in CustomSettings.ini and, I believe, manually update UNATTEND.TXT). That's great, but now I have to maintain the driver in multiple spots. The BDD Workbench isn't helping me out any here.
To work around this, I copied the ZTIDrivers.wsf file to ZTIDriversPreStage.wsf. I made a couple of quick modifications to it so that it would copy all drivers in the list of driver groups into the C:\Drivers directory.
First, comment out the PNP device enumeration sequence on lines 266 - 274. Add a line just below with the command FindMatch "XXX". This will call the FindMatch subroutine. Since we're going to modify that in a second, the PNP ID will become pointless (hence the XXX).
Scroll down to line 395 (in the FindMatch function) and change the If Instr(1, sPNPId, oPNPId.text, 1) > 0 then statement to If 1 = 1 then. This will bypass the PNP ID match and simply resort to driver group matching.
Finally, in my Task Sequence, I modified the two "Inject Drivers" tasks (Preinstall\Non-Replace Only and Postinstall) to use the ZTIDriversPreStage.wsf file.
After these modifications, the system found my unique network card and started it successfully (not to mention pre-staging all of the available device drivers for me).