Hi Lisa,

Thanks for using Sage City.

The recommended method of remote working with Sage 50 Accounts is to use Remote Data Access (RDA), you can read more about remote access options in the following article: Accessing Sage Accounts Remotely >

I know that some customers do use a VPN though so I'll leave this post open so the community can share their thoughts.

Regards

Andy
Sage UKI

I would contend that the safest and most reliable way of accessing Sage remotely is to have the program and data installed on a Windows server, and then use Remote Desktop Services to access it from a client PC.  This can be done via a secure VPN connection to the server over the internet from any location. All that is carried over the remote desktop connection is screen, keyboard and mouse data. The Sage data service and accounts data is on the remote server, as is the program, so there is no chance of network issues causing data corruption.

I have run Sage remotely like this for both ourselves and our Sage clients for many, many years with no issues.

If the internet connection is dropped, or flaky, or slow, or intermittent, nothing breaks and Sage continues to run on the server just fine - and as soon as your RDP connection is restored you can just carry on processing. Remote printing works just fine as well if you need hard copy documents, although I send everything by pdf these days.

I'm happy to assist and advise on this solution, which I thing is far better than Sage remote data access, and is much more secure and reliable.

Oh, and alternatively, if you don't have your own Windows server, there are several companies (e.g. AlphaLogix) who will host your Sage data and program on their servers and give you RDS access to it for a monthly fee.

I've spent some time using Wireshark to observe my Sage 50 client communicating with the Sage Data Service.

My conclusion is that almost every action in Sage generates a huge number of small requests (of less than <500 bytes each), and receives a similarly huge number of replies from the data services. Loading my Transactions screen, for example, generates approximately 1500 HTTP request and reply packets in Sage.

Sage developers have therefore favoured a small packet model of data transfer, which means that latency is significantly more important than bandwidth. Latency can only be improved by moving your client nearer to the server so that the requests and replies have less equipment to 'hop' through.

Therefore a VPN connection will always be slower than a LAN connection due to the likely significant number of hops required to get from the home ISP connection through the various ISP interchanges into your VPN server and onto the Sage server.

This can be easily seen using a standard tracert request to your Sage server using both LAN and VPN pathways. In the real world I've observed 20-30 hops, and about 70ms latency time, to my Sage server when using a VPN connection from my home address, whereas it is only one hop and 1-2ms latency when using my LAN connection. As a result, my Sage VPN access runs significantly slower than when using LAN, despite the fact that the bandwidth available over the VPN (approx. 1Gb/s symmetrical) is identical to my LAN connection (also 1Gb/s). Lack of bandwidth is absolutely not the issue.

I'd imagine that the Sage 50 and the Sage Data Service could be improved by packaging its requests and replies into one larger bundle. Without the overheads associated with generating each packet, available bandwidth would become more important than latency.

I guess this is why Sage Drive was developed because it means that all requests and replies can be carried out on local data without any equipment to hop through. It's a shame, therefore, that Sage Drive is so poorly developed and prone to crashing its server, otherwise I'd have everybody using it, even on the LAN.

The way I explain it:

Sage Calls up the office, ask for a copy of all the company records be sent to them and everyone must stop updating the records.

It then searches for its info and updates as approximately and then sends all the records back, then everyone else can carry on.

And it destroys the local duplicate copies.

VS any modern DB system where the request is sent to the office, an admin member of staff looks up the info for them and send just the requested info back.

Then there is sage drive....

Which is just the top one but instead of a copy being sent every time there is already a copy locally, and it looks up there first and hopes the data is the same as the office.

Then if it looks like you might need to update the office master copy. All STOP. Send in the info, do some checks and hope nobody else was doing anything in the meantime.

But yes RDC and remoteapp are the best way to do sage accounts.

Perhaps I am being over cautious here, but I even RDP in to my own local Windows Server 2019 box where the Sage program and data are located. This then eliminates the Sage data service traffic over my (gigabit) LAN to a local PC!

I can't see any downside to running Sage directly on my server and it is always going to be the fastest way. I am basically just using my PC as a remote terminal, screen, keyboard and mouse with minimal network traffic.

I've been doing this for years with no problems.

Hi Stephen

Sorry to dig up this conversation, we have been using RDS for some time now but some users are reporting slow speeds especially doing things like statements. I've set the "fairshare" registry key to 0 which has made it a bit better but its still slow. Have you come across this before and if so have you managed to make it any better?

Thanks

Mick

Hi Mick - I'm not sure that this is related to using Sage over Remote Desktop at all, as there should be minimal network traffic using it this way - it is only sending screen updates and keystrokes after all. I have noticed that statement production can be very slow, much slower than invoicing, and I think there may be internal reasons in the report design for this, although I have never got to the bottom of it.  It used to be that reports that used certain joins - like to the delivery address table - would be slow, but I haven't really investigated this as I don't do many statements and just let it run until complete!  If I had to produce hundreds, and had multiple users etc., I'd probably try to find out why it is slow.  Might be worth asking support if there is any way to optimise the statement run.

Just a small corrolary to my investigation above.

Despite my previous reservations, we are now using Sage Remote Data Access (formerly Sage Drive) for all office and home users.

Speed of access is super-fast and identical wherever the user is located because Sage is working with local data, and although we experience occasional (once every few weeks) data-sync issues, they are usually resolved by telling Sage to pull a fresh copy of data on the affected client.

There is a secondary benefit too - now that no users are accessing our Sage server directly on our LAN, I can potentially move it to a cloud server. This will remove the final piece of hardware from our server room, so I have planned to do this in the next few months.

In answer to the OP and how to improve VPN access, I'd recommend binning your VPN altogether and simply put all remote users on Sage Remote Data Access.

Hi Tyron

I'm glad that the Sage Remote Data Access is working well for you, but I still think that using Windows RDS into a Windows server on a fast broadband link is safer and more reliable. Especially as the number of users on Sage RDA increases - which in my experience greatly increases the potential for data sync issues. And, of course, you are relying on the robustness and reliability of the Sage RDA servers, and outages are far from unknown.