Some time ago Anders wrote a great blog post (http://contoso.se/blog/?p=2423) on how to move your Orchestrator database. However, with the release of System Center 2012 Orchestrator, some of this information has changed. This post is an updated version for the Orchestrator 2012 installations.

1. Stop all running runbooks. You can find a quick list of running runbooks by executing the query below against your Orchestrator database.
   select P.Namefrom POLICYINSTANCES i       inner join POLICIES p on i.PolicyID = p.UniqueIDwhere status is null
2. Stop the following services on your management server:
   1. Orchestrator Management Service (omanagement)
   2. Orchestrator Remoting Service (oremoting)
   3. Orchestrator Runbook Server Monitor (omonitor)
3. Stop the following service on your runbook servers:
   1. Orchestrator Runbook Service (orunbook)
   2. Orchestrator Remoting Service (oremoting)
4. Since the Orchestrator database uses a Master key, we must move the database along with the key. On your current SQL Server, open SQL Server Management Studio and open a new query window. Execute the two scripts below to create a migration password, and to drop the master key. Be sure to update the script to match your database’s name, and a better password.
   use Orchestratorgoalter master keyadd encryption by password = ‘password’go  use Orchestratorgoalter master key drop encryption by service master keygo
5. Now you can migrate your SQL database to the new SQL server using either the Backup and Restore, or detach and attach method.
6. Once the database is restored on the new SQL server, you will need to restore the master key, and drop the migration password. Open a new query window in SQL Server Management Studio, and execute the queries below.
   use Orchestratorgoopen master key decryption by password = ‘password’alter master key add encryption by service master keygo  use Orchestratorgoalter master keydrop encryption by password = ‘password’go
7. On the new SQL server, in SQL Server Management Studio, expand the Orchestrator database then Security > Users. Right click on your management service account and select Script User as > DROP To > New Query Editor Windows. Execute the query that is generated. Do this for the runbook service account also.
   
8. Navigate to Security, and right click on Logins and choose New Login.
9. In the Login – New window General page, add the login name for your management service account, and set the Default Database to your Orchestrator database.
   
10. On the User Mapping page, select the check box next to your Orchestrator database, and add the roles listed below
    1. Microsoft.SystemCenter.Orchestrator.Admins
    2. Microsoft.SystemCenter.Orchestrator.Operators
    3. Microsoft.SystemCenter.Orchestrator.Runtime
    4. public
    5. db_owner (only required for the account running the IIS application pool)
11. Click OK
12. Repeat steps 7-10 for you Runbook service account
13. On your Management server, open the Orchestrator Data Store Configuration
14. Enter your new SQL server and Authentication method and click Next
    
15. Select Use an existing data store, select your Orchestrator database and click Finish. If you receive a warning about the data store already exists click Yes.
    
    
16. Repeat steps 12 through 14 on each of your runbook servers.
17. Restart all services on your management and runbook servers.
18. Open the Runbook Designer. If everything looks good, continue on to update the Web Service connection.
19. On the server running your Orchestrator Web Service open an administrative command prompt.
20. Execute the command below based on your version to decrypt the Web.Config file:Orchestrator 2012 RTM and SP1
    C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pdf “connectionStrings” “C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012”
    
    Orchestrator 2012 R2
    C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pdf “connectionStrings” “C:Program Files (x86)Microsoft System Center 2012 R2OrchestratorWeb ServiceOrchestrator2012”
21. Open IIS and navigate to the Microsoft System Center 2012 Orchestrator Web Service site
22. Expand the site and click on Orchestrator2012, then Double click on the Connection Strings feature
    
23. Double click on OrchestratorContext
24. In the custom box, change the Data Source to the new SQL Server, and click OK.
    
25. Close IIS
26. Execute the command below, based on your version, to encrypt the Web.Config file:Orchestrator 2012 RTM and SP1
    C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pef “connectionStrings” “C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012”
    
    Orchestrator 2012 R2
    C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pef “connectionStrings” “C:Program Files (x86)Microsoft System Center 2012 R2OrchestratorWeb ServiceOrchestrator2012”
27. Connect to your Orchestrator web console to ensure that it is working.

Note that this post is provided “AS-IS” with no warranties at all. As always I recommend making full backups of your environment prior to making any major changes.

When using the Restart System activity in Orchestrator, the activity exits once the restart command has been sent to the remote system. When using this activity alone, there is no way to know if the system rebooted successfully. However, using a few other activities and some looping, you can make the runbook wait while the server is rebooting. In this example I made a runbook that I can pass a system name to, and have it return whether or not system successfully rebooted. I have provided the details on how to make this runbook below.

1. Create a new runbook and open the Properties window.
2. Navigate to the Returned Data tab and create a definition named “result”
   
3. Initialize Data: Create a parameter named “Server”
   
4. Restart System: Computer is set to the Server parameter from Initialize data. Set all other options to your preferences
   
5. Get Computer/IP Status (renamed to Wait for Reboot): Computer is set to computer from Restart System
   
6. Looping: Right click on Wait for Reboot and select Looping. Check Enable and set delay between attempts (in seconds). On the Exit tab you are first going to select Wait for Reboot returns warning or failed. This will cause this activity to continue to run as long as the runbook is able to ping the server, meaning it has not started to reboot yet. Once the server reboots, the activity will not be able to ping the system. This will return a failure, and in turn exit the loop. Also, you will want to create a fail safe exit condition incase the server does not reboot. Click Add to add an additional condition. Set this condition to Loop: Number of attempts from Wait for Reboot equal 300. This will make the activity exit if your system does not reboot in 5 minutes. Remember you have to select Show common Published Data to get the return information for the Loop.
   
7. Success Link: In this case since the server being offline is the desired result, a failure is considered a success. Therefore you need to set the link between the Wait for Reboot and Wait for Post Boot to continue on warning or failed. Then on the exclude tab set the condition for Loop: Total duration from Wait for Reboot is greater than or equal to 300.
   
8. Failure Link: If the server does not reboot in 300 seconds (5 minutes) then it will be considered a failure. For this, create a second link to the Return Failure activity and set it to include Loop: Total duration from Wait for Reboot is greater than or equal to 300
   
9. Get Computer/IP Status (renamed to Wait for Post Boot): Computer is set to computer from Wait for Reboot
   
10. Looping: Just like the Wait for Reboot activity, Looping will need to be enabled for the Wait for Post Boot activity. However, this time we will exit on success or a loop duration of 600 seconds (10 minutes). The logic behind this, is when the Wait for Reboot activity fails, the system has started to reboot and the runbook will continue to the Wait for Post Boot activity. Then, once the operating system starts back up again, Orchestrator will be able to ping the system and the Wait for Post Boot will be successful.
    
11. Success Link: On the include tab you can leave the default Wait for Post Boot returns success. Then on the exclude tab set the condition for Loop: Total duration from Wait for Reboot is greater than or equal to 600.
    
12. Failure Link: If the server does not come back online in 600 seconds (10 minutes) then it will be considered a failure. For this, create a second link to the Return Failure activity and set it to include Loop: Total duration from Wait for Reboot is greater than or equal to 600
    
13. Return Data (renamed to Return Success): Set result to success
    
14. Return Data (renamed to Return Failure): Set result to failure
    

And there you have it. You can now use the Invoke-Runbook activity for any other runbook where you need to reboot a system, and wait for it to come back online. Keep in mind when invoking this runbook you should check Wait for completion.