Upgrading a Farm in a Distributed Environment

In its simplest form, the process of upgrading a server farm in a distributed environment involves running the Setup Manager on the primary K2 server and selecting Upgrade. Once the primary server is upgraded, the Setup Manager must be run on secondary servers and upgrade selected. Once the server components are upgraded, the K2 for SharePoint Configuration Wizard must be run again. 

There is no need to stop a server before running the upgrade as the Setup Manager will stop and restart the K2 service appropriately. It is important to note that the production environment should not be used during upgrade.

There are varying levels of complexity and the following points need to be taken into consideration. It is recommended that K2 Support should be contacted and be involved in the upgrade procedure.

• If there are database schema changes to be made as part of an upgrade, access to the entire farm should be prevented during upgrade. All access to the production environment must be stopped beforehand to prevent issues during the upgrade. The ideal order would be to upgrade each K2 server one at a time, where the first server will have the database schema upgrade.
• If the servers are only being patched and there will be no changes to the database, it is possible to remove a server from the farm NLB/cluster, upgrade that server and place it back in the farm NLB/cluster and then performing this step on each node in the farm.
• Upgrades should be performed on Development, INT and UAT environments before attempting a live environment with adequate regression testing being performed. This is important when upgrading a number of software versions up from what is currently in use.
• If SharePoint is in the environment, an upgrade time window must also be factored in as the K2 Setup Manager will perform IIS resets and the WSP deployments will stop and restart each web application on each server in the farm.