So I’m in the process of upgrading my lab to System Center 2016 and decided to do some write-ups on some of the issues that I have ran into during the process that might help some of you out there.
For the full upgrade instructions you can refer to the Technet article located here. Since it requires that you uninstall all of Orchestrator I decided to take this opportunity to upgrade my server to 2016 as well. You will also notice that it states Orchestrator should be the first System Center piece that is upgraded.
The first thing I did was make a backup of the DB before I started anything. This was a pretty straight forward install and it took me very little time to get everything back up and running. You will want to check the health of your runbooks before proceeding, making sure nothing important is running or the queue isn’t too high. You can use the Orchestrator health checker for this task. I have a link to this tool in a previous article here.
Since I created a new server for this it did require a few minor changes. I renamed my dev server to SCORCH2016 from SCORCH and since I used the same DB I did need to change the Orchestrator web console to the new server name. You can do this by opening the Runbook Designer under options, choose Orchestration Console and change the name to the new server name. This wont be necessary if you used the same DNS name as the old server. I wanted to keep that server just in case I needed to fall back or run them both at the same time to get some details from the old server without causing conflicts.
When you are doing the install just choose the current Orchestrator DB and all of your runbooks come over with it. You will notice that if you are using any IPs that are not out of the box those will not carry over. You will need to reinstall all of your IPs and redeploy them to the RB servers so take note of the IPs you have installed. Take this time to get the latest 2016 System Center IPs and upgrade those to the latest. You can find those here. You may also want to check with any vendors to see if they have upgraded their IPs to 2016 as well. Don’t fret too much over this. If you are using community IPs that don’t get updated very often they should still work just fine once you install them. I use the data manipulation IP for a lot of my runbooks which hasn’t been updated in a while and it’s still working fine. Once I reinstalled all of the integration packs I was using I reopened the Designer and everything looked good.
The final thing was to create a new connector in SCSM. The one thing I always forget is the proper URL for the web service. This should look as so, http://SERVERNAME:81/Orchestrator2012/Orchestrator.svc/. Oddly it still contains 2012 in the URL. That could be carried over from the DB but I’m not sure on that. When you re-sync your runbooks with the new connector your runbooks come back to life. No duplication or issues with runbooks embedded in currently created RBAs in SCSM. I ran a few test tickets and was back up and running. Pretty easy. I don’t have the weight of an enterprise organization looming over my test lab so I hope you upgrade goes as smoothly as mine.
For those that are starting to venture into OMS automation but have a dreaded feeling of having to recreate all of your runbooks from scratch here is an interesting blog post to settle those fears. The cloud is where everything is going so you better get used to it. Don’t fear though, Orchestrator is not getting deprecated any time soon and still has a big place in the System Center suite.
My next post will be upgrading SCSM to 2016.