Migrated templates lose RB parameter mapping (Orchestrator-related)

Leigh_Kilday

After importing MPs from another environment, a template's RB activities lose their parameter mapping.

A bit of background:
I found a script online to remap Runbook guids for migration and that seems to work well enough after a few tweaks. It uses a direct name resolution, however the nature of Orchestrator Integration Packs requires separate Runbooks for each environment (configuration). This means the names of the Runbooks have to be unique so we have a numbering system to differentiate between environments (e.g. 01.02.05 Runbook Name). I've modified the guid mapping script to match only on the Runbook name and not the numbers.

Thanks to this script there is no longer an invalid guid message on the Runbook tab of the RB, but the prompts are blank and those with no mapping cannot be made active to add text to the field.

What am I missing? I really don't want to have to reconfigure every template with Runbook activities after migration.

Brett_Moffett

You have to keep a single name per connection, per environment.
Having a single Orchestrator environment that connects to several environments (Test, Dev and Prod) there is no way of getting around the issue. 
Only when you have separate Orchestrator environments can you have the same name of a connector.

Does this fix the parameter mapping issue? No.
Parameter mapping is a different issue and that does come back to GUID's.
However, our friends at Coretech have written an amazing script to fix this when you migrate from one environment to another.
http://blog.coretech.dk/jgs/scsm-sco-management-pack-transfer-tool-beta-3-freeware/

Does this answer your question?

Brett_Moffett

Our very own Peter Zerger wrote an article on this back in 2013.
http://www.systemcentercentral.com/tip-managing-orchestrator-global-configuration-settings-across-environments/

In short, the names of the connections are used and not a GUID or other configurable value. So try to keep the connection names generic. (SCSM, ConfigMger, AD, etc.)

Once setup with some naming best practices, you wont have this issue again.

Leigh_Kilday

Great tip. How would you know which instance you're connected to if they're all named identically?

With this implemented, does this still cause issues with losing the parameter mapping when migrating management packs?

This is something I'll have to try tomorrow.

Brett_Moffett

You have to keep a single name per connection, per environment.
Having a single Orchestrator environment that connects to several environments (Test, Dev and Prod) there is no way of getting around the issue. 
Only when you have separate Orchestrator environments can you have the same name of a connector.

Does this fix the parameter mapping issue? No.
Parameter mapping is a different issue and that does come back to GUID's.
However, our friends at Coretech have written an amazing script to fix this when you migrate from one environment to another.
http://blog.coretech.dk/jgs/scsm-sco-management-pack-transfer-tool-beta-3-freeware/

Does this answer your question?

Leigh_Kilday

Thanks Brett!