About PowerShell Script Club

1. You Always Talk About Script club
2. You Always Talk About Script Club
3. If Someone asks for Help, And You Can Help, You Help
4. Two People Help One Person at One Time
5. One Module Per Person Per Night
6. All Scripts, All PowerShell
7. Scripts will be as short as they can be
8. If This is your First time at Script Club, You Have to Script

The first Greater Milwaukee PowerShell Script Club is being formed.

The first meeting will be on Tuesday, January 19th at 6:00 PM at the Greenfield Law Enforcement Center (in the Municipal Court Room), 5300 W Layton Ave, Greenfield, WI  53220.  Register here.

All IT Professionals (sysadmins, network admins, developers, help desk, and all others) with any level of experience are welcome.  If you DO NOT KNOW POWERSHELL, but you WANT TO – This is the place.

Pizza and soda will be provided, but please bring a laptop with PowerShell installed (version 1 or 2 is fine).

What is a Script Club?

Andy Schneider describes a script club:

Script Clubs are like a hands on lab with no set topic or teacher. You bring an idea for a script, and ask your fellow PowerShell users for help getting the script written.

This is not a lecture or presentation based group (though we may have presentations from time to time).  Script Club is focused on creating working scripts that will help you get your work done or just enjoy yourself.

Register here.

PowerShell has two kinds of errors – terminating errors and non-terminating errors.

