Looking inside – The thing with 2>&1

PowerShell  in the Orchestrator “Run .Net Script” Activity runs per default 32-bit PowerShell in version 2.0.

That Orchestrator “Run .Net Script” Activity uses the version  of PowerShell which is available in .Net Framework , you can create a registry entry. If you don’t want to or can’t create that registry entry for cmdlets which needs a higher version of PowerShell, you can call this cmdllets with $Result=PowerShell{#your code}:

I know even a few cmdlets which need a 64-bit version of PowerShell like from the Skype for Business Online module and one of the Office 365 modules. You can use this cmdlets in an Orchestrator “Run .Net Script” Activity with $ResultWithInvoke = Invoke-Command -ComputerName localhost -ScriptBlock {#your code}:

The Problem calling the scripts inside PowerShell {} or Invoke-Command is that you don’t get possible errors  in the Orchestrator “Run .Net Script” Activity per default . This is because a new session is created.

In the below example I simulated an error inside Invoke-Command:

but the “Run .Net Script” Activity has status success:

Then I put

IF ($Error) {throw New-Object System.Exception($Error)}

after the {Scriptblock}:

and now we can see very quick and easy what was happening inside:



Starten Sie jetzt Ihren Weg zu Azure!

Los geht's