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.