I am guessing sage is not going to like DFS being part of the filesystem involved in the company data. I know it gets grumpy if a user has company data located in Onedrive sync folder location (for example). I'm pretty sure Sage is expecting to have 'normal filesystem' access for the sage company data files. And anything that does clever data replication, backup, etc. in the 'background' is going to be a problem.

If your intent is to achieve some measure of multi-user / multi-site concurrency of company data files. You will need to think of alternative way, I am guessing. Possibly this means

(a) Manual sync process, users appreciate that there is some mandatory workflow for 'check in and check out' of files. For example use DFS to sync your 'master' data copy set(s) of company data files. Then users are educated and forced to adhere strictly to a workflow of

>> check out means pull company files off the DFS storage, into a local C:\sagedata non-DFS path (for example)

>> once they finish the work they move the company data back to DFS Storage location and remove their local copy to avoid 'data duplication confusion and version fork issues'.

This is of course klunky and horrid.

Usually the most successful multi-user distributed-geo-location-work-environment kind of arrangement I've found is just to bite the bullet and get an RDP "term server" thing setup somewhere that is accessible easily to all staff, and have them remote onto that box to do their work.

In theory you could also do it with

(a) Sage data server in cloud/accessible somewhere via VPN access, then user hits a Map drive such as S:\ points to \\ip.of.sage.server\sagedata

(b) user gets onto VPN, gets share drive lit up, then opens sage app installed locally on their PC/laptop

(c) they do work, it is a bit slow but functional since sage data is tunneled over VPN.

there are probably ports you need open for (background stuff - sage connection manager <> mySQL.db etc in addition to the pure file share drive map access.  Presumably your vpn config would allow 'all' traffic from client<>server (approx) to allow this to work.

I am guessing termserver style approach will be better

end of the day, maybe? it is politely simple maybe to say (in my opinion?!) that sage is built on older core tech (>10+ years since it was what might be called current?) and under the hood it runs the same way it did in 2000-ish era install environment.  IMHO kinda painful. but it kinda sorta works fine most of the time so I guess that is why the product still exists. Whee.