BDD 2007 and PowerShell

  • Article

I've hinted several times that it is possible to use PowerShell to interact with BDD 2007, basically to perform the same functions via a PowerShell script that you can do by using the Deployment Workbench MMC snap-in.  If you were at MMS 2007, you may have seen a glimpse in a sample script presented in my advanced ZTI session.  Of course now you want to know how you can do it yourself.

First, a little background information.  The Deployment Workbench is an MMC 3.0 snap-in written in C#.  It is a single .NET DLL, Microsoft.BDD.Workbench.dll, loaded automatically by MMC when you select the "Deployment Workbench" shortcut.  It presents the user interface of the snap-in, but it doesn't do the real work.  That's left for another .NET C# component, Microsoft.BDD.ConfigManager.dll (ConfigManager for short) responsible for all data items maintained by BDD 2007.  ConfigManager has no user interface; it is a data layer object, designed solely for interacting with the underlying XML and database data items.

Now technically ConfigManager is not a PowerShell cmdlet; using it is not as simple as using the built-in cmdlets.  But, because PowerShell interacts so easily with .NET components, it is able to make use of all the same objects, methods, and properties that Deployment Workbench uses from ConfigManager.  So, you can build scripts that act exactly like the Deployment Workbench.  To see what all of those objects, methods, and properties are, you can check out the BDD 2007 source code that was released last week, available at https://www.microsoft.com/downloads/details.aspx?FamilyID=6a67f884-d629-4962-bd0a-c51bad560354&displaylang=en.

To help you along, here's a brief tutorial.  At the top level of ConfigManager is a "Manager" class used to access all the other classes.  The main classes correspond to the nodes that you see in Deployment Workbench:

  • OSManager
  • BuildManager
  • DriverManager
  • DriverGroupManager
  • ApplicationManager
  • PackageManager
  • DeployManager
  • DatabaseManager

All of these manager classes behave similarly, enabling the enumeration of available items, adding new items, removing existing items, etc.

By this point you're probably saying "enough babble, show me how to do it."  OK, here's a simple example PowerShell script that lists all of the available drivers in a simple data table:

[System.Reflection.Assembly]::LoadFile("C:\Program Files\BDD 2007\bin\Microsoft.BDD.ConfigManager.dll")
$manager = [Microsoft.BDD.ConfigManager.Manager]
$manager::DriverManager.GetDataTable()

Pretty simple.  Now, let's show something a little more interesting.  The following script will look at each driver and place each into a driver group named after the driver's manufacturer:

# Initialization

[System.Reflection.Assembly]::LoadFile("C:\Program Files\BDD 2007\bin\Microsoft.BDD.ConfigManager.dll")
$manager = [Microsoft.BDD.ConfigManager.Manager]

# Process each driver

foreach ($driver in $manager::DriverManager)
{

# See if the group already exists

$driverGroup = $manager::DriverGroupManager.Find($driver["Manufacturer"])
if ($driverGroup -eq $null)
{
write-host "Adding driver group for" $driver["Manufacturer"]

$driverGroup = $manager::DriverGroupManager.CreateNew()
$driverGroup["Name"] = $driver["Manufacturer"]
$manager::DriverGroupManager.Add($driverGroup)

}

# Make sure the driver is in the group

if (-not $driverGroup.IsMember($driver["guid"]))
{
write-host "Adding driver" $driver["guid"]
$driverGroup.AddMember($driver["guid"])
$driverGroup.Update()
}

}

Hopefully this is enough to get you thinking about the possibilities.  It's certainly not a complete tutorial, but give it a try!  (If you get stuck, drop me an e-mail or post a comment.  I'd be happy to provide more simple samples, but need you to tell me what might be useful.)

A warning before wrapping up:  Think of the PowerShell session as another Deployment Workbench operating against the same configuration.  Running two Deployment Workbenches at the same time can have some interesting results, with one overwriting changes made from the other.  The same can happen between a PowerShell session and a Deployment Workbench, so be careful.