Does this site look plain?

This site uses advanced css techniques

The Evolution™ payroll service-bureau software from iSystems, LLC is updated regularly to fix bugs and to reflect changes in tax/HR law, and these updates must be applied by Evolution licensees as needed. Patches are released several times a month.

Table of Contents

Notice of a new release is sent to the evolution-announce mailing list, and the updates themselves are posted on the support website (iSystems-provided credentials required) for download. This document describes the procedure for applying these updates.

We'll note that this is not the only way to perform this task, but it's a process we've been refining for years, and has worked quite well.

Furthermore, this is only for the routine patch updates: we're not touching on the much more substantial major version upgrade procedures here.


Overview of the update process

iSystems releases two kinds of patches:

SYSTEM database
This is a compressed backup of the SYSTEM.gdb database, and it contains static database tables, tax rates, reports, and the like. The file is unzipped after download, and then restored into the production database.
These files are named like system_17.09.00.02.zip .
These are often called "Snap" releases.
Application Version ZIP
This is a ZIP file containing what amounts to application program code (in the form of .DLLs and .EXEs), and these are virtually always accompanied by a SYSTEM database at the same time: these are more substantial updates and can be quite large.
These files are named like 17.09.00.11.zip.
Though it's possible to download this file directly, we typically recommend using the Evo Management Console to do this; see [later section]. This file is never unzipped.

The files are found on the support site under a directory named for the release: as of this writing, the current directory is Evolution_v17_Ryegate/:

support files listing

Because both kinds of updates require that Evolution be brought down in one form or another, these can only be done in the off hours. See the "Notifying & Booting the users section for the most elegant way to handle this.

However, the actual download process can be performed over the internet at any time in advance so the files will be ready when the update process is to be performed. There's no reason to kick the users off until both of the files have been fully downloaded from the iSystems servers.


Notifying & booting the users

Both of these updates effectively bring down Evolution, so you'll want to make sure users (especially Evo Remote clients) are not interrupted by surprise unless it's an emergency.

Most Evolution service bureaus do not provide advance customer notice of downtime for patching, because the procedure doesn't take very long and is very low risk. This is unlike the major version upgrades, which put Evolution out of service for hours or days, and warrants an announce maintenance window.

Even though it's easy to tell when payroll staff has all checked out, there still may be customers online via Evolution Remote. Customers often work at odd hours, especially the evening before due-tomorrow payrolls.

To find out, visit the Enterprise Management Console with the web browser and navigate to:

Checking users in the EMC

This shows all users logged in, and the last-active-time column showing user last-active time; this makes it possible to tell if your customers are actively working on the system.

We'll note that the EMC has no way to boot an individual user session, nor to kill sessions which are actually dead, but it's possible to send a Maintenance Notice to all connected users.

Sending a maintenance message

A reasonable time before shutdown, enter a message in the box and click Send. All users will receive this message, and as a helpful side effect, this will automatically log out some dead sessions, leaving only "real" users behind.

Once zero hour arrives, stopping the package servers fully brings down Evolution (Eve Remote users will get a message that the system is in maintenance mode).

Updating the System Database

Updating the SYSTEM database is the most common operation, as they're released more often (perhaps once or twice a week).

