Problem

One of the challenges people seem to run into with using Review activities in System Center Service Manager is using Active Directory groups as reviewers. When you add an AD group as a reviewer the functionality you get is:

Everyone who is a member of that group may vote, via the SCSM Console (if they have access) or via the Self-Service Portal.

The group only has a single vote – if there are 5 members of the group and you need a vote from each person, the moment 1 person votes yes/no the entire group has voted.

Unless the group also has a mail address, group members won’t get a notification as the notification engine doesn’t know who is a member of the group.

Even if you do send out a notification via the group address, if the members reply back to the mail with a vote it won’t be processed by SCSM as only the Group is recognised as a reviewer, not them.

Number 4 is essentially a bug, but a long-standing one. However for many people this mechanism isn’t suitable for their needs because:

You may want to require an approve vote from everyone in the group, or a % proportion.

If the group is the only reviewer, as soon as one person votes yes, the activity is approved, even if 30 seconds later someone wants to vote declined.

Each group only gets a single vote – there is no room for weighting. If one group contains 7 people and one contains 3, they both have equal voting share.

When your Service desk is trying to chase or determine who can vote on an activity, it can be difficult to ascertain exactly who can vote.

The alternative is therefore to populate the review activity with the users that make up the group… which can be extremely painful if you’ve got many templates all with individual users that need updating whenever a person joins/leaves a team, nested groups, and must all this must be cross-referenced when building new templates or creating review activities manually.

Solution

In order to address the problem, I’ve put together a powershell script that will replace any Active Directory groups from an instance of a review activity and replace them with SCSM AD Users (assuming they have been imported into the CMDB). This means you can add groups to your templates (or manually created activities) and once they go in progress the groups are expanded. Features include:

Recursively parses groups, so nested groups are supported.

Ensures that a user is not added twice if a member of multiple groups (or manually added to the review activity).

Calculates and maintains the highest approval rights a user may be entitled to (Must vote and Veto).

This script can be hooked up to service manager in a variety of ways – the primary method being a System Center Orchestrator runbook that is monitoring for created review activities. You could also utilise this script in a Service Management Automation (SMA) runbook or even using the native SCSM Workflow engine if you use the community PS workflow activities.

As the script has been written to support System Center Orchestrator, it makes use of Powershell remoting to get around the x86 PSv2 only restrictions, but you can remove these elements if you are running it using SMA or natively on the SCSM Management servers. There are a few variables at the start of the script that contain connection details – these can either be hard coded (not recommended) or populated via SCO Variables. The Review activity GUID needs to be set using a subscription to a “Monitor Object” activity.

Place groups in our templates at design time, and know that the review activity will contain the correct members of the group.

The service desk can add groups to manually created activities, without having to look up who is a member, find their CIs and deal with nested groups

We can use notification channels to allow the reviewers to vote back via email etc.

Finally, if we only wanted to give the group a single vote share in specific cases, we can still do that by putting a parallel activity in our workflow and putting two review activities in – one with the single vote group and one with the remaining voters. The group review activity can then have it’s criteria set appropriately (unanimous, %), and if the group rejects the review activity then the Parallel activity will fail and the parent work item will stop as normal.

Example

In the screenshots below, you can see that I’ve used this script in an Orchestrator Runbook. The “Monitor for New Review Activities” trigger is just set to monitor for new “Review Activity” work items, with no filters.

The script is inserted in the (badly named, i’ll admit) “Delete Group Reviewer” activity, which is actually a Run .Net Script activity. Hook up all your variables and published data (remember that the ID the script is looking for is the SC Object Guid from “Monitor for..”, NOT the work item ID.

Start the runbook, and then go create a review activity. Below I’ve got one user with the “Must Vote” right enabled, and one group with the “Has Veto” right. The user is also a member of the group, so when the runbook executes it should expand the group into users but also give the existing user the “Has Veto” right and maintain their must vote status.

Wait for the runbook to execute, then check back on your review activity – as you can see we now have all users and the group has been removed!