The Evolution™ payroll service-bureau software from iSystems, LLC can be used either on
servers hosted at iSystems in Vermont ("the HSP"), or on machines run in-house
by the service bureau itself. The software works generally the same in either case,
but the transition from one to another requires a few minor steps to make sure
it's a smooth jump.
These adjustments need be done once per existing workstation
during the transition from the HSP: new client
installations have no prior cruft to clean up, and subsequent
version upgrades (say, Jamaica to Killington) won't require
We suggest that service bureaus test the new in-house servers with
just one or two workstations immediately prior to the transition.
Though it's technically possible for a single workstations to have
two separate installations of Evolution, one for the HSP and one for
the in-house servers, this is a bit more tricky to set up than is
worth the trouble for just a few days of testing.
Note - these instructions apply only to single
Evolution installations using the default locations; those
customers using Evolution Offline Remote have additional
considerations not discussed here.
Evo Client Changes
Though iSystems provides several variants of the client (EvoRMT for the
payroll remotes, EvoLocal for the service bureau staff), the procedures for
both are the same.
- Exit Evolution
Make sure the Evolution client itself is not running: close it with the
usual [Exit] procedure. We can't reliably change some of these
settings while the Evo program is running.
- Registry cleanup
Evolution keeps a number of items in the registry, and though most of them
don't care which server the Evolution client is talking to, a few will
conspire to cause trouble.
The registry key HKEY_CURRENT_USER\Software\Evolution\ contains a number
of sub-keys and values, and though it's possible to just delete the whole thing,
this will remove a number of user preferences (grid settings, for instance), and
that's not necessary.
Launch the registry editor by clicking Start » Run,
enter regedit followed by RETURN. Navigate to the proper key via:
- My Computer
- » HKEY_CURRENT_USER\
- » Software\
- » Evolution\
- » Evolution\
On the right panel, Right-click + Delete the Hosts value, which would have pointed
the Evo client to the wrong place. There are other values there that are
asking to be altered, but it's not worth the trouble: deleting the Hosts
entry serves a vital purpose (discussed below), that the others do not.
Then exit the Registry Editor by closing this window.
- Remove the SB.DAT file
- Using the Explorer interface, navigate to C:\Program Files\Evolution\Client
and look for the file SB.DAT. This contains configuration information about
the service bureau's HSP account, and this is not used by the SB-hosted servers.
Note that depending on how your Explorer folder options are configured,
the file might be named just SB (suppressing display of the extension)
— that's the same file.
Right-click on the file and select Delete.
Double-click on the Evolution icon on the desktop, and in the Server
entry field, enter the hostname of the new service bureau address,
not the one evolutionhsp.com one.
Select the proper Connection type, enter your username and password, and
click [OK]. Evolution will update your local copy of the software,
perhaps requiring you to login one more time, and then present you with
the usual Evolution program.
Uninstalling and reinstalling
Though the above steps ought to be the minimal sufficient requirements,
some users will nevertheless prefer to uninstall and reinstall their
clients to be safe, or because their installed version is too old to
allow auto-upgrade to work. Either is a fine reason.
But a mere uninstall will not work, because of the key
registry items mentioned above; these must be attended to properly or
it can lead to a vicious auto-update cycle.
- Exit Evolution
- Make sure that no Evolution.exe process is running: this means exit
Evolution, including any found in the task bar at the bottom of the screen.
- Uninstall the Evo client
- Whether this is Evolution Remote (for remote clients) or Evolution Local
(for the service bureau agents), the familiar Add/Remove programs steps should
remove almost the entire application.
- Delete the installation directory
- After uninstalling Evolution, there will still usually be a few
minor files left behind in the default install area, C:\Program Files\Evolution\,
but these may well matter. One should use the File Explorer interface to navigate to
C:\Program Files\ and delete the entire Evolution\ folder (sending it to
the recycle bin).
This effectively removes the SB.DAT file which might be left behind,
plus any other files which could corrupt a new installation.
- Perform registry cleanup
- The HKEY_CURRENT_USER\Software\Evolution\Evolution\Hosts value
must be removed, and this is described above.
This step must not be skipped
- Reinstall Evolution
- From a suitable source (the Payroll Service Bureau website, usually), install
EvoLocal.exe or EvoRMT.exe, as appropriate, using the defaults. This puts the Evolution
client on the system in a clean way, and it should be suitable for launch immediately.
- Launch Evolution!
- Double-click the Evolution icon. This will bring up the familiar login
page, where one will enter the username, password, server, and type.
- Evolution Remotes will probably leave the type field (Modem/DSL/T1) as it was
previously, but Evolution Local (SB users) must select LAN (which will never
work for a remote). Both sites must enter the proper name or IP address
for the server.
The first time a user connects to the server after a transition, there may be
a delay while the latest software downloads to the user, and this will always
be slower for remotes than it will be for the SB itself, and it may well ask
for a second login after the update. This could take as much as 5-10 minutes
for some remotes, and perhaps more than once. Be patient the first time, and
repeat the process as needed.
Once a user has succesfully — and completely — logged into Evolution,
it will remember all parameters except the password, so subsequent logins
to the same server should be easy.
Update cycle hell
The above steps may seem to be overkill — why not rely on the uninstaller?
— but there is a common bit of pathalogical behavior that plagues Evo updates
when servers change, and it's important enough that we elaborate on it here to
make the case that it's a big deal.
When the Evo client first starts up, it consults the registry for a prior server
IP or hostname, and it "phones home" to make an anonymous login to that server.
It doesn't login or attempt to access any payroll data, but it does exchange
version information with the server: "I have this version - how'm I doing?".
The server compares the individual module versions with what's presented, and
offers an updated set to sync the remote with the server.
This process could involve the download of a great many files, and is
responsible for the flying-papers dialog box familiar to all Evo users
who sign in after an update.
But the problem occurs when the HSP is running a different minor version
of software from the service bureau, and this is how the steps go:
- User fires up Evolution, and it auto-connects with the server
found in the registry: the HSP. It will sync up with the version found
on that server and restart, downloading if necessary. This can be a
slow process if it has to download many files.
The restarted Evo auto-connects with the server found in the registry
(the HSP) and attempts to sync. Finds that it's up to date, so it
displays the login dialog box with the parameters found in the registry.
This includes user name, server name (the HSP), and the connection type.
User changes the server field to the SB's server name or IP, enters
the password, and clicks [Connect].
- Evo connects to newly-specified server, attempts to sync up version
information. It finds that it's not current, so the SB server provides
many updated DLL files, creating the flying-papers dialog.
Evo finishes downloading the files, restarts program to use them.
The restarted Evo connects to the saved-in-registry server; this is still
the HSP, so it replaces all correct local versions with the wrong ones
from the HSP servers.
... cycle continues, without end.
This is widely considered highly unfriendly behavior in the update process, but it
exists nonetheless: by deleting the Hosts entry in the registry, it will
not be able to "phone home" to the HSP, and will stop trying to
re-synchronize with the wrong server.
Only after a user completes a successful login after auto-updating is
the new server name stored in the registry for use the next time.