Download the file
Visit the iSystems support site, using your private credentials to login, and enter the directory associated with the release of Evolution you're running now. The filename looks like 10-3-0-284_system.zip, with _system in the name.
Locate and click on the SYSTEM database file, and click the "Save" button when prompted. You'll be given a Save As... dialog box. Click Desktop, then select the Evo Updates shortcut, then save this in the version-specific directory.
Unpack the file
In the past we've advocated the use of WinZIP to extract these files, but Windows 2003 and Server 2008 includes built-in support for compressed archives; we're able to unpack the SYSTEM database directly (the WinZIP method will work as well).
Right-click on the 10-3-0-284_system.zip file and select Explore — this will bring up a new explorer window, and it contains the SYSTEM.gbk file.
Then, in the explorer window drag the SYSTEM.gbk to the parent directory, as shown here; this extracts the file from the ZIP archive.
Once the SYSTEM.gbk file has been extracted, close the top Explorer window.
Kick off the users
Stopping the Request Processors — the required next step — effectively shuts down Evolution, so you'll have to make sure that users aren't active in the system. Doing this in the off hours means you're not likely to have office staff, but customers sometimes use Evolution Remote in the evening. These steps are shown in a prior section.
Stop the Evo services
To update the SYSTEM database, we only strictly need to stop the Request Processors, as those are what talk to the database, in practice it's usually helpful to stop everything to just to allow Evo to clear its mind.
In the EMC, click into the Maintenance section and Stop All Services:
Restore the SYSTEM database
Still in the same Evolution Updates\Lincoln folder, right-click on the SYSTEM.gbk file and select "Evolution: Update LIVE" (or TEST, if you have a test system) from the context menu. It will open a black-backgrounded console window, show what it's about to do, and ask you to press RETURN to make it so.
Press RETURN to start the update process, and a few minutes later it should finish with an exit status. Failures are usually pretty obviously and hard to miss.
Restart all Evo Services
Note: - if you're performing both upgrades (SYSTEM DB and Application ZIP), stop here until all are completed. There is no point in restarting the package server and testing with Evolution if the other half is not finished yet (it will always provoke an error).
Back in the EMC, click Start All Services to launch all the Request Processors and others; this brings Evo back up completely.
Test the Evolution client
Evo Icon Once Evolution has been updated, it's wise to test it all by launching Evolution from a normal payroll agent's workstation. A common error is a mismatch of the SYSTEM database and the program version ZIP file, and this is reported immediately when Evo launches.

Updating the Application Zip

These virtually always include the SYSTEM database update as shown in the previous section, so those steps are incorporated by reference.

Download the file
As with downloading the SYSTEM database, visit the iSystems sbupdate site and locate the Application version ZIP file in the directory for the current release. The filename looks like 10.03.00.18.zip.
Click the file, then select Save. In the Save As dialog box, click the Desktop icon on the left, then double-click the "Versions" shortcut found on the desktop. Download the file directory to here.
Do not unzip the file! - this is done internally by Evolution, and there's no need to do this yourself.
Stop all Evo Services
Our practice is to manually stop all Evolution services before activating a new version; this may not be strictly necessary, but this step made Killington upgrades go a bit more smoothly.
Once again in the ECM:
Stop all Evo services in EMC
Kill straggling isRWEngine processes
Even after stopping everything in the EMC, it's possible that some isRWEngine.exe processes will linger afterwards, and they must be killed manually.
If left running, they will prevent Evolution from updating to a new version because the old files can't be deleted. This produces an error message and leaves Evo in a bad (and non-running) state.
Task Manager
To do this, visit each middle tier machine, call up the Task Manager, and select the Processes tab. Look for isRWEngine.exe or ISRWEN~1.EXE tasks: kill them all. Repeat for each middle tier machine.
We understand that a more systemic fix will be forthcoming from iSystems.
Activate the new version
Once the file has been downloaded — it's very large, it may take some time — visit the EMC again and navigate to Maintenance, then Version Update:
Evo EMC Versions
In addition to the currently-active version, it will show previous versions that you've upgraded from, as well as the version you just downloaded.
Click the radio button on the new version, then Install Selected Version. This physically installs the software on all of the middle-tier machines, and we normally give it a few minutes for it to all settle down.
Make sure all services are running
The upgrade process normally leaves the services in the same state they were before the upgrade. After it all settles down, restart all the Evolution services:
Via EMC, Restart all services
Test Evolution
Evo Icon As with the SYSTEM database, launch Evolution from a client workstation and insure no version-mismatch errors occur.

Doing two things at once

It's so common to have to update both parts that we've found that doing things in a certain order is the most efficient: though it's possible to do one, and then the other, there's a lot of wasted time waiting for things to finish that can better be used by doing two things at once.

Note - this section is meant to be a guide that augments the previous sections, but only once the individual steps are well understood.


This Evo Tip is not supported or endorsed by iSystems, LLC.

First published: 2008/11/18 @B$ Updated 2017/02/18