The case of the missing file

Last issue, I talked about a discussion I had with David Pann, NetIQ’s product management and marketing vice president in which he presented a number of questions that today’s network manager needs to ask. One in particular intrigued me, because it’s one I’ve often advised clients to keep sight of – “Once I know I have a problem, how can I determine the root cause?”

If you’ve ever been involved in help desk activities or (as I have) volunteered your services in online peer-to-peer support groups, you’re probably very familiar with the phenomenon of users reporting symptoms as root causes. One example is the familiar file not found dialog (“ can’t find one or more of the files it needs to run” is one form of it). Too often users simply want you to replace or restore the file without stopping to think about why it can’t be found. Especially if the application is one that the user has previously run without a problem, it’s most likely that there’s more than just a missing file to be concerned with. Just off the top of my head, here’s a short list of possible reasons why a “file not found” dialog could appear:

* The file was inadvertently moved or deleted.

* The file was deliberately moved but the application’s configuration wasn’t changed.

* The file or folder permissions were changed.

* The file’s attributes were changed.

* The user’s permissions were changed.

* The group through which the user got permissions was changed, modified or removed.

* The server name was changed.

* The disk media has developed bad blocks.

* A RAM module in the user’s PC has gone bad.

* Another user has placed an exclusive lock on the file.

Until you find the root cause of the “file not found” message, other problems will continue to crop up. Each will require your attention while the “band-aid” style solutions (such as simply re-installing the file) will only mask the real problem and delay getting it solved.

Old management tools (the stuff we used 10 or 15 years ago) simply logged problems. Many networks still try to get by with logs which someone is supposed to analyze to determine root causes, but when you’re busy putting out fires you don’t often take the time needed for analysis. Today’s management suites (such as NetIQ’s AppManager, which is how I got to this whole discussion) will not only monitor and log the problems but will also analyze the situation following “best practices” rule sets augmented by your own experience.

Knowing the symptoms of a problem is important, of course. But don’t confuse a symptom with a cause. More often than not, a symptom is a result of a problem, which will keep recurring until you determine why it’s happening and eliminate the underlying problem.