I'm recommending that customers using AUS — the Alternate Update Service — consider abandoning this facility, mainly because the cost/benefit tradeoffs are starting to tip unfavorably against you, and more powerful servers and faster internet connections mainly obviate the reason it was introduced in the first place.

Background

The first thing that an Evo Remote client does when phoning home to the Evo servers is to check for updates, and if it's current, it puts you into payrolls, but otherwise it has to fetch the updates and restart itself and try again.

There are two places from which the client can get these updates:

• From the Request Broker (via Remote Relay); the updates are loaded down the same SSL connection used to connect Evo Remote in the first place.
• From an Alternate Update Server; when (optionally) configured in the Evo Management Console, this is URL pointing to a server located elsewhere — presumably at a data center with great bandwidth — where updates are provided. The machine hosting AUS has no payroll data of any kind, only program updates.

AUS was introduced in the Lincoln release (~2008) to assist service bureaus with limited internet connections (say, only a T1 circuit), because when many remotes all dialed in at the same time, the large volume of updates would flood the circuit and make all of Evolution unusable for everybody.

A few service bureaus had really, really bad times prior to AUS, and I've been running an AUS server for my customers for a long time, found at http://aus.unixwiz.net/(sbname).

Problem: content filtering breaks auto-updates

AUS updates are delivered over HTTP — an unencrypted connection — and an increasing number of payroll customers run firewalls with content filtering that sniff this stream of updates, consider it dangerous, and block the downloads, causing the Evo update to fail and rollback. The fetch of xDelta,exe, in particular, is very commonly the cause of the failure.

The only fixes are to have the customer's IT people whitelist the AUS server in their firewall to bypass content filtering, or to reinstall Evolution with a current-version installer (avoiding an update).

But this problem is getting worse, with more and more payroll customers running into it, and some customers have policy restrictions that don't allow for the kind of whitelisting that will allow Evo to update.

Recommendation: Abandon AUS

I believe it's time for most service bureaus to phase out use of AUS, because those with good internet connections (especially with Evo servers at a data center) and a good middle-tier machine hosting the Request Broker and Remote Relay, the Evo infrastructure has plenty of power to deliver these updates without the complication of AUS.

To disable AUS:

• With your browser, go into the Evo Management Console
• Navigate to Configuration ⇒ AUS
• Record and save the URL found here: if it's empty, you're not using AUS
• Blank out the field for the URL
• Save the page

If you run bandwidth monitoring on your internet circuit, keep an eye on it, especially after you install a new Evo version — that's when the updates will happen.

If you do run into problems caused by disabling AUS, put the URL back, save it, and consult with iSystems or your Evo support person to consider alternatives.

Also: I'm retiring aus.unixwiz.net

The machine hosting my current AUS machine, offered as a service to my customers, is approaching 10 years old, and I'm going to be retiring it in the near future. Though it's working great now, I worry that it may decide to retire itself before I'm prepared.

It's not clear whether I'm going to bring another AUS machine up elsewhere, it depends in part on how much it's actually needed. In the coming week I'll be assessing the use of AUS for all my customers and discussing it with them.

If it were just a matter of bringing a new server up I'd probably just do it quietly, but since a number of customers have whitelisted the server by IP address, this will change with a new server and we'd have to go through the same whitelisting process all over again. This is painful enough that it militates towards just retiring AUS entirely.

Side notes

• If you're on the HSP, iSystems manages this setting for you.
• AUS only applies to Evo Remote getting in via Remote Relay. Service bureau staff connecting directly to the request broker (9500/tcp) always update directly from the Request Broker.
• If the AUS server is unreachable — mine has been down once or twice — the client automatically tries again over the SSL connection.
• Abandoning AUS only avoids the issue of border firewalls corrupting the updates, but fetched updates such as xDelta.exe may still run afoul of desktop security software, requiring a different kind of whitelisting.
• This problem could be addressed if Evolution could use a https URL (encrypted over SSL), but this feature has not received priority over the years, and at this point it's probably not worth iSystems' time.