Chapter 4. Upgrading JBoss ON Servers and Storage Nodes

It is not possible to revert your JBoss ON server to the previous version after it is upgraded. Back up all data before upgrading.

There will be a minimal loss of monitoring data because of the downtime required when the server and agents are being upgraded. Additionally, any monitoring data for the JBoss ON server will be lost, if the server is included in the inventory.

The JBoss ON servers must be upgraded before the JBoss ON agents can be upgraded.

When an agent is upgraded, any files with the .sh or .bat extension found in the agent's /bin directory will be copied to the new agent's /bin directory.

Upgrading the JBoss ON server essentially creates a new server instance that replaces the old instance. If the JBoss ON server was added to the inventory, then the old JBoss ON server resource must be deleted from the inventory because it will not be a usable resource after upgrade. Once the upgrade process is complete, then the JBoss ON server must be added to the inventory again and all of the previous configuration for that resource (like alerts, scheduled operations, and group membership) must be redone.

All JBoss ON servers in the high availablity cloud must be stopped when one is upgraded. Otherwise, the installer will hang when it tries to contact the database and the database is unavailable because it is in use by another JBoss ON server.

Do not copy the new server installation on top of a previous server installation.

On Windows. When configuring JBoss ON servers as services on Windows, it was possible to set the RHQ_SERVER_RUN_AS parameter without setting a password. In JBoss ON 3.3, the RHQ_SERVER_PASSWORD parameter is required with the RHQ_SERVER_RUN_AS parameter.

On Windows. Users who wish to update the Java implementation from 32 bit to 64 bit on a Windows service running JBoss ON are required to uninstall and re-install that Windows service. For more details on this process, see steps 2 and 3 in Section 5.2, “Uninstalling the Server”.