Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP application on newer Windows Server OS. Previous thread says Oplocks cannot be disabled.

Status
Not open for further replies.

wtotten

IS-IT--Management
Apr 10, 2002
181
US
thread184-1792486

The thread I noted above has a reply from VFP superman Olaf where Olaf states that Oplocks cannot be disabled on Windows Server (newer versions) and that these registry settings are to be set on each client.

I have a very busy application running on a Server 2008 R2 server (50 users on a LAN and lots of data) where I have disabled Oplocks and disabled SMB2 and SMB3 on the server.
I also have the registry setting on the clients to not request a Oplock.

I am going to be moving to Server 2019 shortly and expected to take the same approach, but seeing Olaf's post, I need others to confirm what I am to do regarding the well-known issue with file corruption with VFP tables in a LAN environment with the data stored on a Windows Server server.

Olaf stated:
Nowadays oplocks can't be disabled. It's a really high risk to run an old enough Server where SMB can be configured about that, as RANSOMWARE exploits vulnerabilities in older SMB versions. So forget about learning whether that's turned on or off. You should assume it's always on and set these keys on each client within setup of your application:
CODE
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

1. Can others confirm if this is true - is this the approach necessary to avoid the VFP file corruption problem?

2. I have four servers and there are times where I have one of the servers access the VFP application running on another server (where a server (not the one hosting the VFP application) is a client). Do I put these same settings in the server's registry or will that cause problems?

3. If this is in fact the registry setting I should have on the client for newer server OSes, do you see any reason why I shouldn't add it to the existing clients and Server 2008 R2 setup I have running now?

Thanks everyone.

Bill

 
I loathe op locks and it's a shame M$ didn't do something about them earlier.

However, I think they may have done now (2016)…



Can't say for certain, I don't have a 2016 server to hand.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
That's good info, Griff.

By the way, the whole line of arguing about disabling oplocks is, it was only possible in Smb2 or 1 and the MS FixIt, that once was promoted to disable oplocks did both revert to SMB2 or 1 and disabled that. The SMB3 does not have a disabling option, it doesn't react to the reg keys disabling oplocks.

The article I linked you to earlier mentions the Powershell commands necessary to Detect and Enable/Disable SMBv1, v2 and v3 and I asked you to look into it:

It is lengthy and still doesn't go into the details, actually it still indicates you can only disable oplocks when reverting to SMB1 by disableing SMB3 and 2 and that's bad. The article header strongly recommends to only do so for temporary problem solving, not as a solution to our VFP oplocks problem, but the FileLease option Griff links to looks promising.

Bye, Olaf.





Olaf Doschke Software Engineering
 
Griff - thank you for the information on LeasingMode. That is extremely helpful.

Olaf - the information you provided re: the registry entry, am I correct in understanding that it will solve the corruption problem regardless of what the Oplocks or SMB settings are? My client's environment is Server 2008 R2 and Windows 10 and Windows 7 workstations.

Thank you,
Bill
 
You won't need anything else than what Griff recommends, when it is what I understand it to be. At several times I muttered already, that it would be good to give an application the final word on whether it wants oplocks or not. And this is now allowing to specify that on the level of a share.

I'd recommend you only try one thing at a time this and don't combine all tips you find all at once, as you then finally won't know what actually helped.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top