Home› Lifecycle Management app

Migrating Runbook Activity Templates

Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭
in Lifecycle Management app

What is the best practice for migrating the Runbook Activity templates between a dev and prod environment using the Lifecycle Management app? I currently have two environments set up, one for development and one for production. In each environment I have a SCSM and SCO server and used the same connection name in SCO for connecting to SM but used different server names to correspond to the environment it was in (i.e. Prod-SM01.domain and Dev-SM01.domain). The SCO connectors for each environment are set up to pull from the servers in their environment but the runbook names and folders are the same.

The problem I'm having is when I import the runbooks from SCO in the dev environment, SCSM sees them as different runbooks so all of my existing runbook activity templates that were migrated from the prod environment break. I'm assuming this is because they have different GUIDs after being re-synced. Is there a better way to handle this behavior or am I just stuck with rebuilding all my runbook activities every time I use the Lifecycle app?

Best Answer

  • Chris_Chekaluk1Chris_Chekaluk1 Customer Advanced IT Monkey ✭✭✭
    Answer ✓

    I've configured RB connectors in our dev & prod SCSM environments to point to the same folder structure in SCO (therefore the RB guid is the same in both SCSM environments). Basically the only logic in this runbook is to determine the environment and then invoke the business logic for the appropriate environment.

    I also wrote a separate function runbook that determines the environment. This basically takes the RBA's guid as input, and then uses SQL Query activity to first check the dev environment's BaseManagedEntity table for the guid, if not found, then check the prod environment.

    At runtime, the RBA (in either prod or dev) will invoke the same runbook, which checks the environment, and then invoke a separate runbook for the business logic that targets either dev or prod SCSM.

Answers

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭

    @Brad_Zima, I don't have a current Orchestrator environment to look at, but I do have an RBA template in a Management Pack. It looks to me like the only thing you would need to change would be the Runbook Id in the template (probably the RBA template AND any SR templates using the RBA). What I would do in this situation - and maybe it's cumbersome and ugly, but it's what I would do - is the following all in powershell:

    1. Get the new Runbook Id
    2. Locate the Template
    3. Get the Management Pack for that Template and Export it to the file system
    4. Parse the XML in that file to change the Runbook Id to the new Runbook Id and increment the MP version
    5. Re-import the Management Pack
  • Peter_MiklianPeter_Miklian Customer Advanced IT Monkey ✭✭✭

    @Brad_Zima have a look at these articles which may help you:

    1. System Center 2012 SP1 - Orchestrator: Exporting and Importing Runbooks
    2. TIP: Managing Orchestrator Global Configuration Settings Across Environments
    3. Consider Invoke Runbook activities when doing a runbook update
  • Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭

    @Justin_Workman Is this the same behavior that the Lifecycle management app does? Except in my case the runbooks are on a different Orchestrator server so would the Lifecycle app be able to re-link them? The names of the runbooks are the same and have the same folder structure if that makes a difference.

  • Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭

    @Peter_Miklian Those articles aren't giving me much hope that I'll be able to achieve what I want. I essentially want to be able to develop and test runbooks against my Service Manager development environment without having to update all the activities when I promote to the production environment.

  • Peter_MiklianPeter_Miklian Customer Advanced IT Monkey ✭✭✭

    @Brad_Zima sorry, I didn't read your first post carefully. You are syncing Orchestrator runbooks to SCSM...

    We don't use this synchronization. Every automation takes place exclusively in the Orchestrator. Monitoring runbooks catch SCSM item changes and invoke other runbooks so our SCSM doesn't need to know about any Orchestrator existence and switching runbook execution between test and prod environment would mean only to change SCSM server connection and some variables.

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭

    @Brad_Zima - No. I don't believe LMA will change the MPs that point to the runbooks. It will just migrate them as they are. And honestly, I'm not sure the above process will work, but it's at least something to try.

  • Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭

    @Justin_Workman Here is an excerpt from the Lifecycle app manual which I think describes what you are suggesting, I just don't know how it knows to match up the runbooks. Since I am using the same folder and naming structure I'm hoping it will work.

    image.png


  • Dijon_BleaseDijon_Blease Customer IT Monkey ✭

    @Brad_Zima, @Justin_Workman approach is basically how we handled it for our environment. Not sure how many runbooks you have, but I did write a PowerShell script that updates the fields in the management pack for us. Just a small snippet of how we handled it to get you started.

    Using Smlets, get the runbook items for the source (where the RBs migrated from) and target location (where the RBs migrated to). Next, we got the source and target runbook items' template objects. 

    $source_rb_items = foreach ($rb in $rb_items) { (Get-SCSMObject -Class $sou_rb_item_class -SCSMSession $source -Filter "Displayname -eq '$($rb.DisplayName)'") }


