| 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.
|
|
|
|
Thank you for your rating!
|
Share This |
Views: 2658 :: Rank: (2246) |
Filed In: Blog, Operations Manager, Powershell |
436 days ago |
|
|
|
|
|
|
|
|