Does this site look plain?

This site uses advanced css techniques

Evolution Logo

Most SB customers input their own payrolls via Evolution Remote, and Evo Remote has been a longstanding pain point with support. These best practices are offered to help reduce these costs.

These Best Practices are strictly about support — they have no influence on the security posture of the Service Bureau, so there's no need to implement them all against your own better judgment.

Recommendation: Retain the full version number in the client installer filename
Many service bureaus park the Evo Remote installers on their own websites to allow convenient client download and install, and it's helpful to retain the full name of the installer file (EvoClient_11.05.02.01.msi) because this makes the version number obvious.
Many installation issues arise because the customer is inadvertently using a too-old installer (perhaps taken from a long-ago install on a different PC within the office), and with the version number visible, this fact will come up earlier during the support session ("Oh, you're using an old installer. Please download the latest from our website").
However, not all Service Bureaus can conveniently do this: some instead rename the installer to a single fixed name, such as EvoClient.MSI, because it means the website's HTML doesn't have to be modified every time a new installer is uploaded. This is a legitimate concern.
Note: We've submitted a feature request to iSystems asking that the specific version number be visible in Windows Explorer via Right-click + Properties.
Recommendation: Do not publish the current version client installer on your SB website
This will surely sound like odd advice.
If the installer's version matches the SB's production version, no automatic-update will be performed: by using a prior version (but not too old), every new customer install forces an automatic update. This is intended.
It's been our experience that the two most common Evo Remote pain points are (a) firewall issues, and (b) auto-update issues. By forcing the auto-update on the first install, both pain points are addressed during the same installation session.
Otherwise, the auto-update issue could rear its head later, forcing a second support request and leading the customer to believe that Evo Remote requires a lot of care and feeding. This is especially the case if the firewall issues during install took a lot of time to resolve.
Recommendation: Use the Alternate Update Service (AUS)
When a version auto-update is required by a client, it's normally downloaded from the Request Broker itself over the SB's internet circuit. For a single client to do this has no real impact on performance, but if many clients update at once, it can overwhelm the Request Broker, the internet circuit, or both.
We've seen Evo installations positively crushed for days due to a flood of updates.
The Alternate Update Service involves an external website, often hosted at a high-bandwidth data center, where the Request Broker redirects the client to download the needed updates. The client seamlessly fetches the files from the AUS server, taking the load off both the Request Broker and the SB's internet circuit. Once the update is complete, the Evo client returns to the Request Broker to continue the login process.
These updates are strictly Evo client program files: there is no payroll or sensitive data of any kind hosted on the AUS server.
Using an AUS server does require that it be updated periodically when the production Evo server is updated, though the client does fall back to the RB-download method if the specific AUS version data is not found.
Recommendation: Configure port 443/tcp to support Evolution Remote
In our experience, the most common client pain points are firewall issues on the customer's network, either on the PC itself or on the customer's border firewall.
It's all too common to request that customers open outbound ports 9901..9903/tcp from their network to the SB, and in some cases this has required fairly intensive support at the customer site (as in: they have to run their network consultant's clock to make it happen). These always make for a poor customer-install experience.
For some years now, we've recommended an additional port for Evo Remote: 443/tcp.
This is the same port used by secure web surfing (https), and our experience is that it's almost always allowed outbound from customer networks (if it's not allowed, then things like online banking do not work at all).
Enabling this is done in two steps, though you must observe the cautions notes.
  1. Enter the Evolution Management Console, navigate to Configuration » RR Ports, enter "443" in the custom box, and save changes. We normally select "Better" compression, a fair tradeoff.
  2. Configure your outside firewall to route port 443/tcp on the Evo Remote external IP address to port 443 on the internal Remote Relay machine.
This done, customers can use this port in the Evolution Remote login dialog by clicking Settings, selecting 443 from the drop-down list of ports, then clicking Ok to return to the main login dialog.
It's been our experience that this dramatically reduces firewall issues on Evo Remote customer installs.
Important Caveat #1 — if your Remote Relay machine hosts other software that is using port 443 — say, a web-based software application — then Evolution won't be able to listen on this port. It's possible to use a different port (say, 9904/tcp) and remap 443 » 9904 in the firewall, but not all firewalls support this kind of port remapping.
Note: Sonicwall firewalls allow port remapping with the Enhanced firmware, but not with Standard. Other firewalls may or may not support it as well.
Important Caveat #2 — if the outside IP address for Evolution Remote also uses port 443 for some other purpose (which is often the case when a Service Bureau has just a single external IP), you won't be able to use 443 for Evolution.
We urge you to check with your network or Evolution consultant before attempting to enable this.
Recommendation: Brand the MSI installers with SB-specific parameters
As published by iSystems, the EvoClient installer defaults to these parameters:
EvoClient parameters as delivered
parameter value
Login Id (blank)
Password (blank)
Server (blank)
Compression T1
Evolution Server Port 9901
Desktop shortcut Evolution.exe
Product Name
as seen in Add/Remove Programs
Evolution Client
When SB staff are helping new customers install Evo, they have to provide the login ID and password (of course), as well as the server name and possibly the port number if it's different from the 9901 default (example: using 443 as noted in the previous item).
But since the MSI file format is actually a small database, it's possible to customize the installer to prepopulate with SB-specific values. The result of this branding might look like:
EvoClient branded for StevePay
parameter value
Login Id (blank)
Password (blank)
Server evo.stevepay.com
Compression T1
Evolution Server Port 443
Desktop shortcut Evolution - StevePay
Product Name Evolution Client - StevePay
When this updated installer is downloaded by customers, the key values of Server and Port will be filled in already, simplifying the installation process. This is especially helpful if you're able to use the port-443 method, as first-time successful installs will rise dramatically.
The branding of the shortcut and product name are not strictly necessary, but they do help reinforce the SB's name to the customer, and since we're updating the Server and Port anyway, this rides along for free.
Rebranding an MSI can be done with Microsoft's free ORCA tool in the Properties and Shortcut tables, or with a bit of VBScript programming.
We have created some tools which are optimized for branding these Evo Client installers; contact steve by email to inquire as to availability.

We'll update this document as we understand more Best Practices, and we'll recommend that you check with iSystems support or with a qualified Evolution consultant for help implementing any of these items.


First published: 2010/02/01