Es gibt ein PowerShell Execution Script Integration Pack für System Center Orchestrator 2012 welches euch die Ausführung von Powershell Scripts auf entfernten Rechner erleichtert.
Den Download findet ihr hier: http://orchestrator.codeplex.com/releases/view/76101
Das ganze noch importieren und deployen, und schon sehen euch 2 Activites im SCO zur Verfügung.
Die beiden Activities unterscheiden sich nur in der Konfiguration, eines kann Global konfiguriert werden wobei das andere im Activities selbst nach Username, Password und Hostname fragt.
Bei der Konfiguration am Zielcomputer ist folgendes zu beachten.
- auf Ziel und Quell Computer muss folgendes ausgeführt werden: winrm quickconfig in einer administrativen CMD
- Der User muss lokaler Admin am Ziel-System sein.
Sollte einer dieser beiden Punkte nicht gesetzt sein, kommt folgende Fehlermeldung:
Connecting to remote server failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic
Unterschied “Execute PS Script” und “Run .Net Script” Activity
Wer sich schon etwas mit SCO beschäftigt hat, der kennt sicherlich das “Run .Net Script” Activity, welches auch Power Shell unterstützt. Ich möchte hier ein paar Unterschiede aufzeigen, die eventuell die Entscheidung beeinflussen welches Activity ihr in Zukunft benutzen werdet.
1. Errorhandling
Das “Run .Net Script” bietet eigentlich kein integriertes Fehlermanagement, sollte also das Scirpt einen Fehler generieren, ist die Fehlersuche sehr schwer da kein Ergebnis geliefert wird. Auch wenn das Script an sich erfolgreich war, nur bei der Ausführung trotzdem was schief gelaufen ist, dann wird es richtig schwierig.
Hingegen beim “Execute PS Script” Activity ist das schon etwas einfacher, dort ist im Activity schon eine Ausgabe integriert, welche ihr euch im Runbook Tester ansehen könnt. Zusätzlich könnt ihr zum Schluss eures Scripts noch die Variable $error ausliefern lassen, dann erhaltet ihr die gesamte Fehlermeldung.
Import-Module ‘C:\Program Files\Microsoft System Center 2012\Service Manager\Powershell\System.Center.Service.Manager.psd1’
Get-SCSMManagementPack -ComputerName mucscsmmgt1|where-object {! $_.Sealed}|Export-SCSMManagementPack –Path ‘\\MUCSCSMDB1\$_System Center Drive\SCSM\Backup MP\unsealedmps’
Get-SCSMManagementPack -ComputerName mucscsmmgt1|where-object { $_.Sealed}|Export-SCSMManagementPack –Path ‘\\MUCSCSMDB1\$_System Center Drive\SCSM\Backup MP\sealedmps’
$error
2. Variablen übergeben
Hier hat das “Run .Net Script” die Nase vorne, alle Variablen die im PowerShell Script erstellt und befüllt werden, können den nächsten Activities mittels “Published Data” übergeben werden.
Beim “Execute PS Script” Activity ist das schon etwas schwieriger, hier muss das Script etwas umgebaut werden. Als Published Data wird der Script Output ausgegeben, dies würde für ein Beispiel so aussehen.
Import-Module ‘C:\Program Files\Microsoft System Center 2012\Service Manager\Powershell\System.Center.Service.Manager.psd1’
$MP=Get-SCSMManagementPack -ComputerName mucscsmmgt1 -Name “Microsoft.SystemCenter.Internal”
$MP
Das Resultat dieses Scripts wäre
welches ihr mit folgender Published Data dem nächsten Activity übergeben könnt.
Das Ergebnis wird als ein Blob Text Feld ausgegeben, solltet ihr ein Array ausgeben ist das Ergebnis auch ein Array, also werden die nachfolgenden Activities dementsprechend oft ausgeführt.
Hier noch das Beispiel für ein Array.
Import-Module ‘C:\Program Files\Microsoft System Center 2012\Service Manager\Powershell\System.Center.Service.Manager.psd1’
$Array=@()
$MP=Get-SCSMManagementPack -ComputerName mucscsmmgt1
foreach ($M in $MP){
$temp=$M.name
$Array+=$temp}$Array
Der Inhalt von $Array wäre nun das Published Data und alle Activities
Soweit zu den Unterschieden die für mich ausschlaggebend sind, also steht es Unentschieden für die beiden Activities.
Somit habe ich DAS PowerShell Activity noch nicht gefunden.
Michael Seidl aka Techguy