First published on TECHNET on Jul 07, 2011
I’ve had a few customers and partners ask how they can disable our out of box workflows so they can implement their own custom workflow logic in their own code. It’s actually really easy to do with a little “know how” and some XML editing. If you are going to use this technique to disable workflows that we provide out of the box, please be aware that we have not specifically tested that scenario and you should thoroughly test out what the impact is of disabling these workflows are on your system and processes before you try this in a production environment.
Usually customers and partners want to disable our change request related workflows when they want to do something like this so I’ll provide the example of disabling the workflow that changes a CR status from New to In Progress as my example. This behavior happens as a result of either the New Change Request or the Activity Added workflow running so in the example I will show how to disable both of them with an override.
For those of you with a background in SCOM you are probably already familiar with overrides. Overrides allow you to override the configuration of workflows – rules, monitors, and runtime tasks. You can override parameters like scheduled intervals, thresholds, etc using this technique but in this case what we want to do is override the Enabled property.
To do this we first need to identify which rules we want to disable and which MPs those rules are in. To do this I ran a query like this in the ServiceManager database:
select * from rules where rulename like '%change%' or rulename like '%activity%'
You can also find the rule name using the Get-SCSMRule cmdlet in
if PowerShell is more your thing than T-SQL.
You also need to know the management pack ID, public key token, and version that the rule(s) are contained in because we are going to need to create references to those MPs. To do that just grab the ManagementPackId GUID from the query results:
And run a query like this:
select MPName, MPVersion, MPKeyToken from managementpack where managementpackid = '2BF6413B-BB6C-1108-D33A-152C9D1DB56B'
Now we just need to create a new management pack and reference the System.Library and ServiceManager.ChangeManagement.Library management packs. Then we just add the Monitoring section, add an Overrides section inside of there and declare each of our RulePropertyOverride elements:
" ContentReadable="true" SchemaVersion="1.1" OriginalSchemaVersion="1.1">
<RulePropertyOverride ID="DisableNewChangeRequestRule" Context="System!System.Entity" Enforced="false"
<RulePropertyOverride ID="DisableActivityAddedRule" Context="System!System.Entity" Enforced="false"
<LanguagePack ID="ENU" IsDefault="true">
Just to explain a little bit what is going on here:
the ID attribute can be anything. It just needs to be unique within the MP.
the Context attribute should always point at the System.Entity in SCSM. It’s just the easiest thing to do to ensure it is always disabled.
the Enforced attribute should generally always be set to ‘false’. That allows other overrides which are marked Enforced = ‘true’ to override this override.
The Rule attribute should point to the rule name of the rule you want to override the property for. Here, I used an MP reference alias in front of the rule name since the rule is in another MP.
The Property attribute needs to be the name of the property – in this case we want to override the Enabled property value.
The Value element contains the override value. In this case we use false to disable the rule by setting its Enabled property to false.
Now, we can just import this MP into SCSM and disable those two rules. To re-enable them just delete the MP.
I’ve attached the demo MP for this below.