MDT 2010 New Feature #16: PowerShell support

It seems like an understatement to just say that MDT 2010 now supports PowerShell to automate Deployment Workbench administrative tasks.  Really, Deployment Workbench has been completely re-architected – all operations you perform through the UI are turned into PowerShell commands that are executed by the PowerShell engine, providers, and cmdlets.  As a result, a significant portion of the Deployment Workbench has been rewritten – this is definitely no small change.

Behind the scenes, there are a few pieces to make this work:

  • A custom MDT 2010 PowerShell provider.  This exposes all the contents of a deployment share, including all the folders, all the items in those folders, all the properties of those items, etc.  These contents are accessible just like the file system or registry (both of which have their own PowerShell providers).  You use standard built-in cmdlets to access the
  • Several custom MDT 2010 PowerShell cmdlets to perform MDT-specific “things”.

All of these are contained in a single PowerShell snap-in, so before you can use the PowerShell provider yourself you need to load this snap-in.  This is pretty easy to do with a single PowerShell command:

Add-PSSnapIn Microsoft.BDD.PSSnapIn

First let’s talk more about the PowerShell provider.  In order to use it, you need to create a “PowerShell drive” (see for details).  This is like mapping a network drive: creating a logical “drive” that is used to navigate through the logical contents of a deployment share.  The MDT PowerShell provider doesn’t create any drives by default, so you need to create one or more.  This can be done in one of two ways.  First, the manual way:

New-PSDrive -Name MyDrive -PSProvider MDTProvider -Root \\server\DeploymentShare$

In this case, the logical drive name assigned will be “MyDrive” (you could use whatever value you like), it is created using the MDT PowerShell provider which is called “MDTProvider” (always), and it points to the deployment share at \\server\DeploymentShare$.  Once the drive is created, you can navigate through it and look at the contents.

But first, let’s talk about the second way of creating MDT drives.  The Deployment Workbench keeps track of all deployment shares that you opened through the UI.  To get the same ones through PowerShell, you can execute a single cmdlet:


You’ll see the names and paths for all restored drives, e.g. “DS001” for the first deployment share \\server\DeploymentShare$.

OK, so now let’s assume you have at least one PowerShell drive, “MyDrive”.  To see the top-level folders, try this:


Want to see all the drivers?  Try:

dir 'MyDrive:\Out-of-Box Drivers'

Want to create a new folder?  Try:

mkdir ‘MyDrive:\Out-of-Box Drivers\New Folder’

Want to see all the deployment share properties?  Try:

Get-ItemProperty MyDrive:

Want to update the deployment share (generating boot images)?  Try:

Update-MDTDeploymentShare -Path MyDrive:

You can use pretty much any of the standard PowerShell cmdlets for drive providers:

  • Get-Item (to retrieve a specific item or folder, e.g. a driver)
  • Copy-Item (to copy an item or folder from one folder to another, or from one deployment share to another)
  • Move-Item (to move an item or folder to a different folder or deployment share)
  • Remove-Item (to delete an item or folder)
  • Rename-Item (to rename an item or folder)
  • Get-ChildItem (to retrieve all the items or folders in a particular folder, alias “dir”)
  • New-Item (used typically to create a new folder, alias “mkdir”)
  • Get-ItemProperty (used to retrieve specific properties of an item or folder)
  • Set-ItemProperty (used to set specific properties of an item or folder)

What if you want to create new applications, import drivers, create task sequences, update the deployment share, etc.?  That’s where the other MDT cmdlets come in:

  • Import-MDTApplication (to import or create a new application)
  • Import-MDTDriver (to import one or more drivers from the specified path)
  • Import-MDTPackage (to import one or more packages – security updates, language packs, and other components – from the specified path)
  • Import-MDTTaskSequence (to create a new task sequence from one of the MDT templates)
  • Update-MDTDeploymentShare (to update the MDT deployment share, including creating boot images)
  • Update-MDTMedia (to update a media folder and ISO)
  • Update-MDTLinkedDS (to replicate content to another deployment share)
  • New-MDTDatabase (to create an MDT database)
  • Update-MDTDatabaseSchema (to upgrade an existing database to MDT 2010, adding all the necessary new columns)
  • Get-MDTOperatingSystemCatalog (to retrieve or create an operating system catalog for a custom image so that you can edit the unattend.xml using WSIM)
  • Get-MDTPersistentDrive (to retrieve the list of persistent drives, those opened in Deployment Workbench)
  • Restore-MDTPersistentDrive (to create PowerShell drives for each persistent drive opened in Deployment Workbench)
  • Add-MDTPersistentDrive (to add a new PowerShell drive to the persistent drive list)
  • Remove-MDTPersistentDrive (to remove an entry from the persistent drive list)

The Deployment Workbench does all of its work using the cmdlets listed above.  In many cases, the wizards will show you these PowerShell commands, so that you can copy and paste them into your own PowerShell scripts.

With any luck, we’ll post more PowerShell script samples in the coming months.

Comments (2)
  1. Are you using MDT 2010 Beta 2 for that?  If so, please try it with MDT 2010 RC.

    The saving of the XML files is done in the background.  With MDT 2010 Beta 2, if PowerShell.exe exited before that save happened, you’d lose the changes.  With MDT 2010 RC, we fixed that problem – it will now wait for the background saves to complete before allowing PowerShell.exe to exit.


  2. Anonymous says:

    I’ve taken the Add-MDTApplication cmdlet as output by the MDT workbench and placed it in a ps1 file.  I’ve then called this from a batch file and the powershell script appears to execute successfully.

    Only issue is that while the source files are copied to the correct location, the application isn’t added to the applications.xml document.  An Applications.LOCK file is created in the Control folder but the xml doesn’t get updated.  If I run each command in the PS1 file manually, the update works successfully.  

    Any ideas what I’m missing here.  My aim is to script up the addition of apps to the workbench so I can roll apps out to multiple sites easily.  The powershell support seems to be purpose built for this, getting it into a ps1 file would be awesome.


Comments are closed.

Skip to main content