Very helpful, thanks for this. I actually registered at Alaska yesterday, but they just gave me a link to download their trial (but so far not access to log into their download page). However, this is not a big deal as I can easily change those 3 settings in the Registry with Codemine/VFP code, or using my Wise Installer.

>I first saw that Alaska software article some years ago. At that time they were offering an .MSI (IIRC) which as I understood it just created/set those 3 registry values. As far as I know all that's changed since then is now you have to register with them to be able to download it.
>
>There are other ways to make those registry changes, but some things I'm unsure of:
>
>1. A user or process may need elevated privileges to make the changes
>
>2. I don't know if the changes are "hot" i.e. take effect immediately when made. I strongly suspect they are not and that a machine restart is required. I suppose theoretically you could just restart the Workstation service (LanmanWorkstation) but I've never tried that in a running Windows session and I'm not comfortable with that idea
>
>You may also find references to disabling opportunistic locking ("oplocks") with VFP or other peer-to-peer/SMB applications. As I understand it, that's a somewhat different thing which is not a part of this SMB2+ issue we've been discussing so far. I haven't spent much time looking at oplocks, anyone else have any info?
>
>UPDATE: I found some interesting resources:
>http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking
>http://www.dataaccess.com/KBasePublic/Files/2476.Tuning%20Microsoft%20Networks%20for%20the%20Legacy%20Embedded%20Database_PDF_FMT.PDF
>
>Going through the second link, it looks like that paper's origins are in the early days of the SMB2 issue and it gives a good overview of what was known at the time. It rightly points out that oplocks can't be wholly disabled in SMB2+ without completely disabling those protocols. As a workaround it discusses how to disable them and revert to SMB1.
>
>These days, that approach is highly de-recommended (as in no sysadmin would ever agree to it):
>
>- SMB2+ is required for some features in modern versions of Windows, so disabling them entirely is a bad idea
>- SMB1 is very insecure and should no longer be used on any Windows network. In fact, from Windows 10 if I VPN in to a remote network and try to connect to an SMB1 file share on a Server 2003 R2 server (via NET USE), I get this error:
>
>"System error 384 has occurred.
>
>You can't connect to the file share because it's not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack.
>Your system requires SMB2 or higher. For more info on resolving this issue, see: https://go.microsoft.com/fwlink/?linkid=852747"
>
>I might be able to connect by enabling SMB1 on my workstation but that's a truly bad idea.
>
>So, with the idea that SMB2+ should not be disabled, Alaska (or someone else) turned their focus to parameters which could be adjusted. The result is those 3 registry values.
>
>That's the state of the art as I know it.
>
>>Al, thanks so much for the link from Alaska software. If you or someone might have some info/advice on this question, it would be helpful. In reading Alaska info on their install patch to the Registry, it sounds like they are setting these 3 items within:
>>
>>HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\LanmanWorkstation\Parameters
>>
>>and create and set these to 0:
>>
>> FileInfoCacheLifetime
>> FileNotFoundCacheLifetime
>> DirectoryCacheLifetime
>>
>>Using Codemine framework with VFP 9, I can easily do this on the fly. My question (general advice) would be would this be a good idea on my part, or should I require my user's to go through Alaska to get this, or I do it through code.
>>
>>I ask this in case there is something in the Alaska install that I am not aware of.
>>
>>Or are there any other registry settings I should be aware of that pertains to this issue.
>>
>>Any advice is appreciated.
>>
>>
>>>>I suspect this topic has been dealt with before. Can someone give me some links and general advice on when Microsoft Windows changed a setting which has the potential to cause data loss and how to correct this before it happens using latest release of VFP 9. I believe it is a regedit setting.
>>>>
>>>>I am hoping there is an install package I can include that will take care of this.
>>>>
>>>>Thanks in advance....
>>>
>>>Thomas' main point is well taken. However, if you need to use native VFP data tables on modern Windows networks, the generally accepted best practice is to set some registry values on "workstations" per http://www.alaska-software.com/community/smb2.cxp .
>>>
>>>A "workstation" is any Windows computer which runs a VFP executable. These days that can mean:
>>>
>>>- a physical Windows workstation
>>>- a Windows virtual machine in a standalone VM environment or a virtual desktop in a virtual desktop infrastructure (VDI) environment
>>>- a session on a Remote Desktop Services host computer (formerly called Terminal Services)
>>>
>>>Those settings do NOT apply to computers which only store the VFP data files and which do not run any VFP executable.
>>>
>>>They are a response to issues introduced with SMB 2 in Windows Vista. At that time they first manifested as index corruption. I don't recall seeing any incidents of true "data loss" per se but a corrupt index can make it look like rows are missing, even if they are still present in a DBF.