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.
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.
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
| 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
EvoClient branded for StevePay
| 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.