WinPE 5.0 x64: Microsoft.SMS.TSEnvironment Unavailable?

Recently I began exploring leveraging Prestart Commands in my Configuration Manager 2012 R2 environment.  I’d previously leveraged them in the form of a “WebService Boot ISO” compliments of Maik Koster.  I figured this would be no big deal, however I found my self running into troubles right out of the gate.

Specifically, the issue I ran into was not being able to load the Microsoft.SMS.TSEnvironment COM Object during the WinPE Prestart phase (before you select a Task Sequence).  Now Technet provides some lovely documentation telling me that this is for sure possible and they even provide a nice little code snippet showing me that it should work.  The only problem, when I try it, I get this ugly error in PowerShell:

Microsoft.SMS.TSEnvironment Error

Strange error so I start doing some searching and come across this forum posting:  WinPE SysNative Forum Post

Ok, easy enough.  I’ve dealt with this before so we’ll just load up the cmd shell in WinPE 5.0 x64 and launch the 32-bit PowerShell.exe.  SysNative Path Not Found

Path not found.  What???  How can this be?  It’s always “just been there”.

Ok, enough whining, just call it from SysWOW64 directly.

No WindowsPowerShell Directory!
No WindowsPowerShell Directory!

Or not.  The WindowsPowerShell directory doesn’t even exist!  No 32-Bit instance of it is here! And for that matter no 32-bit instances of cmd.exe, cscript.exe, etc.  I even confirmed this by mounting the boot image .wim file.

You may now be thinking “Just use DISM to load the 32-bit PowerShell components from the ADK”.  Yeah, doesn’t work.


Just for good measure I loaded up a stock 64-bit MDT 2013 Boot Image (WinPE 5.0 of course) and same result.

Now here is the kicker.  The Microsoft.SMS.TSEnvironment IS available during the preboot phase, BUT (you knew this was coming) you have a very limited window where this environment is accessible.  If you are just trying to test out some code (before making permanent changes to your Boot Images), you can add a Prestart command to launch cmd.exe /k (The ‘/k’ keeps the command window open so you can test).


So long as you are executing your code leveraging this Prestart Method, you can access the Microsoft.SMS.TSenvironment.

I hope this helps someone out there.  Took me a while to track this “limitation” down while testing out new code.



SCCM 2012 Migration: Copying Boot Image Drivers

When migrating from an older SCCM 2007 environment to SCCM 2012, one of the things that doesn’t carry over are your boot images and the drivers that go along with them. During a recent migration from SCCM 2007 to 2012 R2, I found myself in a position just like this. I created new WinPE 5.0 Boot Images however I still had the need to support Windows XP and Server 2003 for just a little longer so I needed to create WinPE 3.1 boot images to support those aging operating systems.

Since I wasn’t able to easily migrate this information over from the old environment using the built-in migration tool, I took to PowerShell to make my own.

Here the gist of the script:

  1. Connect to your old SCCM 2007 Site Server and get all the drivers associated with each boot image you want to reference.
  2. Loop thru all the drivers associated with that boot image and copy the driver source to a new source directory for your new boot images in SCCM 2012 (I use a separate file share for this so I don’t accidentally overwrite something).

NOTE: I’m automatically naming the destination driver folder based on the Driver Name (excluding special characters) and Version. I’ll let DISM sort out everything else later when adding drivers to the WIM.

Here’s the script:

	[Parameter(Mandatory=$true,HelpMessage="Root Directory for Drivers to be copied too.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Your SCCM Site Server.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Your SCCM Site Code.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Boot Image Package ID.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

$BootImage = Get-WmiObject -ComputerName $SCCMServer -Namespace "Root\SMS\Site_$SCCMSiteCode" -Class "SMS_BootImagePackage" -Filter "PackageID='$PackageID'"
$BootImageDrivers = $([WMI]$BootImage.__PATH).ReferencedDrivers

foreach($Driver in $BootImageDrivers){
    $SourcePath = $Driver.SourcePath
    $DriverID = $Driver.ID

    # Get SMS_Driver Detailed Information
    $SMS_Driver = Get-WmiObject -ComputerName $SCCMServer -Namespace "Root\SMS\Site_$SCCMSiteCode" -Class "SMS_Driver" -Filter "CI_ID='$DriverID'"
    $DriverVersion = $SMS_Driver.DriverVersion
    $DriverName = [System.Text.RegularExpressions.Regex]::Replace($($SMS_Driver.LocalizedDisplayName),"[^1-9a-zA-Z_]","_")

    # Create New Driver folder
    $DriverDestinationFolder = New-Item -Path "$DriverDestinationRoot\$DriverName`_$DriverVersion" -ItemType Directory

    Copy-Item -Path $SourcePath -Destination $DriverDestinationFolder -Recurse -Force -Verbose

Integrating Dell XPS 13 USB 3.0 Drivers into WinPE 3.x

As most of you know by now, Dell’s “newly” released XPS 13 Ultrabook contains a USB 3.0 chipset which also means you have to deal with a new, non-native driver for use with Windows PE.  With that, here is a quick and dirty guide on what drivers are needed for the XPS 13 for Windows PE.

Download the drivers:

Obviously the first step is to obtain our drivers.  So lets go to and download them from the appropriate product page.  Here is the direct link to the current version of the driver (You’ll want to check for updated versions as this may become outdated quickly): Dell Fresco Logic xHCI (USB3) Controller FL1009 Series

Extracting the drivers:

The next step is to extract the drivers.  Using Dell’s utility or a program like 7-zip, extract the drivers to a folder.  In here is the full setup MSI and the fully extracted drivers. 

Gathering the drivers:

There are 2 drivers we will need out of this (2 per architecture, so 4 total).  In the picture below, I have highlighted the directories that contain the x86 and x64 versions of the 2 drivers you need.


Simply import these drivers into SCCM/MDT (remember to give them a Category!) and inject into your boot images like normal.  If done properly, you should have the following 2 drivers in your boot images: