SQL Server loves PowerShell to move data around en de

With a little bit of .NET, PowerShell can establish a very simple and powerful connection to database systems such as Microsoft SQL Server, both on-premises and in the cloud. This makes it very easy to transfer data between different databases in different locations and even Excel files.
In this session we will mainly focus on SQL Server, but also briefly discuss other databases such as Oracle or PostgreSQL. The required systems can easily be set up with the help of containers so that everyone can participate directly.
We will first look at the underlying technologies and then build a small data hub together and optimize it step by step.
Almost all PowerShell code is hidden in functions, which I will publish in advance. However, basic knowledge of PowerShell is an advantage.

SQL Server liebt PowerShell zum Transportieren von Daten en de

Mit ein wenig Hilfe von .NET kann PowerShell eine sehr einfache und leistungsstarke Verbindung zu Datenbanksystemen wie Microsoft SQL Server herstellen, sowohl im lokalen Rechenzentrum als auch in der Cloud. Dies macht es sehr einfach, Daten zwischen verschiedenen Datenbanken an verschiedenen Standorten und sogar Excel-Dateien zu übertragen.
In dieser Sitzung werden wir uns hauptsächlich auf den SQL Server konzentrieren, aber auch kurz auf andere Datenbanken wie Oracle oder PostgreSQL eingehen. Die erforderlichen Systeme lassen sich mit Hilfe von Containern leicht einrichten, so dass jeder direkt daran teilnehmen kann.
Wir werden uns zunächst die zugrundeliegenden Technologien anschauen und dann gemeinsam eine kleine Datendrehscheibe aufbauen und diese Schritt für Schritt optimieren.
Fast der gesamte PowerShell-Code ist in Funktionen versteckt, die ich im Vorfeld veröffentlichen werde. Grundkenntnisse der PowerShell sind jedoch von Vorteil.

dbatools von innen: Was passiert eigentlich, wenn ich Invoke-DbaQuery aufrufe? de en

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.

AI for DBAs: No Framework, No Agent Zoo – Just Start Small en de

A lot of people are talking about AI frameworks and agents. You don't need either to get started. I began with nothing but a Claude subscription, and even that takes real work off my plate.

My core areas are data and databases, that's where I know my way around. Outside of that, my knowledge gets thinner, for example with the operating system or with issuing certificates. That puts me in the same position as many DBAs, because no database runs on its own. I understand how the systems work, but I lack the details. Sometimes it's the exact command, sometimes the log that holds the cause. This is exactly the gap AI fills.

Live in my lab, I show everyday tasks around SQL Server. An instance won't start after a certificate change, and the error message doesn't help. A disk is full, and nobody knows why. Which certificates expire soon, and who is actually a member of the sysadmin role on all my instances? And then there's the inherited script that nobody ever documented.

The decisions always stay with me. AI doesn't replace my understanding. It saves me typing and searching through documentation. I read the generated code and trim it down, and I show that live too: what gets cut from the answer matters just as much as what stays. Finally, a look at where the journey leads if you keep at it: Claude now runs the Ansible deployments in my lab by itself, with the same subscription I started with.

This session is for DBAs who wonder where to start with AI without turning it into a project right away. No prior AI knowledge is needed. After this session, you'll know how to start with a task of your own in small steps and how to check the AI's answers before you use them.

KI für DBAs: Kein Framework, kein Agenten-Zoo – einfach mal klein anfangen en de

Viele reden über KI-Frameworks und Agenten. Für den Einstieg braucht man beides nicht. Ich habe mit nichts als einem Claude-Abo angefangen, und schon damit nimmt mir die KI echte Arbeit ab.

Meine Kerngebiete sind Daten und Datenbanken, da kenne ich mich aus. Drumherum wird es dünner, etwa beim Betriebssystem oder bei der Ausstellung von Zertifikaten. Damit geht es mir wie vielen DBAs, denn keine Datenbank läuft für sich allein. Ich verstehe, wie die Systeme funktionieren, aber mir fehlen die Details. Mal ist es der genaue Befehl, mal das Protokoll, in dem die Ursache steht. Genau diese Lücke füllt die KI.

Live in meinem Labor zeige ich Aufgaben aus dem Alltag rund um den SQL Server. Eine Instanz startet nach einem Zertifikatswechsel nicht mehr, und die Fehlermeldung hilft nicht weiter. Eine Platte ist voll, und keiner weiß, warum. Welche Zertifikate laufen demnächst ab, und wer ist auf all meinen Instanzen eigentlich Mitglied der Rolle sysadmin? Und dann ist da noch das geerbte Skript, das niemand dokumentiert hat.

Die Entscheidung bleibt dabei immer bei mir. Die KI ersetzt nicht mein Verständnis. Sie erspart mir Tipparbeit und die Suche in der Dokumentation. Den erzeugten Code lese ich und kürze ihn, und auch das zeige ich live: Was aus der Antwort rausfliegt, ist genauso wichtig wie das, was drinbleibt. Zum Schluss gibt es einen Ausblick, wohin die Reise führt, wenn man dranbleibt: Inzwischen führt Claude die Ansible-Deployments in meinem Labor selbst aus, mit demselben Abo wie am Anfang.

Der Vortrag richtet sich an DBAs, die sich fragen, wo sie mit KI anfangen sollen, ohne gleich ein Projekt daraus zu machen. Vorkenntnisse zu KI sind nicht nötig. Wer den Vortrag gehört hat, weiß, wie man mit einer eigenen Aufgabe in kleinen Schritten beginnt und wie man die Antworten der KI prüft, bevor man sie einsetzt.

Suddenly SQL Server won't start: Understanding, checking and replacing certificates en de

The infrastructure team renews the certificates on all servers, just like every year, and removes the old ones. Nobody knew that SQL Server was using one of them. At the next restart, the service fails to start. The System log says only "Cannot find object or property", and the application goes down.

That's what happened at a customer, and it can happen anywhere certificates exist but nobody owns them: Those who roll them out don't know who uses them, and those who use them only notice the change when something breaks. This session is about changing that, with the tools a DBA has at hand.

First, the fundamentals, as far as a DBA needs them: Who does the client actually trust, what does TrustServerCertificate really mean, and why do connections that have worked for years suddenly fail with newer drivers such as Microsoft.Data.SqlClient, ODBC Driver 18 or OLE DB Driver 19? Then the practical part: Which certificate is suitable, including for an availability group? How do you find out which one the instance is currently using, and how do you check that regularly? And how do you replace it? On a standalone instance, that requires a restart; in an availability group, a failover with just a few seconds of interruption. Plus the failure patterns: The certificate is missing, the service account can't read the private key, the certificate has expired. The first two end with the same error code, the third is only noticed by the client. I'll show how to tell them apart anyway.

And because I prefer to verify claims rather than take them at face value: According to Microsoft's documentation, certificates whose key is stored in a Key Storage Provider aren't compatible with SQL Server. Such certificates are created, for example, from certificate templates based on CNG. In the lab, SQL Server 2019, 2022 and 2025 used them without complaint. The widely used check code, however, including Microsoft's own example, silently classifies exactly these certificates as unusable. If you check your certificates with your own PowerShell scripts, you should know this. I've already fixed it in dbatools.

The session is aimed at DBAs who run SQL Server and at the colleagues who provide them with certificates. After this session, you'll know which certificate your instances use, check it regularly, find the cause of a startup failure in the event log and coordinate the next certificate change with the people who roll out the certificates, before it causes an outage. All scripts will be available on GitHub afterwards.

Und plötzlich startet der SQL Server nicht mehr: Zertifikate verstehen, prüfen, tauschen en de

Das Infrastruktur-Team erneuert die Zertifikate auf allen Servern, so wie jedes Jahr, und räumt die alten ab. Dass der SQL Server eines davon benutzt hat, wusste niemand. Beim nächsten Neustart startet der Dienst nicht mehr. Im System-Protokoll steht nur „Cannot find object or property“, und die Anwendung fällt aus.

So war es bei einem Kunden, und so kann es überall passieren, wo Zertifikate zwar vorhanden sind, aber niemand sie betreibt: Wer sie ausrollt, weiß nicht, wer sie benutzt, und wer sie benutzt, merkt den Tausch erst am Ausfall. In diesem Vortrag geht es darum, das zu ändern, und zwar mit den Mitteln, die ein DBA hat.

