Troubleshooting "Non-Communication" issues...

Idea created by Ronald Koons on May 25, 2016
    Under Consideration
    • Ronald Koons

    (Originally posted on 16, April 2015)

    I had opened a ticket with the support staff here regarding the Risk report detailing how many computers have not checked in over a 7 day period.

    Although the support staff were very helpful, what seemed like the only available solution was not very helpful.

    Basically I needed to run: ocsinventory.exe /force /debug=2

    This generates a log file that I then send into them to review.

    The problem is: Running this command also seems to fix the communication problem -at least until it drifts back into non-communication again.

    In my case, I have less then 200 machines and around 50 that are not communicating. 25% is a big margin for error. Some of these could be due to all kinds of acceptable issues like being a Laptop or a Tablet that is not on all the time, or a machine that has been retired or removed from the network. But some are just not communicating either from something in my network that is not right, or something specific to the agent in question that is causing the problem.


    I believe that there needs to be something in the system to help better track these types of issues and the potential causes so that there can be more reactive and proactive resolutions.

    Additionally, I believe there should be something to help the agent have more of an ability to try and self correct (if it does not already have one).

    The more we use this suite of tools from Samanage, the more benefit we get from it. What started out as a simple trouble ticket tool has turned into something we rely on for software compliance reporting and inventory control.

    This makes the reliability of the agent's communication with the servers more important than ever...


    What problem will this feature solve?: