Cisco Cisco Process Orchestrator 3.0 User Guide

Launch the Process Orchestrator console, then verify and correct the Reporting database configuration 
if needed. This step is required if the Reporting database connection or the Reporting credentials have 
changed.

Install any additional Process Orchestrator servers as new High Availability servers (see the Cisco 
Process Orchestrator Installation Guide). The additional servers will receive the database settings and 
encryption keys from the first server.

Because the Process Orchestrator server is now installed on a different server:

Review the list of Windows targets in the Process Orchestrator, remove the Windows computer 
targets that point to “old” Process Orchestrator servers that are no longer available, and disable the 
old server target in the target definition.

If the Web Server is on a different computer or virtual machine from the Process Orchestrator server 
computer, and if the Web Server survived the outage but the Process Orchestrator servers did not, 
choose File > Environment Properties to verify and update the Web Console configuration file 
location.

Use the Core Functions Adapter properties to review and update the Automation Summary 
configuration.

Choose Administration > Orchestration Servers and remove the old servers.

This section discusses the following topics:

The rules described in this section apply to moving a process from one Process Orchestrator server to 
another server when a single server fails. If server A goes down, then if the process hasn’t stopped on a 
non-restartable activity, it will move to another active server. 

By default, Process Orchestrator persists all data about running processes so that state is preserved 
across service restarts; whether the restarts are planned or unexpected, process and activity states are 
persisted to the Process Orchestrator database. When the Process Orchestrator server shuts down in a 
friendly manner, it allows in-flight activities time to complete, but blocks new activities from running. 
This typically allows activities that might not be marked as restartable to complete so that processes do 
not fail during friendly shutdowns. 

Generally, processes will pick up and start running again after a restart or failure; in some activities, this 
is configurable by the user. Many activities, if they were running when the server shut down, can be 
restarted without any side effects. Some examples:

If an activity is passive (such a configuration query), Process Orchestrator can simply run the query 
again.