Have you ever tried to move a Service Manager Service Catalogue between a test and production lab (or to any new environment) before? By default this is not exactly easy to do… but I have found a free solution to help with this problem. But first “a little back story” on my experience…….
Over the last few weeks I have been heads down building the next release of the labs that I have posted about previously. For anyone who has not read that post, we design, develop, and maintain a demo environment for the technical evangelist community here at Microsoft. This is a virtualized mini-datacenter that has all the core services you would expect in a datacenter (AD, DNS, DHCP, etc), SQL, Exchange, Lync, SharePoint, all the System Center components, and more. What I did not tell you is that we layer on a ton of content for various scenarios and capabilities, one of which is a Service Manager Service Catalogue.
Now for any of you that know me, I don’t usually do things on a small scale. During the design phase for what this catalogue would look like I got a little carried away (yep me really!!), and wound up doing a ton of research to find the best generic catalogue I could come up with. So what did I end up with you may ask?
- 5 Service Offering categories
- 30+ Request Offerings to go in those categories
- Over 100 templates
- Approx. 30 Runbooks in Orchestrator
……….with all the Runbooks associated with Request Offerings in Service Manager. I was really pleased with the efforts. Everything worked as planned, and when I shared it with everyone, they all agreed it was pretty slick! But that’s where this gets interesting…..
Yes I created this awesome catalogue and I documented everything in it, but……. then I had to move it to other builds of the lab for further testing, eventually building it into the final version of the lab to be released to the field. Off I went and packaged up all my custom management packs and my Orchestrator Runbooks with their many many workflows. The new build of the lab was ready and import went perfectly! I now had the catalogue in the new environment!! WooHoo……oops. Nothing actually worked when tested.
So the problem: moving a Service Catalogue to another Service Manager lab is easy, moving one that has connections to Orchestrator Runbooks is not so easy. And I had over 30 of those….
When Runbooks are imported into Orchestrator they have a GUID applied to each Runbook. When the Runbooks are imported into a different environment the GUID is regenerated, thus gets renumbered with a new GUID. My custom Service Manager Management Packs expected a specific GUID that were “known” in the previous environment. As such my connection between Service Manager Request Offerings and Orchestrator Runbooks was completely broken. The issue was evident in the Runbook Templates I had imported into the new lab.
I tried reconnecting the Runbook templates to the proper Runbook thinking that might work but alas in the end figured out I needed to recreate the Runbook Template => and the Request Template it was connected to => and the Request Offering. While I could probably have kluged the Runbook Template back into the other bits, I had made this complex enough to make sure that was not easy.
I needed to find a way to move these custom Runbooks/Management Packs intact easily and quickly. Rebuild time was adding hours to the build of the labs and that just wasn’t acceptable to me.
I knew someone else must have run into a similar need so started looking around and found a solution that is available at no charge from a Microsoft Gold Partner and it was easy, repeatable, in the end saving me a ton of work. Moral of the story is for anyone running into similar issues check out the SCSM & SCO – Management Pack Transfer Tool Beta 2 – Freeware! created by Jakob Gottlieb Svendsen at CoreTech.