By default System Center Orchestrator 2012 (event R2 latest CU), Run .Net Script activity will launch PowerShell in v2 and x86 mode. But nowadays, the Orchestrator runbook service is installed on Windows Server 2012/Windows Server 2012 R2 or even Windows Server 2016 who used natively at least Powershell v3 and above. Besides a lot of useful modules and cmdlets are implemented in PowerShell v3 and above.
In fact, you can already get around the problem by running the script remotely on another server or an instance of PowerShell shell using: PowerShell {Your Script}, but in both cases, we loose the possibility to publish all variables to the data bus.

In order to change this, if the server executing the Orchestrator runbook service use PowerShell v3 or above, you can change a registry value to use the same version in your activity.

The registry value OnlyUseLatestCLR, that needs to be equal to 1 as above (0 by default) is located:

To apply the changes you don’t even need to restart Orchestrator services. In fact, you can verify that change has occurred by running this activity in a runbook.

To continue series about how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them, in this article we will focus on System Center Orchestrator.

• System Center Virtual Machine Manager
• System Center Operations Manager
• System Center Service Manager
• System Center Data Protection Manager
• System Center Configuration Manager

Unlike Virtual Machine Manager, you can’t install Orchestrator service as a Failover Cluster role. For remember, Orchestrator is composed of several role and services.

• Management Server: The management server is the communication layer between the Runbook Designer and the orchestration database.
• Runbook Server: A runbook server is where an instance of a runbook runs. Runbook servers communicate directly with the orchestration database. You can deploy multiple runbook servers per Orchestrator installation to increase capacity and redundancy.
• Orchestration Database: The database is a Microsoft SQL Server database that contains all of the deployed runbooks, the status of running runbooks, log files, and configuration data for Orchestrator.
• Runbook Designer: The runbook designer is the tool used build, edit and manage Orchestrator runbooks.
• Runbook Tester: Runbook tester is a run-time tool used to test runbooks developed in the Runbook Designer.
• Orchestration Console: The Orchestration console lets you start or stop runbooks and view real-time status on a web browser.
• Orchestrator Web Service: The Orchestrator web service is a Representational State Transfer (REST)-based service that enables custom applications to connect to Orchestrator to start and stop runbooks, and retrieve information about operations by using custom applications or scripts. The Orchestration console uses this web service to interact with Orchestrator.

In order to make your Orchestrator infrastructure highly available you will have to:

• Install multiple runbook servers.
• Install the Orchestrator Web Service on multiple web servers in a Load-balanced configuration.
• Deploy the Orchestrator database on a SQL Server Failover Cluster (or highly virtual machine).
• You cannot deploy multiple Management Servers. When the management server is unavailable, you will be unable to publish new runbooks. You will be able to start, stop, and monitor existing runbooks using the Orchestration console.

Backing up Orchestrator involves backing up the following elements (You can learn more about backing up Orchestrator here):

• Backup of the Orchestrator database (which stores runbooks)
• SQL instance service master key (database uses encryption)
• File backup of the Orchestrator management server (ensure that settings.dat file is backup, it allows Orchestrator program files to access the Orchestration database)
• File backup of each runbook server
• File backup of each Orchestrator web server (ensure that web.config files are being protected)

In order to recover your Orchestrator infrastructure from backups:

• If you are restoring the same database server from which the backup was taken, and the service master key has not changed, simply restore the backup.
• If you are restoring to a different database server with a different service master key, or you are restoring to the same database from which the backup was taken but the service master key has changed, the service master key must be restored to match the one used during the database backup. Use this SQL query

• Restore the database from the backup.
• On the Orchestrator Management Server, run the Data Store Configuration utility from the Start menu or use settings.dat file, and restart the Management Service.
• On each Runbook Server, run the Data Store Configuration utility, and restart them.
• On each Orchestrator Web Server run the following command (assuming your using default installation path)

• Then you need to open up Connection Strings in Orchestrator 2012 virtual application (IIS Manager) and modify Orchestrator Context. Locate the segment that starts with “provider=System.Data.SqlClient;provider connection string” and then modify the Data Source and Initial Catalog attributes according to your new SQL Server and Database Catalog name respectively.
• If you want to re-encrypt the connection strings, you can execute the following at the command prompt