Edit: Since I published this yesterday, I have added in a couple of new features, and integrated a full HTML Help file for the application (which can be access via the “Help” menu).
New features are:
- Option to continue trying to write the Ping File if there has been an error
- Respond to errors that have been generated in the Session Log File
- Change the colour of the Session Log file to red if there has been an error
Over the last few days I have been working on a particularly nasty issue on one of the file servers in work. The server in question is a Windows 2003 x32 Standard Edition Server box, with 2GB of RAM and practically oodles of shares which are used by both the Development and Corporate community within the organisation.
What started to happen around the middle of this week was access to mapped drives (e.g. connected to shares on the File Server) would freeze periodically. Network connectivity to the server was still available (I could both ping and RDP to the box) – but all network shares would become unavailable for anything between five to ten minutes at a time.
As time progressed throughout the day – the downtime on the shares became more and more frequent and lasting longer and longer.
Whilst this particular article is not about how I solved the issue (this may come later when I am convinced that the issues have indeed been fixed) – I found that as the nature of this problem was completely random it was tremendously difficult to know when an instance of downtime had occurred and I was completely reliant on the user community to tell me when they had “lost access”, or I would have to spend precious time clicking in and out of mapped drives on the server to see if they were still responding.
This of course, and understandably led to a lot of “teeth gnashing” and frustration for both my customers and I, as well as making it very hard to tell if any of the remediation efforts that I was making were actually improving the situation.
So, this weekend I decided that I was going to sit down and write a little tool that can be pointed at a share on a file server that will write a compact text file at a specified interval to that location and provide me with feedback on the result of the write operation.
Whilst writing the tool – it further occurred to me that others might benefit from such a program so I have decided to publish it here on telnetport25.com.
I will point out at this stage that the name “File Ping” is perhaps somewhat misleading as in the conventional sense it does not literally “Ping” anything. The context of “Ping” in the title of the application is the value of the result of the write operation performed on the target fileserver share.
It is recommended that File Ping is installed on a local workstation which has the drives mapped from the remote File Server that you wish to monitor. Before you install the tool you will need to ensure that you have the Microsoft .NET Framework 3.5 present on your machine.
The tool is compatible with both x32 and x64 versions of Windows.
When you have downloaded the tool – double click on the “FilePingSetup.msi” file and then follow the on-screen prompts. At the end of the installation File Ping will be launched automatically. After install you can access the tool from your Desktop and Start Menu.
The following video gives you a very quick overview of how you can use the FilePing Tool.
When using the tool I recommend that you setup a dedicated folder share on the target file server that will hold all of the “ping” files – this makes it easier to delete the output of the tool when you are finished monitoring.