SQL lernen mit dem Schachcomputer
Datenbanksprache kreativ vermittelt: Der Erfahrungsbericht einer Nachwuchs-IT-Kraft im Umfeld der Datenbankprogrammierung
Von: Torsten Ahlemeyer
Aller Anfang ist schwer
Anna hat in ihrem jungen Berufsleben erste Erfahrungen mit datengestützten Anwendungen gemacht und möchte nun ihre Kenntnisse als Datenbankentwicklerin erweitern. Als Anfängerin steht sie jedoch vor einem sehr unübersichtlichen Funktionsumfang moderner Abfragesprachen in Datenbanken. Auch interessiert sie sich zusätzlich zur „DQL“ (Data Query Language) für die Bereiche „DDL” (Data Definition Language), „DML” (Data Manipulation Language), „DCL” (Data Control Language) und „TCL” (Transaction Control Language). Sie möchte also nicht nur bestehende Datenbanken abfragen lernen, sondern etwa auch selber Datenbankobjekte und Rechte verwalten. Auch weiß sie noch nicht, wie sich ein Programmablaufplan mit Schleifen und Entscheidungsbäumen in T-SQ abbilden lässt.
Anna beherzt daher den Tipp eines Freundes, sich auf Videoplattformen kurze Schnipsel mit Tutorials anzuschauen, etwa zur Erstellung von Tabellen. Über Blogeinträge oder Foren kann Anna sich dann auch noch selbst beibringen, wie die neue Tabelle sinnvoll indiziert wird. Doch oft verwirren unterschiedliche Beiträge, Quellen oder sogar Sprachen die Hilfesuchende mehr, als dass sie ihr nützen. Die fehlende Wiederverwertbarkeit von Übungsdatensätzen stellt Anna selbst bei kommerziellen Angeboten vor Probleme – die Beispiele unterschiedlicher Kursanbieter passen für sie einfach nicht zueinander. Abschreckend wirkt darüber hinaus die imposante Größe der Übungsdatenbanken der Hersteller. Anna scheut den Download von teilweise bis zu einem Gigabyte fremder Daten, deren Struktur sie nicht kennt. Sie wünscht sich eher ein Projekt von der grünen Wiese, an dem sie nicht nur die benötigten Befehle, sondern gleich auch noch die Grundlagen der System- und Datenarchitektur von Grund auf lernen kann.
Die Idee: Alle Befehle beziehen sich auf denselben Datenbestand
Hier setzt mein Schachworkshop an. Er nutzt „Gamification“ in seiner ursprünglichen Bedeutung, um Anna nicht nur die Grundlagen der Abfragesprache T-SQL, sondern auch die Tricks und Kniffe aus über 20 Jahren Erfahrung als Datenbankentwickler beizubringen. Bei der knobelbegeisterten Person, die lernen möchte fällt die Idee, selber einem Computer das Schachspielen beizubringen, auf fruchtbaren Boden. Dabei lernt sie spielerisch Befehl um Befehl. Zuerst kann sie sich kaum vorstellen, wie man ein derart komplexes Spiel wie Schach überhaupt in Code ausdrücken kann. Die junge IT-Fachkraft spricht zwar rudimentär einige Programmiersprachen wie C#, stellt sich aber einen Algorithmus für das Spiel der Könige auf Datenbankebene mehr als herausfordernd vor.
Der Workshop der arelium GmbH, bei der ich als Datenbankspezialist tätig bin, führt Schritt für Schritt von dem Aufbau einer Datenbank über die Hinterlegung der Spielregeln bis zur Erschaffung eines Computergegners auf Großmeisterniveau zum Ziel. Dabei wird sogar ein Spielbrett mit grafischen Figuren gezeichnet. Anna lernt diverse Statistikauswertungen und perfektioniert ihren Umgang mit Prozeduren und Funktionen… und all das mit reinem T-SQL!
Hohe Motivation dank schneller Ergebnisse
Anna lernt schnell, weil sie mit jedem Stoffblock sofort Ergebnisse sieht und stets weiß, welches Ziel gerade verfolgt wird. Die einzelnen Module sind problemlos zu bewältigen, weil stets nur an einer Schraube des Schachprogramms zur selben Zeit gedreht wird. Das Projekt wächst immer weiter und der Spieltrieb der Berufsanfängerin ist geweckt. Schon nach ungefähr acht Stunden des betreuten Programmierens kann Anna mit nur einem SQL-Befehl ein Spielbrett in der Grundstellung auf den Schirm zaubern und erste Züge unter dem wachsamen Computerauge machen, welches streng über die Regeleinhaltung wacht.
Annas erste Partie: Das Narrenmatt, die kürzeste Schachpartie der Welt .
Sie erzeugt Massendaten, indem sie die Maschine gegen sich selbst spielen lässt. Diese verfüttert sie an eine Künstliche Intelligenz, um daraus Rückschlüsse zu gewinnen und das Spiel ihres Algorithmus immer weiter zu verbessern. Außerdem baut sie im Laufe des Lehrgangs den Schachcomputer um weitere Module aus. Zuerst bildet sie das gesamte Regelwerk (auch „en passant“, Rochade, Bauernumwandlung…) ab. Dann ergänzt Anna verschiedene Computerspielstufen und eine Eröffnungsbibliothek mit 400.000 Großmeisterpartien sowie eine Endspieldatenbank. Auch ein Aufgabeneditor für „matt in n-Zügen“-Aufgaben darf nicht fehlen.
Vorteile der Datenbank nutzen
Einer der ersten Schritte auf ihrem Weg zum Computerschachprogramm führt Anna zu einer Tabelle mit allen in diesem Spiel theoretisch denkbaren Zügen. Diese Tabelle nutze ich als SQL-Experte, um daran zu zeigen, wie mächtig Werkzeuge aus der Datenbankprogrammierung wie zum Beispiel JOINS sind. Mit ihrer Hilfe sind schnell alle Züge ermittelt, die laut Regeln theoretisch vorkommen können. Hierzu sind pro Figurenart nur wenige Zeilen Code notwendig, die explizit erklärt werden. Die Beispiele sind sauber strukturiert und Anna kann schon nach dem Turm als einfachste Figurenart den Quellcode für Läufer, Dame, Springer und König eigenständig notieren. Nur mit dem Bauern tut sie sich noch etwas schwer, da die Regeln für diese Figur (bspw. mit dem Doppelschritt, der Umwandlung oder dem „en passant“) doch etwas umfangreicher sind.
Die theoretischen Bewegungsmöglichkeiten des Turms (zieht und schlägt nur waagerecht oder senkrecht) sind einfach in Code zu formulieren:
In meiner Musterlösung stellt man einen einzelnen Turm auf ein beliebiges Feld eines leeren Spielbrettes [SB]. Dann zieht man diesen Turm auf ein neues Feld, welches sich entweder – aber ausschließlich – in der Spalte (waagerechte Aktion) oder der Zeile (senkrechte Aktion) vom Startfeld unterscheidet. Da es Aktionen einmal als Zug und einmal als Schlag gibt, müssen anschließend noch per CROSS JOIN beide Varianten ins Ergebnis aufgenommen werden. Auch kann der Turm weiß oder schwarz sein, was durch einen weiteren CROSS JOIN abgebildet wird.
Der Code für den Läufer ähnelt dem Code für den Turm.
Anna begreift schnell, dass die Aktionsvermittlung für einen Läufer nach demselben Schema geschieht. Nur muss sie hier die Bewegungsbedingung verändern: Eine Dame ist einfach eine Kombination aus Turm und Läufer, hier muss die Lernende keine eigenen Kriterien mehr formulieren. Auch der König ist schnell notiert: Er bewegt sich wie die Dame, allerdings stets nur ein Feld weit. Der Springer ist etwas komplizierter, er zieht und schlägt in „L“-Form, was Anna aber über die Veränderung der X- und Y-Koordinaten abgebildet bekommt. Eine der beiden muss sich um den Wert 1 absolut verändern, die jeweils andere dann um den absoluten Wert von 2.
Verschiedene Spielstufen implementieren
Ebenfalls sehr früh im Lehrgang vermittele ich die Idee, die hinter den Schwierigkeitsgraden für den Computergegner steckt. Die Grundfrage ist hier: Wie bewertet man eine Stellung? Woran macht man fest, ob man „gut“ oder „schlecht“ steht? Je besser die Bewertungsfunktion ausgearbeitet ist und je mehr Zeit der Rechner bekommt, um einige Züge im Voraus zu planen und zu bewerten, desto besser wird sein Spiel werden. Ich wähle hier den Ansatz, den ich auch verfolgte, um meinen Kindern das königliche Spiel beizubringen.
Kinder lernen zuerst die Grundregeln des Schachspiels, beginnend mit den einfachen Zügen des Turms über die komplexen Bewegungsmuster des Springers bis hin zu den Sonderregeln wie „en passant“. Jetzt sind sie in der Lage, ein Schachspiel zu absolvieren. Das Spielniveau ist allerdings noch deutlich ausbaufähig, da die Züge zwar regelkonform, aber mehr oder weniger zufällig geschehen. Daher lernen Kinder nun „Räuberschach“. Sie zählen einfach die Figuren jeder Farbe und versuchen der Gegenseite beliebige Figuren abzunehmen. Das nächste Level ist erreicht: zu dem regelkonformen Zufallszug gesellt sich eine Optimierung nach Figurenanzahl. Noch besser schneidet ein Kind ab, welches begriffen hat, dass Figuren unterschiedliche Wertigkeiten haben. So ist eine Dame viel universeller einsetzbar als ein Turm. Wird dieses zusätzliche Kriterium ebenfalls berücksichtigt, steigt das Niveau erneut.
Die Spielstärken basieren auf der Kombination von durchgeführten Berechnungen.
Diese Methode lässt sich beliebig ausbauen: Weitere Kriterien wie die restliche Bedenkzeit, die noch zur Verfügung stehenden Rochaden, evtl. vorhandene Bauernketten und vor allem die Aktivität der Figuren werden im Laufe des Workshops durch Anna ergänzt. So entstehen immer mehr Computerlevel. Dabei merkt sie schnell, dass zusätzliche Prüfungen zur Spielstärkesteigerung auch zusätzliche Bedenkzeit bedingen. Die Laufzeitoptimierung wird aber erst im späteren Kursverlauf behandelt.
Projekt ist frei verfügbar – jeder kann mitentwickeln
Die beiden besprochenen Module („theoretische Aktionen“ und „Spielstufen“) sind hier nur exemplarisch aufgeführt, um das Projekt und seinen riesigen Umfang vorzustellen. Der komplette T-SQL-Schachcomputer in seiner aktuellen Ausbaustufe kann deutlich mehr. In Zukunft liefere ich weitere Einblicke und erkläre die Architektur und die Idee hinter den fachlichen Herausforderungen.
Interessierte Leser werden einmal quer durch die wichtigsten Befehle und Programmiertechniken geleitet. Wer Lust hat selbst ein PIVOT zu formulieren, um ein Schachbrett auf den Schirm zu zaubern, oder lernen möchte mit parametrisierten Funktionen und Prozeduren zu entwickeln, kann sich kostenfrei den Quellcode zum Eigenstudium bei GitHub herunterladen.
Wer an einem richtig tiefen Einstieg, einer Nutzung des Schachprojektes als Hackathon oder an einer außergewöhnlichen SQL-Schulung unter IT-Fachleuten interessiert ist, kann sich auch gerne direkt bei mir als Autor melden.
Über den Autor: Torsten Ahlemeyer
Torsten Ahlemeyer realisiert seit 2003 Abrechnungs- und Stammdatenapplikationen in Großprojekten. Der Diplom-Wirtschaftsinformatiker und Professional Scrum Master hat sich international als Projektleiter in Softwareentwicklungsprojekten einen Namen gemacht. Als IT-Consultant hilft Torsten Ahlemeyer Kunden der arelium GmbH hauptsächlich in der Rolle als Projektleiter, aber auch als Architekt, DB-Berater oder T-SQL-Spezialist bei der Umsetzung komplexer Datenbankprojekte.
Diese Beiträge könnten dich auch interessieren:
In diesem Skript wird die Splatting-Technik verwendet, um die Parameter für die Trigger- und Action-Erstellung in übersichtlichen und pflegbaren Hashtabellen zu organisieren. Dadurch wird der Code lesbarer und einfacher zu warten.
Scheduled Jobs vs. Scheduled Tasks
In der PowerShell-Automatisierung stehen zwei Hauptkonzepte zur Verfügung: Scheduled Jobs und Scheduled Tasks. Obwohl beide Ansätze ähnliche Ziele verfolgen, unterscheiden sie sich in ihrer Funktionsweise und in ihren Einsatzmöglichkeiten.
Scheduled Tasks sind Teil des Windows Task Schedulers und bieten eine tiefe Integration in das Betriebssystem. Sie können nicht nur PowerShell-Skripte, sondern auch andere Programme oder Skripte ausführen. Scheduled Tasks eignen sich besonders gut für komplexe Szenarien, die eine enge Verknüpfung mit Windows-Diensten und -Anwendungen erfordern. Sie bieten erweiterte Planungsoptionen, wie die Ausführung basierend auf spezifischen Ereignissen oder Zuständen des Systems.
Scheduled Jobs hingegen sind eine PowerShell-spezifische Funktion. Sie ermöglichen es, PowerShell-Befehle und -Skripte zu planen und als Hintergrundjobs auszuführen. Diese Jobs sind eng in die PowerShell-Umgebung integriert, was das Ausführen von PowerShell-Cmdlets und das Verarbeiten von PowerShell-Objekten erleichtert. Scheduled Jobs sind ideal für Aufgaben, die regelmäßig und ohne direkte Benutzerinteraktion durchgeführt werden sollen.
Ein Scheduled Job kann wie folgt angelegt werden:
# Register eines PowerShell Scheduled-Jobs
$trigger = New-JobTrigger -At 10pm -Daily
$jobOption = New-ScheduledJobOption -StartIfOnBatteries
Register-ScheduledJob -Name "MeinPowerShellJob" -ScriptBlock { # DeinIhr PowerShell-Code hier, z.B. ein Skript ausführen
. C:\ps\scheduledtask\logger.ps1
} -Trigger $trigger -ScheduledJobOption $jobOption
Bei der Verwendung von Scheduled Jobs ist jedoch Folgendes zu beachten:
- Geringere Kompatibilität mit externen Tools: Beispielsweise können Scheduled Tasks auch mittels Ansible angelegt werden, welches wiederum keine Unterstützung für Scheduled Jobs bietet.
- Einschränkungen bei der Auswahl möglicher Trigger: Scheduled Tasks können unter anderem durch Windows Events (EventLog) angestoßen werden. Scheduled Jobs beschränken sich auf die zeitliche Dimension.
Effektive Strategien zur Fehlervermeidung und Optimierung
Die Automatisierung mit PowerShell und Windows Task Scheduler birgt immense Vorteile, jedoch auch potentielle Fallstricke. Im folgenden werden diese Fallstricke, sowie weitere Optimierungspotentiale beschrieben.
Ausführungskontext und Verzeichnisstruktur
Ein häufiges Missverständnis ist die Annahme, dass PowerShell-Skripte automatisch im Speicherort des Skripts ausgeführt werden. Es ist wichtig zu wissen, dass Skripte standardmäßig im Kontext des Systemverzeichnisses, wie z.B. C:\Windows\system32, gestartet werden. Um Probleme mit relativen Pfadangaben zu vermeiden, sollte der Skriptkontext zu Beginn der Ausführung zum Speicherort des Skripts gewechselt werden. Dies lässt sich mit der PowerShell-Umgebungsvariable $PSScriptRoot realisieren:
Set-Location $PSScriptRoot
Nutzung von Scheduled Tasks im Clusterbetrieb
Für eine erhöhte Verfügbarkeit und Ausfallsicherheit können Scheduled Tasks clustergesteuert eingesetzt werden. Dies bietet Vorteile wie Hochverfügbarkeit durch Failover-Fähigkeiten, zentralisiertes Management und verbesserte Skalierbarkeit. Der Einsatz im Cluster-Modus erfordert ein bestehendes Windows-Cluster-Setup.
$taskName = "ClusteredTask"
$taskType = "ClusterWide"
$clusterName = "MeinCluster"
# ... Konfiguration von Trigger, Principal und Action ...
Register-ClusteredScheduledTask -TaskName $taskName -TaskType $taskType -Cluster $clusterName -Trigger $trigger -Principal $principal -Action
Sicherheitsaspekte und Benutzerberechtigungen
Sicherheit ist ein kritischer Aspekt bei der Automatisierung. PowerShell-Skripte werden im Kontext des angegebenen Benutzers ausgeführt, was bedeutet, dass die Sicherheitsberechtigungen dieses Benutzers berücksichtigt werden müssen. Es ist ratsam, spezielle Benutzerkonten mit minimal notwendigen Berechtigungen zu verwenden, um das Risiko einer übermäßigen Rechtevergabe zu vermeiden.
Monitoring und Protokollierung
Standardmäßiges Logging des Task Schedulers reicht oft nicht aus, um eine detaillierte Übersicht über die Ausführung von Automatisierungsaufgaben zu erhalten. Erweitere das Logging durch PowerShell-spezifische Funktionen wie das Transcript- Feature oder nutze fortgeschrittene Tools wie das PSFramework-Modul für ein umfassendes Monitoring.
Parametermanagement
Die Verwaltung von Übergabeparametern ist ein wesentlicher Bestandteil der Skriptautomatisierung. Anstatt feste Werte direkt im Skript zu definieren, sollten externe Parameterquellen wie Konfigurationsdateien genutzt werden. Dies erhöht die Flexibilität und Wartbarkeit der Skripte. Standardmäßig unterstützt die PowerShell JSON und XML als Datenformate.
Fazit
Gerade im Windows-Umfeld stellt die Kombination von PowerShell und Task Scheduler eine sehr starke und kostenfreie Option dar. Der Feature-Umfang ist natürlich bei weitem nicht so umfassend wie bei kommerziellen Tools zur Job-Steuerung. Für Anwendungsszenarien wie einfachem Reporting oder Aufräumarbeiten (Log-Dateien, etc.) erfüllt der Task Scheduler seinen Zweck. Wichtig ist hierbei lediglich, dass die genannten Best Practices angewendet werden und fehlende Features wie die Verwendung eines Credential- und Key-Stores ergänzt werden.
Über den Autor: Philip Lorenz
Philip Lorenz ist erfahrener DevOps- und Cloud-Engineer mit Schwerpunkt auf Prozessautomatisierung. Mit Begeisterung teilt er sein Wissen in Form von Dienstleistungen und Schulungen und erstellt praxisnahe Lerninhalte rund um die Themen Automatisierung, Cloud-Computing und die Umsetzung moderner KI-Lösungen. Seine Trainings, inspiriert von realen IT-Szenarien, vermitteln anwendbares Wissen, das Teilnehmende direkt in ihre tägliche Arbeit integrieren können.
Diese Beiträge könnten dich auch interessieren:
Der Beitrag Das starke Duo für alle Fälle erschien zuerst auf heise academy Blog.
]]>Der Beitrag Alerts mit PowerShell und Teams-WebHooks (2) erschien zuerst auf heise academy Blog.
]]>Alerts mit PowerShell und Teams-WebHooks (2)
Teil zwei: Adaptive Cards und Zertifikats-Monitoring
Von: Philip Lorenz
Im ersten Teil dieser Reihe demonstrierte ich ich die grundsätzliche Verwendung von Teams-WebHooks mithilfe der PowerShell. Dabei habe ich mich jedoch auf die Informationsebene beschränkt, also die reine Übermittlung von textbasierten Alerts ohne zusätzliche Funktionalität. In diesem Teil gehen wir unter der Verwendung individueller Schaltflächen über den reinen Informationsgrad hinaus.
Teams Adaptive Cards: Am Beispiel von Zertifikats-Monitoring mit PowerShell
Falls du zu den Admins gehörst, die noch nie mit Problemen oder Ausfallzeiten aufgrund eines abgelaufenen Zertifikats zu kämpfen hatten, dann hattest du entweder außergewöhnliches Glück, oder du hast dein Zertifikatsmanagement hervorragend im Griff. In vielen Firmen treten gelegentlich Probleme mit abgelaufenen Zertifikaten auf, deren Gültigkeit oft erst überprüft wird, wenn sie bereits abgelaufen sind und der Service nicht mehr verfügbar ist.
Um zu verhindern, dass dir das (wieder) passiert, stelle ich dir ein PowerShell-Skript zur Verfügung, das Server auf ablaufende Zertifikate überprüft. Zugegeben: Das Skript zum Auslesen der Zertifikate ist eher unspektakulär, fast schon nebensächlich. Viel interessanter und relevanter ist die Methode, wie du über das Auslaufen der Zertifikate informiert wirst. In diesem Artikel möchte ich dir zeigen, wie du sogenannte Adaptive Cards versenden kannst. Diese bieten den Vorteil, dass du beispielsweise Buttons in die Nachrichten einfügen kannst, was ganz neue Möglichkeiten zur Reaktion auf Alarme eröffnet, zum Beispiel:
- Du möchtest Alerts automatisch in Tickets umwandeln? Füge dem WebHook-Alert einen Button hinzu, über den die Informationen an den Ticket-Dienst gesendet werden. Du kannst dies sogar von deinem Smartphone aus tun, während du im Fitnessstudio bist oder den Hund ausführst.
- Ein Dienst auf deinem Server hat unerwartet gestoppt? Lass dich darüber informieren und starte ihn mit einem Klick in Teams neu.
Wie du erkennen kannst, gibt es verschiedene Anwendungsfälle, bei denen eine unmittelbare Reaktion direkt aus der Nachricht heraus nützlich sein kann. In diesem Artikel erstellen wir ein Skript, das die Zertifikate auf verschiedenen Servern ausliest, überprüft, ob diese in den nächsten 100 Tagen ablaufen, und dabei eine Nachricht an Teams sendet. Diese Nachricht enthält einen Button, mit dem wir direkt zu den Zertifikatseinstellungen des jeweiligen Servers im Windows-Admin-Center gelangen können, um dort notwendige Änderungen vorzunehmen.
Die Nachricht, die wir gestalten werden, sieht folgendermaßen aus:
Die Vorbereitung
Natürlich brauchen wir wieder einen Teams-Kanal, der WebHooks empfangen kann. Wie du das einrichtest, habe ich dir im ersten Artikel dieser Serie erklärt. Da unsere Anforderungen hier recht einfach sind, können wir uns das Leben erleichtern: Das Modul PSTeams ermöglicht es dir, die Card mit einfachen PowerShell-Cmdlets zu gestalten, so dass du dich nicht mit JSON herumschlagen musst. In unserem Fall benötigen wir natürlich auch eine Installation des Windows-Admin-Centers. Du hast aber die Freiheit, selbst zu entscheiden, wie du auf den Alert über den Button reagieren möchtest, falls du das WAC nicht nutzt. Der Befehl, um alle Zertifikate auf einem Server anzeigen zu lassen, die in den nächsten 100 Tagen auslaufen, lautet:
Get-Childitem Cert: -Recurse -ExpiringInDays 100 | Select-Object FriendlyName, Issuer, Thumbprint, NotBefore, NotAfter, PSParentPathGefiltert habe ich den Befehl übrigens nach den Attributen, die mir wichtig erscheinen. Wir haben nun also alle Informationen, um mit der Gestaltung der Adaptive Card zu beginnen. Der Code am Beginn des Scripts sieht folgendermaßen aus:
# Array with Computers, that should be monitored
$TargetComputers = @("Server01")
# TeamsID - URL generated by Teams
$TeamsID = ""
# URL of Windows Admin Center
$WACURL = "https://localhost:6516/"
# ModuleCheck: Installs PSTeams if not available
if(-not (Get-Module -ListAvailable PSTeams)) {
Install-Module -Name PSTeams -Force
}
else {
Write-Verbose "PSTeams is already installed."
}Zuerst werden sämtliche Ziel-Computer (welche später bezüglich der Zertifikate abgefragt werden) definiert. Anschließend musst du noch deine Teams-D für den WebHook angeben. Die WACURL entspricht der URL deines Windows-Admin-Centers. Anschließend prüfen wir noch, ob PSTeams installiert ist – wenn dieses noch nicht vorhanden ist, wird es installiert.
Gestaltung der Teams-Card mit PSTeams
Drei Elemente aus PSTeams sind für uns von Bedeutung: Facts, Sections und Buttons. Facts enthalten alle Informationen, die wir über Teams darstellen möchten. Diese Facts sind verschiedenen Sections zugeordnet. Diese Sections dienen der logischen und visuellen Trennung. Buttons sind ebenfalls einer Section zugeordnet und öffnen eine Webseite oder setzen andere HTTP-Anfragen ab.
In unserem Fall sind die Zertifikatsattribute jeweils Facts. Der Friendlyname eines Zertifikats, ebenso wie der Thumbprint usw., wird als Fact dargestellt und einer Section zugeordnet. Eine Section enthält dabei immer genau ein Zertifikat. Eine Teams-Nachricht bezieht sich immer nur auf einen Server, daher benötigen wir auch nur einen Button in der gesamten Card, der uns zum Servereintrag im Windows Admin Center führt. Dieser Button hat seine eigene Section.
Nun müssen wir alle Server aus dem Array $TargetComputers abfragen – dies tun wir mit einer Foreach-Schleife, sodass wir direkt danach die entsprechenden Zertifikatsdaten vom jeweiligen Server erhalten können:
foreach ($computer in $TargetComputers) {
# Getting all certificates of specified computer, that will expire in the next 100 days
[array]$ExpiringCerts = Invoke-Command -ComputerName $computer -Credential $cred -ScriptBlock {
Get-ChildItem Cert:\LocalMachine -Recurse -ExpiringInDays 100 |
Select-Object FriendlyName, Issuer, Thumbprint, NotBefore, NotAfter, PSParentPath
}
}Die Variable $ExpiringCertificates beinhaltet nun alle Zertifikate, die in den nächsten 100 Tagen ablaufen. Nun müssen wir diese Informationen, wie zuvor beschrieben, auf die verschiedenen Sections verteilen. Dazu erstellen wir ein leeres Array, das wir nach und nach mit Sections befüllen. Innerhalb der bereits beschriebenen ForEach-Schleife erstellen wir eine weitere ForEach-Schleife, die über alle Zertifikate iteriert. Für jedes Zertifikat wird eine neue Section erstellt, diese Section mit den Facts (den Attributen des aktuellen Zertifikats) gefüllt und die neu erstellte Section dem Section-Array hinzugefügt. Am Ende haben wir also ein Array mit allen Informationen (in Sections unterteilt) und könnten dieses direkt an Teams senden. Bevor wir das tun, erstellen wir jedoch noch eine letzte Section, die den Button für das Windows-Admin-Center enthält. Den Link, den der Button aufruft, passen wir für jeden Server an, da in der URL festgelegt werden kann, welcher Computer/Server im Admin Center geöffnet werden soll. Unser Code sieht nun also folgendermaßen aus:
# Array with Computers, that should be monitored
$TargetComputers = @("Server01")
# TeamsID - URL generated by Teams
$TeamsID = ""
# URL of Windows Admin Center
$WACURL = "https://localhost:6516/"
# ModuleCheck: Installs PSTeams if not available
if(-not (Get-Module -ListAvailable PSTeams)) {
Install-Module -Name PSTeams -Force
}
else {
Write-Verbose "PSTeams is already installed."
}
# Iterating through every computer in $TargetComputers
foreach ($computer in $TargetComputers) {
# Getting all certificates of specified computer, that will expire in the next 100 days
[array]$ExpiringCerts = Invoke-Command -ComputerName $computer -Credential $cred -ScriptBlock {
Get-ChildItem Cert:\LocalMachine -Recurse -ExpiringInDays 100 |
Select-Object FriendlyName, Issuer, Thumbprint, NotBefore, NotAfter, PSParentPath
}
# Checking, whether there are any certificates expiring in the specified timespan before proceeding
if ($ExpiringCerts.Count -gt 0){
# Creating Sections with embedded Facts (Certificate Information) for Teams
$Sections = @()
foreach ($cert in $ExpiringCerts) {
$facts = @()
$cert |
Get-Member |
Where-Object MemberType -eq NoteProperty |
ForEach-Object {
$facts += New-TeamsFact -Name $_.Name -Value "**$($cert.($_.Name))**"
}
$Sections += New-TeamsSection -ActivityDetails $facts
}
# Gets server-URL within Windows Admin Center and Teams-Button to access it
$WACURLServer = $WACURL + "servermanager/connections/server/" + $computer + "/tools/certificates"
$Button = New-TeamsButton -Name 'Edit Certificates' -Link $WACURLServer -Type 'ViewAction'
$Section = New-TeamsSection -Buttons $Button
# Send Card
$Sections += $Section
$Count = $ExpiringCerts.count
Send-TeamsMessage -URI $TeamsID -Color Red -Sections $Sections `
-MessageTitle "Alert: $count Certificates on $computer expire within the next 100 days!" `
}
}Wenn wir nun also diesen Code ausführen und sich auslaufende Zertifikate auf den Maschinen befinden, erhalten wir die oben gezeigte Teams-Card. Du hast nun in wenigen Minuten ein eigenes Alerting für deine Zertifikate erstellt!
Hinweis: Wenn in deiner Organisation alle Zertifikate von einer zentralen Zertifizierungsstelle (CA) ausgestellt wurden, ist es effizienter, eine zentrale Abfrage an die CA zu senden, anstatt jeden einzelnen Server auf seine Zertifikate zu überprüfen. Die genannten 100 Tage sind keine persönliche Empfehlung, da ich diesen Zeitraum für zu lang halte. Ich habe die 100 Tage nur zu Demonstrationszwecken gewählt, um sicherzustellen, dass wir einige Treffer erzielen. Meiner Meinung nach ist ein Zeitraum von 15 bis 30 Tagen für die Überwachung angemessen, obwohl dies natürlich je nach Umgebung variieren kann.
Über den Autor: Philip Lorenz
Philip Lorenz ist erfahrener DevOps- und Cloud-Engineer mit Schwerpunkt auf Prozessautomatisierung. Mit Begeisterung teilt er sein Wissen in Form von Dienstleistungen und Schulungen und erstellt praxisnahe Lerninhalte rund um die Themen Automatisierung, Cloud-Computing und die Umsetzung moderner KI-Lösungen. Seine Trainings, inspiriert von realen IT-Szenarien, vermitteln anwendbares Wissen, das Teilnehmende direkt in ihre tägliche Arbeit integrieren können.
Diese Beiträge könnten dich auch interessieren:
Der Beitrag Alerts mit PowerShell und Teams-WebHooks (2) erschien zuerst auf heise academy Blog.
]]>Der Beitrag Alerts mit PowerShell und Teams-WebHooks (1) erschien zuerst auf heise academy Blog.
]]>Alerts mit PowerShell und Teams-WebHooks (1)
Teil eins: Ein Leitfaden zur Optimierung deiner Alarmierungs-Strategie
Von: Philip Lorenz
Vielleicht ist dir diese Situation bekannt: Aus der Historie der IT-Infrastruktur ist das Monitoring und das zugehörige Alerting stetig gewachsen, wobei verschiedene Tools für unterschiedliche Bereiche eingesetzt werden. Gerade beim Alerting haben diese Tools aber oft eines gemeinsam: Die Alarme werden per Mail versendet. Das führt nicht selten dazu, dass sich neben Einladungen zu Terminen, Abstimmungen und Fotos von der letzten Teamveranstaltung eine Menge Alert-Nachrichten aus verschiedenen Monitoring-Systemen und Skripten ansammeln.
Da die Infrastruktur stetig verändert wird und der manuelle Wartungsaufwand für diese Alerts in den Monitoring-Systemen gleichzeitig steigt, werden Anpassungen oftmals vernachlässigt. Schnell stellt sich ein Credo nach dem Motto “Oh, dieser Alert ist nicht so wichtig, er kommt jeden zweiten Sonntag – einfach ignorieren” ein. Es liegt nahe, einen separaten Ordner im eigenen Postfach zu erstellen, in den alle Alerts automatisch per Outlook-Regel verschoben werden und somit in Vergessenheit geraten.
Zugegeben, das hier dargestellte Szenario ist fast das schlimmstmögliche Beispiel für eine Alerting-Implementierung. Trotzdem ist es eine Situation, die in vielen Unternehmen vorkommt. Die aktuelle Art des Alertings ist angesichts der wachsenden Anforderungen an die Reaktionsgeschwindigkeit einer Operationsabteilung und der schnelllebigen Natur der Infrastruktur nicht mehr angemessen. Allein die Tatsache, dass die Kommunikation über Alerts zwischen den Administratoren normalerweise nicht mehr per E-Mail, sondern meistens über Teams (oder einen anderen Messenger) erfolgt, lässt Zweifel aufkommen, ob E-Mails das passende Medium für Benachrichtigungen sind. WebHooks bieten die Möglichkeit, Alerts oder andere Benachrichtigungen an einen Teams-Kanal zu senden. Hier kann jeder Abteilungsbereich seinen eigenen Teams-Kanal für das Monitoring einrichten. Der Abteilungsleiter hat alle Meldungen im Blick, ohne dass sein Postfach überquillt. Jeder kann selbst entscheiden, welche Bereiche für ihn relevant sind und diese so einstellen, dass er bei einem Vorfall benachrichtigt wird. Alerts und Benachrichtigungen können direkt kommentiert werden, wodurch die Notwendigkeit eines Medienwechsels bei der Absprache zwischen den Administratoren entfällt. In diesem Artikel lernst du, wie du mit wenig PowerShell-Code solche Teams-Alerts erstellen kannst – folgende Abbildung zeigt, wie eine solche Alerting-Nachricht aussehen kann.
Hinweis: WebHooks werden natürlich auch außerhalb von Teams verwendet. Sämtliche Messenger unterstützen mittlerweile WebHooks und können (womöglich mit kleinen Abweichungen in der Konfiguration) ähnlich bedient werden.
WebHooks
Bevor wir uns mit der Einrichtung eines WebHooks beschäftigen, eine kurze Erläuterung zu Webhooks selbst: Eine Anwendung kann sogenannte eingehende (oder auch ausgehende) WebHooks bereitstellen. Dazu bietet sie eine eindeutige URL an, die darauf wartet, Webanfragen in einem bestimmten Format zu erhalten – ähnlich wie eine API. Anwendungen und Server können so mit minimalem Konfigurationsaufwand Nachrichten austauschen. In diesem Artikel konzentrieren wir uns auf die Möglichkeit, WebHooks für Monitoring-Alerts zu nutzen.
Um den Unterschied zwischen einer REST API und einem WebHook zu verdeutlichen, stell dir vor, dass du in einem Restaurant bist. Eine REST API ist wie ein Kellner, den du rufen kannst, wenn du etwas brauchst – sei es eine neue Bestellung aufgeben oder die Rechnung anfordern. Du initiierst die Interaktion und der Kellner reagiert entsprechend. Ein WebHook hingegen ist wie ein Kellner, der dir automatisch ein neues Glas Wasser bringt, sobald er sieht, dass dein Glas leer ist. Du musst ihn nicht rufen oder ihm sagen, was zu tun ist. Er hat eine vordefinierte Aufgabe (dein Glas auffüllen, wenn es leer ist) und führt diese aus, sobald das definierte Ereignis (leeres Glas) eintritt. In diesem Sinne wartet der WebHook (der Kellner) auf ein bestimmtes Ereignis und reagiert automatisch darauf.
Teams-WebHooks mit PowerShell
Wir wollen uns nun also ein konkretes Beispiel für PowerShell-initiierte WebHooks ansehen. Mögliche Anwendungsszenarien wären dabei unter anderem:
- Volllaufende Festplatte
- Benachrichtigung zum Ablauf eines SSL-Zertifikats
- Sperrung eines AD-Nutzers
In diesem Blog zeige ich dir praxisnah, wie Teams-WebHooks zum Senden von Benachrichtigungen genutzt werden können, wenn ein Benutzer-Account im ActiveDirectory gesperrt wird. Auf diese Weise kann man proaktiv handeln und die Sperrung des Benutzers bemerken, bevor die Anwendungen des Benutzers eine erneute Anmeldung verlangen und dieser ein Ticket erstellt bzw. die Support-Hotline anruft. Das Konzept ist in zwei Teile unterteilt:
- die Teams-Konfiguration
- das PowerShell-Skript
In den meisten Fällen fungiert PowerShell als “Klebstoff”, der die verschiedenen Anwendungen miteinander verbindet. Zur Klarstellung: Das ActiveDirectory bietet keine eingebaute Möglichkeit, WebHooks zu versenden, wenn ein Benutzer gesperrt wird – diese Aufgabe wird von PowerShell übernommen. Natürlich gibt es auch anderweitige Tools, um diesen Anwendungsfall abzubilden. Der Vorteil bei Verwendung der PowerShell liegt meiner Meinung nach in der größtmöglichen Flexibilität bei der Gestaltung des Alertings (und möglichen Folgeoperationen) und der kostenfreien Nutzung. Dennoch sollten gerade bei großen Infrastrukturen ebenfalls dedizierte Monitoring-Lösungen evaluiert werden.
Konfiguration von Teams
Zur Einrichtung von WebHooks muss ein Kanal/Channel festgelegt werden, an den die Alerts gesendet werden sollen. Anschließend kann man die Connectors des Kanals über einen Rechtsklick auf diesen öffnen. Anschließend lässt sich über „Konfigurieren“ bei „incoming WebHook“ die Einrichtung der Schnittstelle starten.
Nachdem man einen aussagekräftigen Namen vergeben und evtl. ein Icon hochgeladen hat, klickt man „Erstellen“ und erhält im Anschluss die URL, über welche wir die WebRequests im PowerShell-Script senden können. Diese URL sollte vertraulich behandelt werden, da diese public angesprochen werden kann. Ein Angreifer könnte mit dieser URL Nachrichten in deinen Teams-Channel senden (beispielsweise mit Links zu Phishing-Scripts, etc.) – und das solltest du logischerweise vermeiden.
PowerShell
Für das Senden von WebHooks an Teams wird das sogenannte JSON-Format verwendet. In unserem PowerShell-Code nutzen wird ein sogenanntes PSCustomObject, das weiter unten zu JSON konvertiert wird – PowerShell macht uns dies recht einfach. Grundsätzlich kannst du folgenden Code aber einfach kopieren und deine individuellen Werte eintragen. Wichtig ist natürlich, dass du die WebHook-URI von Teams in Zeile 1 hinterlegst.
[String]$uri = "Hier die Webhook Uri eintragen"
[String]$var = "Text, welcher im Nachrichteninhalt erscheint"
$JSONBody = [PSCustomObject][Ordered]@{
"@type" = "MessageCard"
"@context" = "http://schema.org/extensions"
"summary" = "Meine erste Alert-Summary!"
"themeColor" = '0078D7'
"title" = "Mein erster Alert."
"text" = "Hier steht die genaue Alertbeschreibung!
Variablen kann man natuerlich auch anfuegen: $var"
}
$TeamMessageBody = ConvertTo-Json $JSONBody -Depth 100
$parameters = @{
"URI" = $uri
"Method" = 'POST'
"Body" = $TeamMessageBody
"ContentType" = 'application/json'
}
Invoke-RestMethod @parametersAnschließend können wir durch Ausführen des Scripts direkt testen, ob die Kommunikation zum WebHook-Endpunkt funktioniert. Bei erfolgreicher Durchführung erhalten wir seitens der PowerShell eine „1“ als Rückgabe zurück und die Nachricht erscheint in unserem Teams:
Super, du hast erfolgreich deinen ersten WebHook an Teams gesendet! Wie versprochen, stelle ich dir nun ein Skript zur Verfügung, das dich über Teams benachrichtigt, sobald ein Benutzer im Active Directory gesperrt wird. Dafür benötigen wir natürlich einen Mechanismus, der erkennt, wenn ein Benutzer gesperrt wurde. Glücklicherweise erzeugt das Windows EventLog einen Eintrag mit der EventID 4740, sobald ein Benutzer gesperrt wird. Dieses Ereignis können wir als Auslöser verwenden, um unser Skript zu starten. Dies kann beispielsweise über den Windows Task Scheduler erfolgen. Das Script zum Auslesen des gesperrten AD-Accounts kann wie folgt aussehen:
# Gets locked AD user, that was locked latest
$LockedUser = Search-ADAccount -LockedOut `
| Get-ADUser -Properties badpwdcount, lockoutTime, lockedout, emailaddress `
| Select-Object badpwdcount, lockedout, Name, EmailAddress, SamAccountName, @{ Name = "LockoutTime"; Expression = { ([datetime]::FromFileTime($_.lockoutTime).ToLocalTime()) } } `
| Sort-Object LockoutTime -Descending `
| Select-Object -first 1Setzen wir dieses nun mit dem Script zum Versenden des WebHooks zusammen und passen die Werte an, erhalten wir folgenden Code:
# Gets locked AD user, that was locked latest
$LockedUser = Search-ADAccount -LockedOut `
| Get-ADUser -Properties badpwdcount, lockoutTime, lockedout, emailaddress `
| Select-Object badpwdcount, lockedout, Name, EmailAddress, SamAccountName, @{ Name = "LockoutTime"; Expression = { ([datetime]::FromFileTime($_.lockoutTime).ToLocalTime()) } } `
| Sort-Object LockoutTime -Descending `
| Select-Object -first 1
[String]$uri = "Hier die Webhook Uri eintragen"
$JSONBody = [PSCustomObject][Ordered]@{
"@type" = "MessageCard"
"@context" = "http://schema.org/extensions"
"summary" = "Locked: $($LockedUser.SamAccountName)"
"themeColor" = '0078D7'
"title" = "User locked"
"text" = "`n
SamAccountName: $($LockedUser.SamAccountName)
Name: $($LockedUser.Name)
Mail: $($LockedUser.EmailAddress)
Bad Password Count: $($LockedUser.badpwdcount)
Timestamp: $($LockedUser.LockoutTime.ToString())
"
}
$TeamMessageBody = ConvertTo-Json $JSONBody -Depth 100
$parameters = @{
"URI" = $uri
"Method" = 'POST'
"Body" = $TeamMessageBody
"ContentType" = 'application/json'
}
Invoke-RestMethod @parametersWir erhalten damit nun folgende Nachricht in Teams, sofern ein Benutzer gesperrt wurde:
Fazit
WebHooks stellen einen modernen Ansatz für das Alert-Management dar. Sie bieten klare Vorteile gegenüber Mail-Alerts, obwohl auch diese ihre Stärken haben können (beispielsweise hinsichtlich der Dokumentation, etc.). Die PowerShell eignet sich hierbei hervorragend als Vermittler für Anwendungen, die keine eingebaute Funktion zur Versendung von WebHooks besitzen. Im nächsten Teil dieser Reihe zeige ich dir, wie du die Teams-Alert mithilfe von AdaptiveCards noch weiter gestalten kannst, indem du beispielsweise Buttons hinzufügst, mit denen du direkt per Knopfdruck auf ausgelöste Alerts reagieren kannst – das Ganze natürlich wieder an einem Praxisbeispiel demonstriert.
Teil zwei: Adaptive Cards und Zertifikats-Monitoring
Über den Autor: Philip Lorenz
Philip Lorenz ist erfahrener DevOps- und Cloud-Engineer mit Schwerpunkt auf Prozessautomatisierung. Mit Begeisterung teilt er sein Wissen in Form von Dienstleistungen und Schulungen und erstellt praxisnahe Lerninhalte rund um die Themen Automatisierung, Cloud-Computing und die Umsetzung moderner KI-Lösungen. Seine Trainings, inspiriert von realen IT-Szenarien, vermitteln anwendbares Wissen, das Teilnehmende direkt in ihre tägliche Arbeit integrieren können.