PowerShell code behaving differently under SCCM and MDT TaskSequences

I've got code that has been extensively tested across multiple PowerShell sessions, multiple machines, etc all doing exactly what I expect.

switch ($e.Data.Type) `
{
    {$_ -in [Policy.Reg]::SZ, [Policy.Reg]::EXPAND_SZ} `
        {
            $e.Data[$e.Data.Type] = ([string]$e.Data[$e.Data.Type]) -replace "{PC}", "$PC"
        } 
    {$_ -in [Policy.Reg]::MULTI_SZ} `
        {
            $e.Data[$e.Data.Type] = [string[]]($e.Data[$e.Data.Type] | % { $_ -replace "{PC}", "$PC" })
        }
}

[Policy.Reg] is an Enum that $e.Data.Type is a variable of that enum

Running the code from the ISE or the Powershell command line code works every time.

When I add it as a RunPowerShell task sequence step (MDT 2012/2013 and SCCM 2012 all tried) the task sequence fails with

    you must provide a value expression on the right-hand side of the '-' operator. [Policy.Reg]::SZ, [Policy.Reg]::EXPAND_SZ

I'm at a complete loss what is going on when a TaskSequence runs a Powershell script that makes it different than when I manually execute the some code.

Solution

So really quick it seems my issue was with MDT itself.

The standard wsf and vbs files that control PowerShell Execution check for the existence in the registry for the currently installed version and then runs one of two executables that sets up a unique PowerShell environment.

One of the Exes just runs the most recent version of powershell.

The other forces it to run in powershell 2.0 (for compatibility i'm guessing)

Here's the issue the LOGIC in the script file is all wrong

Instead of being something like

if (PSVersion  >= 2.0) then
    Run newest PowerShell
else
    Run PowerShell 2.0
end if

It looks like

if (PSVersion = 3.0 then
    Run newest Powershell
else
    Run Powershell 2.0
end if

So since all my images have PowerShell 4.0 installed on them, well as LOGIC dictates 4.0 is NOT equal to 3.0 so off to PowerShell 2.0 we go and toss out ALL the things we have gotten used to having since we spent a LONG time ensuring every system in our environment is at least on PowerShell 4.0

So in the end a little code change to the code Launching the PowerShell Scripts fixed the issue.