MonitorWare Knowledge Base

As I have previously indicated, the event 1005 overflows the Application Log if the SETP Server is not available. (We are still running the old 2.2 version of MWAgent in our delivered systems). The obvious solution is of course to always have a SETP Server running.

See http://forum.adiscon.com/htopic,875,1005.html

We are now working on a new system that will also use MWAgent for central collection of security logs. A difference compared to previous systems is that the SETP Server runs on a laptop that may not always be connected. This means that we will have these annoying 1005 events overflowing the Application Log in the operational system as well!

The laptop will typically be connected once a week or so to receive the security logs from the other computers. It will then be disconnected again and stored in a safe place.

Imho the MWAgent should only inform when the contact is lost and when it is again restored! Not each time it fails to contact the server.

Does the current version of MWAgent have functionality for stopping the 1005 event from coming cyclically?

Is it possible to request this kind of change from you?

Hi,

are you using MWAgent for this task only?
Or is it performing other tasks on the Client machines as well? If not I would recommend to write a little script which starts and stops the Services once you connect the laptop to your network.

Currently the 1005 error can not be disabled. However we are currently in RollingBeta process, so if this workaround is no option for you, it is possible for us to add an option to avoid the error 1005.

best regards,
Andre Lorbach

Yes, the only thing the MWAgents in our local machines do is to collect the IT Security events and send them to the SETP Server. And, yes, starting/stopping the service when there is no SETP server could be an option. However, this needs to be possible to do remotely - we can not "run around" doing it manually in some 40 computers. Therefore, stopping and starting the service is not as simple to implement as one might think. I would like to avoid this.

I would much rather prefer that the MWAgent is modified to report "contact lost" the first time the server can not be reached, keep quiet on successive failing send attempts and report "contact re-established" the first time the server can be reached again after a period of send failures.

Why would you need an option controlling this behavour? Why not just replace the 1005 event by the two new events proposed above? Who needs to be informed cyclically about the same thing anyway?!!!

In fact, my collegues in our Systems Integration group tend to consider the MWAgent ILL-BEHAVED when it fills up the application log - rendering the log more or less useless. The MWAgent definitely uses a different philosophy for its error reporting than the one we impose on our own applications. (Our rules e.g. clearly state that this kind of cyclic reporting should be avoided).

In your situation I would try to include the proposed more user friendly error reporting in the rolling beta. Or at least make it possible to optionally suppress the 1005 event. Please inform me if you do so!

(Just trying to help you improve your product. Something we will both benefit from)

Yours sincerely,
Mats Hjelte
Saab Systems

Services can also be started and stopped remotly.

However, thanks for your suggestions. We have thought about this issue before and will consider your recommendations. It may be added in one of the next Rolling beta build (Version 4.3).

Said - done. The new error reporting has been added into the Rolling Beta Version

regards,
Andre