>>>>>As for the SMB issues, I've deactivated SMB v2/3 on the (virtual) server, but doing so also prevent the users from accessing the server.
>>>>
>>>>That hints for me to deactivated SMB1 - perhaps double check ?
>>>>You NEED SMB to access remote files, but only SMB1 is ISAM safe...
>>>
>>>If I understand you correctly, I should deactivate SMB2/3 and let only SMB1 activated?
>>>
>>Correct
>

reordered...

>
>
>As a sysadmin my preference is to disable SMB1 unless it's needed by really old devices or Windows versions, leave SMB2/3 enabled, and apply the Alaska Software registry changes to workstations and/or session servers.

Let me speculate that with you as their sysadmin AT LEAST the symptom/occurrence of not being able to connect atter disabling SMB2/3 would not have occurred, as you are aware of latest new installs not including SMB1 and older updates deleting them silently after period of not using it...

Armchair diagnosis on rather scetchy symptoms is hard, esp. if there is a minimal chance of side effects or 2 factors being involved.
First order of business is to find the reason of corruption and enable them to work uninterrupted in the future as well.

Possible causes are with my percentage guess :

50% SMB/oplocks troubles
15% other weaknesses introduced in new windows versions (ex: drive letters mapped to shares loosing/reestablishing connection)
10% faulty LAN wiring (Cat-5 cables, switches/hubs interconnected, notoriously unreliable WLAN "cable")
05% HW problem on server (disk sectors, cables)
10% intermediate SW running on server (AV, virus)
05% vfp coding errors, as only basic stuff is do ne and across many tables/routines errors crop up NOW
05% acts of Gods, nature, saboteurs and other reasons to get to 100

See my post of 25/09/2018 22:52:32 local time for my approach - reasons are:
OP was 1 month ago, 20 users aggravated/work time lost for all certainly above 100 work H plus at least 2 days of admin and 3 days of Sylvain time. Cost: non-trivial.

Running vfp app against dedicated XP server from virtualized local XP clients should prove network stability and vfp code quality, proiding a base user can work next week without interruption.

I agree a competent and dedicated admin probably could keep settings for SMB3 workable with small worker time lost and little admin time.
Perfomance during last month suggests that admin is either incompetent or Sylvain was unable to pressure/motivate him enough.
So repeat long interruptions are probable every time MS craps on SMB in Update again.


>Hmm, SMB1 has multiple nasty security vulnerabilities and has been deprecated in Windows for a long time. Disabling SMB2/3 is not recommended and reduces functionality of more recent versions of Windows:
>https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
>Specifically, the warning and header information at the top of that link.

True. But the typical back-office data entry program I visualize should be able to run on server hosted XP VMs accessed via MSTSC/RDS hitting a XP server backend on a 32GB quad or hexacore on SSD with ease. I BELIEVE you could keep SMB1 broadcasting/vulnerabilities inside the subnet created by virtualization software inside that machine - in practice I would slap a cheap router in front of that machine creating a cascading subnet and only tunnel through via MSTSC ports and special rules, separating that app and XP vulnerabilities from nomal network ;-)

As written in other post, if the app needs to be integrated into client desktops and is company survival relevant, bite the bullet and switch over to any SQL backend (as hiring competent admins probably is more costly in the long run)