Die Portal Edition ist das zweite Release einer Reihe, welche sich schwerpunktmäßig auf das rollenbasierte Portal fokussiert.
Mit Release 2 werden bisherige Features im Portal verbessert sowie eine weitere neue Portal App für das Monitoring von ScriptRunner Servern eingeführt und erstmalig im Browser verfügbar gemacht:
- Neue Portal App "Monitor"
- Überwachen der Scriptausführung auf allen Servern
- Anzeigen der laufenden Scripte und Einblenden in deren PowerShell-Ausgabe
- Schnellfilter auf unterschiedliche Ausführungen von Scripten (scheduled, Scripted Queries etc.)
- Grafische Anzeige der Lastsituation auf den einzelnen Servern
- Separates Anzeigen von anstehenden Scriptverarbeitungen in der Queue
- Abbrechen laufender Script-Verarbeitungen im Monitor
- Multi-Server-Support für Run App und die Reporting App
- Transparentes Anzeigen und Ausführen von Aktionen von verschiedenen Servern (alle Rollen)
- Transparenter Zugriff auf Reports von verschiedenen Servern (alle Rollen)
Weitere Features im Release 2 sind:
- Integrierte Online & Offline Hilfe im Portal
- Limitieren der parallelen Ausführung von Scripten an allen Targets
- Löschen von Scripten in der Portal App Scripts
- Ausblenden Aktionsliste im Eingabemodus
- Einstellen der Default-Language beim Erstaufruf für das Portal
- Integrierter Trial Guide während der Testphase
- Fixes und Enhancements (Release Guide hier)
Die neue Monitor App
Mit diesem Release wird erstmalig die ScriptRunner Portal App für Monitoring ausgeliefert.
Einsatzszenarien
Folgende Einsatzszenarien sind für die Monitor App vorgesehen:
- Individuelle Überwachung der Serveraktivitäten als Teil der täglichen Aktivitäten
- Überwachung der Serveraktivitäten als Leitstand über einen separaten Screen
Für beide Nutzungsarten ist die Rolle "Main Administrator" erforderlich.
Funktionen und Mehrwert
Mit der Monitor App werden folgende Funktionen zur Verfügung gestellt:
- Überwachung einer konfigurierbaren Liste an ScriptRunner Servern
- Übersicht über alle laufenden Verarbeitungen von Scripten je Server
- Anzeige der insgesamt laufenden Script-Verarbeitungen
- Anzeige der Maximalkapazität paralleler Script-Verarbeitungen je Server
- Anzeige der laufenden Script-Verarbeitungen je Server
- Anzeige der anstehenden Script-Verarbeitungen je Server
- Anzeige der gerade abgelaufenen Script-Verarbeitungen je Server
- Aufschalten auf die Ausgabe der jeweiligen Script-Verarbeitung
- Abbrechen einer laufenden Script-Verarbeitung
Funktionsprinzip der ScriptRunner Portal App für Script Monitoring
Die Monitor App hilft Administratoren und Teams dabei:
- die Script-Verarbeitung auf allen ScriptRunner Servern an einer zentralen Stelle zu überwachen
- die Verarbeitungskapazität jedes einzelnen Servers beurteilen zu können
- das jeweilige Sizing der Server zu prüfen und rechtzeitig anpassen zu können
- Die Verteilung der Script-Verarbeitungen prüfen, planen und anpassen zu können
- Engpässe in Scriptverarbeitungs-Ressourcen zu erkennen und reagieren zu können
- schnell wechselnd einen direkten Einblick in laufende Script-Verarbeitungen nehmen zu können
Die Komponenten der Monitor App
Innerhalb der Monitor App gibt es unterschiedliche Funktionsbereiche für eine schnelle Orientierung.
- Header Block mit Anzeigefiltern
- Live Ausgabe für eine ausgewählten Script-Verarbeitung
- Liste der Script-Verarbeitungen
- Übersicht über alle laufenden Verarbeitungen von Scripten je Server
Header Block
Auf der linken Kachel wird die Gesamtanzahl der Script-Verarbeitungen über alle Server angezeigt. Im mittleren Chart werden für jeden Server die laufenden Script-Verarbeitungen (orange) sowie anstehende Script-Verarbeitungen in der Queue (blau) farblich unterschieden. Die Skala zeigt die Anzahl der Verarbeitungsengines auf dem Server an. Der Server mit der höchsten Anzahl Engines bestimmt die Skalierung. Im Standard sind auf dem Server 10 Engines zur parallelen Scriptverarbeitung vorgesehen. Auf der rechten Seite finden sich Schaltflächen für die Filter.
Auslastung
Bei der Beurteilung anstehender Verarbeitungen in der Queue (blau im Chart) auf dem jeweiligen Server sind folgende Einstellungen zu beachten:
- Anzahl der maximal verfügbaren Verarbeitungs-Engines. Treten dauerhaft mehr parallele Anforderungen auf, kann die Anzahl der Engines auf dem betroffenen Server mit dem Cmdlet Set-AsrSettings erhöht werden.
- Limitierung paralleler Session-Zugriffe auf das Zielsystem. Sollen parallel mehr Verbindungen aufgebaut werden, als an den Target-Einstellungen zugelassen sind, wird die Anforderungen in die Queue gestellt.
- Limitierung paralleler Ausführungen einer Aktion oder eines Scriptes. Sollen mehr als die zugelassene Anzahl Anforderungen ausgeführt werden, dann werden diese in die Queue gestellt.
Hinweis: Es können also Script-Verarbeitungen bereits als anstehend eingestellt werden, obwohl noch Engine-Ressourcen frei sind.
Laufende Scripts und Serverauslastung überblicken und filtern
Anzeigefilter
Die Anzeige, welche Script-Verarbeitungen angezeigt werden, kann mit den Filter-Schaltflächen rechts oben im Headerblock eingestellt werden. Standardmäßig werden alle zu Script-Verarbeitungen ohne Queue und ohne Scripted Queries angezeigt. Die Badges auf den Filter-Schaltflächen zeigen an, wie viele Verarbeitungen laufen, wie viele zeitgesteuert sind, wie viele in der Queue warten und wie viele Scripted Queries verarbeitet werden.
Queued ON/OFF
Vorgemerkte Script-Verarbeitungen, welche auf ihre Ausführung warten, werden angezeigt/nicht angezeigt.
Scheduled ON/OFF
Verarbeitungen von zeitgesteuerten Aktionen und Scripted Queries (bei Queries ON) werden angezeigt/nicht angezeigt.
Queries ON/OFF
Verarbeitungen von Scripted Queries werden angezeigt/nicht angezeigt.
Serverauswahl
Sollen zeitweise nur ein oder eine Auswahl an Servern beobachtet werden, so können diese in der Serverauswahl festgelegt werden.
Liste der Script-Verarbeitungen und Liveausgabe
Abhängig von den eingestellten Filtern werden in einer Listenansicht folgende Script-Verarbeitungen angezeigt:
- Oben hellblau: alle anstehenden Script-Verarbeitungen
- Mitte orange: alle aktuell laufenden Script-Verarbeitungen
- Unten schwarz mit Kennzeichen: abgebrochene Script-Verarbeitung
- Unten schwarz: 10 zuletzt abgelaufenen Script-Verarbeitungen
Hinweis: Nach dem Wechsel in eine andere Portal App und Rückkehr wird der aktuelle Stand neu geladen.
Listenansicht und Liveausgabe der aktuellen und anstehenden Script-Verarbeitungen
Wird eine laufende oder gerade abgelaufene Script-Verarbeitung angeklickt, öffnet sich die Liveausgabe dieser Aktion. Man kann zwischen den Verarbeitungen frei hin und her wechseln.
Eine laufende Script-Verarbeitung kann im Header der Liveausgabe abgebrochen werden.
Erfolgreicher Abbruch der ausgewählten Script-Verarbeitung
Konfiguration der zu überwachenden Server
Die Konfiguration der zu überwachenden Server erfolgt in der Konfigurationsdatei App.Json im Portalverzeichnis auf dem Server. Die Base URI entspricht dabei dem Master-Server, von welchem das Portal geladen wird und die Daten für die anderen Portal Apps verwendet werden, z.B. Script App etc.
Je nach Anwendungsfall für die individuelle Überwachung oder die Ausgestaltung des Leitstandes werden die ScriptRunner Server im Abschnitt "monitoringServer" hinterlegt. Beachten Sie beim Einsatz von Load Balancern, dass die entsprechenden Einträge in der App.Json auf jedem Server vorgenommen werden müssen.
Im Beispiel gibt es zwei zu überwachende Server, jeweils mit speziellem Einsatzzweck. "Host 1", der erste Server, hostet alle Aktionen, welche von Service Desk Mitarbeitern und Endanwendern im Portal interaktiv genutzt werden, "Host 2", der andere Server, ist zuständig für alle zeitgesteuerten Aktionen.
"monitoringServer": [
{
"displayName": "Host 1",
"identifier": "host1",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Host 2",
"identifier": "host2",
"path": "https://serverB.myorg.local:8091/scriptrunner"
}
….
],
Beim Starten des Portals werden die Verbindungen für die zu überwachenden Server geprüft. Ist ein ScriptRunner Server nicht erreichbar, so wird eine entsprechende Fehlermeldung ausgegeben und die Verbindung für die Dauer der Browsersession deaktiviert. Fällt eine Verbindung kurzzeitig während des Monitoring aus, wird ein Reconnect durchgeführt.
Fehlermeldung, wenn ein ScriptRunner Server beim Start des Portals nicht erreichbar ist
Multi-Server-Support für Run & Reports
Die Portalarchitektur wurde um Fähigkeiten zum parallelen Ansprechen von ScriptRunner Servern erweitert. Diese Verbesserung ist fokussiert auf das Ausführen von Aktionen auf verschiedenen Servern sowie auf das Einsehen der Reports. Damit wird der transparente Einsatz des Portals insbesondere für Help Desk und Endanwender möglich. In der Run App werden dem Portalnutzer alle delegierten Aktionen angezeigt, egal auf welchem ScriptRunner Server eine Aktion konfiguriert und nach dem Starten verarbeitet wird.
Funktionsprinzip der ScriptRunner Portal App Run für Multi-Server
Die Konfiguration der einzubeziehenden Server erfolgt in der Konfigurationsdatei App.Json im Portalverzeichnis auf dem Server. Die Base URI entspricht dabei dem Master-Server, von welchem das Portal geladen wird und die Daten für die anderen Portal Apps verwendet werden, z.B. Script App etc.
Im Abschnitt "executionServer" werden die entsprechenden Server hinterlegt. Beachten Sie beim Einsatz von Load Balancern, dass die entsprechenden Einträge in der App.Json auf jedem Server vorgenommen werden müssen.
"executionServer": [
{
"displayName": "Server Team A",
"identifier": "server_a",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Team B",
"identifier": "server_b",
"path": "https://serverB.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Special C",
"identifier": "server_c",
"path": "https://serverC.myorg.local:8091/scriptrunner"
}
],
Fehlermeldung bei Abbruch der Verbindung zu einem ScriptRunner Server
Beim Starten des Portals durch den Anwender werden nun die Verbindungen zu den hinterlegten Servern geprüft. Ist ein ScriptRunner Server nicht erreichbar nicht, so wird eine entsprechende Fehlermeldung ausgegeben und die Verbindung für die Dauer der Browsersession deaktiviert. Fällt eine Verbindung kurzzeitig während der Portalnutzung aus, wird ein Reconnect durchgeführt.
Zugriff nur auf delegierte Actions auch bei Multiserver-Zugriff
Wechselt ein Portalanwender in die Run App, werden ihm nun alle Aktionen angezeigt, auf welche er berechtigten Zugriff hat, egal auf welchem Server die Aktion residiert. Adäquat verhält es sich mit der Ergebnisanzeige der Reports, im Beispiel oben dreifarbig, also von drei unterschiedlichen Servern, dargestellt.
Integrierte Online & Offline Help
Die Portal Edition R2 ist die erste Version, welche mit der neuen integrierten und kontextsensitiven Online-Hilfe ausgestattet wurde. Änderungen und Erweiterungen der Hilfeinhalte stehen somit den Anwendern immer sofort nach Veröffentlichung auf unseren Systemen zur Verfügung. Der Ausbau unserer Hilfen wird konsequent vorangetrieben.
Jederzeit Zugriff auf die eingebundene kontextsensitive Hilfe
Je nach App-Kontext werden Inhalte des Portal Guide auf unserer Supportseite angezeigt. Die Hilfe wird über den Help-Button im Portal-Header aufgerufen. Dazu wird auf der rechten Seite ein Panel eingeblendet und die mobile Ansicht des jeweiligen Abschnittes angezeigt. Die Verbindung zu den Inhalten wird direkt aus dem Portal im Browser des Anwenders zur Onlinequelle hergestellt, d.h. es ist nicht abhängig davon, ob ScriptRunner Server selbst eine Verbindung zum Internet herstellen kann.
Für den Einsatz des Portals in sensiblen Sicherheitsbereichen ohne Internetzugang steht eine Offline-Hilfe als PDF zur Verfügung.
Limitieren paralleler Script-Ausführung am Target
In den bereits vorhandenen Aktions-Einstellungen in der Admin App kann die parallele Ausführung von Aktionen auf dem Server limitiert werden. Ist das Limit bspw. auf 5 eingestellt, so wird jeder weitere Start dieser Aktion in eine Queue gestellt. Wurde eine der bereits laufenden Ausführungen beendet, wird die nächste Aktion aus der Queue verarbeitet. Durch diesen Mechanismus lassen sich Ausführungen und die Belastung von Ressourcen auf ScriptRunner Server besser steuern.
Limitierung parallel ausführbarer Aktionen auf dem Server
Die rein aktionsbezogene Limitierung wurde in diesem Release durch die Limitierung am Target insgesamt ergänzt. So lassen sich nun auch die Verarbeitungsprozesse je Target besser einschränken. Das spielt insbesondere bei Remote-Verbindungen eine Rolle, bei denen es nur eine limitierte Anzahl an PowerShell Endpoints gibt. So sind die parallelen PowerShell-Zugriffe auf Azure und M365 Services seitens Microsoft limitiert. Wird das Limit dabei ohne Steuerung mit Queuing überschritten, führt die automatisierte Scriptausführung zu einem Fehler und Abbruch.
Mit ScriptRunner Server ist nun sowohl der korrekte Sessionauf- und -abbau sichergestellt als auch die Steuerung und das Queuing der auszuführenden Scripte bis zur maximalen Anzahl verfügbarer bzw. konfigurierter Verbindungen.
Löschen von Scripten aus dem Script Repo
Die Portal App für Scripte wurde um eine Löschfunktion erweitert. In Abhängigkeit von der Rolle und dem eingestellten ScriptEditMode auf ScriptRunner Server ergeben sich folgende Möglichkeiten:
ON (default): Diese Einstellung erlaubt es allen Administratoren, Scripte im ScriptRunner Portal zu löschen.
OFF: Die Funktionen des Scripteditor sind komplett ausgeschaltet. Der Code der Scripte wird nicht angezeigt. Die Scripte können nicht gelöscht werden.
ViewOnly: Die Funktionen des Scripteditors sind ausgeschaltet, der Code der Scripte kann allerdings eingesehen werden. Die Scripte können nicht gelöscht werden. Diese Einstellung wird bei Sync mit einem Git-Repository empfohlen, wenn kein schnelles Prototyping auf dem Server direkt vorgesehen ist.
Restricted: Die Funktionen des Scripteditors sind auf das Systemverzeichnis _Upload_ auf ScriptRunner Server eingeschränkt. Diese Einstellung empfiehlt sich für das schnelle Script Prototyping. Die Scripte in diesem Verzeichnis können gelöscht werden. Diese Einstellung wird bei Sync mit einem Git-Repository empfohlen.
Weitere Informationen zur Script App finden Sie hier.
Löschen von Scripts direkt aus ScriptRunner
Vor dem eigentlichen Löschen wird eine Liste der Aktionen und Queries angezeigt, in welchem das Script verwendet wird. Wird das Script trotzdem gelöscht, erkennt ScriptRunner Server die fehlenden Referenzen und markiert die Aktionen und Queries als fehlerhaft und führt diese nicht mehr aus.
Achtung: Die Scripte werden aus dem Repo auf der Disk auf der Fileebene gelöscht.
Ausblenden der Aktionsliste im Eingabemodus
Nach Anwählen einer Aktion in der Run App erscheint die Eingabemaske für diese Aktion. Auf der linken Seite werden alle anderen Aktionen, auf die der Portalanwender berechtigt ist, in einem Listpanel angezeigt.
Um eine bessere Orientierung für die Felder auf der Eingabemaske zu bieten, kann das Listpanel mit den anderen Aktionen mit einem Button geschlossen und auch wieder geöffnet werden. Die Einstellung wird im Browser gespeichert.
Liste schließen und öffnen
Default-Language für den Aufruf des Portals
Administratoren können für den ersten Aufruf des Portals jetzt eine bestimmte Spracheinstellung festlegen, im Anschluss können die Anwender diese bei Bedarf selber ändern.
Die Grundeinstellung kann in der Rolle Main Administrator in der Settings App vorgenommen werden.
Integrierter Trial Guide in Testphase
Um die kostenfreie Testphase für ScriptRunner besser zu unterstützen, wurde der Trial Guide auf unserem Support Portal überarbeitet und in Portal Home integriert. Er wird solange angezeigt, solange das Produkt noch nicht lizensiert wurde.
Direkter Zugriff auf den Trial Guide auf der ScriptRunner Portal Home
Testen Sie jetzt die Portal Edition R2
Entdecken Sie die neuen Funktionen und die Vorteile von Automation und Delegation mit PowerShell!
Weiterführende Links
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.