How to Create Reusable PowerShell Functions for Microsoft SQL Server Database Administration

In my last blog article on “Getting Started with Administering and Managing Microsoft SQL Server with PowerShell“, I left off by introducing you to how to query information about your SQL Server using PowerShell with SQL Server Management Objects (SMO).

In this blog article, I’ll pick up where I left off and write a reusable PowerShell function to return information about SQL Server files and file groups while making the use of SMO transparent to the user of the function.

I’m going to start off by importing the SQL Server 2014 PowerShell module that’s installed on the Windows 8.1 workstation that’s being used in this demonstration. For specifics about this, see the previous blog article that was referenced.

Create a new SMO Object in PowerShell and store it in a variable:

It looks like the information can be retrieved like this:


The problem with retrieving it that way is it doesn’t really scale since when more than one item is returned, you end up with a collection of items. So what you need to do is to iterate through each item that could be a collections of items (databases, filegroups, and files), create a custom object, and then return that object:


That looks better, but it’s very static. It would need to be modified manually each time for a different database server name or SQL instance and do you really want a junior level DBA or System Administrator that you might delegate this task to, to be manually modifying the PowerShell code? I didn’t think so. That’s why this function needs to be turned into a parameterized function so the values such as ComputerName (ServerName) can be specified dynamically on the fly with no modification to the code whatsoever:


That’s a little better. The function is named Get-MrDbFileInfo and it’s been saved in a ps1 file named Get-MrDbFileInfo.ps1. I used my initials (Mr for Mike Robbins) to help prevent name collisions with other functions that someone else may have created that could have the same name (Get-DbFileInfo).

In the previous example, the function was dot sourced and then run against a database server running SQL Server 2014 named SQL01, it was then run against another database server running SQL Server 2008 R2 named SQL02.

The problem now is what if you wanted to run it against a named instance instead of the default one and maybe you’re only looking for information about a specific database?


With all this additional functionality that’s being added to this function, it’s becoming a versatile, reusable tool to query file and filegroup related information from your SQL servers. No need for the user of it to make any manual changes if they want to query information for a specific database server, named instance of SQL, specific database, multiple databases, or to use wildcards in the database name to return information for multiple databases with similar names without having to manually specify each one.

More polish is still needed though. Being able to accept pipeline input on the database name parameter would be nice so the output of one command that returns database names can be piped into this function. Error handling and comment based help are needed as well.


As you can see, the error handling is working as I forgot which database server my MrSharePoint SQL instance was installed on. I was also able to pipe the database name in and not only pipe it in, but pipe it in with a wildcard.

The problem now is that too may properties have been added and I only want certain properties returned by default in the table and list views:


I also don’t want to have to dot source the function every time I want to use it. I’ll resolve these issues in my next blog article by creating a module, module manifest, and custom formatting via a .ps1xml file.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: