nice summary. Stealing from Docker thinking I sometimes wonder if it would be better to run vfp apps solely in VMs working in NT4 or W2K - as long as no internet server is running on the VMs and no browsing is done inside those (better still, browsing there is disabled). Huntig after SMB changes in MS versions reminds of some classic greek tragic tellings...

>>we have a 10 station Visual FoxPro application running on Windows Server 2016 (upgraded from Windows Vista).
>>We have 100's of these networks currently running on Windows 7, Windows 8, Windows Server 2003, Windows Server 2016, an so on without any issues.
>
>Windows Server 2016 is very new, I assume you meant "... Windows Server 2003, Windows Server 2012, and so on..."
>
>>However, The Local IT Tech stated the following in his most recent email trying to trouble shoot random "Error Reading File" across the network.
>>The question is, Is the following statement true?? After I wrote to him that we are using VFP Databases he wrote back?
>>
>>I was afraid of that. As I'm sure you know, Visual FoxPro reached end of life status several years ago, and file sharing in the newest version of Windows rely on SMB2 and SMB3 for a number of features. I located a number or forums where users of programs built using foxpro are experiencing eerily similar issues, that is, file cannot be read, etc. I am going to trial some setting and rgistry changes on the two design computers, and if successful, will deploy to other workstations. Jen, if you could continue to have staff log errors, and email me them at lunchtime and at the end of the day, that will be a big help. Thanks!
>
>Because Server 2016 is so new I haven't yet heard of anyone else running VFP table-based apps with shared tables on a WS2016 server. Congratulations on being the first! {g} I for one would be interested in hearing about your experiences.
>
>The state of the art re: SMB2 and SMB3, as far as I know, is outlined at http://www.alaska-software.com/community/smb2.cxp . Basically, that page recommends creating and/or setting some registry entries on each workstation that runs a VFP app that accesses shared tables. Those registry settings configure SMB2 and SMB3 without disabling them completely, which is a bad idea for Server 2012 and later. There's an overview of changes between various versions of SMB at https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/ .
>
>Server 2016 introduces yet another new point version of SMB (3.1.1). From a quick glance at https://blogs.technet.microsoft.com/josebda/2015/05/05/whats-new-in-smb-3-1-1-in-the-windows-server-2016-technical-preview-2/ I don't see any earth-shattering changes that would make its behaviour affect VFP any differently than earlier 3.x versions on Server 2012. My guess is that applying the Alaska Software registry settings should work as effectively for Server 2016 as for Server 2012/R2.
>
>A note about testing: the registry settings should be applied to *all* workstations running the VFP app. So, when testing them for effectiveness *all* the workstations running the app should have them applied. For example:
>
>Scenario A:
>
>- 10 total workstations running the app
>- Registry changes made to 2 of them (but the other 8 are still running without the changes)
>
>In this scenario, on the other 8 workstations SMB may "misbehave" and cause the app on the 2 changed workstations to still show the errors. This is an incomplete and/or unfair test.
>
>To test properly you should either:
>
>- Apply the changes to all 10 active workstations, or
>- Shut down the app on the 8 unchanged workstations, and test with only the ones that have been changed
>
>These days, VFP desktop apps are being accessed more and more often via sessions on shared Remote Desktop Services servers or equivalents such as Citrix. Each of these sessions is effectively a workstation running your VFP app, so the SMB registry settings should be applied on the sessions host such that they are effective for each session that is run on that host.
>
>Antivirus has been known to interfere with the proper operation of VFP table sharing across a network. If there is AV running on the new WS2016 server, it might be very new and still have some issues. It might be worth, for test purposes, temporarily turning off real-time scanning on the server or excluding VFP data table folders from real-time scanning.
>
>With the "upgrade" from Vista to WS2016 there could be other hardware and configuration changes made. It might be worth reviewing Message#1620380 .
>
>Some other posts I've made on this topic:
>
>Message#1620274
>Message#1620358