Well I am sad to say that this is my last post. But don't worry I have something better.
I have been thinking for quite a while that there are so many different blogs out there with useful deployment information. This is great but it can be difficult to keep track of them all, there must be a better way.
With this in mind myself and a number of other guys that have deployment related blogs have decided to combine our efforts into one blog called "The Deployment Guys".
But that is not all.... We have also managed to convince a number of deployment gurus from within Microsoft Services that do not currently have blogs to contribute. These are guys that have great information to contribute and will really add something to the blog.
So look out for posts from Richard Smith, Daniel Oxley and myself as well as a host of others. We have a lot planned.
I have high hopes for this new blog hopefully you will find it useful as well.
So subscribe to the RSS feed and enjoy.
http://blogs.technet.com/deploymentguys
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.
Well it looks like I no longer have to answer the question "when will Microsoft Deployment be released?" with the response "sometime soon :)".
Microsoft Deployment is now released!!
I wont go into all the details of what MDT does, you will find that information in many blogs (including my previous and future posts) and within the MDT documentation itself. Instead I would simply congratulate the development team for producing a worthy successor to BDD.
If you want to download MDT then you will find it here.
One of my fellow Microsoft Services consultants from the UK Adam Shepherd, has just had an article published in TechNet Magazine.
The article provides advice on how to scale BDD. This includes how to to support multiple databases, use DFS-R and how to leverage WDS.
The advice is based on learning's from real world so you should find it practical. If nothing else it should help you further understand just how flexible BDD really is.
So go out there and read this article and remember to keep an eye out for future articles from Adam, they will be good!
PS. It is worth having a good look around TechNet Magazine as there are a number of good deployment articles in previous issues.
The big secret is now out!
BDD has officially had a name change, the next version will be called Microsoft Deployment. I was hoping the new name would be "the solution accelerator formerly known as BDD" but I don't think that even made it to first cut because the acronym would have been too long (TSAFKABDD).
I think it is fairly obvious that now the server and desktop deployment tools had been unified into one solution accelerator that it needed a a more appropriate name.
So start making up new acronyms as I don't want to type Microsoft Deployment out every time. My bet is on MDT, what do you think will stick?
As well as announcing the new name the Microsoft Deployment Team have released Microsoft Deployment RC1. This contains a number of enhancements over Deployment 4 Beta 3 but there a three that are particularly dear to my heart...
The MDT guys have noted the number of people that create custom task sequences to test application deployment. With this in mind they created a new task sequence template that allows you to create a custom task sequence. This means that you no longer have to create a task sequence that includes a disabled operating system deployment task to get a custom task sequence to work.
The second thing that you may notice is the nice interface they have created for configuring BitLocker, I have included a screen shot below:
And the third thing I like is the little piece of SOLUTIONACCELERATORS branding they have added to the bottom of the properties windows of every task :)
So everyone, "Act Faster. Go Further" and download Microsoft Deployment RC0 from the following location:
https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=14&DownloadID=8689
P.S. I hope you like my gratuitous use of the Solution Accelerators slogan! The marketing guys would be proud:)
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:
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:
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"
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.
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.
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:
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:
In both of these situations I want to ensure that the computer is in the correct OU when the deployment is finished.
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
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.
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.
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.
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.
The task sequence and the process will then function as it would in BDD 2007.
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:
TIP - Make sure you are using BDD patch 1 as this includes a number of fixes.
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:
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:
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”.
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.
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.
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.
Once the deployment point is configured we can capture the image.
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)
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:
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”.
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:
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.
Here is a simple tip when using BDD. DO NOT use special characters anywhere. They cause problems.
Let's illustrate this with an example. I create an application with the name "AT&T Dialer". Then when I add this application to the task sequence I see that it is now displayed as "INSTALL-ATT Dialer".
You can also have problems when you use special characters in your password. This causes issues when BDD tries to save the password to the unattend.xml file, causing the build to fail.
So my simple advice is, avoid using special characters as this is save you time trying to debug those "weird" errors.
Well for those of you that have already installed Deployment 4 may have notice that Deployment 4 does not use builds anymore. Task sequences are used instead.
Task sequences are very similar to builds with a few subtle changes.
All of the task sequence configuration information is now maintained within the task sequence itself, NOT in the general and settings tabs settings tab.
So let’s compare builds and task sequences. The screen shots below are from a BDD 2007 build.
So where exactly is this information stored in Deployment 4?
The information is stored with the task that uses it. So for example let’s have a look at the operating system deployment task. As you can see from the screen shot below there is a drop down box that allows you to choose an operating system.
Now let’s look at the disk partitioning task. As you can see below this task allows you to specify the disk configuration in the task itself... NICE ... no more mucking around with diskpart files!!
I really like this new approach to to configuring settings. I think it will prove to be much more flexible than the way builds are configured.
Unfortunately there is not currently an interface to configure the following operating system configuration settings:
Don’t panic! The Deployment 4 team is working on adding this functionality to the operating system deployment task before it is released. For now you will have to manually update the configuration files. As a teaser I have included a screen shot from an SCCM task sequence to show you the “apply windows settings” task, as this is what the final solution might look like.
For more information about task sequences please have a look at this post by Michael Niehaus.
It looks like the BDD team has been very busy! They have just released Deployment 4 Beta 3 the worthy successor to BDD 2007.
Having spent a reasonable amount of time testing Deployment 4 I must say I am very impressed, particularly when it is combined with SCCM.
So what is it that has impressed me about Deployment 4?
These are only a few of the improvements, more detailed information is included in the release notes.
But the thing I like the most about deployment 4 is the subtle changes, those little improvements to the deployment workbench and task sequences that make deployment easier.
While there are significant improvements from BDD 2007 the overall concepts remain the same. So, you should easily be able to get up to speed.
So go and test it for yourself (particularly with SCCM). I know you will be pleasantly surprised!
Deployment 4 is now available for download now at the following location:
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.
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:
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
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.
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:
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:
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
[Settings] Priority=Default Properties=StagingOU,DomainDC
[Default] StagingOU=OU=Staging,DC=domain,DC=com DomainDC=DC01 DomainAdminUser=Account DomainAdminDomain=domain DomainAdminPassword=password
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.
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.
If you want to see how to move the computer to it's final OU (MachineObjectOU) then have a look at this blog post.
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.
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
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.
4. Delete the _SMSTaskSequence - This folder contains information from the previous task sequence and can cause problems if not removed.
5. Remove any network connections - SMS will try to reconnect to the distribution point, this process will fail if these connections exist.
6. Restart the build process
X:\Deploy\Scripts\LiteTouch.wsf
Hopefully these tips will help save you time when troubleshooting the BDD deployment process.
In the past I have written a number of blogs about how you can use the LTI wizard to create a customized front end for your ZTI deployments. They detail both how to use the wizards to gather information, how to automatically enter this information into the database once you have gathered it and hint at how you could extend this functionality yourself without too much trouble.
So with that preface I must direct you all to Johan Arwidmark's site. Johan has created a pretty good ZTI front end in my opinion (as well as his own) using some of the techniques that I mentioned. He has taken it a lot further though and created a front end with a number of impressive features that is easy to understand and use. These features include:
However the feature that I am most impressed with is how it demonstrates the usefulness and simplicity and flexibility of the BDD LTI wizard. So if this front end doesn't provide all of the features you are looking you should be able to easily adjust it to meet your requirements.
So go and have a look at it yourselves I am sure you will mind it most useful!
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.
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.
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
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).
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.
I will be presenting a session at TechEd New Zealand on Monday covering Vista Deployment using BDD 2007. So if you happen to be attending make sure you come along, introduce yourself and ask lots of questions. I would like to put some faces to the names I regularly communicate with.
There will also be some fantastic giveaways during the session so it will be worth your while to attend!
I am often asked how I perform bulk updates to the BDD 2007 database. BDD 2.5 provided a tool to perform this task but BDD 2007 does not. To get around this issue I use a simple CSV import process.
Unlike the BDD 2.5 the BDD 2007 database is made up of multiple tables, so when adding computers to the database you must update all of the tables related to those computers.
For example when creating a new computer you must first create a record in the ComputerIdentity table. This will create an ID that links the computer to the MAC Address, UUID, Asset tag or Serial Number. Then you must create a record in the Settings table that links the ID created in the ComputerIdentity table with the settings that you want to apply to that computer. If you want to assign a role to the computer then you must create a record in the Setting_Roles table that associates the computer ID with the role.
Hopefully you are starting to see a pattern here...
This is not too hard to do but requires is is a little more planning when creating a script that will perform a bulk import of computers.
I have attached a sample script to this post that performs the following tasks:
1. Reads the specified CSV file and extracts the following five properties: a. Computer Name b. MAC Address c. Machine Object OU d. OSD Install Package e. Computer Role (Single role only)
2. Creates the computer object
3. Assigns the correct OSDInstallPackage and MachineObjectOU to the computer
4. Assigns a role to the computer
The script usage is as follows:
cscript Computer-Import-CSV.vbs <Computers CSV file> <Database Server> <Database Name>
For example:
cscript Computer-Import-CSV.vbs "C:\computers.csv" DBSERVER BDDADMINDB
This script is just a simple example but hopefully it will get you started towards creating your own scripts to perform bulk imports to the BDD database. It should be fairly easy to update the script to import the settings you require. So go forth and create your own versions of this script and if you come up with any other cool idea's don't forget to tell me what you did:)
Note: I have attached a sample CSV file for your viewing pleasure!
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.
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
[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.
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.
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:
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%.
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:
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.
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.
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
For all of you that are new to BDD 2007 (and some of those that aren't) I would highly recommend getting your hands on the "Quick Start for BDD 2007" white paper. As it says it will help you quickly get started with BDD without the need for wading through the BDD documentation. This can be obtained from the BDD download site here. The document is not included within the BDD MSI file but can be downloaded from the same web page as the BDD 2007 MSI.
There is also a second white paper available in the same location that is worth a read called "Windows Vista Deployment Tools Overview". This provides an overview of the numerous tools that BDD leverages to perform deployments.
Note: I would strongly recommend that you take the time to review the BDD documentation, it is full of great information and resources. You will find this documentation located in the BDD folder after installation(.\BDD 2007\Documentation).
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.
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.
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.
[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
[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
[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
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
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.
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
[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"
[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"
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!
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.
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
[CSettings]
SQLServer=SERVERNAME
Database=BDDAdminDB
Netlib=DBNMPNTW
SQLShare=logs
Table=ComputerSettings
Parameters=MacAddress
ParameterCondition=OR
The critical components of the database section are:
Database connectivity issues – There are a number of issues that can stop the client connecting to the SQL server, these are detailed below:
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:
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.
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:
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.
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:
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
Windows PE 2004 - Windows XP
Windows PE 2005 - Windows 2003
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, \
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, \
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"
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"
To automatically integrate the driver files into Windows PE a folder structure must be created to support the added files.
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.
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.
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"
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.
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.
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.
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.
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.
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.
http://www.deployvista.com/Blog/tabid/70/EntryID/18/Default.aspx
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
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:
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.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
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
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.
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.
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.
Well the first patch for BDD 2007 has been released, download it here.
This fixes a number of those niggling BDD issues, hopefully making your BDD experience a happier one!
Here are my highlights:
Be sure to use the correct installation command line as detailed by Michael Niehaus. If you do not install the patch in the correct manner you may find that it has changed your customized scripts or even updated the location of the distribution share in the registry. Here are some alternatives:
1. Replace all the files with new versions from the patch, without disturbing registry entries:
msiexec /update BDD2007_x86_Patch1.msp REINSTALL=ALL REINSTALLMODE=as
2. Update without replacing modified scripts:
msiexec /p BDD2007_Patch1_x86.msp REINSTALL=ALL /quiet