>>Very interesting. Thanks for the recap of the 8.0 - 8.1 connection issue.
>
>No problem. It drove us crazy, I even was saying here that we had problems with 8.1 (and we were blaming some change in SMB...) but nobody believed me. Finally the net admin found this change in the default setting when mapping drives thru a policy, since then we do not have any more issues.
>
>>
>>Regarding the server policy, and your test code, can you explain further how it "dies" when the policy is enabled? Does it experience disconnections, or do you get errors related to VFP data/index corruption?
>
>The most common error is an "Error reading file" or "Invalid seek offset", occasionally the header gets corrupted (we would get a... forgot now... arrggh, well basically the record count and the header are in disagreement) and the last one I remember is invalid or missing memo file.
>
>>
>>Also, do you know if your server(s) have the Alaska Software registry changes implemented?
>
>I am sure we did not hack the registry, neither manually nor thru Alaska Software msi. You can see in the pseudo screen shot I posted before (the output of get-smbconnection) that we are using SMB2 or 3 (or its minor versions, like 2.02 etc).
>
>I mentioned before that we do not have issues, what I should have said is that we do not have more issues than when we were running the applications in SMB 1...

Thanks again for the explanation. BTW the Alaska Software registry mods do not disable SMB2/3 (as some sources recommend), instead they modify default parameter values of those protocols. So, even if the registry mods have been applied, your connections could still be made with 2/3.