Creating Queues and Groups Using Type Projections

Update: You can do this in the console in SCSM 2010 SP1 now.

Background information for this post:  Groups are typically collections of Configuration Items (although technically it can be groups of any kind of object).  Queues are collections of a certain kind of work item – like a queue of incidents.  Groups and Queues can be based on dynamic inclusion criteria like ‘All Windows Computers where the Domain property contains ‘Redmond’’.  Groups (only) can also have static membership like ‘include Computer1, Computer2, Computer3…  Groups (only) can also exclude objects and include other Groups.  Groups and Queues are used for role based security scoping, notification subscription criteria, and for report filtering (and eventually for view criteria – that was unfortunately cut for SCSM 2010 due to lack of time).   The idea is to define a group of things, use it many places, and any time you need to change the definition of that group of things you can do it in one place and have it immediately apply to all the places where that definition is being used.

More information on type projections:


In the Group and Queue wizard you can create criteria based on properties of the selected Configuration Item or Work Item class like this:


We are often asked how you can create groups or queues using properties of related objects in the criteria.  Here are just a few examples we’ve heard:

  • Windows Computers where the Operating System Version is ‘Windows 7’
  • Windows Computers where the Operating System is a Server vs. a Client OS
  • Incidents (or any other work item for that matter) where the affected Service (or any other CI) is ‘some service’
  • Incidents where the affected user is a VIP
  • Incidents where the affected user is in company ‘Contoso’
  • Incidents where the assigned to user is in company ‘Contoso’

And on and on…

You can’t do this in the wizard in the console unfortunately, but you can do this in the MP XML if you know what you are doing.  That’s what this blog post is about.  For the purposes of this blog post we’ll implement the three highlighted examples from above.  From there, you’ll get the idea and can really do anything.

First of all you need to define the Group or Queue as a new singleton ClassType.  Groups should derive from Microsoft.SystemCenter.ConfigItemGroup and Queues should derive from System.WorkItemGroup.


Next, for Queues (only) you’ll need to define a RelationshipType which tells Service Manager what kind of work items will be contained in the Queue.  The RelationshipType should derive from System.WorkItemGroupContainsWorkItems.  The Source Type attribute should point to the ClassType ID from above.  The Target Type attribute should point to the Work Item ClassType that you will be containing.


Next you need to define a Discovery for each  Group\Queue. 

  • The Target attribute should point at the ClassType of the Queue/Group from above. 
  • The DiscoveryRelationship TypeID attribute should point to the RelationshipType ID created above for queues.  For groups it should always point to Microsoft.SystemCenter.InstanceGroupContainsEntities. 
  • The GroupInstanceId MPElement Name should be the same as the ClassType ID from above. 
  • The TypeProjection MPElement Name should point to the TypeProjection ID you are going to query over.
  • The MonitoringClass MPElement Name should be the ClassType ID of the objects you are going to include in the group
  • The RelationshipClass MPElement Name should be the same as the DiscoveryRelationship TypeID.


Next you just need to specify the criteria.  Let’s take this apart a piece at a time…

First we have a simple expression which is just going to look at a certain property of a related object and compare it using a LIKE operator and look for a certain string to be somewhere in the property value.  It’s the equivalent of doing a T-SQL Like %<search term>% query in SQL Server.  The tricky bit here is the Property expression syntax so we’ll take this one piece at a time…

First – always start with $Context/ …


The specify the RelationshipType ID that you want to traverse over…


Then, optionally specify if you only want to look at objects of a specific class by specifying a TypeConstraint…


The specify which class the property you want to look at is defined on…


And lastly specify the property ID…


So – it looks like this when completed:

$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsOperatingSystem’ TypeConstraint=’Windows!Microsoft.Windows.OperatingSystem’]/Property[Type=’Windows!Microsoft.Windows.OperatingSystem’]/OSVersionDisplayName$


For more information on constructing Criteria XML please see this blog post:

Here is the complete management pack with all of these examples in it:


Important Note:  Queues/Groups created in this way cannot be edited in the SCSM console in any way.  Even editing it to change the name or something like that will cause the SCSM console to remove the criteria part of the queue/group definition.  All edits to groups/queues that use this kind of criteria must be done in XML.  To ensure that users dont try to edit these queues/groups in the console and also to ensure upgradeability from one version of the MP to the next you can seal the MP following these instructions: