Why This SQL Server DBA is Learning Powershell

Ron describes how he decided to study Powershell as a single
scripting system to automate all the common repetitive server tasks. He
concludes that time spent learning PowerShell is time well spent, and that
it can help a great deal in understanding the .NET Framework

I started studying PowerShell because I was looking for a quicker, more efficient way to gather information regarding my SQL Servers, and to manage my server workload better. I thought I was just going to learn yet another new scripting language that would help me do this. In fact, alongside providing a powerful means to automate many of my common, repetitive server tasks and heath checks, I’ve found that learning PowerShell has also proved a useful springboard to improving my skills with other, related technologies. For example, while learning PowerShell, I’ve found that I’ve:

  • Improved my knowledge of .NET, so that I can talk more intelligently to the Application Developers I support.
  • Learned how to use Server Management Objects (SMO) to automate my database-related tasks.
  • Learned about Windows Management Instrumentation (WMI), allowing me to query one or more servers for a piece of information.
  • Become more comfortable with object-oriented programming.

In this article, I will describe several examples of using PowerShell that I would hope a DBA would find useful. My scripts will demonstrate how to run SQL queries, WMI queries or SMO code on one or more machines, and help you to better manage multiple database servers. All of the scripts have been tested on SQL Server 2005.

This article is not intended to be a PowerShell tutorial. I assume that you are familiar with the basic PowerShell terminology, how to get help with the cmdlets, how the command line works, how to run a script, what a pipeline is, what aliases are, and so on. If not, plenty of help can be found in various online articles, newsgroups and blogs (a reference section, at the end of the article, lists some of these sources). Some of the scripts I include with this article were derived from examples I encountered during my readings.

Managing Multiple Servers using PowerShell

At the heart of multiple server management with PowerShell is a simple list of the servers on which you wish to run your routine tasks and health checks.

In my examples, I use a AllServers.txt file that simply contains a list of my servers, in the following format:

As I will demonstrate in the examples, I use this list to run a task against each listed server, using a foreach loop. This simple server list forms the cornerstone for completing repetitive tasks.

I work primarily in a Microsoft environment and I’m finding it quicker to perform repetitive tasks with PowerShell than I previously did with Python. For instance, whereas Python needs multiple lines to open, read, and close a file, the get-content cmdlet in PowerShell reads a file with one line of code:

If even that feels like too much typing, you can invoke the get-content cmdlet via its alias:

Figure1: Invoking the get-content cmdlet

The defined best practice is to use the alias at the command line and the complete cmdlet in scripts, for readability.  You can list all the PowerShell aliases with the get-alias cmdlet:

PowerShell is both an interactive command line and scripting environment.

I start solving a problem by executing commands at the command line.  When I have established the correct sequence of commands, I save them to a script file with the .ps1 extension and execute it as needed.

Automating Repetitive Tasks

PowerShell makes it easier for me to automate common, repetitive tasks across all my servers, and to deal quickly and efficiently with the seemingly-endless stream of ad-hoc requests for some bit of information about each of them.

The following sections describe just some of the PowerShell scripts I’ve created to automate these repetitive tasks. The examples progress from those I found the easiest to convert to PowerShell to those that took more effort to solve.

SQL Tasks

The easiest tasks to convert from Python to PowerShell were those that executed a SQL query against multiple machines. In these examples, the basic procedure followed in each script is as follows:

  1. Read a list of database servers and for each server
  2. Create a data table to store the results
  3. Establish a connection to the server
  4. Run the query and format its output.

Checking Versions of SQL Server on Multiple Servers

I run the following script to determine if my servers are at the approved patch level for our company:

The script follows the standard template I use for executing all of my SQL scripts against multiple servers. It uses a foreach loop to read through a list of servers, connect to the server and execute a query that returns the names of the user databases on each server. For this article, I have formatted the examples with comments in Green, PowerShell code in Blue and SQL in Red.

Reconciling Actual Database Inventory with Internal Database Inventory

On a monthly basis, I must reconcile my real database inventory with an internally-developed database inventory system that is used as a resource by other applications.

The query returns the database names for all non-Microsoft supplied databases, sorted by server, and I then compare this to a report generated by the database inventory system.

