SQL Server Reference Guide

PowerShell and SQL Server - Objects and Providers

Last updated Jun 29, 2007.

We're working with scripting techniques, and in the first tutorial in this series, I introduced you to PowerShell and explained how you can download and install it. I described three of the main concepts in PowerShell: the verb-noun format of all commands, variables, and redirection or piping. In this tutorial we'll build on those concepts and introduce two more.

As a refresher, recall that all commands in PowerShell are in the verb-noun format, and always singular. For instance, to find out what PowerShell can do, open the PowerShell interface and type this command:

get-help

Also recall that one of the most powerful concepts in PowerShell is the variable. Variables start with a dollar-sing ($) and any value can be assigned to them. To show the value, you simply type the variable and press the ENTER key:

$name = "Buck Woody"
$name

In that example I used quotation marks around the text to show that the value should be interpreted as a string. You can assign numbers to a variable as well, and they don't need to be quoted. Here's an example of assigning two numbers to two variables:

$a = 10
$b = 5

Once assigned, you can do things with the variables. For instance, let's add the two numbers we just assigned to $a and $b:

$a + $b

In fact, you can create an entirely new variable from the values of others, like this:

$c = $a + $b 
$c

I'm sure you've done simple programming like this before. I show it here because I want to introduce a concept you may not be familiar with: objects. Actually, you're very familiar with objects because you use them every day. Objects are just things. In real-life they are physical, but in PowerShell they are things like numbers or text strings. While you may be familiar with working with a variable and setting it to a string or a number, in PowerShell you're able to set variables to objects as well.

This is very powerful. Since an object is just a thing, you can begin to think about all the objects on your system that you need to work with. As I develop this tutorial series, I'll use several objects with PowerShell, such as the registry, the Windows Event logs, and SQL Server itself.

Once you set a variable to an object (called instantiating) you'll have access to two things: methods and properties. Let me explain that a little further.

Let's consider a pet cat. The cat is an object, but in fact it's only one of several cats. When a mother cat gives birth, we could say that a new cat-object was instantiated. (True, we'd get some strange looks when we said it, but we could.) Now that we have a new cat-object, we notice that it can do things. It can purr, eat, sleep and play. These are the cat-object's methods. So if we created a cat-object in code, we would have access to those methods. Let's look at some concept code (this doesn't really work, of course; I haven't finished coding Mother Cat version 1):

$cat-object = get-cat –newkitten
$cat-object.eat
$cat-object.play
$cat-object.sleep

We've taken a variable, set it to the get-cat command and told that command (with a switch, the — part) to make a new kitten. If we in fact had a get-cat command, and it could create new kittens, then this code would have resulted in a new kitten popping into view, eating, playing and then sleeping.

Notice that I told the new variable (which is now an object) to do things by separating the variable from the method with a period. You'll see that again in a moment.

Objects don't just have methods, or if you want to think about it that way, commands. They also have properties. For instance, a kitten has a color, a size, and so on. Continuing with our Cat-Object we instantiated, we could ask the object what these things are this way:

$cat-object.color
black
$cat-object.size
small

I think you have the idea. Once again I've used a period to separate the variable/object from the property. This works the same way as the method.

Let's cover one more concept and then put all this to practical use. In this example, I've been using an imaginary program called get-cat. This command is also called a Provider. A provider is also sometimes called an Application Programming Interface (API), an Interface, and many other names. The point is that a provider gives you a way to get at objects and their methods and properties. Some are built-in to PowerShell, and others are available by including them in the PowerShell environment. I'll cover that in a moment.

Alright, let's put these new concepts to practical use. A moment ago I mentioned that one of the objects we need to access is the Windows Event log. When we develop our maintenance script we'll want to record an action in the Event log and we'll also want to read the Event log to see if there are any errors on the server we need to deal with. So this object will have a couple of uses.

To read the Event logs, we'll need to access a provider. We'll use several providers throughout this series, and one of the most powerful is Windows Management Instrumentation (WMI). With WMI, you have access to just about everything on the computer. WMI also comes with its own query language, which we'll run into as we go. I won't stop and explain everything there is to know about WMI, but as an administrator it's worth your time to investigate the links I'll post at the bottom of this tutorial.

We could actually use a few different providers to get to the Windows Event logs. That's something you'll find as you scour the web looking for script samples. It seems that each developer or administrator that posts something for PowerShell on the web uses different providers, which can get very confusing. Don't let that bother you. In fact, variety is a good thing. What I find easy to do you might think is very confusing. The important thing is to find a provider that does the best job, and learn enough of it to get the job done.

To access WMI, PowerShell includes a command called get-wmiobject. Using what we already know, we can ask for detailed help about this provider to find out what it can do:

get-help get-wmiobject –detailed

Within the help you can see that Get-WmiObject can show you many things about your computer, such as the currently running processes:

get-wmiobject win32_process

OK, that's a lot of processes, so let's use what we learned in the last tutorial about redirection (piping) to slow the output down:

get-wmiobject win32_process | more

Within the WMI provider are various classes. These are basically the same thing as an object. Classes might have methods, properties or both, which we can use to work with things like the Windows Event log. The class we need for that is called Win32_NTLogEvent. Within that object are namespaces, which are categories of things that this object can talk to. And even within those are various properties that you can ask about.

Let's get started on a simple script that will show some of the information from the event log. We don't need to see all of the information from the Windows Event log, such as the computer name (it's the one we're on) or the record number. We'll use this as a proof of concept, and you can explore the other properties on your own. I'll post a reference at the end of this tutorial that has all of the WMI objects and their properties.

I'll post the script here, and I'll use the # sign to mark comments in it. I'll use those comments to show you what I'm doing along the way.

# ShowEventLog.PS1
# This script uses WMI to show a few columns from the Windows Event log
# for the current computer. 

# First, set the name of the computer where the logs are. 
# The period sets the current computer, you can substitute any system name 
# where you are an administrator.
$ComputerName = "."
# Now we'll make a new variable, which is actually a collection. 
# A collection is a group of objects. We'll use the get-wmi 
# object to call the Event log class, and we'll start at 
# the "root", or top of the Event log. This command requires 
# the computer name, which we set up in the first line.
$logEvents = get-wmiobject -class "Win32_NTLogEvent" -namespace "root\CIMV2" ´
-computername $ComputerName
# Next we'll use the foreach command that makes a loop 
# through each item. To do that we'll set up a new 
# variable called logEvent that loops through the logEvents 
# collection. Notice that the loop requires the curly-braces 
# at the top and bottom of the collection.
foreach ($logEvent in $logEvents) {
# We can output the result of the query to the screen 
# using the write-host command, some text, and then 
# the property that we care about of each record in the event log.
   write-host "Type: " $logEvent.Type
   write-host "User: " $logEvent.User
   write-host "Event Code: " $logEvent.EventCode
   write-host "Insertion Strings: " $logEvent.InsertionStrings
   write-host "Logfile: " $logEvent.Logfile
   write-host "Message: " $logEvent.Message
   write-host "Source Name: " $logEvent.SourceName
   write-host "Time Generated: " $logEvent.TimeGenerated
   write-host
}

And there you have it. So far you've learned how to install PowerShell, and how to set up your environment to run scripts. You've learned about the verb-noun command structure, about variables, and objects and providers. Combine all that with redirection and we're all set to get our maintenance example going.

InformIT Articles and Sample Chapters

Tyson Kopczynski has a free book excerpt you can read here to learn more about PowerShell.

Online Resources

The WMI reference I mentioned in the tutorial is here.

Want to see all of the strings in the Event log? There's an example here.