Mit der Version 2020 erhalten unsere Kunden ein umfangreiches Funktions-Update mit Fokus auf die Themen PowerShell 7, PowerShell Remoting sowie auf Verbesserungen von ScriptRunner im Zusammenspiel mit der Infrastruktur-Automatisierung. Die nachfolgenden Abschnitte geben einen Überblick. Zu einzelnen Themen verweisen wir auf separate Blogbeiträge, Videos und unsere Dokumentation. Die detaillierte Übersicht über alle Neuerungen finden Sie außerdem in den Release Notes in der ScriptRunner Knowledge Base.
PowerShell 7 in ScriptRunner
Die neue PowerShell 7 ist die plattformunabhängige Version der beliebten Automatisierungssprache. Sie basiert auf der plattformunabhängigen .NET Core Runtime.
PowerShell 7 ist für viele Plattformen verfügbar und versetzt IT Pros nun in die Lage, mit einer Scriptsprache ein einheitliches Management einer heterogenen Infrastruktur zu verwirklichen.
ScriptRunner als führende all-in-one solution für Powershell Management unterstützt Szenarien zur Automation und Delegation mit PowerShell 7 parallel zur Windows PowerShell 5.1.
Wenn Sie PowerShell 7 ausprobieren oder nutzen wollen, können Sie das Package PowerShell7pwsh.zip aus dem ScriptRunner Setup verwenden.
- Installieren Sie zuerst die .NET Core 3.1 Runtime auf dem ScriptRunner Server
- Entpacken Sie die Zip-Datei vollständig und kopieren Sie die Dateien in das Verzeichnis
Der ausgelieferte PowerShell 7 Host in ScriptRunner ist self-contained. Das bedeutet, dass keine weitere PowerShell 7 Installation notwendig ist.C:\ProgramFiles\ScriptRunner\Service\Pwsh
Scripte für PowerShell 7 werden von ScriptRunner in der Prozessumgebung von SRXPSCoreHost.exe ausgeführt. Die Auswahl erfolgt in der Aktionskonfiguration in der Admin Web App in den PowerShell Optionen (Abbildung 1).
Einrichtung und Verwendung von SSH mit PowerShell 7
Mit der Einführung von PowerShell 7 rückt nun auch SSH-Remoting stärker in den Fokus. Das PowerShell SSH Remoting verwendet das SSH Protocol zwischen einem SSH Client (auf ScriptRunner Server) und einem SSH Server (auf dem Zielsystem).
Um mit SSH und PowerShell 7 in ScriptRunner arbeiten zu können sind folgende Schritte notwendig:
- Installieren von SSH Client und SSH Server auf ScriptRunner Server und Zielsystem. In Windows Server 2019 ist es als optionales Feature verfügbar, für andere Plattformen sind jeweilige Implementierungen verfügbar.
- Installieren von PowerShell 7 auf den Systemen (siehe Abschnitt PowerShell 7 in ScriptRunner)
- Konfigurieren des von SSH zur Verwendung von PowerShell 7
- Konfigurieren der SSH Authentifizierung
Mehr Informationen dazu hier:
PowerShell Remoting Over SSH – PowerShell | Microsoft Docs
Enable PowerShell SSH Remoting in PowerShell 7 – Thomas Maurer
Um eine SSH-Verbindung mit ScriptRunner nutzen zu können, benötigen Sie außerdem eine entsprechende Zielsystemkonfiguration (Abbildung 2).
Durch die Auswahl des entsprechenden Zielsystem-Typs, dem Zuweisen des hinterlegten SSH-Credentials und der PowerShell 7 Option in der Aktionskonfiguration sind Sie in der Lage, entfernte Zielsysteme über SSH mit PowerShell 7 zu managen.
Zur Einrichtung einer SSH-Authentifizierung an einem Zielsystem legen Sie ein Credential für SSH an und tragen den Account des SSH-Benutzers ein (Abbildung 3). Dieser Benutzer muss auf dem Zielsystem autorisiert sein.
ScriptRunner verwendet entweder bereits existierende SSH-Keyfiles von bestehenden Benutzerprofilen oder verwaltet diese auf dem ScriptRunner Server selbst.
Bereits existierende Key-Files eines Benutzers auf dem ScriptRunner Server liegen standardmäßig im Benutzerverzeichnis. Sie können dazu einfach das Standardverzeichnis (–/.ssh/.) aktivieren oder alternativ ein anderes Verzeichnis angeben (Abbildung 4).
Wenn Sie statt der SSH-Keyfiles in diversen Benutzerverzeichnissen die SSH-Keyfiles in ScriptRunner zentralisieren wollen, dann verwenden Sie die Option „SSH Key File content“ (Abbildung 5).
Diese Option ermöglicht Ihnen, den Inhalt des SSH-Keyfiles in die ScriptRunner Credentials Configuration zu kopieren. ScriptRunner legt jeweils ein SSH-Keyfile an und verwaltet diese automatisch.
Dieses Verfahren bietet über den Standard hinaus mehr Kontrolle, Sicherheit und Zentralisierung.
Workflows mit Office365 Power Automate
ScriptRunner ist ein wichtiger Baustein in einer vollautomatisierten IT. Grundvoraussetzung dafür ist die fehlerfreie Zusammenarbeit mit den anderen Bausteinen der Gesamtlösung: Workflows, Monitoring-Systeme, ITSM-Systeme sowie andere spezialisierte Automaten z. B. für SAP oder in anderen Fachapplikationen.
Die Integration von ScriptRunner mit Workflow-Systemen bereits seit 2016 ein festes Produktmerkmal. Die Beliebtheit von Office 365 hat dazu geführt, dass viele Unternehmen verstärkt über die Verwendung von Microsoft Power Automate in verschiedenen Anwendungsszenarien nachdenken.
Speziell für IT Operations-Teams ist die Verwendung von Power Automate als Workflowsystem in Verbindung mit ScriptRunner als Plattform für PowerShell interessant. So können komplexe Abläufe mit Genehmigungsverfahren in Power Automate als Workflow implementiert werden. Einzelne Workflowschritte, insbesondere Aufgaben mit PowerShell, werden von ScriptRunner als Workflowteilnehmer ausgeführt und die Ergebnisse wiederum an den Workflow übergeben.
Mit der neuen Version unterstützt ScriptRunner die direkte Bereitstellung von ScriptRunner Aktionen inkl. der Parameter in Power Automate. Dadurch kann jede Aktion von ScriptRunner als Baustein im Workflow verwendet werden, ohne dass komplexe WebAPI-Calls und Parameterübergaben programmiert werden müssen.
Folgende Schritte sind dafür notwendig:
- Einrichten von Microsoft on-premises data gateway auf ScriptRunner
- Konfigurieren eines ScriptRunner Web Service Connectors für O365 Power Automate und Zuweisen der im Workflow verfügbaren ScriptRunner-Aktionen
- Exportieren einer OpenAPI-Datei aus ScriptRunner mit der Admin Web App
- Erstellen eines „Custom Connectors“ in Power Automate und Import der OpenAPI-Datei.
- Re-Importieren einer angepassten OpenAPI-Datei nach Änderungen an einer ScriptRunner-Aktion
Zum Exportieren der OpenAPI-Datei ist der zuvor konfigurierte Connector auszuwählen und in der Aktionsleiste die Exportfunktion auszuführen (Abbildung 6).
Erstellen Sie nun in Power Automate einen neuen „Custom Connector“ und importieren sie die OpenAPI-Datei aus ScriptRunner.
Wurde der Custom Connector in Power Automate erfolgreich erstellt, ist dieser noch in den Optionen auf die Verbindung zum on-premises gateway und bei Sicherheit die Windows Authentication einzustellen.
Nach dem Erstellen eines neuen Power Automate Flows mit manuellem Trigger können nun die Workflow-Schritte erzeugt werden.
Für die weitere Konfiguration wird der konfigurierte Custom Connector benötigt. Dieser findet sich im Abschnitt Custom.
Im Custom Connector erfolgt die Auswahl zwischen den verschiedenen Aktionen. Die Aktion – SR INTERNAL – dient der internen Kommunikation zwischen Power Automate und ScriptRunner. Sie kann NICHT in einem Flow verwendet werden.
Nach der Auswahl der Aktion muss eine entsprechende Verbindung konfiguriert werden. Hier wird der Benutzername und das Passwort für die Anmeldung am ScriptRunner Server hinterlegt. Ebenfalls muss das zuvor konfigurierte Gateway ausgewählt werden.
Wurde der Connector vollständig konfiguriert, können nun die Parameter abhängig der gewählten Aktion direkt verwendet und im Workflow zugewiesen werden.
Die steigende Anzahl von Szenarien bei unseren Kunden und das Feedback, welches wir erhalten, fließen in unsere Entwicklung ein. Ein Feature für mehr Flexibilität für den Service Desk stellt die neue Target-Auswahl in der Delegate Web App dar.
Dieses Feature ermöglicht es Usern der Delegate App, z. B. im Service Desk, zum Zeitpunkt der Script-Ausführung ein Zielsystem aus einem zuvor definierten Set auszuwählen, auf dem eine Aktion ausgeführt werden soll. Dadurch erschließt sich eine Vielzahl von Use Cases.
Management von weiteren Office 365 Diensten
Auch für die Verwaltung von Office 365 Diensten mit PowerShell bietet die neue ScriptRunner Version neue Möglichkeiten.
Es wurde eine Erweiterung für die Verbindung zu Exchange Online vorgenommen. So kann ab jetzt das neue PowerShell Modul Exchange Online V2 (EXOv2) verwendet werden (Abbildung 7).
Dazu muss das PowerShell Modul ExchangeOnline Management zuvor auf dem ScriptRunner Server installiert werden. Der Verbindungsaufbau, die Authentifizierung sowie der Verbindungsabbau erfolgt dann mit ScriptRunner automatisch über das neue von Microsoft implementierte Verfahren.
Mit EXOv2 wird nun auch für Exchange Online auf das Modul für Azure Active Directory umgestellt. Das alte Modul MS Online wird damit vollständig abgelöst.
Völlig neu implementiert wurde die direkte Management-Unterstützung für das mittlerweile sehr populäre Microsoft Teams (Abbildung 8). Das gesamte Verbindungs- und Authentifizierungs-Handling wird nun von ScriptRunner übernommen. Das PowerShell Modul Microsoft Teams muss auf dem ScriptRunner Server installiert sein.
Für den Einstieg in das PowerShell Management von Microsoft Teams stellen wir zudem das kostenlose ActionPack for Microsoft Teams auf unserem GitHub Repository bereit.
Der O365 Dienst für Microsoft Teams erlaubt die zertifikatsbasierte Anmeldung am Azure AD für den Verbindungsaufbau. Dazu benötigen Sie ein gültiges Zertifikat auf dem ScriptRunner Server. Das Zertifikat muss im lokalen Zertifikatsspeicher auf dem ScriptRunner Server gespeichert werden.
Hinweise zur Einrichtung einer zertifikatsbasierten Anmeldung im Azure AD finden Sie in den Microsoft Docs: Azure Active Directory: Zertifikatbasierte Authentifizierung.
In die Konfiguration des Zielsystems muss der Certificate Thumbprint sowie die Application ID eingetragen sein.
Azure und andere Cloud-Dienste
Das Azure Management mit Az erlaubt ebenfalls die zertifikatsbasierte Anmeldung für den Verbindungsaufbau (Abbildung 9). Dazu benötigen Sie ein gültiges Zertifikat auf dem ScriptRunner Server. Das Zertifikat muss im lokalen Zertifikatsspeicher auf dem ScriptRunner Server gespeichert werden.
In die Konfiguration des Zielsystems mit Az muss der Certificate Thumbprint sowie die Application ID eingetragen sein.
Für das Management von anderen Cloud-Diensten mit PowerShell wurde ein neuer Zielsystem-Typ implementiert, das Generic Cloud Target (Abbildung 10). Dieses ermöglicht die Eingabe einer PowerShell Befehls-Sequenz für den Verbindungsauf- und -abbau. Zusätzlich kann ein bestimmtes Modul in den Verbindungsprozess geladen werden.
Im PowerShell-Code für den Verbindungsaufbau kann die Variable $Cred verwendet werden. Diese ist belegt mit dem konfigurierten Zugriffs-Credential für das Zielsystem.
PowerShell Remoting via Management/Jump Hosts
Die Verwendung von sogenanntem Management oder Jump Hosts hat im Infrastruktur Management eine lange Tradition. Üblicherweise wurden auf derartigen Systemen zahlreiche Administrations-Tools installiert und nur ausgewählte Admins bekamen Zugriff auf die Maschine und die Tools. Vorteilhaft ist vor allem, dass die Tools nur an einer Stelle aktualisiert werden müssen und der Zugriff von außen auf die Tools kontrolliert erfolgen kann.
Dieses Konzept eignet sich prinzipiell auch für PowerShell in verteilten Umgebungen. So lassen sich bspw. standortgebunden PowerShell Jump Hosts aufbauen, auf welchen alle notwendigen PowerShell Module installiert sind und die Scripte ausgeführt werden können.
ScriptRunner erweitert dieses Konzept, um Jump Hosts als „Verteilerknoten“ zu weiteren Zielsystemen nutzen zu können (Abbildung 11). Damit wird das klassische Double Hop-Problem richtliniengesteuert umgangen.
Neben dem reinen „Verteilerknoten“ können damit nun auch einfache Mixed-Target-Szenarien gebaut werden, um z. B. auf einem Remote Zielsystem ein Script auszuführen und von dort aus direkt Ressourcen eines O365 oder Azure Mandanten ansprechen zu können.
Es ist auch möglich, ein Zielsystem über eine Kette von Jump Hosts anzusprechen.
Das Feature findet ebenfalls für PowerShell Direct zum Management von VMs in Hyper-V-Host bzw. von Containern in Windows Container Service Host Anwendung.
Für die praktische Verwendung dieses Features müssen folgende Voraussetzungen erfüllt sein:
- Der/die Jump Hosts sind als Zielsysteme mit Standard-PowerShell Remoting konfiguriert
- Die eigentlichen Zielsysteme sind konfiguriert. Diese Zielsysteme können auch Cloud-Dienste, VMs und Container über PowerShell Direct sein.
Die Konfiguration erfolgt am eigentlichen Zielsystem mittels der Funktion „Access to this target via management or jump host indirectly“. Dort ist der entsprechende Host auszuwählen.
Zur Steuerung der Zugriffsrechte zum Verbinden und Ausführen der Scripte und zum Verwenden des „Sprungbretts“ wird das am jeweiligen Zielsystem hinterlegte Credential verwendet.
Tipp: Im PowerShell Report wird die Verbindung über Jump Hosts dokumentiert. Sollen Details bspw. während des Testens mitprotokolliert werden, so ist an der ScriptRunner Aktion unter PowerShell Optionen der Verbose-Schalter zu aktivieren.
PowerShell Remoting für Hyper-V, Container und CIM
Die Ausführung von PowerShell Scripten kann auf einem entfernten Zielsystem erfolgen. ScriptRunner unterstützt von Beginn an diese Möglichkeit, welche nun um weitere Optionen ausgebaut wurden. Die zusätzlichen Optionen lassen sich beim Erstellen eines neuen PowerShell Remoting Targets festlegen.
PowerShell Direct ist dabei eine Methode, welche von Microsoft entwickelt wurde, um PowerShell in virtualisierten Umgebungen vielfältiger einsetzen zu können und den Overhead für den Verbindungsaufbau zu virtuellen Maschinen unter Hyper-V bzw. Docker-Container unter Windows Container Service zu reduzieren. Außerdem kann so das Double Hop-Problem vermieden werden.
Im klassischen PowerShell Remoting muss zu jeder virtuellen Maschine bzw. zu jedem Container eine direkte Verbindung und PowerShell Session aufgebaut werden. Bei Verwendung von PowerShell Direct kann eine Remoting-Session zum Hyper-V Host bzw. Container-Host aufgebaut werden. Anschließend lassen sich die virtuellen Maschinen bzw. Container mit ihrer ID oder dem Namen direkt ansprechen.
Die Option für CIM-Sessions ermöglicht das Einrichten und Verwenden von Verbindungen zu standardisierten CIM Endpoints. Windows Management Instrumentation unterstützt CIM.
Zum Einrichten von PowerShell Direct, wie im Beispiel, ist ein Zielsystem mit Standard PowerShell Remoting auf den Hyper-V bzw. Container Host einzurichten (Abbildung 12). Die virtuellen Maschinen bzw. Container werden als weitere Zielsysteme mit der Option PowerShell Direct mit Hyper-V (für VMs) oder Container Service (für Docker Container) eingerichtet.
Dazu kann wie im Beispiel der VM-Name oder die VM-ID verwendet werden. Das Zugriffs-Credential benötigt die entsprechenden Ausführungsrechte von PowerShell in der VM.
Um die VM über den Host mit PowerShell Direct ansteuern zu können, muss in der Konfiguration des VM-Zielsystem in ScriptRunner der Hyper-V-Host als „via management or jump host“ zugewiesen werden (Abbildung 13). Analog erfolgt die Einrichtung von Container-Zielsystemen mit dem Container-Host.
Um die Container-ID für die Konfiguration zu erhalten können Sie auf dem Container-Host den Befehl Get-Container ausführen, sobald Sie das PowerShell Module Container geladen haben.
Multi-Target Szenarien mit PowerShell PSSession
Im praktischen Einsatz von PowerShell, insbesondere in der Automation, werden zur Verarbeitung der Scripte Zugriffe auf unterschiedliche Systeme benötigt, z. B. auf das interne AD und Azure AD, auf Exchange on-prem und Exchange Online, auf Windows Server und verschiedene Shares oder Datenbanken.
Diese Szenarien haben gemeinsam, dass zur Laufzeit des Scriptes auf unterschiedliche Systeme mit jeweils eigenen Systemrechten zugegriffen werden muss.
PowerShell native stellt zu diesem Zweck das Konzept von Sessions bereit. So kann man auf der Kommandozeile verschiedene Sessions mit dem New-PSSession Cmdlet aufbauen und zwischen diesen wechseln. Zudem erlaubt die Präfix-Funktion das automatische Erkennen, in welcher Session ein bestimmtes Kommando ausgeführt werden soll.
Sie können nun diese PowerShell-Funktionalität direkt in ScriptRunner für Multi-Target Szenarien nutzen. Sie benötigen dazu die Definitionen der Parameter für die benötigten Sessions im param-block des PowerShell Scripts.
Param
(
…
# PowerShell Remoting Session Type
[System.Management.Automation.Runspaces.PSSession]
$Session1,
[System.Management.Automation.Runspaces.PSSession]
$Session2,
# PowerShell CIM Session Type
[Microsoft.Management.Infrastructure.CimSession]
$cimsession,
…
)
In der Parameterkonfiguration einer ScriptRunner Aktion können die Session-Parameter mittels Dropdown-Auswahl mit einem Zielsystem belegt werden (Abbildung 14).
ScriptRunner stellt zur Laufzeit jedes Mal vor dem Starten des Scripts die Verbindung zu dem hinterlegten Zielsystem her. Das zugehörige PSSession-Objekt wird an das Script als Parameter übergeben. Nach der Ausführung des Scripts wird die Session durch ScriptRunner automatisch beendet.
Die Verwendung der Session erfolgt im Script selbst. Entweder mit einer Programmzeile
Invoke-Command -Session $Session1 -ScriptBlock { ... }
# or
Import-PSSession -Session $Session1 -Modules ...Damit verbunden ist eine Erleichterung für die Script-Entwicklung. Zum einen muss der Sessionauf- und -abbau nicht mehr programmiert werden und zum anderen können damit Multi-Target-Szenarien in einem Script sehr einfach umgesetzt werden. Zusätzlich wird die Sicherheit in der Verwendung von verschiedenen administrativen Credentials verbessert, da im Script nur die Session, jedoch nicht Benutzername/Passwort bzw. das Credential verwendet werden kann.
Verwendung von PowerShell Objekten in Queries
Queries sind seit Version 2018R1 ein entscheidendes Feature in ScriptRunner. Neben den vielfältigen Einsatz von Active Directory Queries haben sich Scripted Queries als ein sehr flexibles Werkzeug für die Umsetzung von Use Cases etabliert.
Die Grundidee, im UI per Dropdown-Menu eine Auswahl zur Parameterauswahl anzubieten wurde nun für Scripted Queries erweitert. Neben einzelnen Stringwerten können nun auch PowerShell-Objekte übergeben werden.
Da eine Scripted Query und das Hauptscript jeweils in einem eigenen PowerShell-Prozess laufen, müssen die Objektwerte zwischen zwei getrennten PowerShell-Prozessen übergeben werden. Dazu können sowohl Hashtable als auch das PowerShell Custom Object benutzt werden. Voraussetzung für die Verwendung ist, dass die Hashtable bzw. das Custom Object sowohl im Query-Script als auch im Hauptscript definiert worden sind. Die Übergabe der einzelnen Werte von der Query an das Hauptscript erfolgt als base64-encodierter String.
Das Query Script füllt im Ergebnis statt eines einzelnen Strings die encodierte Werte einer Hashtable in die Systemvariable $SRXEnv.ResultList.
In der Systemvariable $SRXEnv.ResultList2 wird der jeweilige Name für das zu übergebende Objekt gespeichert. Das Verfahren gleicht also dem schon bekannten für Scripted Queries. Analog wird verfahren, wenn statt einer Hashtable ein Custom Object genutzt wird.
# Deklaration Hashtable im param block
$hasht = @{ Name = ''; Age = 0 }# Funktionscode der Query mit foreach-Schleife
…
$hasht.Name = 'Paul'
$hasht.Age = 31
# Befüllen der Hashtable
if ($SRXEnv) {
$null = $SRXEnv.ResultList.Add($hasht)
$null = $SRXEnv.ResultList2.Add($hasht.Name)
}
Beim Testen der Query, sind in der Tabellenspalte „Parameter Value“die mit den Strings encodierten Werte zu sehen.
Im Hauptscript wird ebenfalls im param-block die Hashtable bzw. das Custom Object deklariert. Die Deklaration muss dabei der Form entsprechen die im Query Script verwendet wird. Dieser Parameter wird in der Aktion mit der Query verknüpft, sodass zur Laufzeit die Werte der encodierte Hashtable bzw. des Custom Objects an das Hauptscript übergeben werden können.
Startet ein Anwender die Aktion, liefert die Query eine Liste von benannten Objekten im Auswahl-Dropdown. Der Anwender wählt ein benanntes Objekt aus, und die encodierten Werte werden dem Hauptscript übergeben. Anhand des deklarierten Parametertyps im Hauptscript dekodiert ScriptRunner den übermittelten String und weist die einzelnen Werte auf die jeweiligen Properties in der Hashtable bzw. dem Custom Object zu.
Auf die Properties kann direkt zugegriffen werden.
….
# aus Deklaration der Hashtable wie oben
$Age = $hasht.AgeHinweise zum PowerShell Secrets Management Module
Das neue PowerShell Secrets Management Modul unterstützt das Verwenden im Windows Credential Store abgespeicherter Credentials sowie Credential-Anfragen von Passwort Servern. Das Modul funktioniert ausschließlich lokal, d.h. es muss auf ScriptRunner Server installiert sein.
Seine Verwendung ist aufgrund der Architektur ausschließlich auf lokale Scriptausführung begrenzt.
Ein Mehrwert des Moduls in ScriptRunner-Umgebungen ist nicht gegeben, im Gegenteil. Die Möglichkeiten zur entfernten Ausführung von Scripten auch über Jump Hosts hinweg bei gleichzeitiger zentraler Credentialverwaltung in ScriptRunner und Passwort Servern sind nur mit ScriptRunner möglich.
Zusammenhängende Posts
Über den Autor:
Frank Kresse ist Head of Product und CEO von ScriptRunner. Als Erfinder der Automatisierungs- und Delegationslösung für PowerShell berät er Kunden zu Use-Case-Szenarien und entwickelt Lösungen für die Automatisierung und die Digitalisierung ihrer Prozesse. Außerdem ist er an Technologie-Start-ups beteiligt.