Zuerst die Grundlagen, soweit ein DBA sie braucht: Wem vertraut der Client eigentlich, was bedeutet TrustServerCertificate wirklich, und warum scheitern mit neueren Treibern wie Microsoft.Data.SqlClient, ODBC Driver 18 oder OLE DB Driver 19 Verbindungen, die jahrelang funktioniert haben? Dann die Praxis: Welches Zertifikat ist geeignet, auch für eine Verfügbarkeitsgruppe? Wie findet man heraus, welches die Instanz gerade benutzt, und wie prüft man das regelmäßig? Und wie tauscht man es aus? Bei einer Einzelinstanz geht das nicht ohne Neustart, in einer Verfügbarkeitsgruppe per Failover mit wenigen Sekunden Unterbrechung. Dazu die Fehlerbilder: Das Zertifikat fehlt, das Dienstkonto darf den Schlüssel nicht lesen, das Zertifikat ist abgelaufen. Die ersten beiden enden mit demselben Fehlercode, das dritte fällt erst dem Client auf. Ich zeige, woran man sie trotzdem auseinanderhält.

Und weil ich Aussagen lieber nachprüfe, als sie zu übernehmen: Laut Microsoft-Dokumentation sind Zertifikate, deren Schlüssel in einem Key Storage Provider liegt, nicht mit SQL Server kompatibel. Solche Zertifikate entstehen zum Beispiel aus Zertifikatvorlagen, die auf CNG setzen. Im Labor haben SQL Server 2019, 2022 und 2025 sie klaglos benutzt. Der verbreitete Prüfcode dagegen, auch Microsofts eigenes Beispiel, stuft genau diese Zertifikate stillschweigend als unbrauchbar ein. Wer seine Zertifikate mit eigenen PowerShell-Skripten prüft, sollte das wissen. In dbatools habe ich das bereits korrigiert.

Der Vortrag richtet sich an DBAs, die SQL Server betreiben, und an die Kolleginnen und Kollegen, die ihnen die Zertifikate bereitstellen. Wer den Vortrag gehört hat, weiß, welches Zertifikat die eigenen Instanzen benutzen, prüft es regelmäßig, findet die Ursache eines Startfehlers im Ereignisprotokoll und spricht den nächsten Tausch mit denen ab, die die Zertifikate ausrollen, bevor er zum Ausfall wird. Alle Skripte gibt es im Anschluss auf GitHub.

All green, still slow? Why the average lies en de

The business side says the application is slow. In the daily monitoring report, CPU usage looks unremarkable and all the lights are green. Both are right: For a few minutes the CPU ran at full load, and in the daily average the spike disappears.

This session is not about a tool. It's about how measurements turn into a statement you can base decisions on. I deliberately start far away from technology: with my coffee consumption. When do I drink how much? And why is Wednesday, of all days, so expensive? Using this example, I show how aggregation hides patterns, how the choice of metric changes the message, and why it's fine to filter out atypical days, as long as you say why.

Then I apply this to measurements from SQL Server. In the lab, a single load spike shows up as 4, 38 or 77 percent CPU, depending on the resolution. A statement that runs for eight milliseconds can still be the problem if it is executed more than a thousand times with every click. And in my view, the night with the unscheduled index rebuild must not end up in the baseline by accident.

Finally, we look at how numbers become a picture that gets through to the business side without bending the data. Along with that come five questions you should ask any chart before you believe it.

The session is aimed at DBAs who present measurements and at everyone who makes decisions based on such data. After this session, you'll spot what a chart isn't telling you and build your own charts so that they speak for themselves. No code, no formulas.

Alles grün, und trotzdem langsam? Warum der Durchschnitt lügt en de

Der Fachbereich sagt, die Anwendung sei langsam. Im Tagesbericht des Monitorings ist die CPU-Last unauffällig, alle Ampeln stehen auf Grün. Beide haben recht: Einige Minuten lang lief die CPU unter Volllast, im Tagesdurchschnitt verschwindet die Lastspitze.

