After my previous blog about integrating mass storage drivers into Windows PE I have a number of requests about how to the same integrate drivers into XP their XP images. So here we go...

The key point to note about integrating mass storage drivers into your current XP image that that these must be integrated when the client is syspreped. You cannot add drivers to an image after it has been created. (This is a limitation of XP that is now solved with Vista).The rest of this post will detail how to integrate the Intel mass storage drivers into your image.

Download the drivers

The first part of the configuration process is the obtaining of the Mass Storage drivers. The drivers must be downloaded from the hardware vendor. The latest version of the Intel driver is located here.

Gather the Plug and Play ID’s

Once you have downloaded the driver you must identify the PnP ID's and the INF file that matches each PnP ID.

When you download a driver you will find that will include one or more INF files. These INF files will include the PnP ID's that it supports.

The Intel driver comprises of two INF files, IAAHCI.INF and IASTOR.INF, the lines in these files that identify the PnP ID's are listed below.

IAAHCI.INF

[ControlFlags]

ExcludeFromSelect=PCI\VEN_8086&DEV_2652&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_2653&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_27C1&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_27C5&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_2681&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_2821&CC_0106

ExcludeFromSelect=PCI\VEN_8086&DEV_2829&CC_0106

IASTOR.INF

[ControlFlags]

ExcludeFromSelect=PCI\VEN_8086&DEV_282A&CC_0104

ExcludeFromSelect=PCI\VEN_8086&DEV_2822&CC_0104

ExcludeFromSelect=PCI\VEN_8086&DEV_27C6&CC_0104

ExcludeFromSelect=PCI\VEN_8086&DEV_2682&CC_0104

ExcludeFromSelect=PCI\VEN_8086&DEV_27C3&CC_0104

ExcludeFromSelect=PCI\VEN_8086&DEV_2652&CC_0104

Copy the driver files

To automatically integrate the driver files into Windows XP a folder structure must be created to support the added files. These folders will then be referenced by the sysprep.inf file.

To create the folder structure

     1. Create the folder structure, .\Distribution\Control\<BUILDID>\$OEM$\$1\Drivers\IASTOR

Note <BUILDID> should be the Build ID of the build that is used to create your image.

     2. Copy the driver files previously downloaded into the newly created IASTOR folder.

Note  if you already use the $OEM$ functionality then simply add the files into the current folder structure.

Update the sysprep.inf file

Now that we have downloaded the drivers, created the supporting folder structure and identified the PnP ID’s for the mass storage driver we must update the sysprep.inf file used to create the master image.

To update the sysprep.inf file

     1. Open the ..\Distribution\Control\<BUILDID>\sysprep.inf file using Notepad.

Note <BUILDID> should be updated to be the Build ID of the build that is used to create your image.

     2. Update the BuildMassStorageSection entry in the  [Sysprep] section to equal YES.

     3. Update the [SysprepMassStorage] section to specify each PnP ID and it's corresponding INF file.

Note   This will require translating the information gathered from the INF files into the sysprep.inf format.

For example, the ExcludeFromSelect=PCI\VEN_8086&DEV_282A&CC_0104 gathered from the IASTOR.INF file would translate to PCI\VEN_8086&DEV_282A&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF".

The following excerpt provides an example of the updated sysprep.inf file.

[Sysprep]

BuildMassStorageSection = YES

[SysprepMassStorage]

PCI\VEN_8086&DEV_2652&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_2653&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_27C1&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_27C5&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_2681&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_2821&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_2829&CC_0106="C:\DRIVERS\IASTOR\IAAHCI.INF"

PCI\VEN_8086&DEV_282A&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

PCI\VEN_8086&DEV_2822&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

PCI\VEN_8086&DEV_27C6&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

PCI\VEN_8086&DEV_2682&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

PCI\VEN_8086&DEV_27C3&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

PCI\VEN_8086&DEV_2652&CC_0104="C:\DRIVERS\IASTOR\IASTOR.INF"

Recreate the Image

Once you have performed all of these tasks you must rebuild your image then sysprep and capture it. This is a bit of a hassle I know, but there is another solution, use Vista!

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Everytime Intel releases a new mass storage chipset I receive the same call/email from from most of my customers and it goes something like this:

"Hi Ben, I have just got a new machine and I can't deploy an image to it, do you know what is going on?"

The problem they are having is that their Windows PE does not support this new chipset. The new drivers must be integrated into the Windows PE source they are using. This is not an issue for Windows PE 2.0 as BDD 2007 will automatically integrate the drivers for you. But with Windows PE 2004/2005 you must integrate the drivers yourself. 

Well a new Intel mass storage chipset seems to have appeared so I though I might put my recommendations here to preempt the calls. These recomendations use the new Intel  chipset bas an example but can also be applied to any other mass storage driver.  This blog entry specifically recommends how to integrate drivers into Windows PE 2004/2005 using BDD 2007.

Mass Storage drivers consist of a .SYS file that Windows PE references via the txtsetup.sif file. In order to integrate the driver into Windows PE we must identify the .SYS file that the driver uses and the additions that must be added to the txtsetup.sif file. The file that provides this information is the txtsetup.oem file that is shipped with the driver.

The following steps should be followed to integrate a new Mass Storage driver into a Windows PE 2004/2005 source:

Download the drivers

The first part of the configuration process is the obtaining of the Mass Storage drivers. The drivers must be downloaded from the hardware vendor. The driver must include a txtsetup.oem file. The latest version of the Intel driver is located here. The version must match the Operating System that Windows PE is based on, for example:

Windows PE 2004 - Windows XP

Windows PE 2005 - Windows 2003 

Identify the .SYS file

Once the drivers have been downloaded the .SYS file must be identified.

To identify the .SYS file

1. Open the txtsetup.oem file downloaded in the previous section.

2. Locate the [Disks] section, and record the name of the .SYS file specified in that section.

The following excerpt from a txtsetup.oem file clearly identifies the .SYS file (iastor.sys).

     [Disks]

     disk1 = "Intel Matrix Storage Manager driver", iaStor.sys, \

Gather the Plug and Play ID’s

The PnP identifiers for the driver must now be identified. These drivers are of the form PCI\<PnP ID>.

To identify the PnP ID’s

1. Open the txtsetup.oem file downloaded in the previous section.

2. Locate all lines that contain PnP ID’s, and record their values.

The following excerpt provides an example of the PnP ID’s extracted from and Intel Mass Storage driver txtsetup.oem file.

     id = "PCI\VEN_8086&DEV_2922&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_282A&CC_0104","iaStor"

     id = "PCI\VEN_8086&DEV_2829&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_2822&CC_0104","iaStor"

     id = "PCI\VEN_8086&DEV_2821&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_2682&CC_0104","iaStor"

     id = "PCI\VEN_8086&DEV_2681&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_27C3&CC_0104","iaStor"

     id = "PCI\VEN_8086&DEV_27C6&CC_0104","iaStor"

     id = "PCI\VEN_8086&DEV_27C1&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_27C5&CC_0106","iaStor"

     id = "PCI\VEN_8086&DEV_2653&CC_0106","iaStor"

Copy the driver files

To automatically integrate the driver files into Windows PE a folder structure must be created to support the added files.

To create the folder structure

1. Create the folder structure, .\Distribution\Extra Files\i386\System32\Drivers

2. Copy the .SYS file into the newly created Drivers folder.

3. Copy the txtsetup.sif file located in the Windows Source\i386 folder for the ZTI deployment point. (i.e. .\Distribution\Windows 2003 SP1\i386) to the folder .\Distribution\Extra Files\i386.

Note  if you already use the extra files functionality then simply add the files into the current folder structure.

Update the txtsetup.sif file

Now that we have identified the .SYS file and the PnP ID’s for the Mass Storage driver we can update the txtsetup.sif file.

To update the txtsetup.sif file

1. Open the file .\Distribution\Extra Files\txtsetup.sif file using Notepad.

2. Update the [HardwareIdsDatabase] section to specify each PnP ID.

Note   This will require translating the information gathered from the txtsetup.sif file into the txtsetup.sif format. For example:

     id ="PCI\VEN_8086&DEV_2822&CC_0104","iaStor" would translate to PCI\VEN_8086&DEV_282A&CC_0104="iastor".

The following excerpt provides an example of the PnP ID’s extracted from the Intel Mass Storage driver txtsetup.oem file and translated into the txtsetup.sif format.

     PCI\VEN_8086&DEV_282A&CC_0104="iastor"

     PCI\VEN_8086&DEV_2829&CC_0106="iastor"

     PCI\VEN_8086&DEV_2822&CC_0104="iastor"

     PCI\VEN_8086&DEV_2821&CC_0106="iastor"

     PCI\VEN_8086&DEV_2682&CC_0104="iastor"

     PCI\VEN_8086&DEV_2681&CC_0106="iastor"

     PCI\VEN_8086&DEV_27C3&CC_0104="iastor"

     PCI\VEN_8086&DEV_27C6&CC_0104="iastor"

     PCI\VEN_8086&DEV_27C1&CC_0106="iastor"

     PCI\VEN_8086&DEV_27C5&CC_0106="iastor"

     PCI\VEN_8086&DEV_2652&CC_0104="iastor"

     PCI\VEN_8086&DEV_2652&CC_0106="iastor

     PCI\VEN_8086&DEV_2653&CC_0106="iastor"

3. Update the [SCSI.Load] section to identify the .SYS file. This should be in the format DriverName = FileName.sys,4

