UPDATE 02-01-2014: Fixed some issues in script


When dealing with the cmdlet: Set-SCSMTemplate in SMLets, you might have noticed that if you apply a template with activities, the prefix of the ID’s (e.g. RA300 or MA250) is all missing. And it’s the same issue if done via the SDK or Orchestrator.

One workaround, described by Lee Berg here: http://www.leealanberg.com/blog/2013/03/13/scsm-automated-service-request-smlets-creation-issues-and-work-arrounds/ is to modify the management pack that contains the template, and then insert the prefix like this: MA{0}. This approach works, but can be quite cumbersome as it takes time to do and also “locks” the template so any modification done to the template via the console will reset the id property in the management pack. Which means you have to insert the property again in the management pack.

This script takes care of the problem with no need to modify the management pack. All you need to provide is the workitem guid and the guid or displayname of the template that you want to apply.

If you are using Orchestrator, then my collegue Jakob has made a cool Integration pack that takes care of the problem: https://blog.ctglobalservices.com/jgs/scoscsm-2012-create-objects-with-activities-with-coretech-integration-pack-for-scsm-2012-extension-beta-2/

My script is used when you want to apply a template on an already created workitem, where Jakob’s IP is used for creating new workitems based on a template. The same issue will happen in both scenarios. If people find the script useful I could make another script to create a new workitem based on a template as well.

This is the first version, I’d be happy to get your feedback:


The highlevel steps in the script is to

  1. Analyze the template for activities,
  2. Update the template with the right activity prefixes, and then finally
  3. Commit the updated template to the workitem.

Nothing is being changed or needs to be changed in the management pack with this method.





Leave a comment or write me an email for feedback