In diesem Vortrag geht es nicht um ein Werkzeug, sondern um die Frage, wie aus Messdaten eine Aussage wird, die Entscheidungen ermöglicht. Ich fange bewusst weit weg von der Technik an: bei meinem Kaffeekonsum. Wann trinke ich wie viel? Und warum ist ausgerechnet der Mittwoch so teuer? An diesem Beispiel zeige ich, wie Aggregation Muster verdeckt, wie die Wahl der Kennzahl die Aussage verändert und warum man untypische Tage herausfiltern darf, wenn man sagt, warum.

Danach übertrage ich das auf Messdaten aus dem SQL Server. Im Labor erscheint eine Lastspitze je nach Auflösung als 4, 38 oder 77 Prozent CPU. Ein Statement mit acht Millisekunden Laufzeit kann trotzdem das Problem sein, wenn es bei jedem Klick mehr als tausendmal ausgeführt wird. Und die Nacht mit dem außerplanmäßigen Index-Rebuild darf meiner Meinung nach nicht versehentlich in die Baseline.

Zum Schluss geht es darum, wie aus Zahlen ein Bild entsteht, das beim Fachbereich ankommt, ohne die Daten zu verbiegen. Dazu gibt es fünf Fragen, die man jedem Diagramm stellen sollte, bevor man ihm glaubt.

Der Vortrag richtet sich an DBAs, die Messdaten präsentieren, und an alle, die auf Basis solcher Daten Entscheidungen treffen. Wer ihn gehört hat, sieht einem Diagramm an, was es verschweigt, und baut die eigenen so, dass sie für sich sprechen. Kein Code, keine Formeln.

PowerShell for DBAs en de

I really like using PowerShell to access various database systems. Although the first thing many people think of when they think of PowerShell is Microsoft SQL Server, the underlying techniques are also available for working with other database systems.
Since PowerShell is based on the .NET Framework, all that is required is a corresponding library to access the database system from both Windows and Linux.
In the talk, I will show the use of loops, error handling and logging, among other things, to simplify the daily tasks of the database administrator.
I will show only a few slides, the main part will consist of demos close to my projects.
Basic knowledge of PowerShell and/or object-oriented programming is an advantage, but not a prerequisite for participation.

The functionalities I show are publicly available at https://github.com/andreasjordan/PowerShell-for-DBAs and I have already presented them at various events.
Depending on the target group, the focus can be on a specific database system.

PowerShell für DBAs en de

Ich nutze PowerShell sehr gerne zum Zugriff auf verschiedene Datenbanksysteme. Auch wenn viele bei PowerShell als erstes an den Microsoft SQL Server denken, stehen die zu Grunde liegenden Verfahren auch für die Arbeit mit anderen Datenbanksystemen zur Verfügung.
Da PowerShell auf dem .NET Framework basiert, wird lediglich eine entsprechende Bibliothek benötigt, um sowohl von Windows als auch von Linux aus auf das Datenbanksystem zuzugreifen.
Im Vortrag werde ich unter anderem den Einsatz von Schleifen, Fehlerbehandlung und Logging zeigen, um die täglichen Arbeiten des Datenbankadministrators zu vereinfachen.
Ich zeige nur wenige Folien, der Hauptteil besteht aus projektnahen Demos.
Grundkenntnisse von PowerShell und/oder objektorientierter Programmierung sind von Vorteil, aber nicht Voraussetzung für die Teilnahme.

Die von mir gezeigten Funktionalitäten sind unter https://github.com/andreasjordan/PowerShell-for-DBAs öffentlich verfügbar und ich habe sie bereits auf verschiedenen Veranstaltungen vorgestellt.
Je nach Zielgruppe kann der Fokus auf ein spezielles Datenbanksystem gelegt werden.

"Deflate!": Detecting Buffer Pool Fragmentation in SQL Server en de

