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, when they arise, such matters can be very difficult to pin down.  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 -- as ServiceDesk must manage.  This makes it uniquely vulnerable to any performance faults as may exist in your network. 

In particular, for effective sharing among multiple users, it's crucial that files on the server can be accessed and released with great rapidity, by any and all stations.  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).  What we discovered is that, after a Win7 client accessed (but immediately released) a file on the server, there was typically a period of 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 there were no lockouts as triggered by XP clients against others, nor by Vista clients against others.  Nor were the lockouts as triggered by the Win7 clients applicable against other Win7 clients or against 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 very weird situation (as a platform issue, it was the client's responsibility to resolve it).  Regardless, it occurred to us we should provide all users with a tool to detect if anything similar might be occurring in their networks.     

That is the tool you have opened.  What it does is as follows:

When you click on 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 check any time it appears).  The test waits two seconds, then attempts to delete the file.  Assuming there has been no file-lock malfunction as above-described, the deletion will succeed, and the test will report success.  Otherwise (i.e., if the file improperly locked in result of 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 is running at each station in your network.  Because it's a "sharing" issue, the test is not truly relevant unless ServiceDesk is, in fact, running at other stations.  Do the test from each station, and do it several times at each (we've found the mysterious lockout does not occur consistently, even within configurations that are otherwise prone to it).  If you're consistently green at every station, give yourself a green-light in general on this issue.  If otherwise, it follows you've got a very serious problem, and it really, really must be addressed. 

In such 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 above-described.  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 other 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 is not a complex 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) this file-locking fault may occur in a variety of situations.  If you have performance issues at all, we urge you to invoke this test thoroughly.  If you do encounter the lockout, we'd be interested in hearing whether it happened with precisely the same cross-platform dynamic as above-described, or with some other configuration.