Amazon Contextual Product Ads

Thursday, June 23, 2011

A couple of useful PowerShell WMI scripts using dot sourced functions

I work a lot with functions stored in a dot sourced ps1 file because it makes scripting so much easier and more efficient. For instance, if I have several scripts that need to perform the same test, such as a Ping test to determine whether a server is responding to ICMP requests, I simply call the function from the dot sourced file without having to rewrite it over and over again.
So for the purposes of today's example, I have stored all of my functions in a file at the following location:
\\Server\scripts\functions.ps1

The Pinghost function looks as follows:
Function Pinghost  ([string] $Hostname )
{
    $status=get-wmiobject win32_pingstatus -Filter "Address='$Hostname'" | Select-Object statuscode
    if($status.statuscode -eq 0)
    {$result = "$Hostname is REACHABLE"}
    else
    {$result = "$Hostname is NOT reachable"}
        $result
}




So my code in the script would look as follows:
. \\Server\Scripts\Functions.ps1

$server = "MyServer01.domain.com"
Pinghost $server

This would return one of the following results:


MyServer01.domain.com is REACHABLE

or

MyServer01.domain.com is NOT reachable


Let's say you want to see whether a service is installed on a server and determine it's status. To do this, I use a function called Get-RemoteService. The function is in the same functions.ps1 file so the file would look as follows:


Function Get-RemoteService
{
 param($serverName,$serviceName)
 $svc = get-wmiobject win32_service -computer $serverName -filter "name='$serviceName'"
 If ($svc -eq $Null)
 {
  $svc = "No such Service on this server."
 }
 $svc

}

Function Pinghost  ([string] $Hostname )
{
    $status=get-wmiobject win32_pingstatus -Filter "Address='$Hostname'" | Select-Object statuscode
    if($status.statuscode -eq 0)
    {$result = "$Hostname is REACHABLE"}
    else
    {$result = "$Hostname is NOT reachable"}
        $result
}


As you can see, you can stack the functions in any order you want in the functions.ps1 file. When you dot source it, all functions in this file become available to the script that is calling them. This script would look something like this:


. \\Server\Scripts\Functions.ps1

$server = "MyServer01.domain.com"
$service = "Wins"
Get-RemoteService $server $Wins


This returns one of the following results:


ExitCode : 0
Name : WINS
ProcessId : 2100
StartMode : Auto
State : Running
Status : OK


or

No such Service on this server.



These are just a few of the wmi functions I use day to day. The point here is not so much in the functions themselves but in the practice of dot sourcing those functions. Dot sourcing helps me to centralize all of my functions so I don't have to reinvent the wheel each time I write a new script. The common needs of my scripts can reutilize the functions with far less code and with less potential for typoes/user error. Once my functions test out and prove error-free, I can safely reuse them over and over again.



If you do a lot of administrative scripting, I can not recommend dot sourcing your functions enough.


-Edit-
-As a side note, I was reminded that there are other ways to do these scripts in PowerShell v2.0. I should specify that most if not all of these scripts will be PowerShell v1.0 as that is what my experience is in and it will allow for backward compatibility. If you know of a way to do these scripts in v2.0, your comments would be very helpful to folks looking specifically for that version. Until I actually start working with 2.0, it will be a safe assumption that these scripts were written for PowerShell v1.0.

Thanks Tyler for the Heads Up.

No comments:

Post a Comment