The following excerpt provides an example of the .SYS file information as it has been added into the txtsetup.sif file.

     iaStor = iaStor.sys,4

Note   The DriverName value must match the value specified in the HardwareIdsDatabase section. For example if the value is PCI\VEN_8086&DEV_2652&CC_0106="iastor" then the DriverName must be iastor.

Update the deployment point

Once the drivers have been setup we must then update the deployment point to create the updated Windows PE source files.

To update Windows PE

1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

2. Click Deploy, right-click Deployment Points, and then click Image Distribution Deployment Point.

3. Click the Windows PE 2004/2005 tab.

4. Set the Extra Directory to Add to that of the extra files location created in the previous step. (i.e. D:\BDD\Distribution\Extra Files)

5. Right-click the newly created ZTI deployment point, and then click Update to force it to create the ZTI directory on the file system and generate the Windows PE source files.

Update Windows PE in the SMS 2003 OSD Feature Pack

To update SMS with the new Windows PE source files (created in the Deployment Workbench), complete the following steps:

1. From the SMS Administrator console, locate Site Database, then expand Image Packages.

2. Right-click Images Packages, point to All Tasks, and then click Update Windows PE.

3. In the Update Windows PE Wizard, click Next.

4. Browse to the generic Windows PE source folder (DistributionPoint\boot\source), click Open, and then click Next.

5. Click Finish when the update is completed.

Once you have completed all of the steps above then you simply need to re-create any SMS OSD Deployment CD's you may be using and update your OSD packages and the process is complete, EASY ;)

 UPDATE: For information on integrating these drivers into an XP image please refer to the following blog:

          http://blogs.technet.com/benhunter/archive/2007/07/12/bdd-2007-integrating-mass-storage-drivers-into-your-xp-image.aspx

If you are looking for further information then the following article by Johan is a great place to start:

http://www.deployvista.com/Blog/tabid/70/EntryID/18/Default.aspx

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I am often asked how I install and configure BDD 2007.

So I thought now was a good time to detail at a high level the process I go through to create and deploy operating system images using BDD 2007. This is not a step by step guide but more of a rant about how I do BDD and the reasons why.

The first thing I must say is that this is just my way of doing installing BDD. And I am sure that there are many people using BDD in different ways, which may well be better than mine. BDD is a very flexible framework and allows many ways to perform these tasks.

If you have any other suggestions about how to install BDD then I would love to hear from you. (I always like new ideas!)

So here we go....

I have broken the configuration process into a number of steps. Each step in the process is detailed in the flowchart below:  

So let’s go through each of these steps in more detail.

Install BDD 

Installing BDD is very simple, the steps I follow are listed below:

1. The first thing I do when installing BDD is install the prerequisites. This includes the WAIK and MS XML. These can be installed from within the BDD Workbench but I install them manually beforehand.
2. I then install BDD. I usually locate the distribution folder within a folder on D drive (or whatever drive is available) called BDD. I then use this folder to store all other BDD related folders. (this keeps things nice and tidy:)). For example I tend to create the distribution folder in D:\BDD\Distribution.

TIP - Make sure you are using BDD patch 1 as this includes a number of fixes.

Import Source Files

Before I talk about importing source files it is best to discuss my philosophy when creating images. I believe that the process you use to create your images should be fully automated (where possible) and easily repeatable. I NEVER build an image manually. Let me put this another way, the scenarios where you would need manually create your image are very rare and should be avoided.

One of the major strengths of BDD is its ability to fully automate the image creation process. If you want an image that is easy to recreate and manage then BDD is the tool for you.

A good example of why you should use BDD rather than manually building an image illustrated by image patching. Let’s say you manually created your image six months ago and now you want to update the image with extra patches. With BDD you would simply update your build task sequence and recreate your image, EASY. If you manually created your image you could take one of two approaches:

1. You could manually recreate your build and then add the patches. 
2. Deploy the image, manually update it with the latest patches and then recapture the image.

Neither of these approaches is recommended. The first will most likely introduce inconsistencies as it is very hard to create a repeatable image when you are doing it manually. The second process is BAD as you should not sysprep an image multiple times.

So with that rant out of the way let see how I import the required source files.

I import all of the files that will be used in the image creation and deployment process. These Source files are divided into four distinct groups:

• Operating Systems - Any operating system source files used during deployment. This can include Vista source files or even Windows PE 2004/2005 if you are deploying images using SMS.
• Applications - I use the applications option to import more than just applications. I create an application to for every task that I want to perform with BDD, from installing office to removing unwanted shortcuts from the start menu. By doing this I can easily keep a track of the tasks I have created and reuse them across multiple builds.
• OS Packages - If I am deploying Vista then I import language packs and patches. BDD will then integrate these automatically during deployment.
• Drivers - I import the drivers required drivers for each hardware model I will deploy. If I need to use driver groups then I import the drivers using the PowerShell scripts from my previous post here. 

TIP - Create a naming standard that clearly identifies applications. This makes management easier particularly as the number of applications increase. I like to apply a prefix to each application that defines its purpose. For example an application used to install Office 2007 would be called “INSTALL-Office 2007” and an application used to configure the sound scheme would be called “CONFIG-Sound Scheme”.

Create an "Image Creation" Build

A Build binds together a number of components, source files, configuration settings and the installation process (task sequence) defining how to create an image.  With this in mind let’s detail how I create a master image.

1. I create a Build using the New Build Wizard, specifying the operating system imported in the previous step.
2. I then add all of the applications that I want include in the image to the task sequence state restore phase.

Easy huh? It is really that simple. Of course you need to test the installation process and you are unlikely to get it right first time but it really is that easy.

The key point is that I always add the applications to the task sequence; I do not select them during deployment using the wizard. Using this method gives you control over when applications install. It also allows you to control when reboots occur.

TIP: Changes made to applications after they have been added to a task sequence are not propagated to the task sequence. So if you make a change then the best approach is to simply remove the application from the task sequence and add it again. The changes will then be applied to the build.

TIP: If the Master Image is to be deployed by SMS then make sure that you include the SMS client in the build.

Create and Capture master image

Now that I have created a build that defines how to create an image we need to execute the build and capture the image.

The first step in this process is the configuration of the Lab deployment.

1. Configure the deployment point to automate the build process. I tend to to update the deployment point rules so that the only questions I am asked are the capture method and the build I want to execute.
2. Ensure that the deployment point has been updated using the "Update" option (not "update (files only)").

Once the deployment point is configured we can capture the image. 

1. Boot to the LiteTouch_x86 image created - I tend to load the image onto a USB stick and boot from there but you could also use a Windows DS server or cut the image to a CD/DVD.
2. From the Lite Touch Wizard I select the build I just created.
3. From the Lite Touch Wizard I select the capture type. If it is SMS then I select prepare, for LTI deployments I select yes and specify where the image will be saved. The image will now begin to build.
4. If we specified the capture to be LTI then the image will be captured automatically. However if the image is to be deployed using SMS then the final step in the process is to capture the image using the SMS capture CD.
5. Once the image has been captured I then import it into the deployment workbench as a “Custom WIM”.

TIP: Instructions detailing how to fully automate the BDD Lite Touch Wizard are included in the "Configuration reference" document  included with BDD 2007. (Hint: look at the last two pages)

Create an "image deployment" build

One aspect of BDD that causes a lot of confusion is the purpose of Builds. Particularly as builds can be use to both create and deploy images. I prefer to think of builds is as task sequence that controls the execution of a series of scripts which has an operating system and settings associated with it. Task sequences can be used to control the deployment of an image or create an operating system image from scratch.

NOTE: The next version of BDD will no longer refer to builds; instead it makes the task sequence the center of the image creation process.

So with this in mind I create a build that is used to deploy the master image:

1. Create a build using the New Build Wizard specifying the operating system image I imported in the previous step.
2. I then update the task sequence adding the customizations required during deployment such as my SMS GUID reuse script (detailed in a previous post).

TIP: To avoid confusion over the purpose of each build use a naming convention that clearly identifies the builds purpose. For example a build that is used to create a master image could be called “Create-Master Image” and a build used to deploy the image could be called “Deploy-Master Image”.

Deploy the Image

The last thing we need to do is deploy the image we have created. While deployment methods can vary depending on the situation from using SMS to deploying via DVD or directly from BDD itself the overall principles remain the same.

I NEVER deploy an image using the lab deployment point. I always create another deployment point to deploy the image. If I am not using SMS OSD then I will create a Separate deployment point (Network) to deploy the image. This approach allows granular control over the rules used to deploy the image.

I always create a deployment process that is as automated as possible. This is achieved using rules to define values for BDD deployment properties. Where possible I use the BDD Database to define values for properties but I also use UserExit scripts and static assignment when required. Very occasionally I will prompt the user for information if required.

When deploying an image you need to ensure that the correct drivers and applications are applied during deployment. BDD manages the application of drivers for you but extra effort is required to manage hardware specific applications. To address this issue I import each application into the BDD Workbench and then associate it with the appropriate hardware type using the BDD database.

So here are the steps I follow to deploy the image:

1. Create a Deployment Point to deploy the image
2. Configure the Deployment Point with the rules required to automate the deployment process
3. Configure the BDD database
4. Create a database entry for each model type.
5. Create a database entry for each computer
6. Deploy the image.... NICE!

TIP: For further information on rules please refer to my previous post here.

TIP: For further information on prompting users for information during deployment then refer to my previous posts here and here and Johan’s post.

