Archive for February, 2012


SMLets – Enum and wildcards

Posted by: | Comments (11)

I’ve seen the question two times now, and that’s two times too many :)
The script below will show you how you can locate all Incident (as an example) that has an Classification value matching a Incident Classification that has a display name that matches *problem*.

Import-module smlets -Force
$class = get-scsmclass system.workitem.incident$
#Try to narrow the next search down by getting the root value for the enums you're interested in.
$rootEnum = Get-SCSMEnumeration IncidentClassificationEnum$
#Might be performance heavy depending on how many child enums the parent enum has.
$matchingEnums = get-scsmchildenumeration -Enumeration $rootEnum|?{$_.DisplayName -like '*problem*'}
$Filter = ""
$matchingEnums|%{$Filter +="Classification -eq '$($_.Id)' -or " }
$Filter = $Filter.TrimEnd("-or ")
Get-SCSMObject $class -Filter $Filter

Remember that the display name used when matching the filter is the localized display name used by the current process (if you run this in a workflow).
If you haven’t already got it, you’ll find SMLets at

When using smlets ( to work with Service Manager using PowerShell, small details can have huge impact on performance.

Server side vs. Client side filtering

The number one thing is to use server side filtering as far as possible. This has been described before but cannot be told too many times.

Example of client side filtering:

$class = Get-SCSMclass system.workitem.incident$ 
Get-SCSMObject -class $class|?{$_.Title -like '*printer*'}

Example of server side filtering:

$class = Get-SCSMclass system.workitem.incident$
Get-SCSMObject $class -Filter "Title -like *printer*"

In my test lab the server side filtering above is 50 times faster than client side. The reason for that is that client side filtering in the example above, in fact means bringing over all objects of the specific class to the client side and finding the matches there. Not a good idea!

Read more about the gain and tips about server side filtering in these excellent blog posts from Travis Wright and Jim Truher:
Properly Querying SCSM Using SMLets Get-SCSMObject cmdlet
Retrieving projection data with PowerShell

Choosing the lighter type projection

What I want to add to the above is how choosing the proper type projection will affect the performance.

As an example, let’s say we want to retrieve all Incidents that are currently Active and Un-Assigned (assigned to user is not set).

We can do this by using the following PowerShell commands:

#Get type projection
$IncidentProjection = Get-SCSMTypeProjection System.WorkItem.Incident.ProjectionType$
#Create criteria
$criteria = new-object $CTYPE $cc,$IncidentProjection.__Base,$IncidentProjection.managementgroup
#Get incidents matching the criteria
$incidents = Get-SCSMObjectProjection -Criteria $criteria

Note: I cut out the part of defining the criteria “$cc”, you can find it in the download available in the bottom of the post.

Depending on which type projection you choose the time for execution of the commands can differ greatly. The reason for this is that different type projections bring a different amount of data back from the server. A type projection is a definition of what data you want to wrap around the seed class instance (in this case the Incident). When choosing which type projection to use we have to think about how we want to define the criteria and which data we want to retrieve. In our example above we just want to see which incidents are Active and Un-assigned. This basically means that we only require a type projection (read more about type projections here) that has the seed class “Incident” and has one component, the AssignedUser. Let’s look at the effect of choosing two different type projections in the example above.

To see which type projections are available for a specific type you can use the following command:

Get-scsmtypeprojection|?{$_.TargetType.Name -eq "System.WorkItem.Incident"}

Note: Client side filtering is perfectly fine in usage like this of course. Another great way to study type projections is to export management packs and look at the xml directly. Also, if you do not find a suitable type projection you can also define your own, but that’s a different story.

After looking at the type projections let’s say that we choose to use the one called “System.WorkItem.Incident.ProjectionType” since this one contains all the components we’ll ever need. Actually it’s the projection that is used out of the box for the Incident form, which means it contains all the components used by the form like: Assigned User, Primary User, Activities, Affected User etc.

Executing the query for all Incidents with status Active which are Un-Assigned, using the type projection above, in my lab environment (over a medium slow connection) takes about 30s.

Now we might be perfectly fine with that, but let’s take a look at what would happen if we would have chosen a “lighter” type projection (fewer components wrapping the incident). As discussed earlier this scenario really only required one component, the AssignedUser, since we’re using the AssignedUser in our criteria.

The out-of-the-box type projection that has the least components and includes the AssignedUser is the projection called “System.WorkItem.Incident.View.ProjectionType”. This projection actually only contains two components: AssignedUser and AffectedUser. Using this projection for the same query for data as the previous, with the same setup takes 10s.

So by choosing a more suitable type projection we managed to cut two thirds of the time used for retrieving the incidents we were looking for.

So remember folks:

  • Use server side filtering
  • Use the type projection with the least components that fulfill your needs.
    Based on components used by your criteria and what data you want to retrieve.

One last thing, when creating views in Service Manager you can use the exact same reasoning regarding which components are required to achieve as good performance as possible. This has been described on its own in this great blog post by Travis Wright: Why is My Custom Incident View So Slow?

You can download my measurement script here: smletsDataQueryTest.ps1

Comments (0)

I few days ago a friend (Anders Bengtsson over at asked if I could help out with creating an Orchestrator Activity that would convert rich text to plain text. So, today we’re announcing another community contribution from Gridpro, the “Gridpro Orchestrator Text Manipulation Integration Pack”. At this point it only contains the one activity – “RTF to Plain Text”.

Download the integration pack from here: Gridpro Orchestrator Text Manipulation IP

Note: The activity needs the complete RTF content to be able to convert it correctly, line by line coversion is not supported.

Update: See how Anders uses the IP when working with announcements in Service Manager. Integrate Service Manager and SharePoint annoncements with a bit of Orchestrator magic

Categories : Orchestrator
Comments (3)

For our Swedish audience we are happy to introduce a half-day session in how Service Manager 2012 and Orchestrator 2012 can ease your daily IT operation burden by automation. This session is arranged by our partner Expero and is in Swedish. For more information and to book your seat click here

If you want even more hands-on experience on how Service Manager 2012 and Orchestrator 2012 work together we would recommend you to book a seat in our 2 days Labshop were we will be working with these products and see the full potential of the integration. Book your seat here