Unexpected upgrades

Any time that you deploy a new WAR/EAR file to a PolicyCenter server and restart the server, PolicyCenter assumes that an upgrade is in progress. To prevent the unexpected upgrade of a server, Guidewire requires that you set an upgrade flag in PolicyCenter before starting either a full or rolling upgrade.

Guidewire requires the use of this flag to mitigate the risk of accidentally triggering an unexpected upgrade. However, as a consequence, it is possible to encounter situations in which the PolicyCenter server does not start. In that case, you must undertake a recovery sequence to return the server to a state in which it can start.

Full application database upgrade

For a full database upgrade, Guidewire requires that you first set a database flag to indicate that a full upgrade is in progress. This action signals your intention to perform a full upgrade. After you complete the upgrade of all servers in the cluster, PolicyCenter deletes the database flag automatically. You must set the upgrade flag again before starting a new full upgrade.

It is possible to set the full upgrade in progress flag in the following ways.

PolicyCenter	To set the upgrade flag in PolicyCenter, click Start Full Upgrade in the Server Tools Upgrade and Versions screen.
System tools	To set the upgrade flag through system tools, use the following command option: `system_tools -startfullupgrade` At least one cluster member must be running in order for you to use this option.
Web services	To set the upgrade flag using web services, call the SystemToolsAPI web service method startFullUpgrade. At least one cluster member must be running in order for you to use this option.
Java system property	To set the upgrade flag through a Java system property, use the following system property to set the expected date of the upgrade while starting one of the affected servers: `gwb runServer -Dgw.pc.full.upgrade.intended.date=date` The `date` property is the current date in `yyyyMMdd` format.
File database-config.xml	To set the upgrade flag on server start, set the `autoupgrade` attribute on the `<database>` element in file database-config.xml.

If you encounter a situation in which all cluster members refuse to start because the upgrade flag was not set, you cannot set the upgrade flag through the server. Instead, you must use one of the following methods to start the full upgrade:

Set the upgrade flag using the Java system property.
Set the autoupgrade attribute in file database-config.xml.

Both of these methods provide the necessary permission to perform a full database upgrade of the cluster members.

Rolling upgrade

For a rolling upgrade, Guidewire first requires that you click Start Rolling Upgrade in the Upgrade and Versions screen (on any cluster member). This action signals your intention to perform a rolling upgrade and sets a rolling upgrade in progress database flag. If you do not set the upgrade flag, PolicyCenter refuses to start a rolling upgrade.

After you complete the upgrade of all servers in the cluster, you must click Rolling Upgrade Complete on the Upgrade and Versions screen, which removes the upgrade flag. After you do so, it is not possible start a cluster member running the source (old) configuration.

Guidewire permits a rolling upgrade of the individual members of a PolicyCenter cluster under certain conditions only. In effect, the source (old) configuration and target (new) configuration must be compatible in very specific ways.

Thus, during a rolling upgrade, if you mistakenly deploy an incompatible WAR/EAR file to a PolicyCenter server, you can encounter a situation in which the server does not start. This is true whether you have set the rolling upgrade in progress flag. In this case, remove the incompatible WAR/EAR file and deploy a compatible WAR/EAR file before attempting to restart the server.