In database systems, the size of the main memory has a significant impact on performance. The goal is to keep as much relevant data as possible in the memory. Due to the structure of the memory, it can happen that part of the memory contains "air" in a figurative sense that could be used much more sensibly.
Fortunately, Microsoft SQL Server provides a good source for tracking down this waste of space that provides a good basis for responding to this problem in a constructive way: The system view sys.dm_os_buffer_descriptors. So in this talk I show how it can be used to collect information about internal fragmentation in a resource-efficient way.
Beforehand, I briefly talk about the different types of fragmentation and their relevance. Finally, I give an outlook on the possibilities of a periodic analysis to develop customized processes for the reorganization of tables and indexes.

The talk is based on my blog article of the same name, which is available here:
https://blog.ordix.de/buffer-pool-fragmentation-sql-server

"Luft ablassen!": Buffer Pool Fragmentierung beim SQL Server erkennen en de

Bei Datenbanksystemen hat die Größe des Hauptspeichers einen signifikanten Einfluss auf die Performance. Das Ziel ist es, möglichst viele relevante Daten im Speicher zu halten. Aufgrund der Struktur des Speichers kann es vorkommen, dass ein Teil des Speichers quasi "Luft" enthält, die wesentlich sinnvoller genutzt werden könnte.
Der Microsoft SQL Server bietet zum Glück eine gute Quelle, um dieser Platzverschwendung auf die Spur zu kommen und entsprechend reagieren zu können: Die Systemsicht sys.dm_os_buffer_descriptors. Daher zeige ich in diesem Vortrag, wie mit ihr ressourcenschonend Informationen über die interne Fragmentierung gesammelt werden können.
Vorab spreche ich kurz über die verschiedenen Arten der Fragmentierung und ihre Relevanz. Zum Abschluss gebe ich einen Ausblick auf die Möglichkeiten einer regelmäßigen Analyse, um maßgeschneiderte Prozesse zur Reorganisation von Tabellen und Indizes zu entwickeln.

Der Vortrag basiert auf meinem gleichnamigen Blogartikel, der hier abrufbar ist: https://blog.ordix.de/buffer-pool-fragmentierung-sql-server

A flight recorder for the SQL Server: Creating the basis for performance analyses en de

Who doesn't know these inquiries: "The application was slow yesterday, what was going on on the SQL Server?"
To answer these questions, we set up a "flight recorder" that regularly collects the data we need. Even if the SQL server provides all the necessary information about system views, it still lacks a practical way of collecting and processing this data. The "data collection" functionality has not been developed further for years and the "query store" focuses primarily on a single database.
We therefore use the functionality of the First Responder Kit, which we believe should be installed on every instance.
In this presentation, I will first introduce the basic approach to data collection and the actual setup. I will then give some examples of how we work with the collected data. I will not present the solution to the specific problems, but the way to make the problems visible in the data.

Ein Flugschreiber für den SQL Server: Die Basis für Performanceanalysen schaffen en de

Wer kennt sie nicht, diese Anfragen: "Die Applikation war gestern langsam, was war da los auf dem SQL Server?"
Um diese Fragen beantworten zu können, richten wir einen "Flugschreiber" ein, der regelmäßig die für uns notwendigen Daten sammelt. Denn auch wenn der SQL Server alle notwendigen Informationen über Systemsichten bereitstellt, so fehlt ihm doch eine praktikable Möglichkeit, diese Daten zu sammeln und aufzubereiten. Die Funktionalität "Datensammlung" wird seit Jahren nicht mehr weiterentwickelt und der "Query Store" hat vor allem eine einzelne Datenbank im Blick.
Daher nutzen wir die Funktionalität des First Responder Kits, das aus unserer Sicht auf jeder Instanz installiert sein sollte.
In diesem Vortrag stelle ich zunächst die grundsätzliche Herangehensweise an eine Datensammlung sowie die konkrete Einrichtung vor. Im Anschluss stelle ich anhand einiger Beispiele vor, wie wir mit den gesammelten Daten arbeiten. Ich präsentiere dabei nicht die Lösung der konkreten Probleme, sondern den Weg, die Probleme in den Daten sichtbar zu machen.

From user to developer - How can I contribute to open source projects? en de

I took this step myself over five years ago: I didn't just use the PowerShell module dbatools, I started to actively help shape it. I carefully analyzed anomalies, filed my first bug report and then developed and provided the solution myself. With this presentation I would like to pass on my experiences and encourage other users of open source software to actively participate in those projects. It is worth it!

