Virtually all Evolution service bureaus have customers who use Evolution Remote, and
iSystems does not permit SBs to have customers download the installers from the support site directly,
so most choose to host it themselves on their own payroll company websites.
This paper describes some best practices for doing this that will reduce support costs,
smoothe the way for easier customer installs, and make it easier for your web people.
It's important that all service bureaus have an in-house understanding of these issues.
Hosting obsolete installers creates a bad experience for your customers, and gives a terrible
impression when they're told that you gave them an installer that wouldn't work.
- Fetch recent Evo Client Installers from the iSystems support site
You can obtain updates in the same place you get all the other parts of Evo software: on the
iSystems support site (requiring your
usual support credentials). Navigate to the major release folder, then the minor release folder,
then get the EvoClient installer in MSI form.
NOTE: do not give payroll customers access to the iSystems support site.
- Know your current Evo version number
When dealing with installation or update issues, it's not uncommon for a customer to use an
old installer downloaded previously (perhaps reinstalling on a new machine); if the installer
major version doesn't match the current major version, it's more likely to have problems
than if the major versions match.
In the Evo login box, the application version is shown in the title bar:
This shows version 13, which is Orange.
If you ask me for help with an Evo Remote issue, don't be surprised if I ask "What is the major
version of the installer". If it's an old version (or if you don't know), I'll usually ask you
to get the customer a current installer before I dig in.
Recent version reference:
- 10 - Lincoln (fall 2008)
- 11 - Manchester (fall 2009)
- 12 - Norwich (summer 2010)
- 13 - Orange (summer 2011)
- 14 - Peru (fall 2012)
- 15 - Plymouth (summer 2013)
- 16 - Quechee (fall 2014)
- 17 - Ryegate (summer 2016)
- 18 - Stowe (fall 2017)
Your CSRs should be able to recognize an old major-version number on sight (i.e., anything that's not "17").
- Always update the installer for a major release
Though Evolution will update itself from prior releases most of the time, it's a poor idea
to publish a prior-version installer on your website: once you migrate to a new major version
(Norwich, Orange, etc.) it's important to post an updated installer as part of the upgrade process.
- Update installers occasionally during regular production
The installer does not have to be updated on your website after every release, and to do so
would probably be counterproductive, but nevetheless you should still pay attention to the announcements
list from iSystems that notify about certain required updates. This doesn't happen often.
Otherwise, updating the installers every six months or so is not a bad way to keep them fresh.
- Don't publish the exact current minor version installer
As curious as it sounds, the installer on your website should not be the same exact major+minor
version as you're running in production, but should be slightly older. This is because a customer doing
an install should do an auto-update on the first connection to Evolution, and if there are problems
we want to resolve them during installation time, not 2 weeks later when you update the servers.
During the initial install, customers typically lump all the issues they experience together
as "installation issues" even if they are problems with the installers, firewall settings, or
difficulties with auto-update. By publishing a non-current installer, you insure that the first
experience includes the auto-update, so all of the common issues are resolved at that
- Keep the version number in the installer filename
When you post the installer on your website, I strongly recommend including the actual filename
from iSystems that includes the version number, such as EvoClient_188.8.131.52.msi - this makes it really
easy to tell at a glance which is which. This is important.
Some SBs use a fixed name, such as EvoClient.msi or EvoRMT.msi, presumably
to make updating of the website easier (just drop in a new file without changing the HTML
each time), but this is a terrible idea that makes support much more difficult.
If your consultant gets pulled into customer EvoClient issues and when the version number is not
obvious, the SB runs the clock as we figure it out while online with the customer; it's a bad
impression for them to see what looks like bumbling, and make the issue resolution take longer
while it costs you more money.
- Include the exact filesize of the installer with the download link
It's not uncommon for a customer to download the installer but receive an incomplete file,
which will unsurprisingly fail to install with an error such as:
By including the exact filesize in bytes in the link (not round numbers in kbytes or megabytes), the customer ca
verify that s/he got the entire file rather than only part of it.
A good download link might look like this:
- Tell your web people that this file will be updated regularly
Some website software lends itself more to routine updating than others, and though
the web people may want to go down the fixed-filename road, it's important to insist
that they not do this.
By letting them know the requirements for including the version number and filesize,
as well as the note that it will be updated a few times a year, they may be able to
configure your downloads area to make this easier every time.
How to check your own posted version
It's important that all SBs know how to find the exact version of the Evo installer
on their own websites, not relying on outside IT or web staff for this information (though
actually updating the site may well be outsourced).
These are instructions that any CSR or operations staff can use to verify the version: this
procedure will not actually install Evo, and can be performed even on systems that
have Evolution installed already.
- Go to your website's download page and see if the version number is included
on the web page itself. If it's not, it should be. If it is, follow Step#2
to insure that it matches the actual version on the filename to be downloaded.
- Hover your mouse pointer over the download link; does the URL (which usually shows up
at the bottom of the screen) include the version number in the name? If not, it should.
If it does, does the version in the name match the printed-on-the-page version in step #1?
If not, it should.
If there is no version information visible on the web, you'll have to download the installer
and run it yourself. Download + run the installer, and just after the splash screen it will
show the version information:
If this is not the current major version (12.x.x.x, 13.x.x.x, etc.), please have your
web people update it.
Click [Cancel] on the installer setup dialog box. This should not impact
Evolution running on your workstation.
For the web developer
If you are maintaining a website for a payroll company and are asked to host the download file, I'd like
to touch on some points that come up often; you can mostly skip the previous sections.
- We really do need the full filename (including version) in the downloaded filename, as well as
in the link visible on the page. It's tempting to set this up once with EvoClient.msi and
just drop in a new file once in a while, but this has caused no end of support issues. Payroll software
changes constantly, and version visibility matters to us a lot.
While you're updating a link with a new filename, always include the full exact filesize in bytes
to allow your customer's customer to verify that he got the full file. We've burned a lot of time
on this too. See the example to the right.
If you are asked to host the "Remote Help Installer" as well, it doesn't
typically have a version nubmer in the name (unlike the Evo Client
installer). This is not updated as often, and not all service bureaus
host this. Including the filesize-in-bytes on the page will help us as well.
cases the customer will either give you a link to my website with an installer, or a link to the
vendor's website (along with credentials) to download the installer. Download the file and update
the web pages as needed.
NOTE - make sure that the file to be downloaded is hosted on customer web resources and not just
a link to the vendor (evolutionpayroll.com) or my website (unixwiz.net).
Since this will require updating maybe twice a year, please make sure you document the procedures
for performing this update internally so that we don't all scratch our heads each time.
If the site lends itself to third-party updating, consider providing access instructions to
the customer (who would provide them to me), and I'm happy to perform these routine updates
as required. I am comforable with hand-editing of HTML and most common remote-file-access methods.
The typical recommendation is to always host a new version when a major update comes out,
but from time to time there are minor updates that warrant updating the Evo Client on your
website. This section lists key milestones that warrant consideration, and in each case I
recommend hosting this version once you install it or some subsequent version on your server.
Any Ryegate installer will work fine; we have no knowledge of any special cases. We also
believe that Quechee installers will probably be ok too, but we still recommend updating
to a Ryegate installer just on general principles.