Does this site look plain?

This site uses advanced css techniques

Steve Friedl's Evolution™ Resources

Evo Tip: Best Practices for hosting Evo Client installers

• Home
• Contact
• About
• TechTips
• Tools&Source
• Evo Payroll
• CmdLetters
• Research
• AT&T 3B2
• Advisories
• News/Pubs
• Literacy
• Calif.Voting
• Personal
• Tech Blog
• Evo Blog

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.

Best Practices

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 time.

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_13.3.2.1.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.

1. 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.
2. 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.
3. 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.
4. 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.
• In most 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.

Recommended Version

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.

17.x

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.

First published: 2011/12/21
Updated 2017/09/06