Wer dbatools benutzt, ruft einen Befehl auf und bekommt ein Ergebnis. Dazwischen passiert erstaunlich viel: Ein Verbindungsobjekt wird gebaut oder wiederverwendet, Microsofts SMO-Klassen werden bemüht, Ergebnismengen werden in PowerShell-Objekte verwandelt, Fehler werden abgefangen und Meldungen geschrieben. Als Maintainer des Moduls habe ich einige Zeit gebraucht, um zu verstehen, warum manches genau so gemacht wird, wie es gemacht wird. Dieses Verständnis gebe ich gerne weiter, denn es hilft bei der Nutzung des Moduls und damit bei der effizienten Verwaltung von Microsoft SQL Servern.

Wir folgen einem einzigen Aufruf, Invoke-DbaQuery, einmal komplett durch das Modul. Vom Parameter SqlInstance über Connect-DbaInstance und die Verbindungsverwaltung bis zur Rückgabe. Unterwegs schauen wir uns an, was der Parameter -As steuert, wann DataRow, DataTable, PSObject oder SingleValue die richtige Wahl sind, und wie das Modul mit NULL umgeht. Dazu das interne Logging: Wo dbatools mitschreibt, was in Get-DbatoolsLog steht und wie man damit Fehler findet, ohne das Modul zu debuggen. Und die Fehlerbehandlung, damit das eigene Skript einen gescheiterten Aufruf auch bemerkt.

Ich zeige auch, wo ich selbst überrascht wurde. Beispielsweise bei drei Befehlen, die an Zertifikaten mit modernen Schlüsseln scheitern. An solchen Fällen wird deutlich, wie man dem Modul auf die Finger schaut und wie aus einem Anwender ein Mitwirkender wird.

Zum Schluss ein Betriebsthema, das jeden trifft, der dbatools regelmäßig aktualisiert: Jede Version ist mit einem neuen Zertifikat signiert. Wir klären, was das für die Ausführungsrichtlinie bedeutet und worauf man beim Update achten sollte.

Der Vortrag richtet sich an alle, die dbatools schon einsetzen und wissen wollen, was sie da eigentlich aufrufen. Grundkenntnisse in PowerShell reichen. Wer den Vortrag gehört hat, wählt das Rückgabeformat bewusst, findet die Ursache eines Fehlers im Log statt im Debugger, fängt Fehler im Skript zuverlässig ab und spielt neue Versionen ohne Überraschungen ein.