Yes, there is a recommended fix I got from Microsoft, via the Reactive Onsite Support Services team (ROSS) who were fixing an incident in the US at the same time I reported the problem.
Our symptoms:
After upgrading from WinNT4 Terminal Services to Win2000 Terminal Services, we had a sudden rash of 1104 errors. Usually over 100 a day. Also some 2005 errors (reading .SCX forms out of the .EXE file!) with the same ultimate "error reading file" message in the error report.
It would happen towards the end of a shift, where large numbers of users were logging out. Those users had started up the application early in the day and had not left the one screen they use (consultant support enquiry) probably for the whole day. Once one user found the error on logging off, all other users would see the same error.
Our guess at why:
While buffering at the redirector level and reusing connections, something gets screwed regarding the number of uses of the connection. When the first user who had the .EXE file open logs off, their connection is closed. Somethign goes wrong in the reference counting and the connection is
really closed for all users - hence the 2005 errors.
When a user logs off and closes the database and tables, again the connection is closed. This again affects all users of the table because it's marked as not in use rather than not in use by this user.
We never investigated it after the fix :)
But we did notice that the erorrs tended to cluster on a per terminal server basis, as if it wasn't the file server causing the trouble. Some days we sould get errors only on one terminal server out of the five.
I suspect our IT Ops team didn't know the exact configuration of the NT4 servers and didn't move across a registry setting that fixed this problem under NT4.
History:
This seems to go back to NT3.51 with Access and FoxPro databases. There was a documented (KB article) registry change to turn off write behind and caching. Though the registry keys have changed, the intent of the fix (and the underlying bug perhaps) seems to be the same.
Our solution:
Apply the fix below to the Data server and terminal servers.
The only remaining 1104 errors were traced to a faulty 1Gbit fibre interface card in the inter-server backbone switch.
The registry entries below were a complete solution for us.
THE FIX from MSFT:
"---------------
This KB does document a hotfix, which did not work for this customer.
The following RegKeys did however resolve the problem:
Changes:
On the Windows 2000 sp2 Terminal Servers we added the following registry
Keys:
HKLM\System\CCS\Services\Mrxsmb\Paremeters
OpLocksDisabled
DWORD: 0x1
HKLM\System\CCS\Services\LanmanServer\Parameters
CachedOpenLimit
DWORD: 0x0
HKLM\System\CCS\Services\LanmanWorkstation\Parameters
UtilizeNTCaching
DWORD: 0x0
HKLM\System\CCS\Services\RDR\Paremeters
UseWriteBehind
DWORD: 0x0
On the Windows 2000, sp2 File Server which hosts the FoxPro 6
Application we added the following registry keys:
HKLM\System\CCS\Services\LanmanServer\Parameters
EnableOpLocks
DWORD: 0x0
HKLM\System\CCS\Services\LanmanServer\Parameters
CachedOpenLimit
DWORD: 0x0
HKLM\System\CCS\Services\LanmanWorkstation\Parameters
UtilizeNTCaching
DWORD: 0x0
At this stage the 1104 errors have stopped. I will monitor the system
on Wednesday, and if no errors the customer has approved for me to leave
the site."
Hope that helps.
