Beware, following it not a short answer.
3shape programs can be divided roughly to "new gen" (ortho/studio or whatever) and "old gen" (dental system). Old gen programs use old client-server model (as a software design philosophy),which is "LAN centric" : it relies on very basic layer of networking, called "hardware address" (aka MAC-address). In LAN centric C/S -model, client-server connection is direct and where only network apparatus (such as Switch which is box where wires are connected) does not "need" to play any part on establishing or maintaining the connections. Old C/S -model means, that ****load of connections can be opened without compomising network efficency. Because LAN connection is "direct" and efficient, an old C/S -model software usually lacks "caching" (because it is not really needed): caching means prefetching things to "local harddrive" in order to create "temprorary runtime enviroment" which in turn eliminates needs for constantly open connections from client to server.
Routed (WAN) environment requires "routers" (connection is roughly "client-router-router-server", and both "hardware address" and "IP address", along with routing information is needed in order to connections to work) to adjust "headers" (of a data packets) in order to establish and maintain connections: more connections, more "punch" is required from router. Home-level or small business level routers are packed with features. and each feature in use, means that "router box" has more things to with the traffic (connections): Routing itself requires resources, firewall actions require resources, doing "VPN-in" requires resources, then if we have WLAN on same box it requires resources and possibly WLAN security, which again requires resources.
Like said, 3shapes "old gen" programs open ****load of connections from "client to server" and it is not a problem in LAN. But when in WAN, multiple connections are not that good thing: more connections means more load. And the load keeps piling up to a point where small office router which includes tons of features (i have tried with site-to-site VPN setup with router/firewall with vpn-thruput of 400mb/s) simply chokes and then timeouts and dropped packets will happen. And when dropped packets, timeouts and other stuff is combined to LAN centric way (old) of software design, it will cause all kind of "wierd ****".
Programs can be "improved", to certain extend, by using "caching" where it can be used. Problem is, that making major improvements is not possible without completely rewriting whole software: older 3shape programs do (nowdays) "some" caching, but it is relatively minor help to this matter. To me it seems, that newer gen 3shape programs have better "caching" (and require less network action). On newer gen 3shape programs there is still latency over VPN (because of normal "load" encountered by routers/vpn/firewall, but it does not "kill" router) and newer programs run quite nicely (over VPN) WHEN "temprary runtime environment" is loaded and things "cached".
But how to cope with older gen 3shape programs and "their characteristics"?
It is "all about reducing amount of network traffic". And to me, the only way to reduce network traffic on old gen 3shape programs, is to do standalone installations (clone working standalone installation to other stations if possible) which then have its "ups and downs". One thing to remember is that "old gen" 3shape programs stores different things to various places: Some Order information (patient, dentists, dates etc) is in database. Scans are files, that saved in one place. Materials and other things (articulators, shader materials, articulator bases) are actually "split" so that part (ID, desription etc) exist in database and some parts exist as files in "3shape configuration" -folder. And these things spell troubles when "Skinning this Cat".
In theory it is possible to use DFS (replicate 3shape configuration folder, replicate database, replicate orders directory, replicate whole program directory too?). But... then we may end up to Hell called "Runtime Volatility". older 3shape progs may write something into "3shape configuration" -directory (usually c:\3shape configuration) on "runtime" and if that is shared via DFS to all "stations"... If 3shape encounters File Locks and other DFS "tricks" then that will cause funky **** to happen. I would say that you have two options if you dont like the "standard" 3shape client/server installation way.
Option 1: Shared dongle
- REMEMBER: In this Nothing is loaded from "server", only validity of licence ("dongle action") is checked over network.
- this is the most network-efficient way. It can be done thru VPN (and also insecurely over the open internet).
- requires standalone installs (fresh or clones if possible) on all stations: installing is done by transferring physically dongle to each computer and installing. Then take dongle to one computer and configure installed stations to "sniff" dongle from it. Make damn sure you use fixed IP on the "dongle-station".
- Orders (and affiliated scans) are created to Standalone stations LOCALLY: They are NOT saved/sent to server.
- Materials are not loaded from server: Under certain circmstances, this can cause something called "Material Hell" where materials (material ID is the troublemaker) differs between stations. To avoid this hell, Orders are to be trasferred between stations by "Export/Import complete Orders", since Complete Order includes Scans (and Materials if i remember correctly?).
Option 2: Share dongle, "Working Directory and Manufacturing Directory" folders and database.
- this generates a lot more traffic when dealing with Orders and Scans, but can speed up things when starting/using different modules.
- Biggest thing in this, is that one has to remember that Order Info (database),materials (files) and scans (files in working/manuf dir) are stored in different places.
- Do standalone installs just as in option 1. Then change dongle to point to "server" and change database settings so that it points to server. This allows you to use same dongle and you see same Order info.
- Share a folder where you want these things to go. Then change the working/manufacturing directories. Make damn sure that ALL standalone installs (including one which will host dongle and database) are configured so, that they use SAME NETWORK PATH (eg. \\server\3shape) to store scans etc. DO NOT EVER use paths that point to local harddrive (eg. c:\3shape). Failing to use same path in all stations will cause "Location Hell": "old gen" 3shape programs use the "working directory" (and manufacturing directory) information and "hardcode" that location to Order specific configuration at the moment of Creating Order. If path differs between stations, then "other station" will look for location (set on creation of an order) and scans might fail to load even if you see the Orders in Dental Manager.
- Since older 3shape programn materials are "split" between database and local files, there is serious risk of ending up in "material hell": if material (material IDs AND files) differs between stations, **** will hit the fan. Best way to deal "material hell" is to Export Materials from "designated" station (usually server) and importing them (with override option) to other stations.
- This way there is need for exporting/importin Complete Orders. ofc, standalone installations means that "site id" (which then is reflected to Order number) is different, bit it does not have effect how 3shape programs operate.