Windows file locks
The Network File-Sharing "Lock" Problem
Occasionally, but rarely, users encounter poor network performance as connected with ServiceDesk use (slow access times, permission denials, etc.). Over time, we've discovered many different factors can be involved, ranging from viruses to virus protection software, and sometimes even backup systems can interfere. Occasionally, it's network hardware, and sometimes, it's settings configurations within Windows itself.
Happily, these conditions (as mentioned) are rare. But, unhappily, such matters can be very difficult to pin down when they arise. Even a network expert may struggle.
If you are among the unfortunate for whom this has occurred, we hope you'll first understand that, though ServiceDesk may be uniquely affected (i.e., among applications you run), it does not mean it's at fault. You likely do not have any other applications that involve anywhere near the kind of intensive file sharing -- among multiple and simultaneous active users -- that ServiceDesk must manage. This makes it uniquely vulnerable to any performance faults in your network.
In particular, for effective sharing among multiple users, it's crucial that files on the server can be accessed and released rapidly by any station. If your system causes any significant lag in such respect, ServiceDesk performance will suffer.
In May of 2011, we discovered a particularly galling situation in a client's network with 14 stations, using Win7 as the server and with a mix of Windows platforms as clients (i.e., some XP, some Vista, and some Win7). We discovered that after a Win7 client accessed (but immediately released) a file on the server, there were typically several seconds before an XP client was granted access to the same file. In other words, the Win7 client's access triggered a several-second lockout against XP clients.
The situation was extremely odd. We determined no lockouts were triggered by XP clients against others or Vista clients against others. Nor were the lockouts triggered by the Win7 clients applicable against other Win7 clients or Vista clients. It was solely a case of a Win7 client access triggering a problem (duration of many seconds) against XP clients.
We do not know what configuration-setting details stood behind this bizarre situation (as a platform issue, it was the client's responsibility to resolve it). Regardless, we should provide all users with a tool to detect if anything similar is occurring in their networks.
That is the tool you have opened. What it does is as follows:
When you click the "Test" button, it creates a particular file in the \sd\netdata folder on your ServiceDesk server. This is a file each station (assuming ServiceDesk is running at it) will quickly open and close (they're supposed to; it's a file they're programmed to check any time it appears). The test waits two seconds and then attempts to delete the file. Assuming there has been no file-lock malfunction as described above, the deletion will succeed, and the test will report success. Otherwise (i.e., if the file is improperly locked in due to another station's brief access), the deletion will not be permitted, and the tester will report failure. Regardless, it will keep attempting to delete (for up to 30 seconds) and report on its continuing effort.
We suggest you run this test while ServiceDesk runs at each station in your network. Because it's a "sharing" issue, the test is irrelevant unless ServiceDesk is running at other stations. Do the test from each station, and do it several times at each (we've found the mysterious lockout only occurs sometimes, even within configurations that are otherwise prone to it). If you're consistently green at every station, give yourself a green light on this issue in general. If otherwise, you've got a severe problem that must be addressed.
In this regard (i.e., if any station does flunk), we suggest you engage in a troubleshooting process, much as we did in that client's network, to reach the conclusions described above. In other words, once you've found a station that encounters the symptom, see if stations of the same Windows type do, too. See if stations of other Windows types do or do not. Then, close ServiceDesk at various stations while repeating the test at a station that exhibits the symptom. By trying the test, successively, with various other stations simultaneously running ServiceDesk or not, you should be able to determine precisely what combination (or combinations) cause the issue. It's what we did, and it is a simple process. It provides some very telling information, at least as needed for further work.
Whether your network has a mix of platforms similar to what we encountered with the client or not, it's possible (at least so far as we know) that this file-locking fault may occur in various situations. If you have performance issues, we urge you to invoke this test thoroughly. If you encounter the lockout, we'd like to hear whether it happened precisely with the same cross-platform dynamic above-described or with some other configuration.