Vom Anwender zum Entwickler - Wie kann ich bei Open Source Projekten mitarbeiten? en de

Vor über fünf Jahren bin ich diesen Schritt selbst gegangen: Ich habe das PowerShell Modul dbatools nicht nur genutzt, sondern begonnen, es aktiv mitzugestalten. Ganz vorsichtig habe ich Auffälligkeiten analysiert, einen ersten Fehler eingestellt und dann auch selbst die Lösung dazu entwickelt und bereitgestellt. Mit diesem Vortrag möchte ich meine Erfahrungen weitergeben und auch andere Nutzer von Open Source Software ermutigen, aktiv an diesen Projekten mitzuwirken. Es lohnt sich!

Intelligent data objects in PowerShell - A first step towards object-oriented programming en de

Data objects of the general class PSCustomObject are a good and frequently used option for storing data that belongs together in a data structure or variable. What is less well known is that functionality can also be added to these objects using the Add-Member command. The ScriptProperty type can be used to create dynamic properties, for example a FullName property as a combination of the FirstName and LastName properties. The ScriptMethod type can be used to implement complex methods that write the object's data to a file, for example. In the talk, I will show how this can reduce the code in the main program and focus on the essentials. This approach is particularly suitable for smaller projects or projects under construction, where the use of real custom classes should be avoided initially or in general.

Intelligente Datenobjekte in PowerShell - Ein erster Schritt zur objektorientierten Programmierung en de

Datenobjekte der allgemeinen Klasse PSCustomObject sind eine gute und häufig genutzte Möglichkeit, zusammen gehörende Daten auch zusammen in einer Datenstruktur bzw. Variablen zu speichern. Weniger bekannt ist, dass diesen Objekten mit dem Befehl Add-Member auch Funktionalität hinzugefügt werden kann. So können mit dem Typ ScriptProperty dynamische Eigenschaften erzeugt werden, also beispielsweise eine Eigenschaft VollständigerName als Kombination der Eigenschaften Vorname und Nachname. Mit dem Typ ScriptMethod können komplexe Methoden implementiert werden, die beispielsweise die Daten des Objektes in eine Datei schreiben. Ich werde im Vortrag zeigen, wie dadurch der Code im Hauptprogramm reduziert und auf das Wesentliche fokussiert werden kann. Dieser Ansatz eignet sich vor allem für kleinere oder im Aufbau befindliche Projekte, bei denen zunächst oder generell auf den Einsatz von echten eigenen Klassen verzichtet werden soll.

dbatools from the inside: What actually happens when I run Invoke-DbaQuery? de en

Anyone who uses dbatools runs a command and gets a result. A surprising amount happens in between: a connection object is built or reused, Microsoft's SMO classes are put to work, result sets are turned into PowerShell objects, errors are caught and messages are written. Even as a maintainer of the module, I needed some time to understand why some things are done exactly the way they are. I'm happy to pass that understanding on, because it helps you use the module and, in turn, manage Microsoft SQL Server efficiently.

We follow a single call, Invoke-DbaQuery, all the way through the module. From the SqlInstance parameter through Connect-DbaInstance and connection management to the output. Along the way we look at what the -As parameter controls, when DataRow, DataTable, PSObject or SingleValue is the right choice, and how the module handles NULL. Then the internal logging: where dbatools keeps its records, what Get-DbatoolsLog shows and how to use it to track down errors without debugging the module. And error handling, so that your own script actually notices when a call has failed.

I'll also show where I was surprised myself. For example, three commands that fail on certificates with modern keys. Cases like these show how to take a closer look at what the module does and how a user becomes a contributor.

Finally, an operational topic that affects anyone who updates dbatools regularly: every version is signed with a new certificate. We'll look at what this means for your execution policy and what to watch out for when updating.

The session is for everyone who already uses dbatools and wants to know what they are actually calling. Basic PowerShell knowledge is enough. After this session, you'll choose the output format deliberately, find the cause of an error in the log instead of the debugger, catch errors reliably in your scripts and roll out new versions without surprises.