Introduction

This is the part 3 of a series. There is a problem with storing .NET applications on a network share. When you want to release a new version you need to make sure everyone is out of the application. This article presents a solution I came up with, to solve figuring out who is in the application so you can ask them to get out. You may want to read the first two articles:

Background

Even though a .NET app is run locally on the user's PC, a .net app on the network share has an open file lock on it. So you really have two options to discover who has the application open. The first is you need to be a network administrator and have rights on the network server that the share folder resides on. If you meet these requirements, then you can just open the computer management (right click on My Computer then Manage). Then click on Shared folders. Finally Open files. If you are an administrator on your own PC you can try this out just to see what I am talking about. It is important to note here that I do not have administrator rights, which is why I came up with this solution. The second option is to use the programs I wrote so that help desk or release coordinators or whoever can see who has what app/file open.

Overview of the Solution

First, you need to know that there isn't some magic solution. There is setup to get this solution to work. Here is the layout of the solution. You have a Windows service that calls an existing program called openfiles.exe. The openfiles.exe can be found at c:\windows\system32\openfiles.exe. If you can not find this program then you are out of luck. The Windows service is logged in as a domain user that has been added to the Power Users group of the network server you want to see the open files on. The Windows service writes out the list of open files to an XML file on a network share. Then there is a Windows client that reads the XML file and displays the servers and open files. Note the Windows service can run on any network server that has the openfiles.exe. The Windows service uses an XML INI file to know which network servers it should be querying. This XML INI file defaults to c:\. The network share that the XML files get written to can also be anywhere as long as both the Windows service and the Windows client both point to the same place. Note the openfiles.exe is something that is provided by Microsoft. It allows you to query the open files on a network server assuming you have the correct rights on the server. The Windows service will write out one file per server per minute. The Windows client will always try to read the XML file from the previous minute. So yes, this means you will have 60 files per server. If you have a lot of open files, the XML files can get big. Note the source is provided, you are welcome to do better than this.

The Solution

First you need a domain user that is a member of the Power Users group on whatever network server you are interested in. This domain user is used for the login for the Windows service. Next you need to install the Windows service. You need to use the installutil program that comes with the .NET framework. It can usually be found in c:\windows\microsoft.net\framework\v1.1.4322\installutil.exe (Note v1.1.4322 should be replaced with whatever version of the .NET framework you are running). So copy the Windows service to a local drive on a network server. It is usually a good idea to create a services directory. Open a command prompt. Change directories to get to where you saved the Windows service. Run installUtil (c:\windows...\installutil openfilesServer.exe). You will be prompted to enter the domain user and password. Next go into Computer Management. Then Services and Applications, then Services. You should see OpenfilesServer. Start the service. A OpenFilesini.xml file will be created. Stop the service. Locate the Openfilesini.xml file and edit it so that the output directory and the network server(s) you want is/are correct. Don't forget to add the domain user to the Power users group of the network server you want to see the open files on. Once the OpenFilesini.xml file is setup properly, start the Windows service. Note, the default place for the service to load the INI XML file is c:\. You should start the service to see the XML files getting created. Now we are ready to use the client. The first time you run the client Windows app, you guessed it, Openfilesini.xml file will be created. Close the app and edit the Openfilesini.xml file to point to the correct output directory that the Windows service is writing to. It should be a network share some where. Start the Windows client and you should see your listing of network servers. Once you select one, you will see the list view of all the open files. Note, the client does checking to make sure the files are current and are not from yesterday.

Conclusion

So this was just a programmer's fix to get around my lack of rights. Using the Openfiles.exe is a powerful tool to see who is in a file. Beware, the openfiles.exe also allows you to break open file connections. I did not include the functionality into this app, but it could be done. So I hope you have fun with this if your network admin will allow it.

Share

About the Author

