Heart-Profit ERP

I'll put this in English, so more people can benefit.

Some sites exhibit strangenesses regarding File Read errors and other sh*t like (static) files not being found while they clearly exist;
We've even seen one PC being able to access folders and content nicely, while another is told the folder is empty.
The below should be the explanation. Please keep in mind, it is my own explanation, though derived from other related issues I found on the Internet.

A main protocol used to "share" data from a (file) server across the network is "Server Message Block communication" or SMB.
Today, since Vista, there's SMB2 - an improved version of the standard SMB. The main difference in SMB2 is that SMB2 is smart to the sense that it recognizes whether only one user is accessing the file, and in that case far more caching is provided. Say it requires far less communication with the server where the file concerned is held, and therefore things speed up vastly. Ok ...


The clients -where the caching is applied- need to be SMB2 enabled just the same. This means they need to be Vista and up.
Do notice that officially SMB2 can not be disabled. Also notice that SMB2 is not much of an explicit setting etc. at the client side, and that this is a setting only at the server side. However, the client contains "opportunistic locking" settings/features which collaborate with the server side settings. "Opportunistic locking" may be read just like the first word tells : we assume all on the sunny side of life, and without unexpected anomalies we will be able to cache things (read and write) without corrupting tables or files. But things got too "opportunistic" here ...

In collaboration with SMB2 (read : the server is Vista or up) opportunistic locking at the client side can not be switched off. There are registry entries for it, but whatver they are set to, O.L. stays active. Ok ... should be for a good reason. But now there's one small problem : clients under Vista (XP, W2K) do not support the SMB2 protocol. And yes, now it's starting to smell funny.

XP and under, *do* allow to switch off O.L. and when all MS developers thought all over in well fashion, it still should be able to work together with the Vista and up machines. But personally I think that even I would not be that smart. I would forget about a few things;

It is clear to me that the sheer fact that SMB2 has knowledge about more than one client accessing a file, somehow has to go along with clients telling about this. So what if clients which do not support SMB2 do not tell about this at all ? or at least that something would be missing in this "communication" ? Then the one client with SMB2 would be happily caching the (written) data while the other without SMB2, well, would write through her changes to the table. And boy, would we be in trouble then.

All we see happening sure looks like related to the above description.

On a side note, I don't think we ever saw any issues with O.L. being on at the client side, unless from the Novell times and Novell clients. But with the MS clients ? no, we left all to default always, and it looks like O.L. being on then.

At the client, you can check out this Registry entry for it :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters and the entry OplocksDisabled = 1
Is the OplocksDisabled entry not present ? then it will be ENabled.
Remember, don't start adding this entry with SMB2 enabled (see below) because it won't do a thing, plus the solution has to be a different one.

Solution (well, hopefully and for us yet to see) :

Go to your server room, find your servers, and go to this Registry entry :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
In there add this DWord entry : SMB2
and leave its value 0.
Reboot to make it work. Ehm what ? the former (pre Vista) SMB protocol.
Apply this to all your servers.

Might you later want to re-enable SMB2, set the value to 1 or delete the entry.

What you just did is implying a consistent communication situation for all of your clients.
Nothing will happen anymore about a first client using a file being (way) faster compared to when a second client logs in to it. But hey, this is a database environment and nobody here works on his/her own on the database. So, smart that SMB2, but really useless. For us, but possibly for most. And, too complicated if you ask me.

A last thing, before you dive into matters yourself and find that Vista/SP1 / W2008R1/SP1 solved some issues here. Yes, some issues were solved, but I don't think all were.
Also, the chance of running into the issue possibly is not *that* large. I mean, when a second user logs on to the file and like the first one it's a SMB2 user, a third not using SMB2 will not see/create the problem because behavior already (sort of) dropped back to old SMB (induced by the server). Possibly it is even so that the problem only starts to emerge when the first user is an old SMB user.

From of today the couple of sites experiencing the problems will apply above mentioned solution. It will fairly soon be clear whether it solved the issues or not, and either way we will report.
Maybe in a following post we'll sum up what actually can occur while having the issue.

Peter