I am a lazy guy and whenever possible I try to automate things using PowerShell scripts or System Center Orchestrator runbooks. If you work with Service Manager you know that lots of tasks can be automated by using PowerShell cmdlets that are somewhere stored in PowerShell modules. For Service Manager you have 2 PowerShell modules available: either you can use the Service Manager PowerShell module that is delivered with the Service Manager console or you can use the smlets PowerShell module that you can download from the codeplex web site. One cool thing to automate is the enabling and disabling of workflow and notification subscriptions. Why? When you add new workflows or subscriptions that replace others, it can be very challenging to find a good timing. Imaging you have 50 workflows that need to be replaced. You would have to create 50 new workflows, disable all 50 old workflows and enable all 50 new workflows. The goal is to minimize the impact on the running infrastructure. Very challenging in a 7×24 environment. By using scripts this becomes easy as 1-2-3 and is of course also much faster than using the Service Manager console.

Workflow subscriptions and notification subscriptions are internally defined as “Rules”. Rules have (at least) a Data Source module and a Write Action module. The Data Source module is used to define, when a rule is triggered, the Write Action module defines the steps that will be executed.

Here are some detailed information about a rule. It shows the name of the rule and if it is enabled, the name of the Data Source and Write Action modules, and the status. The status shows if the rule configuration has changes or not and if yes, if they were committed back to the management pack or not.

When you open the management pack and check the configuration of the rule, you will get more insights how rules are working and how the different modules are composed.

Rule

Beside some other configurations the rule contains an id and a parameter if it is enabled or not.

Rule Data Source

This example rule represents a workflow that will be triggered whenever a new incident is created. The instance subscription type id relates to Incident objects. The corresponding Write Action module defined what will happen.

Rule Write Action

In this example a mail is sent to the affected user to inform that the incident was successfully created. In the Write Action area you see different parameters are passed, e.g. the notification template that will be used and the id of the related object that the mail will get.

Create new workflows and automate the enable/disable change

It seems that rules can be directly be created by using xml. True. If you have to create a bunch of new workflows or notification subscriptions you will be much faster when directly hacking the xml code in your favorite editor compared to the slow wizards in the GUI. Actually you have to take care about 2 other things when doing so: Categories and Display Strings. Check out the exact configuration of an existing workflow for details about those 2 things.

Now, how can those rules be enabled/disabled by using PowerShell scripts? When investigating the Service Manager PowerShell Module and smlets you will find some options to display information about rules, but there’s nothing to enable/disable them. So we have to dig deeper and use the SCSM Core library to access the management group. The following script will help you changing the enabled attribute of rules in bulk.

##################################################
# Connect to Enterprise Management Group
##################################################

$asm = [reflection.assembly]::LoadWithPartialName(“Microsoft.EnterpriseManagement.Core”)
if (! $asm) {throw “Could not load Microsoft.EnterpriseManagement.Core dll”}
$emgtype = “Microsoft.EnterpriseManagement.EnterpriseManagementGroup”
if ($emg -isnot $emgtype) {$emg = new-object $emgtype localhost}
if (! $emg.IsConnected) {$emg.Reconnect()}

##################################################
# Get Management Pack and all Rules
##################################################

$mp = $emg.ManagementPacks.GetManagementPacks() | where {$_.displayname -eq “itnetx.workflows”}
$rules = $mp.GetRules()

##################################################
# Enable Rules and write back to unsealed MP
##################################################

foreach($rule in $rules)
    {
    $rule.enabled = “true”
    $rule.status = “pendingupdate”
    }

$mp.AcceptChanges()

This script reads all rules from the management pack “itnetx.workflows” directly from the management group. Then for all rules found, the enabled attribute is changed to “true” and the status of the object is changed to “PendingUpdate”. The last step is to write back the changes to the management pack. All objects with status “PendingUpdate” are investigated and written back in the management group. Of course you can apply filters to only target specific rules and change other attributes if needed.

With that, it’s easily possible to prepare a bunch of new workflow and notification subscriptions in a disabled state, and then use scripts to change from the old to the new configuration by executing a script. The change is then be done within seconds and can also be reverted if the new configuration is not working as expected.

Cheers
Marcel