So that is how I create and deploy images using BDD. Low on detail and high on opinion I know, but this is an approach that I have found to be very successful. Hopefully you will be able to use some of these methods to make your deployments equally successful.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Before you can troubleshoot BDD 2007 you need to clearly understand the many logs used during an OS deployment.

If you understand what log to refer to and at what time you will find things that where once mysterious become understandable.

With this in mind I thought I would provide this quick guide to BDD logs.

BDD scripts automatically create log files. Each script creates a log file that matches the name of the script, for example ZTIGather.wsf creates a log file named ZTIGather.log. Each script also updates a common log file (BDD.log) that aggregates the contents of logs created by the BDD scripts.  BDD logs are located in the C:\MININT\SMSOSD\OSDLOGS folder during the deployment process. They are then moved at the completion of a deployment, their destination is dependent on the deployment type:

• Lite Touch -  C:\WINDOWS\TEMP\BDDLogs unless the /debug:true option has been specified.
• Zero Touch - C:\TEMP\SMSOSD or C:\SMSOSD unless the C:\MININT\Archive_OSD.SMS file is found.

The BDD.log file is also copied to a network location at the end of the deployment if the SLShare value is specified in the Customsettings.ini.

The BDD log format is designed to be read by TRACE32, part of the SMS 2003 Toolkit 2 - download here. I would strongly recommend that you use this tool whenever possible to read the logs as it makes finding errors much easier.

The rest of this blog details the log files that are created during the deployment and examples of when they can be used when troubleshooting.

BDD logs

Bdd.log - The aggreated BDD log file.

<Scriptname>.log - A log file created by each BDD script.

Wizard.log -  Updated by BDD wizards.

DeployUpdates_platform.log - Created when deployment points are updated. Also used when updating Windows PE. Useful when troubleshooting Windows PE driver integration issues. This log is located in the %temp% folder.

SMSTS.log - Logs all of the transactions for the Task Sequencer. This will be located in %TEMP%, C:\Windows\System32\ccm\logs, or C:\SMSTSLog, depending on the situation.

WPEinit.log - Logs the Windows PE intialisation process - Useful for troubleshooting error starting windows PE

USMT Logs

BDD 2007 automatically adds the logging switches to save the USMT logs to the BDD log file location

USMTEstimate.log - Log created when estimating the USMT requirements

USMTCapture.log - Log created when capturing data

USMTRestore.log - Log created when restoring data

Windows setup logs

Vista

This is a subset of the log files that are most useful for troubleshooting deployment issues, for more detailed information about Vista setup log files refer to this KB - http://support.microsoft.com/kb/927521.

setupapi.dev.log - Windows setup log, located in C:\Windows\inf - Useful for investigating failed Driver installations.

setupact.log - Windows setup log, located in C:\Windows\panther -  Useful for investigating failed installations.

setuperr.log - Windows setup log, located in C:\Windows\panther - contains a list of errors that occurred during installation.

netsetup.log - Windows setup log, located in C:\Windows\Debug - useful for troubleshooting domain join issues.

XP

setupapi.log - Windows setup log, located in C:\Windows - record inf installation actions - useful for investigating failed driver installations.

setupact.log - Windows setup log, located in C:\Windows - Lists installation actions.

setuperr.log - Windows setup log, located in C:\Windows - Details installation errors.

netsetup.log - Windows setup log, located in C:\Windows\Debug, useful for troubleshooting domain join issues.

OSD logs

The following logs are created during the deployment phases, these logs are located in the C:\MININT\SMSOSD\OSDLOGS folder:

OSDAgent.log - This is the primary log and should be the first place you look to determine what step failed

OSDEnv.log - Indicates which OSD environment variables are set

OSDInstallWIM.log - Logs image installation options

IDUser.log - User notification log

IDUserNotification.log - User notification log

MachineState.log - Logs computer state migration information (computer name, IP Address, Registered Owner/Org

WinPEInstall.log - WinPE installation information

Exec.log - Logs ‘Run SWD Program’ actions

scanstate.log - USMT scanstate log

OSDLaunch.log - OSD Bootstrap - May contain errors if the Advanced Client Network Access account is not configured correctly.

SMSCMT.log - Logs SMS Client migration information (site code, client GUIID)

WinPEInstall.log -Windows PE installation information.

OSDInstallWizard.log - Logs start-up operations.

OSDShell.log - Launches the OSD Install Wizard.

OSDSWDProgramExec.log – Logs Run SWD Program Actions.

OSDUsmtScanstate.log – Logs Capture User State operations

OSDUsmtLoadstate.log - Logs Restore User State operations

OSDBootstrap.log - May contain errors if the Advanced Client Network Access account is not configured correctly.

Note: The C:\minint folder is lost during the disk partitioning process. If you need to trobleshoot issues that occur before this point then disable the disk partitioning task in the task sequencer.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

To truly unleash the potential of BDD 2007 you must first understand the concept of rule processing.

A rule is used to define the variables that drive the entire imaging process. They are used to define properties such as the computer name, the local administrator password, or how user data should be saved during an image deployment.

There are a number of methods by which rules can be used to define variables. The following sections review these methods and how to best use them to customize BDD 2007.

Rule processing overview

Before you look at how to define rules it is important to understand how BDD processes rules.

The values that BDD obtains from rules are called “properties”. Properties are similar to environment variables, and once defined can be used by all other scripts. There are two types of properties:

1. Standard properties – Default properties defined within BDD

2. Custom properties – Properties you can define and assign as required

Note: Properties can be single valued or lists

BDD uses a gathering mechanism to determine the values of the properties. It does this by running the script “ZTIGather.wsf”. The script performs the following steps:

1. Determines the standard properties by referring to the standard properties definition file “ZTIGather.xml”.

2. Parses the “CustomSettings.ini” file and determines what custom properties it should use.

3. The “CustomSettings.ini” file is then processed to gather values for all of the properties required to deploy the operating system to the client.

The rest of the post will explain how the rule gathering process works for each of the assignment methods.

Assigning values through rules

Values can be assigned to properties through a number of different methods.

1. You can use hard-coded values, for example you could statically define the logging share (SLShare) to point at the share “LOGS” on “SERVER”:

SLShare=\\SERVER\LOGS

2. You can use variable substitution, for example you could statically define your logging share (SLShare) to point at the share “LOGS” on the SMS deployment point that you are currently connected to:

SLShare=\\%SMSDP%\Logs

3. Rules can call script functions, for example you may want to assign the ComputerName based on information gathered from the Asset Tag, functions are recognized as being enclosed in “#”’s:

ComputerName=#MyFunction(‘%AssetTag%’)#

(See the Userexit script section below for further information)

4. Rules can be selected based on the value of dynamic keys, the following example will return the computer name “Computer1” if the MAC Address is “00:01:AB:34:CD:02”

[Settings]
Priority=MACAddress,…
[00:01:AB:34:CD:02]
ComputerName=”Computer1”

5. You can assign values based on database lookups. (See the database section below for further information)

The structure of the CustomSettings.ini

It is important to understand the structure of the customsettings.ini file before we look at the rule processing options. The file is structured into sections. These sections give you the ability to customize how properties are gathered.

Settings section

This section is divided into two lines, priority and properties which define properties to be gathered and the rule processing order.

Priority

The rules are processed according to the section they belong. This line determines the order in which rules should be processed. Values are assigned to a property on a first come first served basis.

For example with the priority line below if a value is specified in the “Default” and “CSettings” sections the “CSettings” section will take precedence.

[Settings]

Priority=CSettings,Default

[Default]

OSInstall=Yes

Computername=Computer1

[CSettings]

Computername=MyComputer

Note: When the property is a list then each subsequent value will be added to the list.

Properties

BDD defines its standard properties via the ZTIGather.xml file, these properties do not have to be explicitly defined. In some scenarios the standard properties may not be adequate for your requirements. In these cases you can define custom properties. These can be used within all BDD scripts. Custom properties are defined on the “Properties” line.

For example if you wanted to create a new disk partitioning script that would configure partitions according to custom partition sizes, you would define these properties in this section as follows.

[Settings]

Properties=Partition1Size,Partition2Size

These properties would then be available to use in all BDD scripts.

Rule Sections

Once you have defined the rules processing order and any custom variables you can then assign values to these properties.

Default

Rules that you wish to be applied to all computers are generally specified in the default section. These values could be values such as the time zone or the BDD Deployment Root.

Custom Sections

There are three custom section types, dynamic, database or static.

Dynamic sections

Using variables such as make model or default gateway you can dynamically specify rules.

For example if you specified “Priority=Make” and the make is “Dell Corporation” BDD will look for a section called “Dell Corporation” and will then process any rules in that section.

[Settings]
Priority=Make,…
[Dell Corporation]
ComputerName=”DellComputer”

Database sections

This will perform a database lookup and return a single record. It will then assign the values of any column that matches a BDD property to that property.

BDD automatically recognizes database sections based on the information they contain. The information is used to connect to the DB and construct a select statement which retrieves values from the DB.

The following variables are used to declare DB connectivity requirements:

• SQLServer - This is the SQL Server hosting the DB you wish to connect to.
• Instance – The name of the instance of SQL Server to be used for querying property values.
• Port – The number of the port to connect to the SQL server, if required
• Netlib –The protocol to be used in communicating with the SQL Server. DBNMPNTW – Named pipes, DBMSSOCN –TCP/IP Sockets
• Database – The name of the database to be used for querying property values
• Table – The name of the table or view to be queried for property values.
• Parameters – The list of parameters to pass to the database query
• Order - The sorting order for the result set on a database query.
• SQLShare – Any share on the SQL server. You need to connect to a UNC path to get a secure named pipes connection as WinPE is not a member of the domain.

The best way to explain this section is by an example:

[MSettings]

SQLServer=SERVER1
Instance=SQLEXPRESS
Port=1433
Netlib=DBNMPNTW
Database=BDDAdminDB
Table=MachineDetails
Parameters=AssetTag
SQLShare=Logs

This will connect to the machine using the share \\SERVER1\Logs , then establish a connection the DB using the first four properties. Once this has been established it will then execute the following dynamically created select statement.

SELECT * FROM MachineDetails WHERE AssetTag = ‘%AssetTag%’

This will perform a search for records where the AssetTag value is equal to that of the current machine. It will return any column values that match the standard properties or any custom properties declared in the properties section.

So for example if the column ComputerName had a value “Desktop1” it would update the ComputerName property within BDD with that value.

It is also possible to retrieve information from databases other than the BDD database. To make these database lookups more flexible it is possible to translate the column names. Say for example you want to perform a query of a table where the column name of the table does not match the value of that we want to retrieve. In this case we can create mappings that translate these values.

For example if we want to connect to an asset management database to retrieve the computer name. Unfortunately records within this table do not have a “ComputerName” column. However it does have a “computer” column. To retrieve this value we simply add a line to the database section which will translate the column value:

Computername=Computer

Static sections

This is simply a section that is defined in the priority line that is not a dynamic or database section.

User exit scripts

In some situations the standard rule processing options may not be sufficient to meet your requirements. To extend the capabilities of rules, you can create user exit script(s).

User exit scripts are specified in the customsettings.ini file, and are processed before and after the CustomSettings.ini rules for each section are processed. User exit scripts have full access to the global variables.

The user exit script is essentially a function library. You create the functions you need to extend the rule processing functionality and then place them in a user exit script. You then reference the functions within the user exit script from the customsettings.ini file.

For example you may want to use the MAC Address with the colons stripped out as the computer name. A function can be used to “clean” MAC address. The result of the function can then be assigned to the computer name.

The following is an example of a eser exit script that would perform this function.

Function UserExit(sType, sWhen, sDetail, bSkip)

UserExit = Successfs

End Function

Function CleanMac(sMac)

                Dim re

                Set re = new RegExp

                re.IgnoreCase = true

                re.Global = true

                re.Pattern = ":"

                CleanMac = re.Replace(sMac, "")

End Function

This function is then referenced from the CustomSettings.ini as follows:

ComputerName=#CleanMac("%MacAddress%")#

UserExit=UserExit.vbs

Note: The user exit script must be placed in the same folder as the CustomSettings.ini file.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I have lost count of the number of times I have been asked to help some troubleshoot their database issues, so I decided it was time to write a blog about it. This blog details the common issues faced when using the BDD configuration database. The first part details the common causes of database issues and the second recommends troubleshooting methods.

Common issues

The following section details common issues and recommended configurations for each.

Database Rules - Ensure that the appropriate database rules have been created. Database rules are specified using the deployment point rules tab. Configuration database rules can be created manually or using the Configure DB Wizard in the Deployment Workbench.

A typical database section should look similar to the following:

[CSettings]

SQLServer=SERVERNAME

Database=BDDAdminDB

Netlib=DBNMPNTW

SQLShare=logs

Table=ComputerSettings

Parameters=MacAddress

ParameterCondition=OR

The critical components of the database section are:

• SQLServer - must specify the SQL server that hosts the BDD configuration database.
• SQLShare – must be a valid share on the SQL server and the user account (UserID as specified in the rules) must have access rights to that share. If SMS OSD Feature Pack is used for deployment then the SMS Advanced Client installation account will require access rights rather than the user account.
• Netlib – there are many issues with using TCP/IP sockets based connections so ONLY USE NAMED PIPES (DBNMPNTW).

Database connectivity issues – There are a number of issues that can stop the client connecting to the SQL server, these are detailed below:

• Ensure that Named Pipes is enabled for remote connectivity on the SQL server, this is not enabled by default.
• Has the surface area been configured to enable Named Pipes? When using SQL 2005 it is important to ensure that the “Surface area” is configured in such a way that remote connectivity to Named Pipes is allowed.
• If you have issues accessing the database from the workbench then ensure that you are using Named Pipes. The Deployment Workbench always uses Named Pipes to connect to the database.

Security - has the deployment account got the appropriate database rights? The account used will need read rights to the BDD admin database. The account can vary depending on the deployment type:

• ZTI – The SMS advanced client installation account.
• LTI – The user account specified in the rules (bootstrap.ini).

SQL instances – If you are connecting to a database instance then this instance must be specified. This value is specified using the Instance field in the deployment workbench.

Troubleshooting methods

During the troubleshooting process it is critical that you can easily test the database rules. The following instructions detail how to manually test the database connectivity. The rules specified in the deployment point can be tested without running through the entire BDD build process. Rules are processed using a script called ZTIGather.wsf, this script can be run separately from the other BDD scripts allowing easy testing. The steps below detail the process required to perform manual rule testing. To properly reflect the deployment environment it is important to perform these tests from a client device:

  1. Create a folder on the client device and copy the following files from the deployment point to this folder:

• ZTIGather.wsf
• ZTIGather.xml
• ZTIUtility.vbs
• CustomSettings.ini

  2. Delete C:\MININT directory if it already exists. This folder can also be located at X:\MININT if the C drive is not available.

NOTE: BDD stores configuration and progress information in the MININT folder, if this folder is not removed between tests then the results will be invalid.

  3. From the command prompt navigate to the newly created folder and execute the rule processing script using the following command:

"cscript.exe ZTIGather.wsf /debug:true"

      The script will then be processed and the results outputted to the command prompt and a log file ( .\MININT\SMSOSD\OSDLOGS\ZTIGather.log)

NOTE: The script can be run within Windows PE or the host operating system.

  4. Review the results of the script.

The following screen shots show five examples of the output that you will see from this process. The first three screen shots show general database lookups while the other two show common errors you are likely to see.

This screen shoot shows a successful connection to the database. The computer record is then queried based on the MAC Address and the OSINSTALL, COMPUTERNAME and MACHINEOBJECTOU values are returned.

The next two screen shots show a database lookup based on the make and model of the client device. In the first screen shot shows a database lookup based on a Virtual PC client where the model is a "Virtual Machine" and the make is "Microsoft Corporation".  This record does not exist in the database and the log reflects this - "Record count from SQL = 0". I then created a record in the database using this information and assigned an application to the model type via the deployment workbench. The script is then rerun and and the lookup successfully returns the application. (Second screen shot).

NOTE: Applications are identified as GUID's in the BDD logs. To determine which application is represented by the GUID you should reference the applications.xml file.

The following screen shot show the results of a database look up where the user account does not have rights to the database. The important thing to note is the error message - "login failed for user 'WOODGROVE\BDDBuild'". Remember that the user account must have at least read rights to the BDD configuration database.

The following screen shot show the results of a database look up where named pipes has been disabled. The important thing to note is the error message, "SQL Server does not exist or access denied". This problem can be caused by a number of issues, please refer to the database connectivity issues point above.

Hopefully this will help get you started with troubleshooting your BDD configuration database issues.

For further information on rule processing please refer to this blog.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

In a previous post I detailed the process for using a cut down version of the task sequence to test application installation, unfortunately this process has not worked for a number of people so I thought I should add the following tip.

If you leave any folders behind then make sure that you remove any conditions. A example of this is the folder for the state restore phase, when using the custom task sequence BDD will see that it is not in the state restore phase and skip the folder. This means that non of the tasks in that folder will be run. The screen shot below shows the condition that should be removed.

Another good tip is to leave the "Gather local only" task in your task sequence as this will then ensure that the BDD environment variables are collected. These are then able to be used by other scripts.

UPDATE - 01/09/08

MDT 2008 now includes built in support for custom task sequences and you do not need to use this process.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I see the same issues coming up over and over again with BDD 2007. So, I decided it was time for my own Top Ten List!

Number 1. - Partitioning within the Unattend.xml

BDD likes (no needs) to look after partitioning itself! Do not do this via Unattend.xml. The most common symptom of this is the Task Sequence not restarting after the operating system has been installed.

Number 2. - XP disk partitioning

Affectionately know as the UBERBUG, this little baby causes some machines to blue screen when an XP image is applied to a machine that has been partitioned with Windows PE 2.0. For more information see my previous blog.

Number 3. - Trying to deploy images with WDS

This is a common misunderstanding about the relationship between BDD and WDS. Let me assure the relationship is not a close one, BDD is just using WDS! Simply put uses WDS as a mechanism to boot the Lite Touch WIM which connects to the BDD deployment point. Once this has happened it has nothing more to WDS, nothing! So my advice here is DO NOT try to load an image captured with BDD into WDS.

Number 4. - Failure to join the domain

Oh the joys of documentation, one little error and everyone has strife. The BDD configuration reference states that "MachineObjectOU=NewYork" , it's wrong! Instead it should say something like this "MachineObjectOU=OU=NewYork,DC=DammTypos,DC=com". So if for some reason your machine fails to join the domain then make sure you have specified the correct OU in the correct manner.

Number 5. - Drivers

Where do I start with this one? This could be a number of blogs on its own, maybe I could use this as a teaser to make you keep coming back and finding more useful information on my blog(did I say that out loud?). I will write a blog(s) on drivers soon.

Number 6. - Creating custom WIM image without using /flags

So you already have a Vista machine built up and you have decided that you want to manually image it . So you capture an image and try to import it into BDD but it won't work. Well the real lesson is you should have used BDD to create and capture the image then you wouldn't of had this problem in the first place. But if you really have no choice then remember to specify the correct flags for the Version of Vista you a capturing. Here is and example command line:

       imagex /flags “Enterprise” /capture c: d:\image.wim "Custom Image"

And if you want to add a flag to an image you have already capture try this command line:

       imagex /flags [flags value] /info mywim.wim [image index] [new name] [new description]

Number 7. - SQL connectivity

Having trouble connecting to your SQL database well take heed of these four simple rules, and your life will be simpler :

        1. Make sure your BDD account has access to the database

        2. Ensure that the "surface area" of SQL is opened up enough to allow connections

        3. Use named pipes - it makes life easier as you cannot use integrated security with TCP/IP sockets

        4. If you have an instance then be sure to specify it when connecting to the DB

Number 8. - Memory requirements for Vista PE

Do random things happen when you try to build some machines? Do you have 256Mb of memory? Well the problem you have is that Windows PE 2.0 can boot with only 256MB of memory but it cannot run. This means that when it tries to do stuff it freezes randomly, NICE! So when building machines make sure you have at least 512Mb of memory and everything will be rosy.

Number 9. - Not removing the MININT folder

Are you testing your build and nothing you do seems to have any effect. Usually this is caused by the fact that BDD is storing information from a previous build in the MININT folder. So commit this to command to memory, your gonna need it:

        rd c:\minint /q/s

And while your at it you may as well remember this one:

        rd c:\_SMSTaskSequence /q /s

Number 10. - Adding Windows PE to console

Are you trying to add your customized version of Windows PE to the console, yeah the one that you spent hours getting just right! Well its not going to work, the Windows PE source files need to be taken straight off the volume source CD. BDD will then combine this with the OS source files and create a version customized just for BDD.

There may be other common issues I have missed but I thought it is worth while getting these out there. Anyway one day I will create a Top Ten Returns list and I will need something to put in it!

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

When performing a refresh based deployment using Zero Touch BDD will retain the computers current SMS GUID. This is very handy if you want to rebuild a computer but not lose any information associated with the computer SMS. (i.e. Assigned applications or configuration). This also has the effect of reducing the number of duplicate records in SMS.

Unfortunately when rebuilding a computer using a New Computer scenario (from PXE or CD/DVD) the SMS GUID value will not be retained. To get around this issue I query the SMS database to see whether an SMS 2003 GUID already exists for the computer. If one does exist, the SMSCFG.ini file on the computer is updated to include the SMS 2003 GUID.

The process is used to perform this "magic" involves two main processes:

    1. Use rules to perform an SMS database lookup.

    2. During the Post Install phase the SMSCFG.ini file is updated with the correct SMS GUID.

The rest of the post details how these two processes are implemented.

Update the Rules on the ZTI Deployment Point

The next thing you need to do is update the rules on your ZTI deployment point. These rule updates perform a lookup on the SMS database. If it finds a record with its NetBios_Name0 value equal to the current computer name then it will populate the SMS_Unique_Identifier0 variable with the value from that record.

To update the rules on the deployment point, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Open the ZTI deployment point, select the Rules tab.

    3. Add the GetSMSGUID value to the priority line of the rules:

Priority= Default, GetSMSGUID

Note - The GetSMSGUID section must be added after the section that determines the computer name.

    4. Add the SMS_Unique_Identifier0 value to the Properties line of the Rules:

Properties=SMS_Unique_Identifier0

    5. Add the following section to the end of the Rules:

[GetSMSGUID]

SQLServer=SMS DB Server

Instance= SMS DB Instance, if used

Database=SMS DB name

Netlib=Netlib type

SQLShare=Share on SMS DB Server

Table=System_DISC

Parameters=OSDNewMachinename

Order=Creation_Date0 DESC, Active0

OSDNewMachinename=Netbios_Name0

Note - For more information on how database lookups are performed using rules please refer to my rule processing blog here.

Copy the Script to the Deployment Point

The attached script will update the SMSCFG.ini file with the SMS GUID if one was identified by the rules.

    1. Copy the script Z-CONFIG-Reuse-smsguid.wsf to the .\Distribution\scripts folder.

Note - Any script in the Distribution\scripts folder that starts with a "Z" will be automatically replicated to the ZTI deployment point.

Create an Application

I am a strong believer in an application for every task you perform within BDD wether they update a file or install an application. These applications can then be added to the task sequence as required.

To create an application, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Click Distribution Share, right-click Applications, and then click New.

    4. Select Application without source files or elsewhere on the network, and then click Next.

    5. Set Application Name to CONFIG-REUSE-SMSGUID.

Note - When creating an application you should use a naming convention that clearly identifies the purpose of the application.

    6. Set the Command Line to cscript "%SCRIPTROOT%\Z-CONFIG-REUSE-SMSGUID.wsf".

    7. Set the Working Directory to %SCRIPTROOT%.

Add the Application to the Task Sequence

Now that you have created the application you must now add it to the builds task sequence.

To add an application to the build task sequence, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Click Builds, right-click BuildID (where BuildID is the name of the build to edit—for example, DEP-VISTA-ENTERPRISE), and then click Properties.

    3. Click the Task Sequence tab.

    4. Navigate to the Postinstall group.

    5. Select the Inject Drivers task.

    6. Click Add, and then select Application\CONFIG-REUSE-SMSGUID.

Note - This will add the CONFIG-REUSE-SMSGUID after the Inject Drivers task.

Update the BDD Deployment Point

Once the changes have been made to the rules and the applications you must update the deployment point to commit the changes and copy the new script to the deployment point.

Update the SMS Package

Now you must update the SMS package and the distribution points with the new script (Z-CONFIG-REUSE-SMSGUID.wsf) and rules.

To update the task sequence, complete the following steps:

    1. In the SMS Administrator console, locate Site Database, and then expand Image Packages.

    2. Double-click the image package you are updating, and then click the Programs subfolder.

    3. Right-click the program (for example, Install), and then click Properties.

    4. Click the Advanced tab.

    5. In the Phase selection field, ensure that Validation is selected, and then select Zero Touch Install - Validation.

    6. Click Settings.

    7. In the Custom Action dialog box, click Add.

    8. Browse to \\ServerName\ZTI$\BuildName (where BuildName is the name given to the build select all the files, and click Open.

Note - Ensure that All Files (*.*) is selected in the Files of Type dialog box.

    9. In the Custom Action dialog box, click OK.

    10. In the Install Properties dialog box, click OK.

    11. Right-click the image package, point to All Tasks, and then click Update Distribution Points.

Note - Be sure to determine the network implications of updating distribution points before performing the update.

    12. In the Confirm Update Distribution Points dialog box, click Yes.   

So that's how it done. Hopefully you will find this process useful, I certainly do. 

UPDATE - 31/12/207

This script will not work for Configuration Manager. This is because it uses certificates to identify clients rather than the GUID.

However if you are using the built-in media and PXE support provided in ConfigMgr then it will automatically look up the previous identity and try to use it.  But it will only succeed if:

       1. The site is in native mode and the new machine is given the same certificate (e.g. using AD)

       2. The site is in mixed mode and configured to manually resolve conflicting records and the admin resolves the conflict using the “Merge” action (See the “Conflicting Records” help topic 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I have had recently had a couple of enquires from people having issues with setting multiple keyboard locales.

When setting the “KeyboardLocale” value using a Lite Touch new computer deployment any settings specified in the CustomSettings.ini are being ignored.

To solve this problem, update the KeyboardLocale line in the ZTIGather.xml file to set allow overwrites to true.

     <property id="KeyboardLocale" type="string" overwrite="true" description="Locale used for Keyboard, can be either 0409:00000409 or en-US format (default is OS Default)" />

You then need to make sure that you skip the locale selection screen, otherwise it will override any values specified in the customsettings.ini. Here is an example of the rules you will need to skip this screen:

     SkipLocaleSelection = YES

     UserLocale = en-NZ

     SystemLocale = en-NZ

     UIlanguage = en-US

     KeyboardLocale = 0413:00020409;0413:00000409;0409:00020409;0409:00000409;1409:00001409

When making this change you need to be aware of its effects. This will cause the last value gathered during rule processing to be the one used. So for example if you specify a KeyboardLacale in the database and it is also specified in the Default section then the last section processed will win(normally the first section will win), which usually means the values in the default section will win.

For more information on rule processing see this blog.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Many people have been having "Fun and Games" when using Windows Preinstallation Environment (Windows PE) 2.0 to create partitions on a hard disk.

They use Windows PE to create a partition which XP is then installed onto, this then results in a "Blue Screen" at first reboot. This issue only occurs with some BIOS's but can be extremely frustrating.

There is now a patch available for this issue:

Windows 2003: http://support.microsoft.com/kb/931761/en-us
Windows XP: http://support.microsoft.com/kb/931760/en-us

This patch needs to slimstreamed into your XP source files, and your done!

There is also a workaround for this issue which is detailed in the KB article or if you are using BDD 2007 then take a look at Johan Arwidmark's blog.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

BDD provides a scripting framework, by leveraging this framework you can write a custom script that can utilize the functionality that BDD provides. This functionality includes a logging, accessing and changing environment variables and a number of utility functions.

Before describing how to create a script it is best to review how the scripts included with BDD are constructed.

The standard BDD script is a WSF file, this allows references to be made to functions that are contained in other scripts. BDD scripts leverage this functionality by referencing a script called “ZTIUtility.vbs”.

Understanding ZTIUtility.vbs

ZTIUtility.vbs is used to initialize the BDD environment and setup classes, these can then be used by scripts that reference it.

The script defines a number of standard objects:

• oFSO – File System Object
• oShell – Wscript Shell object
• oEnv - Process Environment object
• oNetwork - WScript Network object

Note: You do not need to declare these objects in your script.

Four classes are defined which perform a number of standard tasks:

• Environment – This configures environment variables gather via WMI and BDD rule processing and allows you to reference these directly I from you script
• Logging – Provides the logging functionality used by all BDD scripts, creating a single log file for each script and a consolidated log file of all scripts
• Utility – Provides general utility functionality
• Database – performs functions such as connecting to databases and reading information from databases (See this blog for further information)

These classes can be referenced in your scripts, here are some examples for each of the classes:

Environment class

This class is referenced in scripts through the object “oEnvironment”.

For example you change the computer name to “Blah” using the following command:

            oEnvironment.Item("ComputerName") = “Blah”

Or if you needed to determine if this is an x86 or x64 then you could query the architecture using the following command:

            oEnvironment.Item("Architecture")

Logging class

This class is referenced in scripts through the object “oLogging”.

When creating a informational log entry use the following command:

            oLogging.CreateEntry "Informational message", LogTypeInfo

When creating a error log entry use the following command:

            oLogging.CreateEntry "An error occured“,LogTypeError

Utility class

The class is referenced in scripts through the object “oUtility”.

To determine the name of the the current script, use the following command:

            oUtility.ScriptName

To find the location of a file and BDD use the following command will look in a number of locations for it.

            iRetVal = oUtility.FindFile("CustomSettings.ini", sIniFile)

Database class

The class is referenced in scripts through the object “oDatabase”. There is generally no need to use the database class directly. Database lookups can be performed using rule processing. See my rule processing blog for more information.

This is a high level view of the tasks that ZTIUtility.vbs can perform. It is worthwhile taking a good look through the script yourself as there are many hidden gems.

Now that we have reviewed the framework lets look at how to write a custom script. I have created a script template below which is based on the structure used within the standard BDD scripts. The template is simply a wrapper that references the ZTIUtility.vbs script and  launches the function "ZTIProcess". To create your own script you simply place your code within the ZTIProcess function.

Here is a quick overview of the steps required to add your script to a BDD build:

1. Create your script based on the template
2. Place the script in the folder \Distribution\Scripts
3. Create an Application in the BDD Workbench that references this script
4. Add the Application to the build task sequence

It is also important to remember the following key rules when creating your script:

1. Always declare variables
2. Only create objects where required - BDD creates most objects you will need
3. Check if ZTIUtitlity provides the functionality you require before writing a function
4. Script names should always start with a "Z" as BDD will replicate only scripts beginning with "Z" to other deployment points

Hopefully these tips will get you started, writing your own scripts that  leverage the true flexibility of BDD.

Template

Use the following template to create your own custom scripts.

<job id="Z-Sample">
<script language="VBScript" src="ZTIUtility.vbs" mce_src="ZTIUtility.vbs"/>
<script language="VBScript">

' //***************************************************************************
' // ***** Script Header *****
' //
' // Solution: Solution Accelerator for Business Desktop Deployment
' // File: Z-Sample.wsf
' //
' // Purpose: Template
' //
' // Usage: cscript Z-Sample.wsf [/debug:true]
' //
' // Customer Build Version: 1.0.0
' // Customer Script Version: 1.0.0
' // Customer History:
' //
' // ***** End Header *****
' //***************************************************************************

'//----------------------------------------------------------------------------
'//
'// Global constant and variable declarations
'//
'//----------------------------------------------------------------------------

Option Explicit

Dim iRetVal

'//----------------------------------------------------------------------------
'// End declarations
'//----------------------------------------------------------------------------

'//----------------------------------------------------------------------------
'// Main routine
'//----------------------------------------------------------------------------

On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

'//---------------------------------------------------------------------------
'//
'// Function: ZTIProcess()
'//
'// Input: None
'//
'// Return: Success - 0
'// Failure - non-zero
'//
'// Purpose: Perform main ZTI processing
'//
'//---------------------------------------------------------------------------
Function ZTIProcess()

     iRetVal = Success

     ZTIProcess = iRetval

     '!!!!!!!!!!!   INSERT YOUR CODE HERE   !!!!!!!!!!!!

End Function

</script>
</job>

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Many of my customers want to prompt information during a ZTI deployment. For example if for some reason the computer name is not available then they you like the user to be prompted for this information.

An elegant way to provide this information is by using the Lite Touch wizard within ZTI.

To do this you must copy the following files to your ZTI deployment point (\\<server>\zti$\BuildID):

• BackButton.JPG
• DeployWiz_Definition_ENU.xml
• DeployWiz_Initialization.vbs
• DeployWiz_Validation.vbs
• Wizard.css
• Wizard.hta
• Wizard.ico
• WizUtility.vbs

You then need to create a cut down version of the "DeployWiz_Definition_ENU.xml" file and place it in the same folder. To prompt for the computer name only you would simply remove all panes accept the computer naming pane (Notepad.xml is a good tool for editing this file).

Next you need to add a task to the task sequence in the "New Computers only" folder within the "Preinstall" phase.

mshta.exe "%SCRIPTROOT%\Wizard.hta" /definition:DeployWiz_Definition_ENU.xml

This should hopefully get you started, you could also add other screens to gather further information if required.

This process can be extended to capture any information you need for the build process. For example the computer role or the MachineObjectOU.

This script can also be called from "bootstrap.ini" using a user exit script. This way you could gather information from users and then update the database with this information. This approach is also popular with customers who are not able to pre-populate the database with computer details.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Many of my customers have Group Policy settings that are very restrictive and cause problems during operating system deployments. For example the legal notice messages can interrupt an automated logon process.

This can be a real hassle to get around when deploying so to solve the issue the I perform by performing one of the following steps:

1. If the computer is already in the domain - I move the computer to a "Staging OU" that has no group policy settings applied.

2. If the computer is not in the domain - I ensure that the computer will be created in the  "Staging OU".

This process is performed during the State Restore phase from within Windows PE. At the end of the deployment I then run another script that moves the computer to the correct OU, the group policy is applied and everyone is happy. :)

To make this happen I use two scripts:

1. Z-MoveComputer-StagingOU.wsf - This script move the computer to the "Staging OU" and updates the MachineObjectOU property with the "Staging OU" value.

2. Z-MoveComputer-SwapOUValues.wsf - This script runs after BDD has configured the Sysprep or Unattend.xml files, it's purpose to change the MachineObjectOU and  "Staging OU" properties back to their original values.

I have attached the required scripts, to implement the scripts follow the steps detailed below:

Enable ADSI in Windows PE

Windows PE must have ADSI enabled (not officially supported) for these scripts to work, the steps below details how to enable ADSI.

To enable ADSI to in Windows PE 2004/2005 (ZTI Only) you will need to perform the following steps:

1. Update Extra.inf located within the WinPE source directory with the following lines:

                  [ExtraFiles]

                  activeds.tlb = 1,,,,,,,2,0,0,,1,2

                  adsldp.dll = 1,,,,,,,2,0,0,,1,2

2. Update the BDD OSD deployment point creating an updated Windows PE source

3. Import the new Windows PE source into SMS

4. Recreate SMS deployment CD

To enable ADSI in Windows PE 2.0 (LTI) then follow Johan Arwidmark's instructions here.

Update the deployment point rules

1. The following properties to be declared in the deployment point rules. These properties are used to connect to AD and move the computers. The account used must have the rights to create and delete computer objects in the domain:

               DomainAdminDomain
               DomainAdminPassword
               DomainAdmin

2. You also need two new custom properties to be declared in the deployment point rules:

               StagingOU – The full staging OU path, this is in the same format as the MachineObjectOU property.
               DomainDC – The name of a Domain Controller to connect too.

Here is an example CustomSettings.ini file:

               [Settings]
               Priority=Default
               Properties=StagingOU,DomainDC

               [Default]
               StagingOU=OU=Staging,DC=domain,DC=com
               DomainDC=DC01
               DomainAdminUser=Account
               DomainAdminDomain=domain
               DomainAdminPassword=password

Update the scripts folder

Next you must add the scripts to the .\distribution\scripts folder. You will notice that the script names have the prefix "Z-" this is because BDD automatically copies all scripts that start with "Z" from the distribution share to other deployment points when they are updated.

Update the build task sequence

The next thing you do is add the scripts to the build task sequence. I would recommend creating an application for each script that executes a script and then add it to the task sequence as shown below. It is important to note that the "Move Computer" script must be run before the Configure task and the "Revert OU" script must be run after the configure task.

Update your deployment points

Finally you should update your deployment points to so that these changes are propagated to the correct places.

If you want to see how to move the computer to it's final OU (MachineObjectOU) then have a look at this blog post.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

How often when creating a your perfect image do you find that you run through image build process only to find that one of your applications fails to install?

I find this to be a very commmon occurence. After a cursing about how I have just wasted another hour I ring the wife and tell her I am going to be late home and then start the process over again only to find that I have made another mistake, DAMM!!!

It doesn't have to be this way!

You can create a custom task sequence which includes only the applications you want to test. This can then be launched from within the OS allowing you to quickly test if the application installs correctly.

Here's how its done:

First you need to create a custom task sequence, the following steps detail the creation the task sequence:

1. Create a new build using the BDD workbench (i.e.) ApplicationsOnly

2. Copy TS. XML from your current build under the distribution share on your BDD server - \distribution\control\<Build ID\TS.xml

3. Copy it to the newly created build directory (i.e.) \distribution\control\ApplicationsOnly

4. Delete every task except for the custom tasks that you want to test -

Note: If you leave any folders behind then remember to make sure that you remove any unwanted conditions from the options tab

5. From the client computer launch cscript \\<yourserver>\<distribution share>\scripts\LiteTouch.vbs

6. Watch the task sequencer execute your tasks

7. Make adjustments as necessary

8. Update your build with the tested Tasks.

This process will literally save hours when troubleshooting application installation.  

UPDATE - 14/05/07 

Please see the following blog for further tips on this process.

UPDATE - 26/09/07

To make this process work with Deployment 4 please refer to this post.

UPDATE - 01/09/08

MDT 2008 now includes built in support for custom task sequences and you do not need to use this process.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

As promised in a previous blog post here is a script to move a computer to the correct OU from within the host operating system.

There are two situations where I find this script useful:

1. When a computer object already exists in Active Directory for the computer you are deploying. In this situation the existing computer object will be reused and the computer will remain in the original computer objects OU.
2. When you are using a Staging OU during deployment. In this situation the computer is added to a staging OU when it is joined to the domain.

In both of these situations I want to ensure that the computer is in the correct OU when the deployment is finished.

To implement the script follow the steps detailed below:

Update the deployment point rules

The script uses the MACHINEOBJECTOU property specified using BDD rules to determine the OU that the computer object should be moved too.  You will need to ensure that your rules specify a value for this property for each computer.

The following properties to be declared in the deployment point rules. These properties are used to connect to AD and move the computers. The account used must have the rights to create and delete computer objects in the domain:

DomainAdminDomain
DomainAdminPassword
DomainAdmin

Update the scripts folder

Next you must add the script to the .\distribution\scripts folder. You will notice that the script names have the prefix "Z-" this is because BDD automatically copies all scripts that start with "Z" from the distribution share to other deployment points when they are updated.

Update the build task sequence

The next thing you do is add the scripts to the build task sequence. I would recommend creating an application for each script that executes a script and then add it to the task sequence as shown below. it is important to note that the "Move Computer" task is run near the end of the State Restore phase, particularly if you are moving the computer from a staging OU.

Update your deployment points

Finally you should update your deployment points to so that these changes are propagated to the correct places.

If you want to see how to move the computer to a staging OU from within windows PE then refer to my previous blog post.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Richard Smith one of my fellow Microsoft consultants from the UK has started a blog (finally!). Richard is very knowledgeable on everything about BDD and operating system deployment so I am sure you will find his blog very useful. 

Richard has started his blog with two great video walk through's covering Lite Touch and Zero Touch deployment. This are very informative and should prove particularly useful to those new to BDD.

It looks like I will have too put together my own video walk through's now just too keep up!

I recommend that you subscribe to his blog as there is bound to be lots more great stuff coming... No pressure Richard;)

http://blogs.technet.com/richardsmith

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Windows Recovery Environment (Windows RE) is a recovery platform based on Windows Preinstallation Environment (Windows PE). Windows RE provides two main functionalities, Automatic diagnosis and repair of boot problems using a tool called Startup Repair and a centralized platform for advanced recovery tools.
based on this functionality I think it makes a lot of sense to integrate WinRE into all of your Vista deployments. From the number of questions I have received on the topic it seems like I am not the only one!

So how do we integrate WinRE into the Vista deployment process using BDD 2007?

The first thing I do is I create my WinRE source. There is a good article on the WinRE team blog that explains how to create a WinRE source using the WAIK. Unfortunately adding the Mass storage and network drivers for all the models you want to support can be quite laborious. The obvious question here is “why can’t we just use the BDD driver library?” to do this for us, after all it is used to create the Lite touch WIM. Well thanks to Dave Hornbaker a fellow Microsoft Services consultant you can.

Dave has developed a PowerShell script that automatically creates a WinRE WIM and then injects the drivers that you have already imported into BDD, NICE!

The script must be run on a machine with both BDD and the WAIK installed. The script is attached to this blog and is usage is detailed below:

Powershell .\CreateWinRE.ps1 [Arch] [Group] [–ISO] [–MassStorageDrivers] [–Net] [–system] [–Display]
     Arch - “x86” or “x64” (“x64” has not been tested) Default is “x86”
     Group - BDD Driver group name. Driver group to be injected into the image. Default is “All Drivers”
     -ISO - Create an ISO image Default is to just create a WIM
     -MassStorageDrivers - Inject Mass Storage Drivers (default)
     -Net - Inject network drivers (default)
     -System - Inject system drivers
     -Display - Inject display drivers

Now we have this fantastic script, run it to create the WinRE WIM the and inject the drivers as required:

Powershell .\CreateWinRE.ps1 –MassStorageDrivers –Net

Now that we have out WIM we can integrate into the BDD deployment process:

Copy the following files to the specified locations:

1. Copy SetAutoFailover.cmd to the distribution\scripts folder and rename it to Z-SetAutoFailover.cmd - This script is provided by the Windows AIK - under: C:\Program Files\Windows AIK\Recovery.
2. Copy the script Z-INSTALL-WinRE.wsf to the distribution\scripts folder – Attached to this blog

Now create an application with the following settings:

1. Open the Deployment Workbench
2. Right click on Distribution Share \ Applications and click New
3. Select Application without source files or elsewhere on the network and click Next
4. Set Application Name to INSTALL-WinRE and click Next
5. Set the Command Line to cscript "%SCRIPTROOT%\Z-INSTALL-WinRE.wsf"
6. Set the Working Directory to %SCRIPTROOT% and click Add

Next add the application to task scheduler, it is important to note that you should add this to your deployment build not your master image as WinRE will be disabled by sysprep :

1. Open the Deployment Workbench
2. Right click on Builds \ <Build ID> and click Properties
3. Select the Task Sequence tab
4. Navigate to the State Restore group
5. Select the Enable Bitlocker task
6. Click the Add button and select Application \ INSTALL-WinRE
7. Click Ok to confirm

NOTE: <Build ID> is the name of the build to edit i.e. DEPLOY-VISTA

The sample script I have provided simply copies the WinRE.wim file to the C drive and enables WinRE. You may want to look at other options such as locating it on a partition with Bitlocker or creating a seperate partition just for WinRE. For more information about the possible configuration options please refer to the WinRE team blog.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I am often asked how to setup a custom task sequence that will continue after a reboot.

If you have created a custom task sequence to install a number of applications that includes a reboot then you will know the problem I am taking about. When you do this you will find that the computer will reboot and then return to the logon prompt. The computer does not automatically logon :(. So you logon manually and BDD does not continue, so you have to manually launch the litetouch.wsf script :(. Then FINALLY the script will continue happily, until next next reboot at least.

Well I don't find this very convenient and I bet you don't either. So I have created a script that will setup required components to allow the BDD processes to continue as they would in a normal BDD deployment process.

The script configures three main components:

1. Populates the required auto logon keys in the registry
2. Populates the MININT folder with the scripts required to launch the script at when the client reboots
3. Configures the BDD script to launch at reboot by creating a shortcut to the litetouch.wsf script in the "all users" startup folder
4. Configures the correct phase information so that BDD knows what phase it should process

I find this script very useful, hopefully you find this script as useful as I do.

To implement the script follow the steps detailed below:

Update the deployment point rules

The script uses the ADMINPASSWORD property specified using BDD rules to determine the password that should be used for the local administrator account. If this is not correct then you can change the following line from the script to correctly reflect the value you want to use:

 oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword", oEnvironment.item("AdminPassword"), "REG_SZ"

Update the scripts folder

Next you must add the script to the .\distribution\scripts folder. You will notice that the script names have the prefix "Z-" this is because BDD automatically copies all scripts that start with "Z" from the distribution share to other deployment points when they are updated.

Update the build task sequence

The next thing you do is add the scripts to the build task sequence. I would recommend creating an application for each script that executes a script and then add it to the task sequence as shown below. It is important to note that the "CUSTOM TS - Setup for reboot " task is run before the first reboot is performed.

Update your deployment points

Finally you should update your deployment points to so that these changes are propagated to the correct places.

For more information about custom task sequences then please refer to the following links:

• Deployment 4 task sequences
• BDD 2007 task sequences
• More BDD 2007 task sequence information

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

When trying to manage drivers and hardware specific application with BDD 2007, I have found that with some model types (HP D530) return many variations on the same model number. While these have slight variations to their model names they have virtually no difference to their driver set. This means that I end up wasting heaps of time duplicating database entries for each of these model types.

There is however a solution to this issue., here it is….

I use it to cater for all the HP machine types which have slight variations to their model names but virtually no difference to their driver set. These names are composed of a model name and then a code, for example “Hp D530 (XY12345)”. This solution simply truncates the names at the “(“.

To implement this solution perform the following steps:

1. Create aliases for Hardware types in the “Make and Model” section of the Database. In this example I truncate the Model type at the “(“ in the model name. (eg. "HP D530" rather than “Hp D530 (XY12345)")
2. Update the rules in the following manner
   • Add the custom variable “ModelAlias” to the “[settings section]”
   • Create a new “SetModel” section.
   • Add the “SetModel” section to the Priority settings in the “Settings” section
   • Add a line to the “ModelAlias” section to refer to a user exit script that will truncate the model name at the “(“
   • Create a “MMApplications” DB lookup where the “Model” column is matched with the “ModelAlias”
3. Create a “User Exit” script and place it in the same directory as the CustomSettings.ini file to truncate the Model name.

Here are samples of the userexit script and CustomSettings.ini.

Customsettings.ini:

[Settings]

Priority=SetModel, MMApplications, Default

Properties= ModelAlias

[SetModel]

ModelAlias=#SetModelAlias()#

Userexit=Userexit.vbs

[MMApplications]

SQLServer=AHSL99

Database=BDD2007AdminDB

Netlib=DBNMPNTW

SQLShare=logs

Table=MakeModelApplications

Parameters=Make, ModelAlias

ModelAlias=Model

Order=Sequence

User Exit script:

          Function UserExit(sType, sWhen, sDetail, bSkip)

                    UserExit = Success

          End Function

          Function SetModelAlias()

                    if Instr(oEnvironment.Item("Model"), "(") <> 0 then

                              SetModelAlias = Left(oEnvironment.Item("Model"),Instr(oEnvironment.Item("Model"), "(") - 1)

                              oLogging.CreateEntry "USEREXIT - ModelAlias has been set to " & SetModelAlias, LogTypeInfo

                    else

                              SetModelAlias = oEnvironment.Item("Model")

                              oLogging.CreateEntry " USEREXIT - ModelAlias has not been changed." , LogTypeInfo

                    End if

          End Function

I you would like further information regarding the functionality of database lookups and user exit scripts please refer to the following blog:

Http://blogs.technet.com/benhunter/archive/2007/03/17/understanding-bdd-rule-processing.aspx

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I have previously mentioned how to create a custom task sequence to save time when testing application installation in BDD 2007.

You will find the article here.

There are two problems you could run into when using this process with Deployment 4.

1. If you create a custom task sequence based on a REPLACE template then it fails saying it cannot find \distribution$\control\ts.xml
2. If you use a different template then I get an error saying you haven’t specified a deploymenttype value.

These problems are caused by checks put in place to verify the type of task sequence being executed. This design essentially means that you cannot use a custom task sequence unless you include an “Install Operating System” task in the task sequence.

Don't worry, there is no need to despair...... I have a solution.

1. Simply add an “Install Operating System” task to your the task sequence and then you can disable it.
2. Never use a Replace template to create your custom task sequence.

The task sequence and the process will then function as it would in BDD 2007.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Hands up everyone who has tried to add an application to the task sequence and been frustrated by the fact that you can not control the order of the applications. Instead you have too scan through a list of applications that are ordered by the time you imported the application into the Deployment Workbench. Well this has frustrated me for a while and can become a real issue when you have a large number of applications to choose from.

It turns out that it frustrated a fellow consultant (Mark Piggot) down here in New Zealand, so he got one of our development consultants (Mark Rees) to create a little utility (see attached file) that sorts the applications alphabetically. It does this by simply sorting the contents of the applications.xml file.Then as if by magic you will have much less trouble finding your application when adding it to a task sequence.

To use this utility simply run the command:

BddSort.exe -filename <path to control folder>\applications.xml

This will then create a file called applications.xml.sorted which you can rename and use to replace the original applications.xml file.

This application will change the applications.xml header to include the following information:

<?xml version="1.0" ?>

 <applications xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

This should not be an issue but if it concerns you then you can simply update the header to look like this:

<applications>

                                Before                                                                                  After!!!

NOTE: Please remember to backup the orginal applications.xml file before making any changes.

NOTE: No warrantee of any kind, express or implied, is included with this utility; use at your own risk.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

When using BDD to deploy and OS one of the first things it does is detect information about the hardware via WMI. As part of this detection process it determines the Chassis Type of the machine. By using this information we can configure the rules to perform different tasks based on the hardware type. For example we could base the computer name of the machine on the hardware type. So for example if the client type is a laptop then the computer could be the letter "L" followed by the computers serial number (also collected via WMI).

The chassis type is identified by the numeric value returned to BDD via a WMI query. These numbers are then matched to specific hardware types , these values and their corresponding hardware types are listed below:

Laptop:   8, 9, 10, 11, 12, 14, 18, 21

Desktop: 3, 4, 5, 6, 7, 15, 16

Server:    23

This information is returned in the form of a boolean value, so if the chassis type is a laptop then the %IsLaptop% variable will be true.

So with this in mind the following example shows how to name a machine based on the hardware type identified by BDD. I have also included an empty section that could be used if you machine was not a laptop ([Laptop-False]).

[Settings]

Priority= ByDesktopType, ByLaptopType,ByServerType, Default

[ByDesktopType]

Subsection=Desktop-%IsDesktop%

[ByLaptopType]

Subsection=Laptop-%IsLaptop%

[ByServerType]

Subsection=Server-%IsServer%

[Desktop-True]

ComputerName=D-%SerialNumber%

[Laptop-True]

ComputerName=L-%SerialNumber%

[Server-True]

ComputerName=S-%SerialNumber%

[Laptop-False]

[Default]

For further information on understanding rule processing please refer to this blog.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

I have previously published posts detailing how you can perform bulk updates to the database and how you can use the LTI wizard to prompt for information in ZTI deployments. Now I think it's about time I show you how to combine these two features and populate the database with the information gathered by the wizard.

This process can be very useful when you are trying to build a client that is not in the database. Generally the build process starts and a database lookup is performed to determine the settings, but there are no settings in the database so the build fails. This is not always the best situation and you may not want to manually update the database every time you need to build a computer.

So with this in mind I have created the solution detailed in the flowchart below:

The following steps detail how to implement this process.

Copy files to the ZTI$ share

First we must copy the following files to the deployment point. I have included a sample Custom_Wizard_Definition_ENU.xml file in the attached ZIP file.

• BackButton.JPG
• Custom_Wizard_Definition_ENU.xml
• DeployWiz_Initialization.vbs
• DeployWiz_Validation.vbs
• Wizard.css
• Wizard.hta
• Wizard.ico
• WizUtility.vbs

Update the deployment point

Next we must update the deployment point bootstrap.ini file. I have included a sample bootstrap.ini and UserExit.vbs files in the attached zip file.

To update files on the deployment point, complete the following steps:

  1. Add the CheckDatabase value to the properties line of the deployment point bootstrap.ini file:

Properties=CheckDatabase

  2. Add the following lines to the [Default] section of the deployment point bootstrap.ini file:

CheckDatabase=#CheckDB#

UserExit=UserExit.vbs

OSDInstallProgram=Install

  3. If no user exit file currently exists, copy the userexit.vbs file to the ZTI folder.

  4. Copy the CheckDB function from the userexit.vbs file provided to the current file.

  5. Replace the <DB SERVER> value in the userexit.vbs file with the name of the server hosting the BDD 2007 database (for example, Data Source=MyDBServer).

Update the Custom_Wizard_Definition_ENU.xml File

The Custom_Wizard_Definition_ENU.xml contains the control information for the wizard. You must customize this file to meet your requirements. The sample file included in the attached file will only prompt for the computer name, but this can easily be updated to include other information such as roles or OU information.

So I hope this helps, it may not be used by everyone but there are certainly times when you will find this process invaluable. 

For more detailed information about updating the database please refer to this post.

For more detailed information about using the LTI wizard with ZTI please refer to this post.

Note: These scripts are set up to use the MAC address as a unique key to store information in the database. You can easily update the scripts to use other values, such as a serial number or asset tag, if required.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

When troubleshooting the BDD deployment I often make a change then test. Then find that I need to make another adjustment and test again. Well this this process can be time consuming especially if you have to wait for Windows PE to reboot each time.

Well I have a couple of tips to help speed this process up!

When troubleshooting BDD 2007 deployment issues there is a quick way to restart the deployment process without having to restart the computer. I detail methods for both LTI and ZTI deployments that should save you a lot of time in the deployment process below.

ZTI Deployments

The first thing you need to do is make sure that you have enabled the "Lab Shell". The Lab Shell allows you to start a command prompt from within Windows PE. Once you have enabled the Lab Shell then you can use the methods detailed below once the build process has failed:

       1. Delete the MININT folder - This folder contains information from the previous failed deployment and can cause problems if not removed.

                      rd C:\MININT /q/s

       2. Delete the _SMSTaskSequence - This folder contains information from the previous task sequence and can cause problems if not removed.

                      rd C:\_SMSTaskSequence /q/s

       3. Remove any network connections - SMS will try to reconnect to the distribution point, this process will fail if these connections exist.

                      net use * /d

       4. Restart the build process

                      OSDShell

LTI Deployments

The process to restart an LTI deployment is also very similar to the ZTI process. Once the build process has failed perform the following steps:

       1. When the build process fails you should close the summary window using the window close button in the top left hand corner. Do not use the finish button.

       2. Maximize the command prompt window.

       3. Delete the MININT folder - This folder contains information from the previous failed deployment and can cause problems if not removed.

                      rd C:\MININT /q/s

       4. Delete the _SMSTaskSequence - This folder contains information from the previous task sequence and can cause problems if not removed.

                     rd C:\_SMSTaskSequence /q/s

       5. Remove any network connections - SMS will try to reconnect to the distribution point, this process will fail if these connections exist.

                      net use * /d

       6. Restart the build process

                      X:\Deploy\Scripts\LiteTouch.wsf

Hopefully these tips will help save you time when troubleshooting the BDD deployment process.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.