In diesem Beitrag zeigen wir, wie Sie durch Tasks ausgeführte Powershell-Skripte nutzen können, um Alltagsaufgaben in LOGINventory zu automatisieren. Konkret sollen bestimmte Nutzer benachrichtigt werden, dass deren Geräte einen Neustart benötigen.
Über unseren Support erreichte uns neulich die Anfrage eines LOGINventory-Nutzers, der die mitgelieferte Auswertung zu ausstehenden Updates und Reboots als sehr praktisch empfand. Allerdings wollte er gerne nicht selbst eine E-Mail mit den betroffenen Geräten erhalten, sondern direkt die Nutzer der Geräte benachrichtigen lassen. Diesen Anwendungsfall haben wir gerne aufgegriffen und zeigen hier, wie diese Aufgabe realisiert werden kann.
Hintergrund: Mitgelieferte Tasks
In LOGINventory können auf allen Abfragen Tasks positioniert werden, um gewisse Aktionen zu triggern. Detaillierte Erklärungen dazu finden sich im entsprechenden Handbuch-Kapitel.
Ebenso werden in der Baumstruktur von LOGINventory bereits Abfragen mitgeliefert, auf denen sich Tasks befinden. Diese Abfragen befinden sich größtenteils im Ordner “Interessant” und versenden beispielsweise eine E-Mail, wenn es Geräte gibt, auf denen die Partition C:\ fast belegt ist. Eine andere Abfrage zeigt alle Geräte mit ausstehenden Betriebssystem-Updates oder Reboots.
Über das Ribbon-Menü “Task bearbeiten” kann geprüft werden, welche Task sich auf dem jeweiligen Knoten befindet. Die hier mitgelieferte Task prüft einmal die Woche, ob die Zeilenanzahl größer 0 ist (=ob es Geräte mit ausstehenden Updates / Reboots gibt) und schickt, falls dies der Fall ist, eine Email an die in den Task-Einstellungen hinterlegte Adresse, welche im Anhang den PDF-Export der Abfrage enthält.
In den folgenden Schritten zeigen wir, wie Sie händisch die Abfrage anpassen und die Task modifizieren, sodass ein Powershell-Skript ausgeführt wird. Alternativ steht der fertige Knoten zum Import in LOGINventory hier bereit.
Achtung: In diesem Skript müssen in jedem Fall die Einstellungen des Mail-Servers angepasst werden – selbst wenn in LOGINventory bereits ein Mail-Server hinterlegt ist.
Ebenso muss die Task auf dem importierten Knoten noch angepasst werden und die mitgelieferte ps1-Datei ausgewählt werden, damit dieses zum Resource Repository hinzugefügt wird.
Anpassen der Abfrage
Damit nicht nur der Administrator, sondern der jeweilige Hauptnutzer (=Owner) des Geräts per E-Mail benachrichtigt werden kann, sollten zur Abfrage weitere Spalten, wie Name, Vorname und E-Mail-Adresse des Hauptnutzers, hinzugefügt werden. Dazu wird erst eine Kopie der bestehenden Abfrage angelegt, diese wird dann bearbeitet und die Eigenschaften “Owner.Name” “Owner.UserAccount.FirstName” und “Owner.UserAccount.Mail” werden hinzugefügt. Außerdem wollen wir in diesem Beispiel nur noch Nutzer mit Geräten mit ausstehenden Updates benachrichtigen, weshalb die Filterbedingung so angepasst wird, dass nur noch auf OperatingSystem.UpdatesPending = True gefiltert wird. Deswegen wird die Abfrage jetzt auch umbenannt.
Die Eigenschaft Owner wird automatisch vorbefüllt mit dem User, der bei der ersten Erfassung des Geräts der letzte angemeldete Benutzer war, und kann überschrieben werden. Diese Eigenschaft ist dafür geeignet, Geräte zu Benutzern zuzuweisen. Die zugewiesenen Geräte eines Benutzers sind dann auch in den entsprechenden Berichten und Abfragen sichtbar.
Die Eigenschaft Owner updated sich automatisch, wenn der zuletzt angemeldete Benutzer sich bei fünf aufeinander folgenden Scans vom aktuellen Owner unterschieden hat. Dieses Verhalten lässt sich in den Einstellungen ändern.
Erstellen eines PowerShell-Skripts
Wird über eine Task ein PowerShell-Skript aufgerufen, so wird u.a. der Parameter $data übergeben, der die Ergebnisse der Abfrage enthält.
Die Task selbst kann nicht auf die in LOGINventory hinterlegten Mail-Server-Einstellungen zugreifen, weshalb diese im Skript hinzugefügt, bzw. angepasst werden müssen.
Folgendes Skript extrahiert also aus dem $data-Parameter die benötigten Informationen zu Vorname, Geräte-Name und Email-Adresse und schickt dem Hauptnutzer des Geräts eine entsprechende Email, wenn die Mail-Server-Einstellungen bei $PSEmailServer = "relay" korrekt angepasst wurden (ebenso wie die Absender-Adresse bei $mailfrom =):
param (
[string]$data
)
$date = Get-Date -uformat "%Y-%m-%d"
$mailfrom = "it@company.de"
$subject = "Update required! $date"
# Set mail server
$PSEmailServer = "relay"
Import-Csv $data -delimiter ";" | ? Owner.UserAccount.Mail -match "\S" | foreach {
$mailTo = $_.'Owner.UserAccount.Mail'
$firstname = $_.'Owner.UserAccount.FirstName'
$asset = $_.'Name'
$body =
"Hey $firstname,
Please install latest Windows patches on your computer ('$asset')!
Kind regards,
Your Admin Team"
Send-MailMessage -to $mailTo -from $mailfrom -Subject $subject -body $body -encoding ([System.Text.Encoding]::UTF8)
}
Exit-PSSession
Aufruf des Skripts über eine Task
Auf der oben angepassten Abfrage kann jetzt eine neue Task hinzugefügt werden (oder je nach Bedarf die alte abgeändert werden).
Die Task soll ausgeführt werden, falls es Rechner mit ausstehenden Updates gibt (Zeilenanzahl > 0). Diese Bedingung soll einmal wöchentlich geprüft werden (z.B. jeden Dienstag um 10 Uhr). Als Aktion wird das Ausführen eines PowerShell-Skripts gewählt. Hier muss jetzt nur noch das zuvor erstellte Skript eingefügt werden.
Um zu testen, ob alles erfolgreich durchgeführt wird, kann nach einem Speichern der Task (durch Klick auf “Übernehmen”) “Jetzt ausführen” gewählt werden. Jetzt sollten alle Nutzer mit ausstehenden Reboots eine entsprechende Mail erhalten haben.
Test der Funktionsweise
Vermutlich hat der Administrator selbst immer vorbildlich alle Updates auf seinem Rechner installiert, weswegen er keine Email bekommen würde. Um zu testen, ob das Skript trotzdem wie gewünscht funktioniert und noch ein Finetuning an Inhalt und Layout der Mail vorzunehmen, kann eine Kopie der verwendeten Abfrage erstellt werden, die als Ergebnismenge nur einen Rechner, nämlich den Client des Administrators enthält. Dies kann z.B. geschehen, indem der Filter modifiziert wird, sodass nicht mehr auf “ausstehende Updates”, sondern auf einen bestimmten Rechner-Namen gefiltert wird.
Die Funktionsweise des Skripts ist natürlich die gleiche – diesmal wird eben nur ein Nutzer benachrichtigt.
Fazit
Mit LOGINventory können viele Prozesse im Unternehmen automatisiert werden. Das hier verwendete Beispiel zeigt nur einen spezifischen Anwendungsfall. Ebenso könnten Nutzer auch aufgrund von anderen Bedingungen benachrichtigt werden, z.B. wenn
- der Client länger als 30 Tage nicht mehr neu gestartet wurde (Filter auf
OperatingSystem.LastBoot < Today - 30 days) - die Druckerpatronen fast leer sind (Filter auf
PrinterMarkerSupply.Level < 20) - auf einem Gerät eine unerwünschte Software installiert ist (Filter auf
SoftwarePackage.Undesired = True) - die Garantie des Geräts demnächst abläuft und der Nutzer nach Mängeln am Gerät gefragt wird (Filter auf
Warranty.End ist zwischen Today und Today + 90 days) - etc.
Durch die relationale Datenbank-Struktur und die Inventarisierung von unterschiedlichen Datenquellen lassen sich also beliebige Auswertungen erstellen, auf denen Tasks frei positioniert werden können, sodass sich viele Aufgaben im Administratoren-Bereich automatisieren lassen. Trotzdem sollte sich immer vor Augen geführt werden, dass diese Auswertungen nur Sinn ergeben, wenn die Daten möglichst aktuell sind. Der reibungslose Betrieb von LOGINventory muss also sichergestellt werden, was sich seinerseits zwar auch mit Tasks überprüfen lässt, jedoch den aufmerksamen Blick eines Administrators nicht ersetzen kann.