Environment:
Windows XP sp3, Windows 2003 server
Problem:
We have several dozen kiosk machines each with the same logon name who occasionally and briefly a file on a share. The rate is several locks and releases a minute.
Recently, we have experienced one of the clients locking a file exclusively, and then not releasing the file.
We can close the file when this happens, but several minutes or longer elapses, and this is an unacceptable outage.
The unreleased lock issue has happened several times in the last month. I've been looking for which kiosk device is responsible for the locking, and to detect it quickly when it happens.
There appears to be a gap in the information we can get from the server:
We can see from various tools:
-What files are open and locked. (many ways)
-What logon has a specifc file open or locked. (many ways)
-That a particular computer generally has a file open. (Shared folders, sessions mmc)
What we cannot see is that a specific computer has a specific file open and locked.
Anyone know of a way to get to this?
Thanks -
Rob
Check out this little freeware util (ShareWatch), I think it'll do what you're looking for.
One of the features listed: "Shows the users and computers that are connected to each share, along with what files are open."
Enter the command line(CMD),
then type : openfiles /query ip of the networkshare
And the username and password may be required.
You can get more information of openfiles on here.
I believe you are going to want to refer back to Sky100's post as he is correct, not in providing you with what you asked, but in providing you with what you need to resolve your issue. You will need to reference the locked ID number via the "openfile /query /v" (verbose) command as it will supply you with the data you need. Search for the file name within the list given, the data will show which item has the read & write enabled, and along with it will provide a specific ID number. No, you may not be able to find which specific system has the file locked, but with the tools provided, you can disconnect that user from the file. Here is a step-by-step to simplify my ramblings.
1) On the fileserver with Administrator rights, do Start > Run > CMD [ENTER]
2) CD Desktop [ENTER] (You'll see why soon.)
3) openfiles /query /v > file.txt [ENTER] (This will create a file on the desktop with a list of all the opened files on the server.)
4) Open the file.txt and search for the line containing both your file name and the Read + Write permissions.
5) Note the ID number on that line and go back to your Command console.
6) openfiles /disconnect /ID [Put ID Number Here] [ENTER]
As long as you have Administrative rights on the file server, it will disconnect that system from the file and assuming your system is automated, should allow things to keep moving along as needed.
References: openfiles /query /? openfiles /disconnect /?
If you are in need of a script or programmed application catered to your system, please feel free to comment and I will provide with contact info, a very low price along with tech. support on my application.
Is the problem you are trying to solve the one you state (ie map the specific client computer (not user) to the locked file) or is it that there is a locking problem that you need to resolve?
If the latter would help then there are two things I would look at:
Check the AV that is installed on your clients - I've seen multiple Client side AV cause seriously nasty anomolous locking behavior on shares.
Try disabling opportunistic locking by setting the EnableOpLocks registry value to 0.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 or 1 Default: 1 (enabled)
This will reduce performance somewhat but should not break anything.
I'd love to see someone actually answer your stated question though - it's an interesting problem.
In my attempt to troubleshoot RobW's problem, and provide an alternate solution, I failed to answer his question.
I believe the solution you are looking for is going to be in setting up Audit policies on that system and then setting that file to audit any access from that particular user. The steps to performing this can vary depending on your network setup, so I'm going to refer you to microsoft's technet link on how to setup different systems to audit.
http://technet.microsoft.com/en-us/library/cc787268(WS.10).aspx
After setting that up, making sure to follow through with setting up the specific file you wish to monitor by attaching the user account as an Auditor, you should be ready to go.
Simply check your Security Event logs in the future and though it will list each system (as they are all using the same username), it should not be difficult to sort through and locate which system currently has Read and Write access to the file.
It may be useful to setup the Security log to clear every few days.
If this doesn't work, it is likely you will need to set the system up per each host name accessing the file, rather than the user name. I believe this is made possible via the Microsoft Management Console.
Again, if you need programming, I'm not a businessman interested in taking loads of your money for some tiny program. I provide quality programming at a price that even an individual would not shy away from. I hope this helps you in resolving your issue.
On modern Windows systems,
will do the trick for this. You'll get the local filepath, client computer's IP or hostname, and the AD user who has the file open.
I'd also assign different users to different kiosks if possible - it might help you in analyzing other logs...
If that's not possible: Outline of possible solution: A solution could be to run a tool like sysinternals processmonitor with a proper filter (to the file in question) on the kiosks (don't know if you can hide it). There's some command line options you can play with that save the captured data to file.
Collect these from the various kiosks, import them into e.g. Excel and look for the one that wasn't closed...
What about using the command netstat to determine this?
This should give you the IP addresses of the machines connected.
If you want the hostnames rather than IP addresses, use
however this will take longer to execute, especially on busy file servers or domain controllers, as it will have a lot of host lookups to perform.
Also, bear in mind that the results will show inbound, outbound and idle listening ports.
Inbound connections will show the :445 in the left column, outbound show it in the right column.
You can safely ignore any results that state 'LISTENING' and also any lines that show only local IP addresses (e.g. 0.0.0.0 or 127.0.0.1) or the computers own hostname if you don't use the -n option.
For example:
The only connected host here is 192.168.16.87. The connections to 192.168.16.24 are outbound. All the other connections are local connections.
I remember there was graphical tool within windows to check used shares and locked files.
It should be in the "system tools" under "Computer management" (~ translated from french...), under the name "shared folders".
I know this is very old, but ADSI provides the WinNT:// interface, which allows you to access the LANMANSERVER service and query for properties already exposed in the "Shared Folders" mmc snapin. I am currently researching a way to link a host and a user to a open file.