>Hi All,
>
>Apologies in advance for rehashing old ground.
>
>We have inherited an old VFP 9 application where the DBFs and exe are run from a shared folder on a 2003 server. There is a mix of Windows 10 and Window 7 clients on the network that all have the shared folder mapped as drive G:. This is a mature application and has run for years without issue.
>
>As we want to replace 2003 with either 2012r2 or later I was hoping that someone could point me to a definitive article on the steps required to prevent the data corruption issues I have read about. It is not a viable option at this stage to convert the application to a SQL server back end, and the users would prefer to keep operating the same way rather than run the application in terminal server sessions which I understand is a common workaround.
>
>They also have an MS Access application were the back end tables are stored on the same drive. Are the changes necessary for VFP also applicable to Access or will VFP and Access have competing requirements. If needs be we can host the Access application on a different server.

I've been following this issue for some time. My best understanding is per this article: http://www.alaska-software.com/community/smb2.cxp

Basically, those registry entries should be applied to all computers running your app, which could be:

- Workstations
- RDS hosts (i.e. Terminal Servers) which host sessions which run the app
- Servers where console sessions are started up (local or remote), and the app is run in those sessions

All of the above may be actual hardware, or VMs - makes no difference.

One scenario where you do NOT have to apply the registry changes is to a server computer or VM which only hosts shared data files, and your app is never run directly on that server.

The requirements for MS Access are the same as for VFP. The original advisory/MSKB article issued soon after the release of Windows Vista said ISAM "file-server" databases were affected, and specifically included MS Access. As I recall it some VFP community members spent considerable time with Microsoft support trying to address this issue.