Configuration Deployment

Central Administration enables users to quickly update all modified servers by deploying all servers for which the user owns the lock with one action. In other words, the deploy action deploys every EMS server locked by the current user.

Note: The Central Administration server does not automatically update its configuration snapshot for an EMS server. If configuration changes were made directly to the EMS server, such as through API calls, you should refresh the server configuration in Central Administration before deploying. See Refreshing the Server Configuration for details.

Permission Requirements

To deploy, the current user must have administrative credentials for each EMS server in the deployment. If you do not have adequate permissions to modify an EMS server, the deployment of that server fails.

If the user who owns the lock does not have the necessary permissions to deploy the changes, another user with administrative permissions can take the lock and deploy. See Take the Lock for more information.

Deployment Errors

Deployment of an EMS server fails if the Central Administration encounters any errors while connecting to and updating the server. Errors include:

  • Failure to connect to the EMS server.
  • Inadequate permissions for the user initiating the deployment.
  • Invalid settings in the new EMS server configuration.
  • The configuration currently held by the EMS server was modified either through the Administration Tool or the administration API.

Each deployment can affect a number of EMS servers, but there is no dependency between the servers. That is, some EMS servers may deploy correctly while some fail. Those servers that did not deploy can attempt redeployment later. The server lock file remains in its edited state.

Deployment Results

Following a deployment, you can check its status in the deployment log. Review the status of each server:

  •   Deployment succeeded.
    • The server accepted the changes.
    • All changes have been activated.
  •   Deployment succeeded. Restart required.
    • The server accepted the changes.
    • The server requires a restart to activate the changes.
  •   Deployment failed.
    • The server rejected the changes.
    • Central Administration could not connect to the server.

Because deployment succeeds or fails for each EMS server individually, deployment results may differ for each server. If deployment to an EMS server fails, that server remains locked and editable by the user.

Warning: Fault Tolerant Configurations

When a server that is a member of a fault-tolerant pair requires a restart, both servers must be restarted to activate the change. When the active server of the fault tolerant pair is shut down, the standby server does not reinitialize its properties (such as listens, heartbeats, timeouts, and so on) during activation. It does reinitialize objects such as queues, topics, factories, routes, and so on. It also takes into account the addition, deletion, or modification of stores of type File Store.

The correct sequence when a deployment requires a restart is to:

  1. Shutdown the active server.
  2. Let the standby fully activate.
  3. Restart the server shutdown in Step 1.
  4. Let the restarted server reach the standby state.
  5. Shutdown the server activated in Step 2.
  6. Let the standby fully activate.
  7. Restart the server shutdown in Step 5.

If restart can wait until a period when the servers can both remain offline for the recovery period, shutdown both servers and restart them simultaneously. In the particular case of the addition or deletion of stores of type File Store, only steps 1 to 3 are necessary.