Blog

June 24 2009 12:29 PM

faq I posted an updated Powershell script for a client to resolve rule-generated alerts in SCOM 2007, but also to illustrate an example of TRUE and FALSE evaluation in Powershell.

The fact is, it’s really about $TRUE and $FALSE. Powershell has a more accurate notion of true / false than one might imagine. I just wanted to add a pointer to some clarifying information for the benefit of all who may not be familiar.

My client had written a script  that attempted TRUE / FALSE evaluation using the –eq comparison operator as though “TRUE” and  “FALSE” evaluation where strings, and they were getting an unexpected results, getting a true match when a false was expected, and vice versa. (Code snippet below)

get-alert | where-object { ($_.LastModified -lt $targetdate) -and ($_.ResolutionState -eq 0) -and ($_.IsMonitorAlert -eq“false”)}

 

This is actually a Boolean comparison, and using –eq $TRUE or –eq $FALSE will deliver the expected results.

 

So what are the potential consequences of using “TRUE” and “FALSE” strings in such comparisons?

Notes from “The Architect”

Powershell architect Jeffrey Snover has a great explanation if you’re not familiar. Jeffrey also explains why the unexpected results are returned as well. 

http://blogs.msdn.com/powershell/archive/2006/12/24/boolean-values-and-operators.aspx

 

Sample Script

I modified one of my old scripts to address rule-generated alerts only. For a “Close Rule-Generated Reports” that treats these as boolean values, click HERE.


 Print  

Quick Links
Top Contributors
Featured Members
Pete Zerger
Points: 41211
Level: System Center Expert
Simon Skinner
Points: 30429
Level: System Center Expert
Tommy Gunn
Points: 29964
Level: System Center Expert
Stefan Koell
Points: 20109
Level: System Center Expert
Tenchuu
Points: 15261
Level: System Center Expert