I started my programmer career over 18 years ago doing COBOL and SAS on a MVS mainframe. It didn't take long for me to move into windows programming. I started my windows programming in Delphi (Pascal) with a Microsoft SQL server back end. I started working with vb.net when the beta 2 came out in 2001. After spending most of my programming life as a windows programmer I started to check out asp.net in 2004. I achieved my MCSD.net in April 2005. I have done a lot of MS SQL database stuff. I have a lot of experience with Window Service and Web services as well. I spent three years as a consultant programing in C#. I really enjoyed it and found the switch between vb.net and C# to be mostly syntax. In my current position I am programming in both vb.net and C#. Lately I have been using VS2012 and writing a Windows 8 app. You can search for the app it is called ConvertIT.

On a personal note I am a born again Christian, if anyone has any questions about what it means to have a right relationship with God or if you have questions about who Jesus Christ is, send me an e-mail. ben.kubicek[at]netzero[dot]com You need to replace the [at] with @ and [dot] with . for the email to work. My relationship with God gives purpose and meaning to my life.

Comments and Discussions

Hi kubben,
I'm doing a vb.net desktop app with filesystemwatcher and I can't get username who opens a pdf or jpg file.
I found your article but I can't compile your project in VS 2013.
I just need username (your ACCESS_BY) for a pdf/jpg opened files.
Can you help me, please?
Thanks a lot

Thanks for your time and answer,
my problem is with pdf/jpg opened files.
I use filesystemwatcher to detect opened files. With MS Office files it is OK, because a tmp file is created when the .doc is open (f.i.) and I get the domain username.
But not with pdf or jpg files, because when these type of files are opened, they do not create a temp file, so filesystemwatcher does not work.
Can you help me, please?

Honestly it has been a number of years since I have used this app. The company I wrote this for I haven't worked for in a number of year. Anyway, I believe the PC that has the share lock open is the Host variable.

I have been trying to do something similar with an ASP.net version thinking I could deploy it across a network so that anyone would be able to see who has what files open.

Background:
I am an IT Manager for a medium sized company, so I personally have access to check who has what files locked and even close those files on other people. This is not my personal challenge but instead I want to give the ability to others to be able to also at least view who has what files locked.

Situation:
We use Acrobat pretty extensively and try to be as paperless as possible, however acrobat does not tell you when someone else has your file open so the few people who need to update these PDF files frequently are not able to because multiple people have these files open. They would come to me or one of my substitutes to find out who has the file open and depending possibly close that file on them. It happens at times when they cannot find me and with no access to the server or an admin account cannot find out other than to walk all over to find who has it open. This is not very affective, if I could deploy a simple webpage that would allow them to be able to view who has the files open they can ask them to close it personally.

My solution:
Instead of running a service that checks open files every minute I'd like to make that part of my ASP.net application such that whenever the page is opened it will fire the openfiles.exe and output the results into a csv which I can then interpret into a gridview or something. I have the basic gridview working (though I want to modify it as viewing the csv directly doesn't give me good options for filtering or sorting). I can solve my csv/gridview fine by importing the csv line by line into some datasource and read it back from there to a grid. My problem lies in firing the openfiles.exe command from asp.net.

My Problem:
I have researched the command on the microsoft website and developed a command that will give me what I want, and put it into a batch file. This script returns all the open files on a particular server using an administrative account credentials and outputs them into a csv. When I run this batch manually it works like a dream. When I try to launch it out of an ASP.net application it doesn't recognize the openfiles.exe as an internal or external command.

I think if I took your service idea I could essentially do the same as you are just simply make the front end an ASP.net site instead of a forms application. I just don't like the 1 minute delay and the need to run the service on the server constantly when it seems it could simply just be fired when needed. Any insight would be appreciated.

You know, the post just below yours, someone posted some code to call the dll directly that openfiles calls. I didn't even know that could be done. I would suggest looking at that code as perhaps another way to get the information you need.

For me the reason I wrote the window service is that openfiles only seems to work when you have an admin login that has the correct rights etc. So that type of admin login isn't something you would want just anyone running. So it was easiest for me to just create a service that could run with that admin rights on a server and then have a windows app that looked at the data.

