MonitorWare Knowledge Base

Resolved issues:

(1) Demo was expired upon initial installation. Solution was to contact support for an executable that would extend the trial period.

(2) SystemID error during report generation - solution is to add SystemID colum to SystemEvents table

Unresolved issues:

(1) Report Manager - Event Log Summary Report when generated has the following error message:

Adiscon.MonitorWare.Console.MWException: Unable to connect to the database server.--->Microsoft.Data.OdbcException: ERROR[42S22]

(2) Report Manager - System Status Report when generated has the following error message:

Source: mscorlib
Message: Exception has been thrown by the target of an invocation
Details: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at SystemStatus.applyGroupingAlgo(String& reportBody)
at SystemStatus.generateReport()
at SystemStatus.startAlgo()

(3) Report Manager - Log On Log Off Report when generated has the following error message:

Source: mscorlib
Message: Exception has been thrown by the target of an invocation
Details: Microsoft.Data.Odbc.OdbcException: ERROR [42S02] [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name 'systemeventsProperties'.
at LogOnLogOff.executeQuery(String sql)
at LogOnLogOff.startAlgo()

(4) Device Manager - Discover generators the following error message:

Source: SQLSRV32.DLL
Message: ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot resolve collation conflict for equal to operation.
Details: Microsoft.Data.Odbc.OdbcException: ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot resolve collation conflict for equal to operation.
at Microsoft.Data.Odbc.OdbcConnection.HandleError(IntPtr hHandle, SQL_HANDLE hType, RETCODE retcode)
at Microsoft.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method)
at Microsoft.Data.Odbc.OdbcCommand.ExecuteReader(CommandBehavior behavior)
at Microsoft.Data.Odbc.OdbcCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
at Adiscon.MonitorWare.Console.DiscoverDevicesForm.cmdRefresh_Click(Object sender, EventArgs e)

(5) During SQL During setup, when executing the MWDB_HelperTZ.sql the following error is recorded twice in the messages window of the SQL Query Analyzer:

Server: Msg 8115, Level 16, State 2, Line 1
Arithmetic overflow error converting expression to data type datetime.
The statement has been terminated.

Hello,

thanks for pointing out these issues. I "own" the MonitorWare line of products and will personally look into the issue of fixing the quality issues within MonitorWare Console.

I tried to find some support calls from you, but did not find some under the alias. However, I am aware that we have an issue with MonitorWare Console not correctly working with the database schema provided by earlier MonitorWare line products. This is currently being addressed. I have also - today - become aware of some invalid handling of MySQL in the reports. This was unfortunately NOT discovered during the beta testing. Do you eventually use MySQL?

I am currently pressing for these issues to be resolved and I am positive we are making progress. A new version 1.1 is already underway and we are positive it will fix the majority of issues. I will talk to the team tomorrow if we can make some "hotfixes" available.

Please let me say bluntly that we have messed up with the initial release. Our apologies for this. I hope you at least appreciate the honesty and us not trying to hide behind some marketing speak...

I will keep you posted.

Best regards,
Rainer Gerhards
Adiscon

Thanks for your honesty in the issues with the current version. This product as it is exactly what I have been looking for to enhance the EventReporter product. I will anxiously await the release of the next version!

Hello,

Its a long post. But i want to explain you the *actual* cause of each trouble so please bear with me

Actually some of your exceptions would disappear once you run our database update utility tool. (It will be up on the web in a day or so) Please read the my post in the following thread. It explains about it:

http://forum.adiscon.com/viewtopic.php?p=1011#1011