$source_obj_tpls = foreach ($source_rb in $source_rb_items) {
                                                                                                           
                        Get-SCSMObjectTemplate -SCSMSession $source | ?{([xml]$_.GetXML()).SelectNodes("//ObjectTemplate[contains(@TypeID,'ServiceRequestProjection') or contains(@TypeID,'Incident.Projection') ]//Property[contains(text(),'$([guid]$source_rb.Id)')]") }            
                     }


$target_obj_tpls = foreach ($tpl in $source_obj_tpls) { 
                        
                        Get-SCSMObjectTemplate -Id $tpl.Id -SCSMSession $target
                   }

    You then have to find all of the runbook activity nodes in the template's management pack. This can easily be done by doing using "selectnodes". 

    $rb_act_nodes = $mp.SelectNodes("//ObjectTemplate[@ID='$($target_tpl.Name)']//Object[contains(@Path,'RunbookAutomationActivity')]")

    The goal is to match the the runbook from one environment to the other and update the following properties for that node: PropertyMapping and RunbookId.

    The target runbooks' information most likely matches the source runbook information. By using the LMA tool, the runbooks were migrated from our QA (source) environment to our Dev (target) environment. Everything matched but the GUIDs. So, this affects the template mapping.

    By using smelts, you can query the source runbooks to find the runbook that matches the one migrated to the target site. 

    $source_rb = Get-SCSMObject -Class $sou_rb_item_class -Filter "Id -eq $($rb_old_id.ToString().replace('-',''))" -SCSMSession $source

    Or, if you simply already have the information, you can just do:

    Get-SCSMObject -Class (get-scsmclass -name 'Get-SCSMClass -Name Microsoft.SystemCenter.Orchestrator.RunbookItem') -Filter "Name -eq $($source_rb.Name)" -SCSMSession $target

    This will get the runbook item on the target server, and this will provide the information you need to update the management pack (ex. the runbook id). You can update the xml manually or use powershell to do it for you. Save the management pack changes and import it.

    Note: This isn't the whole script. Just chunks of it to give a general idea how to use PowerShell to update these items.

  • Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭

    Thanks guys, I was hoping there would be an easier solution out there for moving runbooks from dev to prod but I guess this will have to do. I'll see if I can get something cobbled together in the next few days.

  • Chris_Chekaluk1Chris_Chekaluk1 Customer Advanced IT Monkey ✭✭✭
    Answer ✓

    I've configured RB connectors in our dev & prod SCSM environments to point to the same folder structure in SCO (therefore the RB guid is the same in both SCSM environments). Basically the only logic in this runbook is to determine the environment and then invoke the business logic for the appropriate environment.

    I also wrote a separate function runbook that determines the environment. This basically takes the RBA's guid as input, and then uses SQL Query activity to first check the dev environment's BaseManagedEntity table for the guid, if not found, then check the prod environment.

    At runtime, the RBA (in either prod or dev) will invoke the same runbook, which checks the environment, and then invoke a separate runbook for the business logic that targets either dev or prod SCSM.

  • Geoff_RossGeoff_Ross Cireson Consultant O.G.

    Chris, thats nice. So you only have 1 SCOrch env that serves Dev and Prod, rather than 2?

Sign In or Register to comment.