So in your case you could probably do it in asp.net, but you would run into a few hurdles. First your asp.net site runs as aspnet_user. This user generally does not have any network rights. The way around this is to setup your application pool to run as a network use. Still I would caution against this since it would mean that your asp.net site would be running as someone who has pretty elevated rights. Normally when I set up an application pool to use a network user, it is a normal user that just has rights to a sql server so then I can use NT authentcation to access sql not a sql user name and password.

Anyway, I don't know if I have been much help. Let me know if you have more questions.

With a few switches you can run the command as another user so if the user running the command doesn't have sufficient permissions they can still run it as long as they add the credentials in a switch. I put this in the batch script where no one would have access to the batch script and it would not require me to give this web application access to the administration of the computer (I agree very bad idea, even though this will be intranet only).

The code below seems to require that the user running it is indeed an administrator, this is where openfiles.exe was the better option for me since I could let it run as a plain jane user and still get results (because the admin credentials were in the swtiches). Though maybe there is some credence to the need to give some rights to the website user in order to even run the command. I will have to look into this possibility. I guess I should also verify that a non administrative user can run my batch script with the embedded credentials.

It has been a while since I have played with this code. The original company I wrote this code for I haven't worked for, in a number of years. Anyway, if my memory serves me correctly, a non admin user is not able to call the openfiles and have it return the data you are seeking. I could be wrong, but that is what I remember.

Their example was in write out to a file. So we would be doing the reading in of a file. So I am guessing if you changed the code to read the file with the correct encoding then the characters would display correctly.

So this is a complete guess on what the code would look like, but hopefully this helps point you in the right direction.
So myprocess.StandardOutput is our StreamReader
If you create a new streamreader
something like:
dim eAnsi as Encoding = System.Text.Encoding.GetEncoding(1252)
dim sr as StreamReader = new StreamReader(myprocess.StandardOutput,eAnsi)

Then use sr where the code has myprocess.StandardOutput

I am guessing that you will properly read the special characters and thus they will display correctly.

It would be much easier to just call the NetFileEnum Windows API to get the same information, instead of running an external process and parsing its output.

But anyway, in order to get the correct characters with accents and everything, you have the set the correct encoding in the property StartInfo.StandardOutputEncoding, which in your case would be "ibm850" (CodePage = 850).

My first guess would be that your user doesn't have rights to write to the event log. Sometimes it is best to start the service once with an admin user that has rights to write to the event log. Then change the login to be a network user that has the correct rights on the network.

Check the event log to see if the windows service is writing out any messages.

In the OpenFilesService.vb file, there is a Private sub called readXmlini

In this sub there is a default path which is d:\share\openfilesdata\
You can change this to point to your path or you can pass a parameter into the window service. If you find your windows service in the console, then right click and select properties, on the general tab there is a box at the bottom called start parameters:
You can pass the path to your exe in that.

It might make the most sense to just change the OpenFilesSErvice.vb file and recompile the app, but either way will work.

This sounds like you have a problem with your xml file
The OpenFilesini.xml should have two nodes in it
<?xml version="1.0" standalone="yes"?>
<NewDataSet>
<Settings>
<OutputDir>\\servername\folderforoutput\</OutputDir>
<TimerElapse>60000</TimerElapse>
</Settings>
<FileServers>
<FileServerName>\\Server1</FileServerName>
<Active_Flag>Y</Active_Flag>
</FileServers>

</NewDataSet>

You need one Settings node and at least one FileServers node
I am guessing the xml file exists, but you are missing one of those two nodes.

NOTE you also need to have a valid servername and folder in OutputDir
and FileServerName
If you leave the defaults in there they will not work since those servers and folders do not exist on your network.

Hello Ben,
thank you for the help. It was not the .xml file, it is the parameter in the startbox.
I compiled the source with the right path to the exe, now it works.
I don't know the right parameter in the startbox, with c:\services it doesn't work.
The exe is in this directory.
I will work with the "right" source, so don't need a startparameter.