Notifications user system GUID rather than ID Defined in XML

Question

I've been working on creating, and sealing a set of management packs that anyone could import and use, and I've hit a bit of a snag. There are a number of things in the management pack that seem to be expressed using a system GUID rather than the ID defined
in the management pack. To give an example, inside one of the management packs there is a template named  with the ID "Template_2189ec1298d647a5b971c5429e72a04e". When this template is referenced by a notification workflow, the workflow uses
a system GUID to reference it instead. It seems as though, when a management pack is imported, the system creates all of the objects within in, so these system GUIDs are not the same and cannot be predicted. I'm having the same issue with Support Groups and
other things as well.
In the definition of my Notification Channel for example, one of the workflow parameters is the TemplateID the notification should use to sent the alert (Note <Item>):
<WorkflowArrayParameter Name="TemplateIds" Type="string">
<Item>Template_2189ec1298d647a5b971c5429e72a04e</Item>
</WorkflowArrayParameter>
The alert is also dependent on Support group (note the <value>):
<Expression>
<SimpleExpression>
<ValueExpression>
<Property State="Post">$Context/Property[Type='WorkItem!System.WorkItem.Incident']/TierQueue$</Property>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>{cd712f91-a26b-8ff8-133d-36f9f4b40d46}</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
I built my management packs, and tried to move them to a new system, they imported no problems now that I've sealed them, but when I went in and looked the template for the notification channel was blank, and since the management pack is sealed now, I can't
change it. I thought it was odd, so I referenced my XML, and I used this to get the ID of all the templates, and I noted... now they all seem different now that I've imported them into the new system:
foreach ($template in (Get-SCSMObjectTemplate))
echo $template.Id
echo $template.Name
echo $template.Description
I realized, when you import the management pack the first time, it must created GUIDs for all these things... is there a way to within the management pack reference the ID I can define, rather than the system GUID that's impossible to fix? I'm going to look
into writing a script that uses smlets to correct all this information and update the MP once it's been imported the first time, but that seems like a bit of a hack, there must be a way to do this? Anyone find elegant solutions to this problem that didn't
involve writing a fancy installer script for their management packs?

Answer 1

I'll give that a try, I tried just the MP reference and the error it gave complained it expected a GUID in a particular format.
A bunch of them are notifications that notify "affected user" or other internal references, that shouldn't need to change, the ones that go to people, or groups will have to be in an unsealed management pack. Initially, my goal was just to try
to get as much as I could into a few management packs as possible to avoid having a large amount of management packs, more it's just looking like this isn't possible.
I'm looking at breaking things down like this:
Incident Customizations
Incident Customizations Overrides
Service Request Customizations
Service Request Customizations Overrides
Work Item Customizations (storing some things common to all work items, like urgency)
Service Catalog
Notifications
So, my initial hope was to avoid splitting out ROs and SOs, putting any changes that need to be made quickly into the Override MPs. What this means, is that my solution can be implemented, and then customized without making changes to the core MPs directly
in PRD, then I have a promotion process. I dislike changing things in PRD on the fly, and would prefer a solution that forced people to use a promotion process, but it's looking like with Notifications, ROs, and SOs, it's just not possible.
Regardless of whether I'm going to seal this management pack or not, I'd like to avoid manually fixing every single Notification, or anything that references one of these internal GUIDs every time I implement this in a new system, since the possibility is
totally there for the MP name to be used instead, I'm confused why that isn't the default behavior.