Oplock when installed on local pc but data is on network server?

[Vince Wen]

I've read all I can on this forum re: oplock with VFP9 application on a network server.

My question is a little different.

What about if the application is installed on a local pc, but the data is on a network server? Would this setup still have the same oplock issue?

Logically, I think it would, but I wanted to double-check this.

ps. I am a newb. So apologies in advance if this question is basic.

-vince

 

[ManniB]

The problem often talked about is when you run a VPF application on your local PC, but the data is on another workstation or "server". Then issues with oplocks etc. can appear. When you have all the data on the same PC as the application (hence a single user application), then there shouldn't be any problems with oplocks.

There are system settings in the newer Windows versions (powershell commands) to prevent oplocks and caching on the server, so VFP can run savely even when the data is on a different pc.

Regards,
Manni

 

[Vince Wen]

Thanks Manni. I think you've answered my questions ("yes, same issue").

ps. I am aware of setting leasingmode to none, if that is what you are referring to. Unless there is another way?

Thanks.

 

[Chris Miller]

As Manni already said oplocks problems occur, when data is on a different computer than the application. The details, whether that's a server or another workstation on a workgroup network don't play a role. Oplocks are not just a feature of servers.

On top of that, people also talk of "applications on a network server" when they store an exe on a server network share and run it from there. The stress is on "from". They don't run it there, it's still run on the client and that makes it the same situation as a local application getting data from a server.

It does help if EXE and DBFs are on the same server and you operate with RDP, but if the EXE is only located on a server for centralising that EXE file for all clients and it's executed on clients, that's still the situation the EXE runs on a different computer than the DBFs. It's not about where files are, it's about whether the process runs on the same computer that has the data or not.

RDP is also not a general solution against the oplocks problem, when the terminal server nodes clients connect to still have to get their data from yet other network file servers. RDP with application and data on the terminal server or a single user application on a pc, networked or not, kill the oplocks problem as the process running doesn't get at DBF files through the network.

 

[ManniB]

Thanks Manni. I think you've answered my questions ("yes, same issue").

ps. I am aware of setting leasingmode to none, if that is what you are referring to. Unless there is another way?

Thanks.

Yes, that's essentially the setting you have to deactivate on the server (where data is stored) when using SMB-2/3 (default in Windows 10/11) with VFP. The oplocks setting is relevant only for SMB-1, but it's not recommended by Microsoft to go back to SMB-1.

 

[Chris Miller]

That's an outdated truth, Manni, there was an SMB3 Leasing Mode change introduced in Windows 10 build 16215 and Windows Server 2019 that makes it feasable instead of needing SMB-1.

I wonder if I misunderstand you, but it seems to me you say the leasingmode none only works on SMB-1, which is not true. It's actually there to enable working with SMBv2 or later.

The leasing mode is set for a share, on the computer that hosts that share, so usually a server, that's right, you can't set the s leasing mode of a share from the client side.

But when you're able to set leasingmode to none for a share on a network, that enables VFP applications to use DBFs from that share without oplocks, also for SMBv2 or 3 or higher.

 

[Joe Crescenzi]

I'm just adding my agreement to what has been said so far.

The problem is based on where the data is stored, regardless of where and how the exe is run.

Before I started making Remote Desktops my main way to run my programs, I used to use two .REG files that changed the Optimistic Locking parameters, one for the client, one for the server.

Then I used a utility called OpLockSet that cost about $15 to all my setups when I used to use file servers. It also let me confirm and change a few other settings, but as it stands now, I closed the door to file servers so I not only eliminate the problem, but my applications run ridiculously faster because of the benefits of local access vs network bottlenecks, not to mention the caching.

 

[Chris Miller]

regardless of where and how the exe is run.

Don't agree on that completely. And RDP run application that has application and data on the same terminal server runs network free from the point of view of the application and thus needs no oplocks and works with any SMB protocol that server uses as a server or as a client, as it doesn't make use of SMB at all, it runs on local DBF files.

You still use the network as an RDP client connecting to terminal server, but for the RDP protocol and getting the desktop displayed on your client side, that's not using the network for file access, that's killing the problem that way.

What needs to be known about leasing mode and oplocks is that SMB2.1 advanced oplocks to so called leasing-oplocks. SMB1 up o SMB2.0 used an older oplocks mechanism, That's why you can solve the oplocks problem by turning off oplocks in SMB1 or turning off leasing mode and thereby indirectly also turning off oplocks that now operate on the basis of leases with SMBv2.1 or higher. And as said, you set the leasing mode for a share and can only do so on the computer that defines and hosts the share. That doesn't turn off oplocks for any other file access on other shares, so that's the solution that doesn't effect all applications, only a share and also not the whole server or client. It would still be even more ideal for us as VFP application programmers, if there would be an opt out of oplocks or leasing mode for our application - the process. And maybe per file or directory. Because we still require the cooperation of admins to make it happen. At least you can argue with them, now, that it's not for all the server and all applications.

 

[Joe Crescenzi]

My point is that RDP eliminated the Oplocks issue completely for me without asking my client's IT people to change the default SMB settings on either the clients or servers. While there still is network traffic to display the screen, it's much less traffic than you'll see if you continuously access gigabytes of data just to run reports.

Here's the benefits I've found:

1. I only need to install the runtimes once, on the RDP server.

2. No Optimistic Locking issues.

3. The application is more secure, because remote apps don't also give individual users access to the filesystem. They run the remote app, and they never see the folders. This is a great way to protect them from Ransomeware or accidental file deletion or meddling in the folders.

4. Speed.

5. Speed.

6. Speed.

