System Center Orchestrator

Orchestrator und PowerShell v3 funktioniert, auch ohne Workaround

Wer jetzt glaubt, das hier wäre der nächste Artikel, der euch einen Workaround zeigt, um PowerShell v3 in System Center Orchestrator zu starten, der irrt.

Ich zeige euch wie ihr PowerShell V3, ganz normal, mittels “Run .Net Script” Activity starten könnt.

Problem besteht ja darin, das SCO standardmäßig nur die Powershell v2 startet. Das ist soweit kein Problem, so lange SCO auf einem Server 2008 R2 installiert ist.

Da wir mittlerweile jedoch das Jahr 2015 schreiben und viele Server mit Server 2012 R2 und PowerShell v3 oder höher daherkommen, haben wir da ein Problem, sobald wir PowerShell Module importieren die unter v3 oder v4 laufen.

Das Problem

Solange das “Run .Net Script” Activity kein spezielles CMDlet benötigt könnt ihr das Activity ganz normal nutzen, wie dieses Beispiel zeigt.

Run .Net Activity | techguy.at

Run .Net Activity | techguy.at

 

Jetzt kommen wir zum Problem.

Wenn wir jetzt versuchen ein Get-ADUser CMDlet zu starten, kommt folgendes Problem, obwohl wir zuvor ein “import-module” machen

Run .Net Activity | techguy.atRunbook Tester | techguy.at

The term ‘Get-Aduser’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Problem hier, das PowerShell Module “ActiveDirectory” erwartet eine PowerShell v3 Umgebung, SCO bietet aber nur V2

Bisher war es notwendig dieses PowerShell Script so umzubauen

$theresults = PowerShell{
 
    import-module ActiveDirectory
    $User=Get-Aduser -identity seidlm

 
    new-object pscustomobject -property @{
        User = $User
    }
}
 
$User = $theresults.User

 

Was ja doch etwas umständlich erscheint, vor allem da keine Fehler ausgegeben werden.

Die Lösung

Lange habe ich nach einer besseren Lösung gesucht und jetzt endlich gefunden. Es ist ein einzelner RegKey der SCO dazu bring, die aktuellste PowerShell Version zu nutzen.

sobald folgender RegKey gesetzt ist

HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework

Reg_DWORD: OnlyUseLatestCLR

Value: 1

 

Registry | techguy.at

funktioniert es auch mit PowerShell v3 und höher, im SCO.

Run .Net Script | techguy.at

Viel Spaß beim umsetzen und testen, ich hab noch keine negativen Auswirkungen bemerkt. Generell gilt für diesen tipp, Use at our own risk, gibt keine Garantie das dies keine anderen Problem verursacht.

Michael Seidl aka Techguy

6 thoughts on “Orchestrator und PowerShell v3 funktioniert, auch ohne Workaround”

  1. Interesting find, however this method appears to be explicitly discouraged by Microsoft, and doesn’t seem wise in light of the fact that there are fully-tested ways to invoke a new session with latest PS version from Orchestrator’s Run .Net Script activity. So, be careful. 🙂

    See: https://connect.microsoft.com/PowerShell/feedback/details/525435/net-4-0-assemblies-and-powershell-v2

    “While it is possible to force PowerShell 2.0 to run with .NET Framework 4.0 using various mechanisms such as creating a config file for PowerShell or editing the registry, these mechanisms aren’t supported and can have negative side effects on other PowerShell functionality such as PowerShell remoting and cmdlets with mixed-mode assemblies.”

  2. Is it possible to use powershell to set the Orchestrator product key? That would be great to automate installation and manage my licences

Leave a Comment

Your email address will not be published. Required fields are marked *

*