PowerShell code behaving differently under SCCM and MDT TaskSequences - powershell

Question

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.

Answer 1

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.