Use the other Write- cmdlets

One of the unsung features of PowerShell are the many ways to provide output.  For completely automated script via Scheduled Task or Orchestrator, I go straight to the Event Log now. 

But for the majority of scripts you’ll run on the command line, there is a lot more than Write-Output.  By the way, Don Jones says God kills a puppy each time you use Write-Host, so don’t do that.

Write-Debug

Excellent for trace level information and you can enable/disable with –Debug and $DebugPreference.

Write-Verbose         

· Step by step information like “Now running trash compactor…”, switched with –Verbose and $VerbosePreference.

Write-Warning         

Show of hands, who actually knew this was there?  Now you do.  Switched with –WarningAction and $WarningPreference.

Write-Error

Looks just like a regular paragraph long red error message, switched with –ErrorAction and $ErrorPreference.

I’m moving all inline comments to Write actions and making decisions about the right level of notice along the way.  I definitely like the ability to control output when running scripts now.

Use Native Methods For Huge Performance Gains

Many PowerShell examples, samples and everything generated by PowerGUI use a common structure to filter out desired objects:

Get-Something | Where-Object { $_.Name –match “pattern” }

This is great for samples and one-off scripts.  It is clear and easy to read.  However, when run in production against large data sources or large numbers of object, this frequently becomes a bottleneck.

This performance hit is especially noticeable when polling remote data sources.  In this example I found in an Operations Manager forum, we query for all objects found in two classes and then filter locally:

Get-MonitoringClass | `
Where-Object {$_.Name –eq “microsoft.windows.server.2008.computer”} | `
Get-MonitoringObject | Where-Object {$_.state –eq “Error”}

In a small demonstration environment of 10-20 servers, this would not be a problem.  However, my environment is a bit larger and this command times out at 1 minute and 45 seconds.

A better way is to use the native methods of the Operations Manager SDK to filter and match those objects required:

Get-MonitoringClass –Name “Microsoft.Windows.Server.2008.Computer” | `
Get-MonitoringObject –Criteria “HealthState = 3”

This ran in about 9 seconds for a huge performance gain.  I would imagine that this saves performance on the server hosting the SDK, my backend database and even the network.

Summary – for production use, take time to make use of native class methods for more efficient code.

NetApp MP – SnapMirror Discovery

While trying out the latest MP from NetApp (ApplianceWatch) I ran into this d’oh moment.

All objects and attributes were being discovered with my six test filers as expected, except for SnapMirrors.  A call to NOW gave me the obvious answer, “You must have both source and destination for any snapmirror in order to discover it.”

They will be posting a KB article for this issue soon.

Problem with BMC Remedy connector for Opalis

I was geting started with Opalis’ Remedy Integration Pack and found that I could not get a connection to my AR server.  I copied in the AR System DLLs into my Action Server and Clients per IP instructions, but no go. 

After talking with Microsoft Support I obtained a yet-to-be documented issue when connecting to Remedy port-mapper.  You will need to create a System Environment Variable called “ARTCPPORT” with the value of your Remedy TCP port.  I believe this is usually port 4190 by default.  This needs be created on any Opalis Action Server and Client making AR connections.