locked
Notifications user system GUID rather than ID Defined in XML RRS feed

  • 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?

    Friday, September 19, 2014 9:43 PM

Answers

  • So I discovered, this doesn't work:
                      <WorkflowArrayParameter Name="TemplateIds" Type="string">
                        <Item>Template_dde4cf07392e4159943a9bada8559c80</Item>
                      </WorkflowArrayParameter>
    However, this does work:
                      <WorkflowArrayParameter Name="TemplateIds" Type="string">
                        <Item>$MPElement[Name='Template_dde4cf07392e4159943a9bada8559c80']$</Item>
                      </WorkflowArrayParameter>
    I think this solves my problem, I can use this method to reference everything using MP names rather than system assigned GUID.
    • Edited by _Keith_ Tuesday, September 23, 2014 8:28 PM
    • Marked as answer by _Keith_ Tuesday, September 23, 2014 8:46 PM
    Tuesday, September 23, 2014 7:51 PM

All replies

  • You can try replacing the GUID with an MP reference, in the format MPAlias!MPElementName. that should be stable between systems, but you'll need to manually edit the MP before sealing. 

    here's a dumb question: why do you want to seal notification subscriptions or workflows? this is something that should be editable in the production system, so changes can be made rapidly if need be. 

    Monday, September 22, 2014 3:53 PM
  • 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.

    Monday, September 22, 2014 4:32 PM
  • So, using the MP reference doesn't work, even if manually edited, once edited going to Notification Subscriptions throws this error:
    Date: 2014-09-23 1:31:51 PM
    Application: Service Manager Console
    Application Version: 7.5.3079.0
    Severity: Error
    Message: An error occurred while loading the items.
    
    System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
       at System.Guid..ctor(String g)
       at Microsoft.EnterpriseManagement.Subscriptions.NotificationSubscription.InitializeMembers()
       at Microsoft.EnterpriseManagement.Subscriptions.WorkflowSubscriptionBase.CreateSubscription(String xmlValue)
       at Microsoft.EnterpriseManagement.Subscriptions.SubscriptionManagement.GetSubscriptionsByCriteria(ManagementPackRuleCriteria criteria)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.WorkflowSubscriptionBaseAdapter.GetDataFromSdk(EnterpriseManagementGroup managementGroup, AdapterQueryParameters queryParameters)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SdkDataAdapter`1.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.ViewFramework.ListSupportAdapter.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.DataModel.QueryQueue.StartExecuteQuery(Object sender, ConsoleJobEventArgs e)
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)
    

    Tuesday, September 23, 2014 7:36 PM
  • So I discovered, this doesn't work:
                      <WorkflowArrayParameter Name="TemplateIds" Type="string">
                        <Item>Template_dde4cf07392e4159943a9bada8559c80</Item>
                      </WorkflowArrayParameter>
    However, this does work:
                      <WorkflowArrayParameter Name="TemplateIds" Type="string">
                        <Item>$MPElement[Name='Template_dde4cf07392e4159943a9bada8559c80']$</Item>
                      </WorkflowArrayParameter>
    I think this solves my problem, I can use this method to reference everything using MP names rather than system assigned GUID.
    • Edited by _Keith_ Tuesday, September 23, 2014 8:28 PM
    • Marked as answer by _Keith_ Tuesday, September 23, 2014 8:46 PM
    Tuesday, September 23, 2014 7:51 PM