Beware PowerShell ISE != powershell.exe

At work, word has gotten out that I like to program, so being a system administrator I write a lot of PowerShell. I've used/shoehorned it into projects where it didn't really belong and have experienced some strange behavior from the PowerShell ISE that I thought I'd share before you fall into the same rabbit hole.

Did you know that the PowerShell interpretor inside the ISE is throttled differently from powershell.exe? Workflows and other async jobs are allowed more parallelization than inside the script editor so if you're not seeing the speedups you've hoped by running workflows (better than async jobs: faster, new, shiny) try it in the good old command-line before you start "optimizing". 

One other fun fact: the script editor uses a different console output encoding than powershell.exe by default. Yay! Your output can be mangled or incorrect depending on where you run it! Even though both consoles appear to support many of the same character encodings, they are not the same by default:

If that's too small for you, it shows that the PowerShell ISE is set to "US-ASCII" while powershell.exe is "IBM437". It just so happens that while pulling many DFS target paths from the NetDfsEnum system call, blank spaces can be converted into the ÿ character. That directory path doesn't exist and the script throws exceptions during development that it doesn't in production. I've avoided this by changing the output encoding inside a begin{} block and back to the previous setting in a finally{} block...like so:

 
function Get-Links {
  param ( [Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true, ValueFromPipelinebyPropertyName=$true)]
    [string]$Path
  ) 
  Begin {
    $en_pre = [console]::OutputEncoding
    [console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(1250)
  } 
  Process {
    # Do some super great Powershelly stuff 
  }
  Finally {
    [console]::OutputEncoding = $en
  } 
} 

That has seemed to work out for me so far and I hope it saves you a headache. I'm sure there were reasons these trade offs between the PowerShell ISE and powershell.exe were made it woul just be nice if someone documented them in a feature matrix (maybe...someday if I get time).