>>>>>>>>>>regarding the categories for OS, Network - it's really 2008 server r2 for both, VFP on terminal server.
>>>>>>>>>>
>>>>>>>>>>We have two separate errors in two separate terminal server environments:
>>>>>>>>>>
>>>>>>>>>>1) On an app that hasn't changed in a really long time, nor the OS or terminal server. Upon opening a form we got
>>>>>>>>>>'Error reading file'. If we went into any terminal server session from any desktop or thin client, and tried to open the same form in the app, we got the error. But if we went into the app from a regular desktop non/TS environment, the form opened fine.
>>>>>>>>>>
>>>>>>>>>>I kicked everyone off the TS and restarted it, and the problem went away. Any ideas? Any MS updates affecting TS environment?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>2) On another Terminal Server environment, we just setup a new vmware virtual machine as a TS - windows 2008 server r2
>>>>>>>>>>file server for the vfp app is also win2008 r2. There is a weekly batch routine that one user needs to run - close orders - requires that everyone be off the system - and needs to gain exclusive access to a table. All users exit - for all intents and purposes it looks like there are no open files anywhere on the system. When the user tries to close from within a TS session, it tell him the file is in use by another (I think that's the message - that's what I was told - in any event the lock can't be obtained) However, the same as #1 above, if the user starts the VFP app from a regular desktop non/TS environment, he is able to get the lock and proceed.
>>>>>>>>>>
>>>>>>>>>>This environment (item #2) was just migrated to a new VMWare environment and new TS. However, this problem with the exclusive lock is longstanding - had it in the previous environment - not vmware, but still 2008 server r2.
>>>>>>>>>>
>>>>>>>>>>A year and a half ago, in this non vm environment, wary of 'SMB2' issues, I had disabled SMB2 and did a bunch of other stuff supposedly related to potential issues - but the exclusive lock issue still remained. In the new TS environment, I haven't disabled SMB2.
>>>>>>>>>
>>>>>>>>>I don't have any answers, but if you can't obtain a lock, that implies the OS thinks someone else has the file open, with or without a lock. Have you checked to see who has the file(s) open when the problem occurs? http://www.techrepublic.com/blog/datacenter/server-2008-manage-open-files-with-share-and-storage-management/315
>>>>>>>>
>>>>>>>>Al, that's the maddening thing. share and storage management shows no open files no user sessions. And it works fine if the user attempts the same operation from a regular desktop machine. So I think that somehow the TS is not keeping track of file handles properly? Back in about 2002, in ts/citrix win 2000 environment we had a huge problem with ts/citrix losing track of file handles - forget how that one was solved - but I thought these problems were long gone. In that case we got repeated error reading file errors and repeated index corruption.
>>>>>>>
>>>>>>>I found the reference to the 'file handle count' problem I was referring to... but this refers to windows 2000... hoping this problem was long gone... but it seems that is similar to what we are experiencing now, especially for item #1.. not sure about item #2
>>>>>>>
>>>>>>>http://support.microsoft.com/default.aspx?scid=kb;EN-US;299603
>>>>>>
>>>>>>That article seems to apply to the case where, within a TS session, you're accessing files on another computer, either via UNC names, or a mapped drive. Is that your situation? If so, can you test by copying data to a "local" drive of the TS (and not using UNC or mapped drive)?
>>>>>>
>>>>>>Like you, I'd think MS has put a *lot* of work into TS and its protocols and redirectors since 2000, and problems like this should have been ironed out.
>>>>>
>>>>>I read the article, and thought that's what they mean, i.e. local to the TS, but wasn't sure... good to hear confirmation that that's what they mean. And yes, that applies to us. The vfp files are not local to the TS.. they are on another win 2008 r2 box. So, it seems like a really good place to start.
>>>>>
>>>>>With respect to your other reply about op locks... I researched this a while ago and will revisit... and get back to you again.. but my recollection is that the disabling of SMB2 and the op locks problem are connectected... i.e. disabling SMB2 disables op locking? Not sure, but I'll look it up again. But even with SMB2 disabled (at least I think it is) we still had this persistent problem in the 'old' ts environment. In that case, we had 5 machines on TS and 20 'regular', but now, we have moved to an all TS environment, and it is proving to be a big problem.
>>>>
>>>>Have you been able to rule out antivirus? That's absolutely the first thing I'd do in your position.
>>>yes... did a test where there was no real-time antivirus running - still can't get exclusive lock in scenario #2
>>
>>OK, for discussion's sake, let's suppose your two separate servers are "TSServer" and "VFPServer" for the Terminal Services and VFP data files, respectively.
>>
>>I don't mean to harp on about AV, but are you sure you did a clean test? If you haven't done so already I'd recommend:
>>
>>- Restart TSServer
>>- On TSServer, before anyone runs any app that accesses data files on VFPServer, turn off AV real-time scanning and any other components that might interact with VFP data files and temp files folder(s)
>>- Ideally, turn off equivalent AV functions on VFPServer (if present)
>>- Test that a separate workstation can get a lock on a file when communicating directly with VFPServer
>>- If successful, fire up one session on TSServer and see if you can get a lock
>>- If successful, try with 2 or more sessions, locking and unlocking, to see if it works as expected
>>
>>If, for example, you've been running VFP apps on TSServer for a while with AV enabled, I wouldn't consider just closing all VFP apps/sessions and turning off AV to be a "clean" test. Who knows what sort of caching or locking AV may do behind the scenes, which could still be in force if the server has not been restarted?
>
>Al, believe it or not, there is NO AV on the TS, and there hasn't been. This new TS has been up for about a month.... it was on the network consulting firm's to do list... but... so, I can say with certainty it wasn't done. When I said we had done a clean test, it wasn't done by me personally... I was getting 3rd hand info, which was wrong. When I pursued it further I realized that there was no AV software on there at all! (We will correct this)
>
>Anyway, in the meantime we have moved all the data 'local' to the TS to a new f: volume (not a share). This is as per Microsoft's (old) instructions. Before the end of the week we will try the batch routine at night to see if we can get a lock.

Well, from the POV of trying to figure this out, having no AV on the TS is actually ideal :) (unless it's infected with something). A lot of TSs run "canned" environments, so if user sessions aren't accessing the Web or handling e-mail, there may not be a lot of attack surface.

For testing, were you able to appropriately disable AV on your VFPServer? I suppose that could be moot if you've moved the data local to the TS for testing (or permanently, if that works).