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.
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
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
funktioniert es auch mit PowerShell v3 und höher, im SCO.
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
Super! Vielen Dank!
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.”
Remember you are starting powershell in 32bit from orchestrator.
Muito obrigado 🙂 !!!!!
Funcionou perfeitamente……
Is it possible to use powershell to set the Orchestrator product key? That would be great to automate installation and manage my licences
I think so, That you can trigger the MSI and send the Product Key.