System Center Orchestrator (SCORCH) is fairly powerful when it comes to automating tasks in your SCSM environment. However, one common task that eludes admins is setting up a dev environment for Orchestrator. It’s tedious to set up a new server for something as resource unintensive as SCORCH. In this blog, we’ll go over an easy method for using a single SCORCH environment to easily handle multiple SCSM environments.
Note: We are assuming that:
- You have an SCSM development environment already set up.
- Your runbooks are calling .NET scripts, probably with SMLETS (but not required) instead of using native Orchestrator runbook activities.
First, I’ll start with my runbook structure. Originally, I have something like this:
Next, I’ll create a new folder for dev.
I could then export and import all of our runbooks into my dev folder. But instead, I’d rather create (or copy) new dev runbooks one at a time since I can mostly only test one at a time. For now, I’ll copy over User Management > Create New Employee.
Now that the new runbook is created, let’s take a look at editing both the .NET script runbook activity, as well as the actual PowerShell. Opening up the .NET script, we see this:
This leaves very little room for determining if this runbook is running against dev or prod. Let’s open up our script and take a look at our parameters.
I’ll have to do some edits to this script. But it’s only sometimes a good idea to dev in prod. So I’ll make a copy of the script.
In my newly-copied dev script, it only prompts for one parameter, the SCSM runbook activity’s ID. I’ll need to add another parameter for the SCSM server. That way, when SCORCH starts this runbook it will always point to our dev SCSM environment.
As noted above, after I added the $scsmServer parameter, I then:
- imported SMLETS, which sets the smdefaultcomputer variable to the SCSM management server, probably production.
- reassigned smdefaultcomputer to the parameterized SCSM server. This must occur after importing smlets.
After my script is updated, I still have to update the SCORCH runbook to use this updated path and parameter.
Next, I can check in this runbook, run my dev SCSM’s SCORCH connector to pull in this runbook, and then update my SCSM Library > Template > RBA Template > Runbook to use the correct dev runbook.
After I confirm that this is correct, I can then copy the
C:\RunbooksDev\Runbook_CreateNewEmployee.ps1 script back into the production
C:\Runbooks\folder, and update the prod SCORCH runbook to point to the production server.
You can pick up additional tips and tricks in the Cireson Community and during our Community Open Floor meetups.
