You can find the installation (383 KB) for the Cisco NetManager troubleshooting tool, here.  (Warning:  you have to scroll down to find the download link)

The tool

The output

The need ?

Read on …

Ever Experienced this before ?

Day 1

Customer (NewYork)    – “Hyper drive feature doesnt work right”
Tech Support (Sydney) – “Have you switched on the feature ?”
Customer – “Yes i have ”
Tech Support – “Please send the logs from xyz directory”

Day 2

Logs and Installation get verified. Nothing turns up.

Day 3

Developer (Bangalore)  – “Check if the registry entries are present …”
Customer – “Registry what ?”
Tech Support – “We need to look into your box – when can we do it”
Customer – “Cant let you – but i orderd this *@* software – let me get the permissions”

Day 5

Agree to have a meeting

Day 6

Developer – “Feature seems to be started  – What exactly did you modify?”
Translation – Its 11.45 pm and i dont feel too bright

Customer – “err .. not sure – cant you figure it out”
Translation – Hell if i knew – Its been 6 days – i dont even remember if i came to work on that day

Tech support – “Let us get back to you”
Translation – This call sucked

Day 7

Customer – Any F@@@@ idea what has happened ???!!!??
Tech support – I want a new job ….
Developer – I have to attend more customer calls. Somebody help …

Sounds familiar ?

How well does this sort of support scale when you have a software that has shipped to thousands of customers and has a good amount of bugs? I would say you would have a problem in your hands.

Our product, the NetManager, is intended for use with smaller setups and priced as such and hence is expected to do more volumes than pricey “enterprise” class softwares. Therefore the rate at which bugs come in when the tool really starts shipping in volume might be higher during the early stages. Therefore a higher bug fix rate / turaround time is required.

This thought was what got me to collate my multiple tools that existed internally into a single diagnostic tool for use with netmanager.  I had been using many scripts for exporting device list, getting the DB state for reporting purposes etc), which I combined into a single stand-alone program. Thats one reason everyone should be writing automated tools for everything including unit test cases.

Using a tool would ensure that the there is a better chance of capturing the state of problem than when the issue is investigated 3-4 days after the problem has occured. This might increase the chances of the bug being resolved faster.

State information that cannot be duplicated at a later time, like

1. CPU consumption figures
2. State of the disks
3. The logs
4. The database state / event logs

are captured in a timely fashion. This ensures that the developers have a unique window into the state of the system during the time which the problem was observed.

Then again by using a tool we reduce the loops of communication between the user and tech support which is the other factor that contributes to a long delay in the time it takes to fix the bugs. Information like

1. System configuration
2. Software configuration
3. Startup services
4. patches installed

can be easily captured by an automated tool. No bugs should be delayed based on requests for such information that are pften required as a bug fixing session unrolls.

Further using a tool is so much more proffessional and builds good will. The  program also benefits from the lesser interaction with users and tech support which might often rub the users in the wrong way depending on how the communication is carried forward.

On the whole, its one more tool to make life easier for everyone involved. Even for me, who thinks the cost of supporting the tool is well earned in the less no of support calls i might have to take.

Update : The tool might be included it in the next skew