(i have also explained the reason for Resolved issues # 2 in that)

Now coming to your unresolved issues:

1. I am not sure about it but it could be due to the old database. Can you tell me which database are you using?

2. This exception is produced when you are trying to generate this report on an empty systemevents table.

Solution: When you start the database make sure that the DSN that you have provided (by clicking on the link at the bottom right) points to the correct database (the updated one) and the systemevents table contains *some* data. If it is empty, point MonitorWare Agent or WinSyslog to log the data in this systemevents table and run the report again. You will find a nice report

3. This report tries to access systemEventsProperties table which is a latest addition to the database and which is NOT present in your database As I said, when you run that tool, this problem will also be gone

Solution: Run database update utility

4. I am not sure about this error. Can you tell me the exact sequence of steps.

5. Yes you are right about this. Actually in the scripts for MWDB_HelperTZ, there are two entries which are incorrect and hence it gives these 2 errors. Again, the database update utiilty will take care of it

Solution: Run database update utility

In short, except for problem 1 and 4, all are related to database update. I would have to work a little with you to get more details about problem 1 and 4. Please Do let me know which database are you using?

Do let me know about any other questions or problems that you have. I will be glad to answer them too Waiting for your response.

Best Regards
Wajih-ur-Rehman
Adiscon

1. I am using a SQL 2000 database that was initially setup for WinSysLog. It had one table in use called SystemEvents.

2. The systemevents table is not empty. I did delete the records once yesterday, but within 5 minutes I had 20 or more records in the table.

I do believe that Monilog is pointint to the correct DSN.

Thanks for your help on this.

Hello,

The Database Update Utility is now available on the following link (Read the ReadMe.txt for details)

http://www.adiscon.org/download/Monitor ... pdater.zip

______________________________________
Best Regards
Wajih-ur-Rehman
Adiscon

I have used the MonitorWare Database Upgrade Utility, and this appears to have resolved all the error messages. However, all the EventMonitor views are empty.

I can click on the Syslog Views and see the entries from the servers running EvntSLog which log to WinSysLog which then logs to the SQL table.

Any ideas? Or do you require the MonitorWare Agent to be running on a client in order to use the EventMonitor Views?

Hello,

If you are 100% sure that your systemevents table is not empty, then the problem lies with the filter conditions. For each view that is shipped with MonitorWare Console, certain filter conditions have been applied. The view is displayed on the basis of these filter conditions. If you click on the view, and if MonitorWare Console sees that no records are returned, it asks you a question to remove the time filter or not. (Initially all the views are created using a time fitler that says "Display only those records that were logged in the last day") If you say yes, it removes that time filter. If you *still* see an empty view then check for the other filter conditions in the view definition. You can edit a view and see its filter conditions. I would also suggest that you create a new view of your own choice and with your own filter conditions and see if it displays the results or not. To get even a better understanding of editing or defining a new view, you can quickly see and listen to an online seminar in which i have demonstrated various features of views module and how it can be used. You can listen to this online seminar on:

http://www.mwconsole.com/Common/en/SeminarsOnline/

(There are other online seminars as well on various features of MonitorWare console)

I hope this explanation will help you out.

If you have any other questions or problems, dont hesitate to contact us.

Best Regards
Wajih-ur-Rehman
Adiscon

The InfoUnit Filter was set to ID 3 "Windows Event Report" only. When I checked ID 1 "Syslog Reported Event" it reported the information.

What is considered ID 3 "Windows Event Report"?

Hi,

it is because it was logged over Syslog. So they will become the Type Syslog within the database. If you want to have intact "Windows Event Report" entries in the database, you will have to use SETP to receive them instead of Syslog.

Take a look to the following FAQ's
http://www.monitorware.com/Common/en/FA ... onfigs.asp
http://www.monitorware.com/Common/en/FA ... ndSETP.asp

Hoep this helps , nice Avatar btw

EventReporter Using ODBC?
I setup my Evntslog agents to use an ODBC System DSN. This appears to be working very well. Is there any downside to this versus the SETP configuration that I should be aware of?

SETP with EventReporter and WinSysLog?
Also, I was using WinSysLog to gather the clients which are running Evntslog. The links you provided refer to configuring the MonitorWare Agent for SETP. I don't see a SETP option for Evntslog, so does this mean the only way to get this information logged correctly for use with the Monitorware Console EventMonitor Views is to use the DSN method mentioned above?

Servers in our DMZ
I'd also like to have our DMZ servers logging data to the MonitorWare database (residing on an internal Microsoft SQL 2000 server), but would prefer to use SETP through the firewall and then have an internal client logging the data to the SQL database. Does this mean I would require Monitorware Agent on the DMZ servers, as well as an internal machine running Monitorware Agent for this configuration?

Monitorware Console Report
One more question relating to the reports. The Log On Log Off Report (For MWAgent 2.0) generates a report using the Evnstlog agents using a DSN, but only the machi, user, logon/logoff and date and time columns contain data. The User Name, Domain, Login ID and Logon Type are empty. I also tried using a instance of MonitorWare Agent on my domain controller and still had the same results. The domain controllers are 2003 Server running in domain and forest 2003 native mode.

Product Differentiation
I think the hardest time I've had with your products is distinguishing which product should be used for which purpose. Seems like there is a lot of overlap (Monitorware Agent seems like a mix of WinSysLog and Evntslog).

I'm still getting a feel for the new MonitorWare Console, but already I can see this tool quickly becoming a daily timesaver in preventative maintenance and security auditing.

Hello,

Once again, it would be a long post, but I hope it would also help in answering all of your questions.

First of all let me clear the concept of SETP and Syslog. SETP is Adiscon's protocol that uses TCP to send messages and thus provides guarantee of message delivery. SETP is *only* present in MonitorWare Agent. So both sender and receiver would *have* to be MonitorWare Agents if you want to use SETP in your environment.

Now i come to your questions:

EventReporter Using ODBC?
SETP has nothing to do with ODBC System DSN because in both of the cases (i.e. whether you use Syslog or SETP), you would have to create an ODBC DSN to connect to a database. The downside of not using SETP is that you cant gurantee the delivery because by design Syslog works over UDP.

SETP with EventReporter and WinSysLog?
If you are using EventReporter and WinSyslog then you *cant* use SETP. But that *does not* mean that you cant use MonitorWare Console. The only difference that you would have to make in the filter conditions of views is that you would have to use InfoUnitId as 1 instead of 3. As i said that these views are just *some* of the views that we thought are useful and hence added them in Console. Using this console you can create *any* view of your own choise and your own filter conditions depending upon your needs.

Servers in our DMZ
Yes, in this case you would have to use MonitorWare Agent as a sender and as a receiver as I said above.

Monitorware Console Report
Please read the following FAQ to get the answer:
http://www.mwconsole.com/en/faq/Empty-C ... eports.asp

Product Differentiation
Well Actually you are right about it because MonitorWare Agent *is* actually a mixture of WinSyslog and EventReporter but it also offers certain functionality that is not present in both of them. The ideal solution to get a very clear picture of our products is to listen to my online seminar that actually explains exactly what you want to learn. Its an overview of our MonitorWare Line of products. You can listen to it (with conceptual diagrams) at:

http://seminars.adiscon.com/mwproductso ... efault.htm

I hope I have answered all your questions. If you need any additional help, we are always available

Best Regards
Wajih-ur-Rehman
Adiscon

I watched the presentation and it did help answer the confusion about the various products. One small item with the presentation, your schematic showed that EventReport could not log directly to a database. Using ODBC and a DSN, this is actually possible. Just thought you may want to consider including that in a future version of the online seminar.

I think this answers all of my questions, outside of one relating to the future of EventReporter, which I posted here:

http://forum.adiscon.com/viewtopic.php?p=1051#1051

Thanks for all your help!

Hi,

let me add something to the technical issues.

I think the way to go for now is - as you have done - write directly to ODBC. I would strongly suggest to use the TCP/IP network library while doing so. The default named pipe library has a number of security implications and - at least in our testing - has shown to be not as stable as the plain TCP/IP library.

If all machines are locally and well-connected, there should not be that much downsides of using ODBC. Of course, running ODBC is not as robust or ressource-conserving as a plain message delivery protocol, but it provides a good alternative to SETP and the upcoming syslog-based approach. I think it will work well in situations where you do not want to upgrade to another product.

Regarding the seminar, that was actually based on EventReporter 5.x and I have created a todo entry to update this. Hopefully this will happen soon.

Rainer