--- title: Promoting the replica administrative node description: If the primary administrative node fails, promote the replica admin node to the primary admin node. component: pingaccess version: 9.0 page_id: pingaccess:reference_guides:pa_promoting_the_replica_admin_node canonical_url: https://docs.pingidentity.com/pingaccess/9.0/reference_guides/pa_promoting_the_replica_admin_node.html revdate: December 8, 2025 section_ids: about-this-task: About this task manually-promoting-the-replica-administrative-node: Manually promoting the replica administrative node about-this-task-2: About this task steps: Steps next-steps: Next steps using-the-admin-api-to-temporarily-promote-the-replica-admin-node: Using the admin API to temporarily promote the replica admin node steps-2: Steps example: Example: next-steps-2: Next steps --- # Promoting the replica administrative node If the primary administrative node fails, promote the replica admin node to the primary admin node. ## About this task The replica admin node is intended to be used for disaster recovery. If you can recover the clustered console, you should focus on recovery rather than failing over to the replica admin node. | | | | - | -------------------------------------------------------------------------------- | | | Only one primary admin node should be running for the cluster at any given time. | Promote the replica admin node manually by making file system changes, or, in DevOps environments, use the replica admin API to temporarily promote the replica admin node. * Manual promotion * Temporary admin API promotion ## Manually promoting the replica administrative node ### About this task To promote the replica admin manually: ### Steps 1. Open the `/conf/run.properties` file in a text editor. 2. Locate the `pa.operational.mode` line and change the value from `CLUSTERED_CONSOLE_REPLICA` to `CLUSTERED_CONSOLE`. These properties are case-sensitive. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | Do not restart the replica node during the promotion process. PingAccess can detect and apply this change without a restart, and restarting the node during its promotion can cause file corruption or failure to promote correctly. | ### Next steps Complete [Reinstating a replica administrative node after failing over](pa_reinstating_a_replica_admin_node_after_failing_over.html). ## Using the admin API to temporarily promote the replica admin node Use this method to promote the replica admin node to the primary admin node without requiring file system changes. | | | | - | --------------------------------------------------------------- | | | This promotion method is intended for DevOps environments only. | ### Steps 1. Sign on to the replica admin PingAccess system and start a non-Internet Explorer (IE) browser. 2. Go to the API doc page at https\://*\*:*\*/pa-admin-api/v3/api-docs/index.html and sign on. #### Example: https\://localhost:9005/pa-admin-api/v3/api-docs/index.html | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | You can use the **POST /adminConfig/replicaAdmin/status** endpoint to check the status of the replica admin. For example, you can review the node's identifier and check the last time its configuration was modified. | 3. Click and expand the **/adminConfig** section, then expand **POST /adminConfig/replicaAdmin/promote**. This endpoint is only available on the replica admin server, and only if the primary server is unavailable. 4. Fill out the configuration as necessary: | Property | Description | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `editRunPropertyFile` | If set to `true`, the admin API changes the value of the `pa.operational.mode` property from `CLUSTERED_CONSOLE_REPLICA` to `CLUSTERED_CONSOLE` in the `run.properties` file. | | `editPrimaryHostPort` | If set to `true`, the admin API updates the primary admin node's configuration with the promoted replica admin node's **host:port** value. | | `editPrimaryHttpProxy` | If set to `true`, the admin API updates the primary admin node's configuration with the promoted replica admin node's **HTTP Proxy** value. | | `editPrimaryHttpsProxy` | If set to `true`, the admin API updates the primary admin node's configuration with the promoted replica admin node's **HTTPS Proxy** value. | 5. Click **Try it out**. ### Next steps | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | Changes last until you restart the promoted node. If you want the promoted replica node to remain the primary admin node, complete the [Manually promoting the replica administrative node](pa_manually_promoting_the_replica_admin_node.html) procedure after restarting the promoted node. Then complete [Reinstating a replica administrative node after failing over](pa_reinstating_a_replica_admin_node_after_failing_over.html).Otherwise, the promoted replica node will return to being the replica admin node. |