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.

DISM

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).

PrestartCMD

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.

 

5 thoughts on “WinPE 5.0 x64: Microsoft.SMS.TSEnvironment Unavailable?

  1. What an awesome find! I have this same issue with my OSD FrontEnd and have just been saving all my variables to .txt files then importing them in when the task sequence actually kicks off! I will definitely be testing this out. Thanks Dustin!!

  2. Hi,

    Thank you very much for this information – it has lead me to figuring out the problem im having. but for everybody who comes across the Microsoft.SMS.TSEnvironment error. This COMObject only works in 32bit environment. So when running a script that uses this COM object in a Task Sequence, you must enable(tick) “Disable 64-bit system redirection” in Run Command-line. Or do the following

    %windir%\system32\cscript.exe
    %windir%\system32\WindowsPowershell\v1.0\powershell.exe
    etc…

    hope this helps

    Regards,
    EJ

  3. Thanks for the pointers.
    I encountered this SCCM 2007, here are the specifics of my solution:
    Scenario:
    A task sequence step to ‘Run Command Line’ running a VBScript that analyses partitions to see if an XP upgrade is in progress, and (if so) make sure that enough disk space is available to perform a ‘hard-linking’ backup of some user data (or not) – results of whether to partition the disk or not passed back through Microsoft.SMS.TSEnvironment variables.
    Since this script interacts with the user via confirmation/timeout pop-ups, serviceUI was used.
    (I renamed the serviceUI.exe with 32/64 suffix respectively and put them in an OSD ‘scripts package’, so I could be sure what was actually running)

    TS start point might be 32Bit XP, 32bit OSD boot (Win PE), 64Bit Windows 7, 64Bit OSD Boot so the respective ‘disktest.vbs’ task sequence steps are conditional on WMI:
    select * from Win32_ComputerSystem where SystemType=’X86-based PC’
    or
    select * from Win32_ComputerSystem where SystemType=’x64-based PC’

    the 32Bit command worked fine in XP and OSDBoot32bit:
    serviceui32.exe -process:tsprogressui.exe %WINDIR%\System32\wscript.exe DiskTest.vbs

    The 64Bit one did not:
    serviceui64.exe -process:tsprogressui.exe %WINDIR%\System32\wscript.exe DiskTest.vbs
    (‘Disable 64bit file-system redirection’ NOT checked)
    this assumes 64bit process for serviceUI.exe and 64bit version of WScript.exe in the System32 folder ( yeah, a bit daft, that isn’t it?… why didn’t they create a System64 folder??)

    Tried changing ‘Disable 64bit file-system redirection’ to CHECKED – no difference, but left that in place…
    Tried changing command to
    serviceui64.exe -process:tsprogressui.exe %WINDIR%\SysWow64\wscript.exe DiskTest.vbs
    to run the 32bit version of WScript.exe – no difference.
    however, it seems the serviceUI64.exe makes the WScript.exe into a 64bit process also, so changing the command line to :
    serviceui32.exe -process:tsprogressui.exe %WINDIR%\SysWow64\Wscript.exe DiskTest.vbs
    with ‘Disable 64bit file-system redirection’ to CHECKED

    WORKS on a 64bit machine.

    the Microsoft.SMS.TSEnvironment appears to be provided to a task sequence session but only as a 32bit component, so 64bit processes cannot instantiate it and neither can it be instantiated in a standalone script from any version of cmd or WScript.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s