Requirements

The following requirements must be met for the incremental upgrade process to work correctly and not impact the functioning deployment.

1. To perform an incremental upgrade to v8.5, all components in your deployment must be at v8.1 or later.

   To perform an incremental upgrade to v8.5.3, all components in your deployment must be at v8.2 or later.

   To perform an incremental upgrade to v8.5.4, all components in your deployment must be at v8.4 or later.

   To perform an incremental upgrade to v8.5.5, all components in your deployment must be at v8.5.3 or later.

2. Back up your current deployment, including the Log Database, before you begin the upgrade process.
3. Stop all Log Servers and stop all Log Database jobs. This is to avoid any problems during the database upgrade.

   The Log Database upgrade occurs when the first Log Server instance is upgraded. During the upgrade process, the Log Database version is checked. If the database has not yet been updated, the upgrade will attempt to stop any jobs that are still running. Any jobs that cannot be stopped will need to be stopped manually.
   When the database update is complete, the upgrade process will attempt to re-start all Log Database jobs. Any Log Database jobs that were not automatically restarted and all Log Server instances can be restarted.

4. Upgrade the primary Policy Broker machine first.
5. In distributed Log Server deployments, upgrade the central Log Server first. This will allow logging to continue uninterrupted. Log data sent from the remote Log Server instances will continue to be processed.

   If your configuration is set up so that a remote Log Server is upgraded first, cache files sent to the central Log Server may not be in a recognized format and, therefore, not sent to the Log Database. To avoid interrupting the logging process, before upgrading the remote Log Server, do one of the following:

   1. If the central Log Server has not been upgraded, configure each remote Log Server to be a standalone Log Server (which will send log data directly to the Log Database).

      Set up the distributed environment after the central Log Server is upgraded.

   2. During the upgrade process, configure all Filtering Service instances to send log data to a Log Server with the same or newer version.
      Note: A Log Server that has been upgraded can receive and log data from a Filtering Service that has NOT been upgraded. A Log Server that has not been upgraded, however, cannot receive log data from an upgraded Filtering Service. Be sure to upgrade Log Server if an associated Filtering Service is upgraded.

      Although distributed logging continues to be supported, note that, after all Log Servers have been upgraded, each can now be directly connected to the Log Database. Support of multiple Log Servers all connected to the same database is offered.

6. Once the upgrade of the primary logical deployment has started, the upgrade process for that logical deployment must be completed prior to making any changes that would impact the Policy Database.

   For example, after upgrading the primary Policy Broker and primary Policy Server, do not run the Management API to create new categories or make policy changes prior to upgrading the management server machine and Log Server.

All components on a machine are upgraded at the same time. You cannot select specific components for upgrade.