Why Can’t we all just get along? AKA Task Sequences vs PowerShell (32/64 bit)

Once Upon A Time….

I was recently in a situation where I needed both 32-bit and 64-bit PowerShell scripts to be able to read/write Task Sequence Variables. After trying various methods I was able to get the 32-bit scripts to read and write Task Sequence Variables successfully.


All Was Well Until…

The scenario was an SCCM 2007 client running on a 64-bit Windows 7 device. In this case, the SCCM client is a 32-bit process. As such, the Task Sequence COM object that manages the task sequence variables is a 32-bit object. This is not an issue in cases where you need to run 32-bit Powershell Scripts, but on a 64-bit Operating System, some Powershell CMDlets must be run under a 64-bit Powershell process.

This can be a real problem because you quickly become limited in controlling the flow of the Task Sequence based on results within your 64-bit Scripts.

And They All Lived Happily Ever After…

This bugged me enough that I decided to write a PowerShell Module that would ensure I never dealt with it again. The solution allows you to use Machine Level Environment Variables as “Common Ground” and then return control back to the Task Sequence Variables as needed.

I’ve included the code for the PowerShell module below. Here are a few tips on how to make use of it. I probably don’t need to remind you, but just in case: These scripts will only work if they are run from inside a Task Sequence.

1) Use the “Connect-TSVarsToENV” Cmdlet at the beginning of your Task Sequence to initialize the process of linking the variables. This will create a Machine Level Environment variable for each Task Sequence Variable. The Environment Variables will be prefixed with “TSC_”. So for example, the Task Sequence variable “ScriptRoot” will be copied into an Environment Variable named “TSC_ScriptRoot”.

Note: Keep in mind that the values will not automatically sync without you running an action to do so.

2) Only use the Get-EnvironmentVariable, Get-EnvironmentVariables, and Set-EnvironmentVariable cmdlets to manage Environment Variables. The reason for this is that the build in powershell ENV: Drive only updates when PowerShell is started, so any changes made will be invisible to active Powershell Scripts. The Cmdlets I’ve provided use the .NET object to access the Environment Variables directly, so you get the correct values each time.

3) Use the “Sync-TSENVars” to copy all variables one way or the other as needed.

4) Use the “Disconnect-TSVarsFromENV” Cmdlet to clean up by copying all Environment values back into the Task Sequence Object before Removing the Environment copies.

5) The “Compare-TSVarsToENV” Cmdlet will return a table showing the values for both copies of your TS Variables. It also indicates which variables do not currently match on one side or the other.

I hope you find these as useful as I did.   If you find another creative use for them or have a question, let me know at todd.linke@model-techology.com.

Now as promised, here is the source code:

By |2016-12-02T13:34:41+00:00December 2nd, 2016|PowerShell, SCCM|0 Comments

About the Author:

steve bowman

Model Technology

Let us help you get your end point and data center strategy on cruise control!  Ask about our Calibration Assessment.


  • 12125 Woodcrest Executive Drive, Ste. 204 Creve Coeur, MO 63141
  • (314) 254-4138
  • sales@model-technology.com