>>>>IMO disabling SMB2/3 on clients is a bit severe, the Alaska Software patch/reg entries modifies the parts of those protocols that are problematic.
>>>>
>>>>SMB1 is already deprecated, and may disappear from future versions of Windows Server. I think it's important to get VFP to work reliably without disabling SMB2/3, especially since other functions of current Windows server and client OSs rely on those newer protocols.
>>>
>>>Our solution was, instead of hacking the registry or disabling SMB2/3, to disable in the server the "Microsoft network server: Digitally sign communications (always)" policy, that solves the SMB issue, it leaves you open for middle man attacks, but so does SMB1... We have this setting for years now and we only experienced SMB issues when we changed servers and the net admin forgot to turn this setting off)
>>
>>Just to be 100% clear - when you're talking about "solves the SMB issue", do you mean:
>>
>>- Unexpected client disconnections from drive shares/mapped drive letters
>>
>>- The "classic" index corruption problem
>>
>>or, maybe both?
>
>SMB with "Microsoft network server: Digitally sign communications (always)" enabled: frequent disconnections and data or index corruption.
> "Microsoft network server: Digitally sign communications (always)" Disabled (on the server): We have NO problems, no disconnections nor corruption (well, we always experience some index corruptions, but related with "circular" tables and since the days of SMB 1/ windows 95).

Interesting. In your case it could be argued that the disconnections might have been causing the data/index corruptions.

Was this related to your findings that things worked with Windows 8, but not with 8.1? Do you recall what the server policy was when you were running 8? Maybe something like:

- Policy enabled, Windows 8 -> no problems
- Policy enabled, Windows 8.1 -> problems. If the policy is also present on clients, maybe client-side it's disabled by default in 8 and enabled by default in 8.1 (?)
- Policy disabled, Windows 8.1 -> no problems

All this brings up another question. My understanding is the original SMB2 issue results in corrupted indexes, without any indication of network disconnection. If I recall correctly, Brandon Harker's repro code needs to run for a bit (i.e. server under load) before it manifests. Presumably it did so without disconnection errors (?) Also, it dates back to the early Vista days, I'm not sure the server policy existed back then or if it was enabled by default. So, I'm thinking the "original/classic" SMB index corruption issue is separate from what you've been dealing with.