Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Making Changes in your JSA Environment


When you make configuration changes to JSA, the changes are saved to a staging area, and the deployment banner on the Admin tab is updated indicating that changes need to be deployed. Deploying the changes might require JSA services to restart.

JSA has two methods of deploying changes: standard and full configuration. The type of deployment that is required depends on the type of changes that were made.

Standard Deployment

This deployment method restarts only those services that are directly affected by the changes that were made. You begin a standard deployment by clicking Deploy changes on the banner on the Admin tab.

The following list shows examples of changes that require a standard deployment:

  • Adding or editing a new user or user role.

  • Setting a password for another user.

  • Changing a users' role or security profile.

Full Configuration Deployment

Changes that affect the entire JSA deployment must be deployed by using the full configuration deployment method. You begin a full configuration deployment by clicking Deploy full configuration from the Advanced menu on the Admin tab.

This method rebuilds all configuration files on each of the managed hosts. To ensure that the new configuration is loaded properly, all services on the managed hosts are automatically restarted, except for the event collection service. While the other services restart, JSA continues collecting events and stores them in a buffer until the managed hosts come back online.

The following list shows examples of changes that require a full configuration deployment:

  • Adding a managed host.

  • Changing the configuration for a managed host.

  • Configuring offsite hosts for sending or receiving data from the JSA Console.

  • Restoring a configuration backup.

Changes that impact Event Collection

Events come into JSA through the ecs-ec-ingress event collection service. Starting in JSA 7.3.1, the service is managed separately from other JSA services. To minimize interruptions in collecting event data, the service does not automatically restart when the hostcontext service restarts.

The following situations can cause an interruption in event collection:

  • Rebooting an appliance that collects events.

  • Adding an HA managed host.

  • During HA failover.

  • Restoring a configuration backup.

  • Adding or removing an off-site source connection.

  • Whenever a partition's disk usage exceeds the maximum threshold.

When you deploy changes after you restore a configuration backup, you can restart the event collection service now or later. When you choose to restart the service later, JSA deploys all changes that don't depend on the event collection service, and continues to collect events while the other services restart. The deployment banner continues to show undeployed changes, and the Event collection service must be restarted message is shown when you view the details.