Blog
By Craig Pero on 8/11/2010 5:53:27 PM • Rank (7922) • Views 8052
3

3

I'm not a full fledged powershell person as of "yet".  In the few things that I have done, however, I have seen a trend that can hurt more than help in some cases.

The traditional PowerShell example is:

   
   Get-Somthing | where {$_.name -eq 'this or that'}  
 

When you have 10 or 20 simple objects, that is fine.  The down side is when you are pulling data from a remote location like the SDK. Basically you are saying GET everything and bring it to my computer so I can sort through it further.

Let's say the "Get-Something" returns 50,000 objects of type "something" (maybe closed alerts in the console) and you only want 3 of those objects because only 3 of them have a property with a specific value "Type='Very Special'"

Let's try it this way now...

   
   Get-Somthing  -Criteria "Type ='Very Special'"  
 

What you said here is,  look through the 50,000 objects of type "something"  and only send me the objects where the Type is equal to "Very Special". Now you only get the 3 objects with that value.  Granted there could be more or less, the point of the example is that you want to pull the least amount of data from a remote source possible.  the less you pull down, the less you process locally and the less time you wait for the data to come down to you.  This improves performance significantly.

Of course you could further filter on the client side by piping to WHERE.

One cmdLet in Operations Manager that has the Criteria Option is GET-Task.  If you have 1000 tasks and you want to get all that are your custom tasks that you name with "MT-" at the beginning of the Task Name, you could use the following:

   
   Get-Task  -Criteria "Name like 'MT-%'"  
 

Now instead of downloading all 1000, you only pulled down YOUR tasks. You can then further process them.

Personally, I feel cmdlet's should always include a criteria option where data is remotely transferred and can be filtered at the source.

If you like boosting performance like this, please take the time to comment to microsoft that you would like to see more server-side criteria options in powershell.  the connect site is a good start.   https://connect.microsoft.com

if you are on the TAP for Operations Manager and have access, please read my comments to MS regarding the use of criteria and Increase the vote count if you agree with me.

https://connect.microsoft.com/site799/feedback/details/585599/criteria-option-in-cmdlet-powershell

Comments (4) - Comment RSS
Andreas Zuckerhut wrote: on Aug 12, 2010 02:33 AM
That's pretty interesting.

So, when you use the -criteria it modifies the request that is sent to the SCOM DB right?
Craig Pero wrote: on Aug 12, 2010 09:24 AM
Correct. If you are familiar with SQL, it's basically modifying the WHERE clause. (not sure what "officially" happens under the hood)

Select * FROM [viewName]

Select * FROM [viewName] WHERE Name like 'MT-%'

I should add, the field names are case sensitive as far as the SCOM cmdLets. "Name" works but "name" will not work for the GET-TASK cmdLet for example.
Marco Shaw wrote: on Aug 13, 2010 08:43 AM
Related post:

http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexId/49785/Default.aspx



SDK documentation:

http://msdn.microsoft.com/en-us/library/microsoft.enterprisemanagement.monitoring.aspx



In the SDK docs, look simply for a class *criteria to see where there is support for this functionality.



I strongly doubt this would be stripped out of the SDK, and thus no longer available with the cmdlets in OpsMgr v.Next.
Craig Pero wrote: on Aug 13, 2010 05:02 PM
If for nothing else... it emphasizes that this is a valuable feature to the SCOM community and worthy of increasing its usage. All it takes is increasing the vote count.


Who Viewed
Who Reviewed
Categories
Tags
SCOM Powershell criteria cmdlet
Related Pages
Shortened URL
http://tinyurl.com/35jzu78

Top Contributors
Featured Members
Pete Zerger
Points: 65622
Level: System Center Expert
Tommy Gunn
Points: 42748
Level: System Center Expert
Simon Skinner
Points: 40804
Level: System Center Expert
Stefan Koell
Points: 28999
Level: System Center Expert
Andreas Zuckerhut
Points: 27734
Level: System Center Expert