Terminating errors are the errors that can stop command execution cold.  Non-terminating errors provided an additional challenge, as you need to be notified of failed operations and continue with pipeline operations.  To deal with this issue and to provide additional output options, PowerShell employs the concept of streams.  There are three additional streams (other than the primary pipeline stream) available in PowerShell – Verbose, Warning, and Error (and .  We’ll be concerning ourselves with the output from the Error stream.

There are some automatic variables in the shell that deal with errors as well.  $ErrorActionPreference is a variable that describes how PowerShell will treat non-terminating errors.  $ErrorActionPreference has four options: “Continue” (the default), “SilentlyContinue”, “Inquire”, and “Stop”.  $error is an array of all the errors that have occurred in the current session up to the number specified in $MaximumErrorCount.  $? is a boolean value that is $true if the previous operation succeeded and $false if it did not.

PowerShell does have some built in flexibility to turn non-terminating errors into terminating errors.  Based on our setting of $ErrorActionPreference, PowerShell will treat a non-terminating error differently.  If $ErrorActionPreference is set to ‘”Stop”, PowerShell will treat the errors from that scope and all sub scopes (unless explicitly overridden) as terminating errors.  If “Inquire” is chosen as the $ErrorActionPreference, then PowerShell will prompt the user at the console upon each error to ask whether it should continue (treat as non-terminating) or halt (treat as terminating), as well as providing an option to drop into a nested prompt.

$ErrorActionPreference is a global preference that can be set, but the PowerShell runtime also allows more granular control by providing common parameters for -ErrorAction and -ErrorVariable (shorthand -EA and –EV) which allow you to determine per cmdlet (and in V2 per advanced function) how errors should be handled.  The –ErrorAction parameter takes the same options as $ErrorActionPreference.

So what happens when you encounter an error?

If you hit a terminating error, your script, function, or command will stop.  The error will be logged to the $error variable and written to the error stream.  The $? will be set to false.  You can use the trap construct (or the try/catch/finally construct in V2) to deal with terminating errors and we’ll cover that further in the fourth post in this series.

If you hit a non-terminating error, the result will depend on the $ErrorActionPreference in the scope or the –ErrorAction parameter.  If the $ErrorActionPreference or –ErrorAction parameter is set to ‘Continue’, the error will be written to the error stream, added to the $error array, and the $? will be set to $false.  ‘SilentlyContinue’ will not write an error to the Error stream, but $error and $? are updated.  Finally, ‘Inquire’ provides you an option at each error as to whether to treat it as terminating or non-terminating.  If treated as a non-terminating error, the error will be treated like the $ErrorActionPreference or –ErrorAction parameter is ‘Continue’.

Now, I’ve mentioned that some terminating and non-terminating errors both write to the Error stream, so where does that actually get reported back to the user?  If an error has been written to the error stream, it will be written to the output stream (which may surface differently based on the PowerShell host) separately from the pipeline output unless it is redirected.  This means that the exception objects, which are how the errors are represented, are not saved to a variable if you are assigning the pipeline output to a variable.

For example:

$results = Get-WMIObject Win32_Bios –ComputerName localhost, ComputerThatDoesNotExist
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At line:1 char:22
+ $results = Get-WmiObject  <<<< Win32_Bios -ComputerName localhost, ComputerThatDoesNotExist

creates this output to the screen, but $results will only hold the results of the successful WMI query.  This is where the –ErrorVariable comes in.  You can specify a variable to hold the exceptions generated by a particular cmdlet (or in V2 advanced function).  Specifying a variable does not remove an item from being written to the error stream and displayed as output.

In a console session, you can redirect the error stream with the redirection operators ( 2> or 2>>) or you can merge the error stream with the output stream (2>&1) and write the output to a file, the pipeline, or assign it to a variable.

Up next:

• Error Objects
• Tracing Errors
• Trapping Errors
• Reporting Errors

Other great PowerShell Error Handling posts:

• http://huddledmasses.org/trap-exception-in-powershell/
• http://blogs.msdn.com/powershell/archive/2006/11/03/erroraction-and-errorvariable.aspx
• http://tfl09.blogspot.com/2009/01/error-handling-with-powershell.html
• http://weblogs.asp.net/adweigert/archive/2007/10/10/powershell-try-catch-finally-comes-to-life.aspx
• http://powershell.com/cs/blogs/ebook/archive/2009/03/30/chapter-11-finding-and-avoiding-errors.aspx

I’ll be covering the basics of PowerShell, as well as an introduction to the VI Toolkit (for Windows)/PowerCLI.

Scott will be talking about  the Virtualization EcoShell Initiative (VESI).

If you are in Wisconsin, the meeting details can be found here.

If you are not able to make the meeting, VMWare will be providing a live stream of our presentations via WebEx, as well as providing recordings after the fact.  

My presentation starts at 9 AM Central time and Scott follows me at about 9:50.

I just checked my WSUS Server and there it is!!! Deployment is now a snap.

More details in his blog post.. or in the MS Knowledge Base.

The problem that you run into in V1 of PoweShell is that it is easy to make your functions work with the pipeline

Function Check-Service {
  Param([string]$service=”spooler” )
  PROCESS
  {
    $wmi=get-wmiobject win32_service -filter “name=’$service’” -computername $_ 
    if ($wmi.state -eq “running”)  {
      write $True
    }
    else {
      write $False
    }
  }
}
 
Get-Content servers.txt | Check-Service

OR work well with parameters being passed in.

Function Check-Service {
  Param([string[]]$server=$env:computername, [string]$service=”spooler” ) 
    $wmi=get-wmiobject win32_service -filter “name=’$service’” -computername $server 
    if ($wmi.state -eq “running”)  {
      write $True
    }
    else {
      write $False
    }
} 
  
Check-Service –Server Server01, Server02, Server03

Advanced functions in V2 of PowerShell can alleviate this problem (a topic for a whole new post), but a workaround I’ve found for V1 is to use the Begin block to take certain command line parameters and pass them back into the function via the pipeline.

Function Check-Service {
Param([string[]]$server=$null,[string]$service=”spooler” )
  BEGIN
  {
    if ($server -ne $null)
    {
      $server | Check-Service –Service $service
    }
  }
  PROCESS
  {
    if ($_ -ne $null)
    {
      $wmi=get-wmiobject win32_service -filter “name=’$service’” -computername $_
      if ($wmi.state -eq “running”) {
        write $True
      }
      else {  write $False  }
    }
  }
}

This enables both of the above scenarios:

Get-Content servers.txt | Check-Service

Check-Service –Server Server01, Server02, Server03

PSMDTAG:FAQ param

PSMDTAG:FAQ pipeline

Updated: (Missed a little recursion bug.. thanks Aleksandar!)

Jeffrey recommended to cast your parameter as the type of object that you are expecting, as way to catch errors.  I wholeheartedly agree.  That can cause trouble though, if you want to allow consumers of your script to pass in one or more values for that parameter.  In the spirit of the article’s title, I thought I would share a method I’ve come across to handle that situation.

Jeffrey gave is the below function.

Function Check-Service {
  Param([string]$computername=$env:computername,
    [string]$service=”spooler” )
  $wmi=get-wmiobject win32_service -filter “name=’$service’” -computername $computername
  if ($wmi.state -eq “running”)  {
    write $True
  }
  else {
    write $False
  }
}

Now, you can easily see where you might want to check for a service on multiple computers, but as this function stands, we would have to call it one time for each computer we want to check.

We can modify this script to take one or more computer names simply by changing the cast for the $computername variable from [string] to [string[]].  That changes makes our variable hold an array of strings, rather than just one. 

We don’t have to change the default value, as PowerShell handles the details of converting that value to an array. 

Since the –ComputerName parameter for Get-WMIObject can take an array of computer names, we don’t have to change much else in the function. 

I do add a foreach loop for the reporting end of the script, so we can see which machines have the service running.

And I end up with this (my changes in bold):

Function Check-Service

{

  Param( [string[]]$computername=$env:computername, [string]$service=”spooler” )

  $wmi=get-wmiobject win32_service -filter “name=’$service’” -computername $computername

  foreach ($one in $wmi)

  {

    if ($one.state -eq “running”)

    {

      write $one.SystemName, $true

    }

    else

    {

      write $one.SystemName, $False

    }

  }

}

I almost forgot - 

PSMDTAG:FAQ param

To send an email from PowerShell using the .NET Framework, you can use the System.Net.Mail.SMTPClient class.

First, you need to create your MailMessage

PS C:\scripts\PowerShell> $message = New-Object System.Net.Mail.MailMessage –ArgumentList steve@usepowershell.com, nobody@adomain.com, ‘This is a test’, ‘I’m going to send an email via PowerShell’

If you need to add an attachment, you can add one with the System.Net.Mail.Attachment class.

To create the attachment, we’ll create an use an overload of the Attachment class that allows us to specify a filename and a MIME type (the MIME types are available in several enumerations:  System.Net.Mime.MediaTypeNames.Application, System.Net.Mime.MediaTypeNames.Image, and System.Net.Mime.MediaTypeNames.Text – I’ve had a bit of trouble accessing those enumerations via PowerShell, but you can specify the name of the enumeration value in a string).

PS C:\scripts\PowerShell> $attachment = New-Object System.Net.Mail.Attachment –ArgumentList ‘c:\docs\test.xls’, ‘Application/Octet’

PS C:\scripts\PowerShell> $message.Attachments.Add($attachment)

After we have our email and optional attachment, we’ll create the SMTP client and have it configured to use the SMTP server of our choice.

The constructor of the SMTPClient class that we will use is

SmtpClient(
        String host,
)

PS C:\scripts\PowerShell> $smtp = New-Object System.Net.Mail.SMTPClient –ArgumentList 10.10.10.15

All that is left is sending our email..

PS C:\scripts\PowerShell> $smtp.Send($message)

Have fun!

NOTE:

There is a shortcut to creating the MailMessage object like we did.. there is an overload of Send where you can pass in four strings (from, to, subject, and message).  The SMTPClient handles the creation of the MailMessage in the background.

A faster method would be

PS C:\scripts\PowerShell> $smtp = New-Object System.Net.Mail.SMTPClient –ArgumentList 10.10.10.15

PS C:\scripts\PowerShell> $smtp.Send(‘steve@usepowershell.com’, ‘nobody@adomain.com’, ‘This is a test’, ‘I’m going to send an email via PowerShell’)

A constructor is a method whose job is to create the object that you want to work with.  When I created the Ping object

PS C:\scripts\PowerShell> $ping = New-Object System.Net.NetworkInformation.Ping

the New-Object cmdlet calls the constructor for Ping.

Like other methods, constructors can require parameters and can have multiple overloads. 

Let’s look at System.Net.Mail.MailMessage, which is a object that represents an email message.

The MailMessage constructor contains several overloads.  The first method listed is MailMessage(), which is the default constructor.  This method does not require any arguments and returns an empty MailMessage object.  In PowerShell, we would call this method via New-Object, just like with Ping class.

MailMessage()

PS C:\scripts\PowerShell> $message = New-Object System.Net.Mail.MailMessage

The first overload requires two MailAddress objects, the first of which is the “from” address and the second is the “to” address. 

MailMessage(
        MailAddress from,
        MailAddress to,
)

Creating an object in PowerShell from a constructor that requires parameters can be done in two ways.  The first is to use the method call notation.

PS C:\scripts\PowerShell> $message = New-Object System.Net.Mail.MailMessage($MailFrom, $MailTo)

The second is to use the ArgumentList parameter.

PS C:\scripts\PowerShell> $message = New-Object System.Net.Mail.MailMessage –ArgumentList $MailFrom, $MailTo

If you happen to have MailAddress objects floating around, this might work for you.  A more common scenario would be to use the next overload, which takes two strings.

MailMessage(
        String from,
        String to,
)

This overload requires two strings, one for the “to” and one for the “from” address. 

The final overload for MailMessage is

MailMessage(
        String from,
        String to,
        String subject,
        String body,
)

This overload allows you to pass in four strings and get back basic MailMessage object that is ready to be sent.

Wouldn’t it be great to have a function, where we could provide a type name and get a listing of all the constructors, right from the command line (not needing to go to the MSDN documentation every time).  Jeffrey Snover has beaten me to the punch and provided a function to find the constructors, appropriately called Get-Constructor.  Add that function to the your toolbox, and exploring the .NET Framework becomes a lot easier.

Next up, we’ll look at static methods.  Static methods are methods that can be called without having to create a instance of an object.

One particular type of static method that we’ll dig in to is the factory method, which is another way to create instances of objects.

(It has been bugging me and I can’t really concentrate on my other tasks, so I need to get this out of the way.)

One suggestion I had was to create a type extension that had the property he was adding, but he was more interested in tagging specific functions, not all of them.

So, I’ve written a couple of little ScriptProperties to save and restore NoteProperties which have been added to FunctionInfo objects.  I’ve added these to a PS1XML.

   1: <?xml version="1.0" encoding="utf-8" ?> 

   2: <Types> 

   3:     <Type> 

   4:         <Name>System.Management.Automation.FunctionInfo</Name> 

   5:         <Members> 

   6:             <ScriptMethod> 

   7:                 <Name>SaveMetadata</Name> 

   8:                 <Script> 

   9: $DefaultProperties = 'PSPath', 'PSDrive', 'PSProvider', 'PSIsContainer'

  10: $SaveDirectory = Split-Path $profile

  11: $File = Join-Path $SaveDirectory "$($this.Name).xml"

  12: $this.PSObject.Properties | Where-Object {$DefaultProperties -notcontains $_.Name -and $_.MemberType -like 'NoteProperty'} | Export-Clixml -Path $file

  13:                 </Script> 

  14:             </ScriptMethod>

  15:             <ScriptMethod> 

  16:                 <Name>LoadMetadata</Name> 

  17:                 <Script> 

  18: $SaveDirectory = split-path $profile

  19: $PathToCustomProp = Join-Path $SaveDirectory "$($this.name).xml"

  20: if (Test-Path $PathToCustomProp)

  21: {

  22:     foreach ($Property in Import-Clixml -Path $PathToCustomProp)

  23:     {

  24:         Add-Member -InputObject $this -MemberType NoteProperty -Name $Property.Name -Value $Property.Value

  25:     }

  26: }

  27:                 </Script> 

  28:             </ScriptMethod> 

  29:         </Members> 

  30:     </Type> 

  31: </Types> 

After saving this file as a PS1XML file, you can call Update-TypeData –Prepend path\to\thefile.ps1xml, and every FunctionInfo object will have two script properties – SaveMetadata and LoadMetadata.  As I’ve configured it, the data will be saved to the user’s profile directory and under a filename that matches the function name.  So, you can add NoteProperties to your heart’s desire and save and recall them as needed. 

I don’t have a direct application for this, and it can probably be cleaned up or done more efficiently, but I had to work through the problem.  I’d love to hear your feedback!

Since I spend a good portion of my day in PowerShell, I wrapped some system table queries in a PowerShell script and use Compare-Object to find any differences in the tables and compare the column definitions as well.  The queries targets only user tables.

Compare-DatabaseSchema.ps1 takes several parameters.

• SqlServerOne – SQL Server for the first database
• FirstDatabase – Name of the first database for the comparison
• SqlUsernameOne – SQL user name for the first database
• SqlPasswordOne – SQL password for the first database
• SqlServerTwo – SQL Server for the second database
• SecondDatabase – Name of the second database for comparison
• SqlUsernameTwo – SQL user name for the second database
• SqlPasswordTwo – SQL password for the second database
• FilePrefix – Prefix for the log file name
• Log – Switch parameter that saves one CSV file with the difference in the tables.  If the Column switch parameter is chosen also, it will save one CSV file per table with differences in the columns
• Column – Switch parametr that enables a comparison of the columns in the tables that match.  Columns are compared by name and datatype.

I still have to add some checks for the various constraints, but that will come later.

You can find the script on PoShCode.org.

I did some digging and found there are several different types of timeouts that can affect your WMI queries.  I’m still working through different scenarios and I’d appreciate any feedback.

The first type of timeout can occur if the machine that you are targeting does not respond to network traffic (it’s down, you have the wrong IP address, firewalled, etc..).  Your WMI call will usually time out after around 20 seconds.

A partial solution to that type of timeout is to ping the machine first.  If you can ping that machine, you’ve eliminated a number of potential problems.  You still might have permission issues or firewall issues, but you are able to reach the machine.

The second time of timeout I’ve seen is when the connection is made, but the WMI call hangs and does not return.

A potential fix for this issue is to use the [WMISearcher] accelerator.  In the options property of the resulting object, there is a ReturnImmediately property, which should be set by default to true.

$searcher = [WMISearcher]”

$searcher.Options.ReturnImmediately

The ReturnImmediately property being set to true requires that the invoked operation (the search) be done synchronously and return immediately.  The enumeration of the results of the WMI call are handled after the return of this operation.

An alternative solution for this issue would be to check the Transaction timeout setting on the target machine.  Run DCOMCnfg.exe and navigate to the Component Services->My Computer.  Right click and choose properties.  On the options tab, there is a timeout (in seconds) for DCOM transactions.  The default value for this setting is 60 seconds.  Fiddle with that at your own risk.  Also, I haven’t had a chance to check for where that value is in the registry or see if there is a Group Policy setting for it.  Setting this value should allow a failed WMI connection to timeout more quickly.

The third area in which I’ve found timeouts/hangs in WMI queries is during the enumeration of the query results.  There is a property in options for the WMI class accelerator called Timeout, which sets the length of time between enumerations before timing out.  The options property is hidden in the default view of PowerShell, so you will need to access it via the psbase property. 

The timeout value is a System.TimeSpan object.  You can specify the value with a TimeSpan object, a number of ticks, or a string that can be cast to a TimeSpan.

It can be set like this:

$wmi = [wmi]”

$wmi.psbase.options.timeout =’0:0:2′ #String that will be cast to a two second TimeSpan

You can also set a timeout value for the [WMISearcher] accelerator.

$searcher = [WMISearcher]”

$searcher.Options.timeout = ’0:0:2′

WMI timeouts can be aggravating, hopefully one of these solutions will help mitigate your WMI woes.