Remove BUILTIN\Administrators Group from the Sysadmin Role

This script, instead of a foreach loop, defines a function that allows me to remove the BUILTIN\Admin group from the sysadmin role on any server, simply by typing:

The function accepts one parameter, establishes the connection to the server and executes the sp_dropsrvrolemember system stored procedure.

This script saves me time since I don’t have to jump into Management Studio to complete the task. In the SMO section you’ll find two other functions that I created to list the members of the sysadmin group and a server’s local administrators.

Windows Management Instrumentation (WMI) Tasks

My next task was to get a quick view of free space on all my servers. In order to do this, I had to dip my toes into the world of WMI, which provides an object model that exposes data about the services or applications running on your machines.

The first obstacle here is figuring out what WMI has to offer. As soon as you start looking you’ll realize that the object model for WMI (and SMO) is vast and you’ll need to invest a little time in browsing through it and working out what does what.

MSDN is the best place to go for documentation on the WMI classes.

Browsing the Win32 WMI Classes

The WMI classes that will be the most useful to a DBA are the Win32 classes  and you can use the following one-liner to get the list of all the available Win32 classes:

The classes I found interesting initially were:

  • Win32_LogicalDisk â gives you stats on your disk drives
  • Win32_QuickFixEngineering â enumerates all the patches that have been installed on a computer.

The following examples will highlight the use of these and other classes of interest.

Checking Disk Space

The simplest way to check disk space is with the Win32_LogicalDisk class.  DriveType=3 is all local disks.  Win32_LogicalDisk will not display mountpoint information.


After a little digging around I found that, rather than try to calculate free space percentages from the output of the Win32_LogicalDisk class, it was easier to use the Win32_PerfFormattedData_PerfDisk_LogicalDisk class and its property PercentFreeSpace. In this example, I’m checking for drives with less than 20% free space.  The other reason  to use this class for checking disk space is that it will display mountpoint information.


Checking what Services are Running on a Server

A quick way to find out which services are running on a remote server is to use the get-wmiobject, specifying the class, Win32_Service, and then the properties you want to list, and finally the computer that you wish to query. In this example, I’m just retrieving the name of the service:

Is IIS Running on your SQL Server? Oh, No!

If you want to see if a specific service is running on a remote machine use the filter parameter, -f, and specify the name of the service.

The output will look as shown in Figure 2:

Figure 2: IIS is running on my SQL Server. Panic!

SQL Server Management Objects (SMO) Tasks

SQL Server Management objects is a collection of objects that allows you to automate any task associated with managing Microsoft SQL Server.

Again, the biggest obstacle for the DBA who is unfamiliar with object-oriented programming is working through the rather intimidating object model. Again, as with WMI, you need to know how to examine an object to determine its available properties and methods.

In the SMO examples, you will again see the use of a foreach loop being used to execute SMO code against multiple servers.  All of the examples begin by setting a reference to the SMO assembly. Once, you have established this reference, the script can then instantiate new objects derived from the classes in the assembly.

Browsing the SMO Classes

The SMO classes are documented in Books Online but it’s also helpful if you learn to list an object’s properties and methods.  To browse the SMO classes, you need to set a reference to, and then use, the get-member (gm) cmdlet to display that object’s properties and methods. 

To examine different objects change the second and third lines of the above script accordingly.

List the members of the sysadmin role on a server

Depending on your previous experience, figuring out how the SMO object model works might prove tricky. I understood the basics of object-oriented programming but it didn’t really sink in until I was working on a script to list the sysadmin role members on my servers. Initially, I tried to use the code shown in Figure 3 and received the displayed error message:

Figure 3: Incorrect object reference

I had a minor epiphany at this point. The concept of object-oriented programming and “Everything is an object” in PowerShell finally made sense to me. In the example in Figure 3, I had successfully created an instance of the Server object and, from there, wanted to work my way down to the ServerRole object for the sysadmin role. So, I set the variable, $svrole, to the string value ‘sysadmin’.  

I then tried to invoke a method on that string object, thinking that I was, in effect, invoking a method on the ServerRole object. In this case, the $svrole variable only contained a string object not a reference to a ServerRole object. Thus, the error was thrown.

The following code sets the object reference correctly:

Then, the command, $svrole.EnumServerRoleMembers(), will enumerate the members of the sysadmin server role on the selected server, as shown in Figure 4:

Figure 4: Enumerating the members of the sysadmin server role

The following script wraps the PowerShell code needed to list the sysadmins on a server into a function.

List the Local Administrators on a server

I use the following script (and the previous one) to keep to a minimum the number of people who have admin rights on a server and in SQL Server.

This example was inspired by Microsoft MVP Ying Li’s post on his blog demonstrating how to list local admins on a server (see the Reference section at the end of this article for the link). The function is supplied a server name. It then connects to the specified server and lists the members of the local Administrators group.

Find a Login or AD group on Multiple Servers

One of my first SMO examples was inspired by my supervisor, who asked me to find out which database servers the data modeling group had access to.  She was hoping it was only the development servers.

The following example ends up being five to seven lines of code, depending how you format it, but it will find a login/group on however many servers you have on your list.

The trap statement handles an error if one is encountered when the connection is made to a server. In this example, if there is an error connecting to the server, it will return the name of the server and the error message.  Occasionally, I will see “Oops! Failed to connect to server SERVERNAME.” in the output.

Check for failed SQL Agent jobs on multiple servers

Every morning I run the following script to check for any failed SQL Agent jobs on my servers:

Miscellaneous Tasks

Pure PowerShell examples follow from here on out to answer a few more questions a DBA might have.

Checking for installed Hot Fixes

Finding a Port Number

I’m often asked by a developer for the port number of a named instance. By combining in a short pipeline two cmdlets, get-content and select-string, you have a one-liner that find a port number in the errorlog text. This is much quicker than searching the errorlog manually, or running a bit of SQL code to return this result.

I did try to use select-string by itself to search the errorlog but, for some reason, select-string can’t read the active errorlog unless combined with get-content. In the following example, I search for the word “listening” in a SQL Server 2005 errorlog:

The result is shown in Figure 5:

Figure 5: Searching a SQL 2005 errorlog

Keep in mind that if you have cycled the error log on your server the line you need to find might not be in the current error log and you will need to adjust the command below to search through your archived errorlogs by appending .1, .2, .3, etc. to ERRORLOG.

If you are searching an errorlog on a named instance of SQL Server 2000, you will need to escape the $ in the path with a backtick, as follows:

Generate a Random Password

If you need to generate a random password for a SQL login, use the following .NET class:

Checking that Database Backups are Current on Multiple Servers

In my environment, I have two database configurations and the backups don’t always land in a standard location. As such, I use a ‘brute force’ solution for checking my backups.

I have developed a script that checks that the backups are current for each of the servers that I support. The basic template is as follows:

In the script, I repeat the above statement block for each server I need to check. Example output is shown in Figure 6:

Figure 6: Checking that Backups are up-to-date

If the server has multiple drives to be checked, I repeat the get-childitem cmdlet for the additional drives.

Here’s a slice of my full ChkBkups.ps1 script.

I run this script each morning. We do have a set of automated routines that run nightly that handle the standard DBA tasks like backups, consistency checks, index maintenance, etc. Each server’s maintenance process sends e-mails reporting on their status. This script saves me from having to read multiple e-mails.


I think using PowerShell will make me a better DBA because I have the means to automate mundane tasks, gather information quicker regarding my servers and manage my workload better. I’ve also found that using it has stretched my knowledge into areas I might not normally go, which can only be a good thing.

It is really striking to me how a few lines of PowerShell can do so much. 

In my opinion, time spent learning PowerShell is time well spent.


I started with Bruce Payette’s book and the “Getting Started Guide”.  I found a lot of good examples via Google by using simple search terms like: powershell sql; powershell smo; powershell wmi; powershell adsi; powershell blogs.

Bruce Payette’s book laid the foundation but all the people who have contributed to the newsgroup, blogs, and articles filled in the gaps. The section below is a just a subset of the materials I’ve used to learn PowerShell.





  • Books.
    • “Windows PowerShell In Action” by Bruce Payette
    • Windows PowerShell: TFM” by Don Jones and Jeffery Hicks
  • Newsgroups
    • microsoft.public.windows.powershell