I am sure that many of you a very keen to use the functionality demonstrated in the PowerShell Guy's BDD 2007 teaser. Well be teased no more..... it’s available!
http://thepowershellguy.com/blogs/posh/archive/2007/06/14/powertab-0-93-powershell-tab-expansion-scripts-library.aspx
This is a fantastic tool, so dive in and discover all of the BDD functionality exposed via PowerShell.
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.
Those of you who are keen to leverage PowerShell to manage BDD will find the following teasers from the PowerShell Guy very interesting:
Teaser #1
Teaser #2
They should help you understand the functionality that can exposed by PowerShell, I believe the potential is HUGE!
Now hopefully Marc will release PowerTab 0.93 quickly because I am desperate to have a play!
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">
<?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.
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:
Now create an application with the following settings:
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 :
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.
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
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]
[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.
When testing BDD in a Lab environment or even some customer sites I find that when I update an OSD package it takes a long time for the package to be distributed to the distribution points. This delay is usually due to the time it takes to compress the WIM image (or the network speed). Compressing the WIM strikes me as pointless as the WIM format is already compressed.
Did you know that you can exclude certain file extension types from being compressed by SMS?
You simply need to update the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Compression\DontCompressExts
By default it contains the following extensions:
".cab;.zip;.arj;.rar;.jpg;.jpeg;.wma;.wmv;.mpg;.mpeg;.mov"
So just add the WIM extension:
“cab;.zip;.arj;.rar;.jpg;.jpeg;.wma;.wmv;.mpg;.mpeg;.mov;.wim"
I have found this can make a big difference in lab environments and in those customer sites with overworked SMS servers.
This an extremely simple tip (my favourite type) but hopefully it will save you lots of time.
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.
BDD 2007 has a great technique of determining which drivers should be applied to the clients being deployed. It maintains a central driver library and then deploys the drivers based on the plug and play ID’s of the client.
So for example if we where deploying an HP DC7700 it would see that it has a Intel Pro 1000 network card and apply the appropriate driver to the client. This process works well until you realize that once we add the drivers to the driver library for the DC7700 we can affect the drivers that are applied to other hardware models.
This may not be a problem but a lot of sites must validate the drivers that are deployed to an image and they do not want unintended drivers to be deployed to their client devices.
To get around this issue BDD uses Driver Groups. Drivers can be added to a Driver Group and then you can specify the driver groups each model will receive. Through this process you can ensure that each hardware model will only receive the drivers that you specify.
This is good but unfortunately managing driver groups can be a time consuming and prone to errors. To add a driver to a group you need to open the drivers properties select the groups tab and then select the driver group that you wish to add this computer too. This process must be repeated for each driver you wish to add to the group.
The second issue that I have is determining what drivers are members of each group. You must look at each driver individually, a task that no one is keen to perform.
To get around these issues I have created a couple of PowerShell scripts, the first will import a set of drivers and add them to a specified group, and the second produces a CSV file listing each driver and the group it belongs to. These are relatively simple scripts but they should show the some of the ability's of PowerShell when managing BDD 2007. For further information on using PowerShell with BDD please refer to Michael Niehaus' blog.
IMPORTANT NOTE - When running PowerShell scripts please ensure that the BDD Workbench is closed.
Import Drivers and add to Driver Group
This script will import all the drivers in a specific folder and then add those drivers to a group. This script first imports all the drivers in the specified folder then it iterates through all the drivers in the driver library and adds any drivers that are a member of of only one group ("All Drivers") too the specified Driver Group. I have made the assumption that all drivers will be a member of the "All Drivers" group and one other group, using this assumption we are able to identify the newly added drivers and add them to the desired group.
Note - If the driver group name or source folder contains spaces then these should be enclosed in single quotes, for example:
powershell .\Import-Drivers.ps1 'C:\Drivers\IBM T60' 'IBM T60'
# //***************************************************************************# // ***** Script Header *****# //# // File: Import-Drivers.ps1# //# // Purpose: Imports Drivers and assigns them to a group# //# // Usage: powershell .\Import-Drivers.ps1 [Drivers Location] [Driver Group]# // Drivers Location – The folder containing the drivers to be imported# // Driver Group - BDD Driver group name. Driver group to which the drivers will be added. - This is case sensitive.# //# // Notes:# //***************************************************************************Param( [string]$DriverLocation, [String]$Group)
[System.Reflection.Assembly]::LoadFile("C:\program files\BDD 2007\bin\Microsoft.BDD.ConfigManager.dll")$manager = [Microsoft.BDD.ConfigManager.Manager]write-host "Driver Location: " $DriverLocationwrite-host "Driver Group: " $Group$dgmgr = $manager::DriverGroupManager$dmgr = $manager::DriverManager
# Refresh the Driver Groups to ensure we can see any new groups$dgmgr.Refresh()
# See if the group exists $dgadd = $dgmgr.Find($Group)if ($dgadd -eq $null){ write-host "Driver Group does not exist, please specify "} else{ $dmgr.Import($DriverLocation) $dmgr.Refresh() foreach ($driver in $dmgr) { # Count the number of gr0ups that this driver is a member of $intcount = 0 foreach ($DriverGroup in $dgmgr) { # Make sure the driver is in the group if ($driverGroup.IsMember($driver["guid"])) { $intcount++ } } if ($intcount -eq 1) { # Make sure the driver is in the group if (-not $dgadd.IsMember($driver["guid"])) { write-host "Adding driver " $driver["name"] " to group " $Group $dgadd.AddMember($driver["guid"]) $dgadd.Update() } } }}
Reporting on Driver Groups
This script simply lists each group and the drivers that are a member of the group in a CSV format. It is very simple but does the job!
# //***************************************************************************# // ***** Script Header ***** # // # // File: DGMembershipReport-csv.ps1 # // # // Purpose: Creates an CSV report on driver group membership # // # // Usage: powershell .\DGMembershipReport-csv.ps1 # // # // Notes: # //***************************************************************************
[System.Reflection.Assembly]::LoadFile("C:\program files\BDD 2007\bin\Microsoft.BDD.ConfigManager.dll") $manager = [Microsoft.BDD.ConfigManager.Manager] $CSVFilePath = ".\DriverGroups.CSV" $strDate = get-date -uformat "%Y/%m/%d" $strOutputString | out-file -filepath $CSVFilePath -encoding ascii
# Create and write CSV to file $strOutputString = "Driver Group Membership Report" $strOutputString | out-file -filepath $CSVFilePath -encoding ascii -append $strOutputString = "Date: " + $strdate $strOutputString | out-file -filepath $CSVFilePath -encoding ascii -append
foreach ($DriverGroup in $manager::DriverGroupManager) { foreach ($driver in $manager::DriverManager) { if ($driverGroup.IsMember($driver["guid"])) { $strOutputString = $driverGroup["Name"] + "," + $driver["Name"] $strOutputString | out-file -filepath $CSVFilePath -encoding ascii -append } } }
The User State Migration Tool has updated to address two issues:
1. You can now install USMT on computers that are running non-English versions of Windows Vista
2. Some settings for local accounts were not being migrated, this has been addressed
If you are using USMT with BDD you will need to use the CAB file workaround described in the BDD 2007 release notes. This essentially means that you will need to manually download he USMT files, build a CAB file using the process described in the release notes, then use that CAB file with BDD.
The new version is 3.0.1 and you can download it here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=799ab28c-691b-4b36-b7ad-6c604be4c595&displaylang=en
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!
When creating your own script to use with BDD it is a good idea to leverage the framework that BDD provides. See my previous blog about how to leverage these functions.
To make this process a little easier on myself I have created the following list which defines the functions that BDD provides, hopefully you will find this as useful as I have.
The first list defines the useful functions that are available via the oUtility object created by ZTIUtility.vbs:
LocalRootPath() – Returns the path of the root folder
LogPath() – Returns the path to the logs folder
ScriptName() – Returns the name of the current script
BootDevice() – Returns the system boot device
StatePath() – Returns the path of the state store, eg C:\MININT\StateStore
ScriptDir() – Returns the directory of the current script
ReadIni(file, section, item) – Reads the specified item from an ini file
WriteIni( file, section, item, myvalue ) – Writes the specified item to an ini file
Sections(file) – Reads the sections in an ini file and stores them in an object
SectionContents(file, section) – Reads the contents of the specified section and stores them in an object
RunWithHeartbeat(sCmd) – Runs command will providing heartbeat information to logs
ComputerName() – Determines the computer name to use for the build process
FindFile(sFilename, sFoundPath) – Returns the location of a file by looking in a number of standard locations
FindMappedDrive(sServerUNC) – Checks to see if a drive is mapped to the specified UNC path and returns the driver letter
ValidateConnection(sServerUNC) – Checks you are connected to the server if not then it will try to connect
MapNetworkDrive(sShare, sDomID, sDomPwd) - Maps a drive letter to the sShare UNC path, returns the drive letter, example: "C:", otherwise returns an error string
VerifyPathExists(strPath) – Verifies if the specified path exists, returns TRUE if path exists
There is also another script that can be referenced for disk utilities, this is called ZTIDiskUtility.vbs. These functions are not class based but can be referenced directly.
GetDiskSize(iDrive) – Returns the size of the specified disk
GetPartitionSize(sDriveLetter) – Returns the size of the specified partition
GetDiskPartitionCount(iDrive) – Returns the number of partitions on a disk, will also log the size of the partitions
GetDiskFreeSpace(iDrive) – Returns the free space available on the specified disk
GetNotActiveDrive() – Returns the active drive
GetBootDrive() – Returns the boot partition
MatchPartitionConfiguration(iDriveIndex, iPartitionIndex, sDriveLetter, iMinSizeMB) - Determine drive status as compared to the custom partition config, return codes are - 0 = Partition exists and meets criteria, 1 = Partition exists and does not meet the criteria, -1= Partition does not exist.
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:
Note: You do not need to declare these objects in your script.
Four classes are defined which perform a number of standard tasks:
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:
It is also important to remember the following key rules when creating your script:
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 NextiRetVal = ZTIProcessProcessResults iRetValOn 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>
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-usWindows 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.
For all of you who want to further understand the inner workings of BDD 2007, the source code is now available!
You will find it here:http://www.microsoft.com/downloads/details.aspx?FamilyID=6a67f884-d629-4962-bd0a-c51bad560354&displaylang=en
This means that you can make modifications, enhancements or perhaps even fix bugs!!If you feel the urge to make changes to the source code for your own use be aware that you may need to reengineer these changes when upgrading to the next version of BDD.
Anyway I know some folks have been waiting for this for a while, so go and have a play with it at least.
The code has been released under the Microsoft Permissive Use license.
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.
When discussing the use of BDD 2007 with partners I like to introduce the concept of "hydration".
Desktop deployment projects tend to be very similar between customers. The desktop master images tend to contain the same roughly the same set of applications, such as Office, Acrobat Reader and perhaps some plug-ins. On top of these applications partners tend to perform the same set of "tweaks" across all customers. Once the standard stuff has been completed they then tend to add a few customer specific applications and tweaks.
In general the number of tasks to create a master image usually numbers at least 30. Setting up BDD to perform all these tasks can be quite time consuming and prone to errors due to typos or perhaps adding things in the wrong order.
To help alleviate these issues I suggest implementing a hydration process. Here are the steps to create this process:
Setup the De-Hydrated environment.
1. Setup BDD in a lab environment, configure BDD with all the standard settings you would normally use at a client site.
2. Once you are happy with your configuration simply remove product keys and any customer specific media (e.g. OS source files).
3. Make a copy of the BDD Distribution folder.
You now have a de-hydrated BDD installation.
When you arrive at a new customers site you can simply copy the de-hydrated distribution folder over the customers distribution folder, and perform a few tweaks and you have a fully configured BDD, FAST. Here are the steps to rehydrate your BDD installation.
1. Install BDD 2007 and the Window Automated Installation Kit (WAIK)
2. Create a lab distribution point.
3. Copy the files from your dehydrated distribution point over your newly created distribution point.
You then need to “re-hydrate” BDD with the customer specific settings, these include:
4. Update the bootstrap.ini and Customsettings.ini with the correct server values for the customer
5. Update the OS source files with the customers source files (Vista, office etc)
6. Update product keys with the customers keys
7. Add any customer specific applications into your build
Now you have a fully customized BDD installation. This process should save heaps of time setting up BDD at each customer, not to mention avoiding some of the tedious tasks around setting up builds. It also has the advantage of creating consistency across customer sites which makes everyone’s life much easier.
Patching XP images is common topic of discussion with many of my customers. When deploying XP should they continuously update their “master” image every time a new patch is released or should they deploy the image without every patch and wait for the machines to be updated automatically via SMS or WSUS?
One of my favourite features of Vista is the ability to patch images offline. This will hopefully mean that the “patching discussion” will be short from now on!!
BDD 2007 leverages this functionality and will patch a Vista client directly after an image is deployed in the Windows PE phase of the deployment. This means that you have a fully patched client when Vista launches for the first time.
Unfortunately for this process to work you will need to update the script that performs the patching process “ztipatches.wsf”. This is due to an a feature that was intended to prevent the addition of the same language pack multiple times.
To fix the problem simply find the following block of code and comment out the line “fLangCanContinue = FALSE”.
fLangCanContinue = TRUE
If not oExistingLang is nothing then
If oExistingLang.Length > 0 then
fLangCanContinue = FALSE
End if
It is also important to know that patches must be converted into a CAB file format before they can be imported into BDD. To do this you simply use the expand command as shown below and then import the expanded CAB file.
Expand patch.msu -F:*.CAB c:\temp
Hopefully with these two tips you will be well on the way to a secure fully patched Vista environment.
UPDATE - 16th June 2007: This fixes detailed in this blog have now been fixed by BDD patch 1. You will find further details here.
NOTE: This process is for Vista only, NOT XP.... sorry.
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:
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
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
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
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
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):
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.
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.
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
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.
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.
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)
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.
This section is divided into two lines, priority and properties which define properties to be gathered and the rule processing order.
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
Priority=CSettings,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.
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
Properties=Partition1Size,Partition2Size
These properties would then be available to use in all BDD scripts.
Once you have defined the rules processing order and any custom variables you can then assign values to these properties.
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.
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:
The best way to explain this section is by an example:
[MSettings] SQLServer=SERVER1Instance=SQLEXPRESSPort=1433Netlib=DBNMPNTWDatabase=BDDAdminDBTable=MachineDetailsParameters=AssetTagSQLShare=Logs
[MSettings]
SQLServer=SERVER1Instance=SQLEXPRESSPort=1433Netlib=DBNMPNTWDatabase=BDDAdminDBTable=MachineDetailsParameters=AssetTagSQLShare=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.
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
UserExit = Successfs
Function CleanMac(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
CleanMac = re.Replace(sMac, "")
This function is then referenced from the CustomSettings.ini as follows:
ComputerName=#CleanMac("%MacAddress%")# UserExit=UserExit.vbs
ComputerName=#CleanMac("%MacAddress%")#
UserExit=UserExit.vbs
Note: The user exit script must be placed in the same folder as the CustomSettings.ini file.
When creating rules within BDD I find that it can take alot of time to tune them to provide the results that I am looking for. Each time I make a change I need to restart the entire build process to see if rules have the desired effect.
It is however possible to run BDD rule processing manually on a computer without needing to completely rebuild a machine. The following process is invaluable in configuring and troubleshooting rule processing within BDD.
The rules that are applied to a particular computer are gathered together using a script called “ZTIGather.vbs” in conjunction with “ZTIGather.xml”. These scripts can be run directly without the needing to launch the entire BDD process.
The steps below detail this process. These can be run when the computer is running the host operating system or WinPE.
Note: The process does not make any changes to the client computer.
I have found that creating a batch file with the following commands helps speed up this process.
rmdir c:\minint /s /q
cscript ZTIGather.wsf /debug:true
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.