Rehydration of Control Room cluster to new servers - Windows - This topic describes the steps to migrate an existing high-availability (HA) Control Room cluster, including its primary (PR) and disaster recovery (DR) nodes, to new servers without losing cluster state or historical data.

This topic describes the steps to migrate an existing high-availability (HA) Control Room cluster, including its primary (PR) and disaster recovery (DR) nodes, to new servers without losing cluster state or historical data.

About this task

Rehydration is the process of moving an existing Control Room HA cluster to new PR and DR servers while the Elasticsearch data, Apache Ignite cluster state, and Control Room database configuration are carried over from the old cluster.

Note: This method of installation is currently supported only through manual installation and not on automated installation using scripts (for example, AWS ASG).

Before you begin

Review and complete the following before you begin. This procedure requires downtime for both the PR and DR clusters.

Infrastructure
- Six new virtual machine (VM)s provisioned (three for HA and 3 for DR).
  New PR and DR servers are provisioned, networked, and reachable from the existing Control Room database server.
- Firewall rules and ports opened as per Control Room installation guide.
- DNS resolution validated between all nodes
- Node mapping between existing and new servers is documented, for example:
  - Existing PR Node 1 → New PR Node 1
  - Existing PR Node 2 → New PR Node 2
  - Existing PR Node 3 → New PR Node 3
  - Existing DR Node 1 → New DR Node 1
  - Existing DR Node 2 → New DR Node 2
  - Existing DR Node 3 → New DR Node 3
- System time synchronized (NTP).
Certificates
- SSL certificates created
- SAN entries include new server hostnames or IPs.
Backup (mandatory)
Note: Do not proceed without completing all backups.
- Control Room database backup is complete.
  C:\ProgramData\AutomationAnywhere\elasticsearch and C:\Program Files\Automation Anywhere\Automation360\elasticsearch.
- Saved a screenshot of the Audit logs page.
- Virtual machine (VM) snapshots of all existing PR and DR nodes.
- Capture and record Elasticsearch (ES) health from old cluster:
  - GET _cluster/health
  - GET _cat/nodes?v
  - GET _cat/shards?v
Access
Ensure that you have administrator access to all existing and new servers, and access to the Control Room database to run SQL statements.

Procedure

Stop services on the existing cluster.
1. On all three existing PR servers and all three existing DR servers, stop all Control Room services, including Elasticsearch.
2. Set the startup type for those services to Manual.
  This prevents the services from starting automatically if a server restarts during the migration.
Copy the Elasticsearch data to the new servers.
Copy the entire folder from each existing node to its mapped new node, according to the node mapping documented in the prerequisites:
```
C:\ProgramData\AutomationAnywhere\elasticsearch
```
Preserve the folder structure and file permissions during the copy.
Clear the Elasticsearch cluster state on each new node.
1. On each new node, navigate to C:\ProgramData\AutomationAnywhere\Elasticsearch\data\nodes\0\.
2. Delete the _state folder.
Note: This step is critical. It removes the old cluster metadata and forces the new servers to form a new cluster.
Truncate the Ignite cluster table.
Connect to the Control Room database and run the following SQL statement to clear the stale cluster node registrations so that Control Room does not retain the old cluster topology:
```
TRUNCATE TABLE IGNITE_CLUSTER;
```
Update the Elasticsearch configuration in the database.
Run the following SQL statements to point the cluster at the new first nodes. Replace IP_ADDRESS_OF_FIRSTNODE with the IP address of new PR Node 1, and replace DRFIRSTNODEIP with the IP address of the new DR Node 1:
```
UPDATE ES_SETTINGS SET value = 'IP_ADDRESS_OF_FIRSTNODE' WHERE attribute = 'first_node_ip';
UPDATE ES_SETTINGS SET value = 'DRFIRSTNODEIP' WHERE attribute = 'first_backup_node_ip';
```
Install Control Room on the new PR cluster.
Install the nodes in sequence — Node 1, Node 2, and then Node 3. After each node installation completes, stop all services on that node except Elasticsearch.
- Point the installer to the existing Control Room database. The installer does not prompt for Elasticsearch details.
- In the cluster configuration step, enter the new node IP addresses as described in the official installation guide.
- Enter every other configuration value manually so that it exactly matches the previous installation or updated on the old cluster. The only value that changes in the installer is the new cluster node IP address.
After you complete the installation on all three PR nodes, run the following command from any node to confirm cluster health:
```
GET _cluster/health
```
Confirm that the response shows:
```
{
  "status": "green"
}
```
Run the following commands for additional verification:
- GET _cat/nodes?v
- GET _cat/allocation?v
- GET _cat/shards?v
Note: Do not proceed to the next step until the cluster status is green.
Install Control Room on the new DR cluster.
Repeat the previous step — installation, service startup type, and Elasticsearch health checks — on the three new DR servers.
Start Control Room services on the new cluster.
After the Elasticsearch health check is successful on both the new PR and new DR clusters, start all Control Room services on all six new nodes.

The Control Room HA cluster is running on the new PR and DR servers, with the Elasticsearch data and Apache Ignite cluster state carried over from the old cluster

What to do next

Complete the following validations:

All Control Room services are running on all six new nodes.
You can log in to Control Room and existing automations, users, and roles are visible.
You can execute a sample automation successfully.
Historical audit logs are available, and new audit log entries are generated after rehydration.