locked
Importing Runbooks sets the "Invoke by Path" property RRS feed

  • Question

  • Wondering if anyone else has seen the Invoke by Path property being set (checked) on Invoke Runbook activities after importing runbooks into Orchestrator.  This was also seen in Opalis when exporting/importing policies.

    Even when setting to overwrite folders on import, if the invoke runbook activity targets an existing runbook....the Invoke by Path is checked (even when it wasn't when being exported).

    Question is would this be expected behavior? 

    Is there a reason that the property should be left enabled?

    After importing 1000+ policies from Opalis, the only sane way of reverting the property would be an Update query to the database to do a mass update.  Would this be a "supported" method?

    Thanks!

    Thursday, June 21, 2012 2:53 PM

Answers

  • The fix to this is ultimately going into each Invoke Runbook activity and selecting the runbook again if it was imported seperately.  The target runbook has a different GUID than the existing runbook that was imported prior.  So changing the path of the target runbook w/o doing anything would break the Invoke Runbook activity when it runs.

    To find all Invoke Runbook activities that have this property set, you can run this SQL query:

    Select POLICIES.Name AS SourceRunbook, TRIGGER_POLICY.PolicyObjectID AS TargetRunbookID, TRIGGER_POLICY.PolicyPath AS TargetRunbookPath, TRIGGER_POLICY.TriggerByPolicyPath, TRIGGER_POLICY.TargetActionServers
    From TRIGGER_POLICY
    INNER JOIN OBJECTS ON TRIGGER_POLICY.UniqueID = OBJECTS.UniqueID
    INNER JOIN POLICIES ON OBJECTS.ParentID = POLICIES.UniqueID
    Where TRIGGER_POLICY.TriggerByPolicyPath != 0 and OBJECTS.Deleted != 1

    Once you see the results, you can see that it's possible to update the "PolicyObjectID" with the new GUID of the target runbook....but by no means would this be supported.


    • Marked as answer by Jon Mattivi Friday, November 16, 2012 2:25 PM
    • Edited by Jon Mattivi Friday, November 16, 2012 2:32 PM
    Friday, November 16, 2012 2:25 PM
  • I've added a further write up to this issue at the link below....

    http://jmattivi.blogspot.com/2012/12/orchestrator-runbook-migrations-invoke.html

    • Marked as answer by Jon Mattivi Tuesday, December 4, 2012 9:33 PM
    Tuesday, December 4, 2012 9:33 PM

All replies

  • i do not see the same in my Orchestrqtor 2012 RTM environment. I tried different scenarios

    1. Export folder containing both parent and child. In this case the connection between the 2 runbook are always kept

    2. Export single runbook and import them seperately Again. In this case the parent runbook was pointing to the already exiting child runbook and not the new instance fo it that was imported (expected behavoir imho)

    but in none of the cases the invoke by path was checked.

    Are you running the RTM code?

    I dont think the direct to DB method is supported. editing the database is usually not.

    and if the activities are saved by the invoke by path, they might not have GUID for the runbook that they need to invoke, so you would have to both disabled the invoke by path property and figure out what GUID the runbook you are calling


    Best Regards
    Jakob Gottlieb Svendsen
    Trainer/Consultant - Coretech A/S - Blog
    MCT - MCTS - VB.NET - C#.NET - Powershell - VBScript Mastering System Center Orchestrator 2012 - 3 day workshop - worldwide traning click here

    Tuesday, July 3, 2012 8:31 AM
  • Hi Jakob,

    To your two scenarios:

    1)  This is correct

    2)  Sounds like you imported but chose NOT to overwrite existing folders/runbooks.  In that case, yes....it would be expected that the existing connection remain the same.

    If you export/import the child runbook alone (choose to overwrite/keep existing values, not that it matters yet since it doesn't exist....).  Then, export/import the parent runbook alone (choose to overwrite/keep existing values).  In this case, the parent runbook A that was imported points to the already existing Runbook B that already existed.  This is when the "Invoke by Path" is checked upon import.  I also just tested simply unchecking the Invoke by Path afterward, and the parent still invokes the child runbook successfully (which you would think it would fail if the option was checked to make it work).

    Friday, July 6, 2012 1:12 PM
  • I did choose to overwrite.

    but i will try the scenario that you explained asap.


    Best Regards
    Jakob Gottlieb Svendsen
    Trainer/Consultant - Coretech A/S - Blog
    MCT - MCTS - VB.NET - C#.NET - Powershell - VBScript Mastering System Center Orchestrator 2012 - 3 day workshop - worldwide training click here

    Friday, July 6, 2012 1:15 PM
  • I actually had it happen today. I imported a folder of runbooks, and checked to see how things went. One "invoke runbook" activity was set to call a child which was in a different folder, which did not exist in the environment into which I did the import (I hadn't imported anything from that folder, and forgot that's where my child runbook lived).  The Runbook path to the child was still showing in the activity, but since the path didn't exist the "invoke by path" box got checked.

    My guess is if the path to the child runbook doesn't exist during the import, the "invoke by path" box gets checked during the import.

    Wednesday, July 25, 2012 9:15 PM
  • Did you manage to fix the problem ? if no activity, this thread will be closed in 7 days. Feel free to open a new one if needed.

    Christopher Keyaert - MVP - My SCUG.be blog : http://scug.be/blogs/christopher

    Monday, November 12, 2012 8:16 AM
  • The fix to this is ultimately going into each Invoke Runbook activity and selecting the runbook again if it was imported seperately.  The target runbook has a different GUID than the existing runbook that was imported prior.  So changing the path of the target runbook w/o doing anything would break the Invoke Runbook activity when it runs.

    To find all Invoke Runbook activities that have this property set, you can run this SQL query:

    Select POLICIES.Name AS SourceRunbook, TRIGGER_POLICY.PolicyObjectID AS TargetRunbookID, TRIGGER_POLICY.PolicyPath AS TargetRunbookPath, TRIGGER_POLICY.TriggerByPolicyPath, TRIGGER_POLICY.TargetActionServers
    From TRIGGER_POLICY
    INNER JOIN OBJECTS ON TRIGGER_POLICY.UniqueID = OBJECTS.UniqueID
    INNER JOIN POLICIES ON OBJECTS.ParentID = POLICIES.UniqueID
    Where TRIGGER_POLICY.TriggerByPolicyPath != 0 and OBJECTS.Deleted != 1

    Once you see the results, you can see that it's possible to update the "PolicyObjectID" with the new GUID of the target runbook....but by no means would this be supported.


    • Marked as answer by Jon Mattivi Friday, November 16, 2012 2:25 PM
    • Edited by Jon Mattivi Friday, November 16, 2012 2:32 PM
    Friday, November 16, 2012 2:25 PM
  • I've added a further write up to this issue at the link below....

    http://jmattivi.blogspot.com/2012/12/orchestrator-runbook-migrations-invoke.html

    • Marked as answer by Jon Mattivi Tuesday, December 4, 2012 9:33 PM
    Tuesday, December 4, 2012 9:33 PM