Did I mention speed? Yes, speed. I've seen reports that used to take minutes complete run in under 10 seconds.

 

[Chris Miller]

I had that for a larger customer, that wouldn't be able to support all about 100 users on one terminal server, so they had a terminal server "farm" and the data was still on yet other (file) servers. Such a situation introduces the oplocks problem, again, you cannot solve it with terminal server and RDP for all situations because you cannot dimension a single terminal server with locally stored DBFs for any number of users, concurrent users, using the application (and data) at the same time. It's not that scalable.

 

[Joe Crescenzi]

Agreed. I've never needed to scale a traditional dbf project that large, so there is no one size fits all.

With larger numbers of users, you will still likely use a file server, but at least you won't need to adjust the optimistic locking parameters for every workstation.

Thankfully if you have that many users, you likely use faster networking from the farm to your storage.

I've only had a couple of projects that needed large numbers of users. For those, I used SQL.

 

[Chris Miller]

When your database backend is MSSQL (or any other database server), then the problem is already solved that way. RDP then is used for other reasons, like that of reducing workstation maintenance and user interference , needing less effort in policy management, for example.

 

[GTGeek88]

My point is that RDP eliminated the Oplocks issue completely for me without asking my client's IT people to change the default SMB settings on either the clients or servers. While there still is network traffic to display the screen, it's much less traffic than you'll see if you continuously access gigabytes of data just to run reports.

Here's the benefits I've found . . .

Ok, but Remote Desktop Services is not so easy to set up and now requires a second server for the broker (at least in the recommended setup). And the servers have to be very beefy to handle more than just a few users.

 

[GTGeek88]

Thanks Manni. I think you've answered my questions ("yes, same issue").

ps. I am aware of setting leasingmode to none, if that is what you are referring to. Unless there is another way?

Thanks.

So it would appear I can set leasingmode to none with this PowerShell command:

Set-SmbShare -Name "<ShareName>" -LeasingMode "none" (not sure if none needs to be in quotes or not)

And I can get shares with this PowerShell command:

get-smbshare

Do you feel other settings need to be modified based on your research? There used to be a good deal of info on this issue in the FoxPro Wiki before Steven Black decided to selfishly take it down.

 

[Joe Crescenzi]

Ok, but Remote Desktop Services is not so easy to set up and now requires a second server for the broker (at least in the recommended setup). And the servers have to be very beefy to handle more than just a few users.

It's definitely not for everyone, but I found a few easy ways to make it happen for my clients without any expensive hardware or software.

My smallest client runs 5 terminals on a computer smaller than a Mac mini, that cost me under $700, including the software needed to run the RDS. I secure it using DUO for 2-factor authentication and block the users from using it for anything but running my program.

Larger clients use either Amazon or Azure to run a much larger number of users.

 

[Chris Miller]

Sure, wthin the cloud it's far easier to scale. On the other hand in my case the customer wanted a solution on premise (in house).

We did this switch to RDP as it was a relief of the oplocks problem, far before the time turning off the leasing mode was available. Earlier they used the oplocks switch off by providing an older server OS for the DBF file shares. They had a lot of VFP applications, across several VFP versions, not enough man power to convert up to VFP9 even less so away from Foxpro. 2 or 3 applications also were reimplemented with SQL Server backend. Anyway, there was a time when the administrators were not happy anymore to have an outdated Windows Server running for that and though there was no light at the end of the tunnel in sight the switch to terminal server helped to minimize the problem as then the terminal servers were closer to the file servers and that made network traffic much more stable already.

The trend later was to actually switch all their Foxpro based software suite and replae it with something like SAP. That decision overruled long plans to migrate steadily to the dot net world by change of management. Bad decisions, if you ask me. But this is not about their or my story.

You can be happy enough for the leasing mode solution. And Microsoft based RDP is not the only solution that is available to work like that. So you still have multiple options, of which defining (or requiring it from customer IT department) a file share with leasing mode none is a DBF friendly solution. A Terminal solution always sounds technically difficult, but it's more about administration than any other changes, because for your software nothing has to change. The core terminal (host) server runs your software, just ona server Windows version, not a workstation Windows Vista 7,8,10,11. VFP works on Server Windows without any problems, too, so there's no need for changes. The rest of the world may still be another Windows Server, there's no change in that. It is not even necessarily your task to provide the rdp files used for connecting (or other means like Team Viewer connections starting a software remotely). Client devices can easily also be Other OS based Tablets, etc.

I'm not up to date with client licensing prices, etc. MS I think is still not cheap for providing software on Terminal Servers with client access licenses. One advantage of VFP software is, that it often has a smaller RAM usage footprint as other software, so you can cater for multiple users. It scales better then at the time I did this about 10 years ago, hardware advanced, Moore's law is still going very strong if not better with RAM scaling.

 

[Joe Crescenzi]

I took some major shortcuts for my smaller clients. I found a couple of dirt cheap terminal server alternatives, including TSPlus and ThinStuff that run on plain Windows 10 Pro or Windows 11 Pro.

I settled for ThinStuff. You can just install it, create user accounts, put icons in the public\desktop folder and you're good to go in 5 minutes.

Taken to the next level, you add Duo for authentication, turn off access to the Internet from Edge and they can even get a full Windows 11 Pro desktop experience.

For added security, you can configure it to just push your app as a Remote App, so they never see the desktop and your app just runs like a built-in program.

For the bigger clients, I defer to their IT people who tend to use Parallels, Cytrix, AWS, or Azure. The Azure clients now have an even easier option that Microsoft just rolled out called Windows 11 Desktop With MultiSession. Basically, it's Windows 11 Pro without the 1 user at a time Remote Desktop limit.