In Monitoring and Alerting you can set a monitor to watch the event log for Critical and Warning messages. The normal way to filter this is by parsing for a substring from the description of the event.
This how to will show you how to monitor for a warning and error notifications from a particular source ie, Winlogon, WMI, System-Restore, Perflib, VSS, etc.
(Warning: This is not a supported configuration and any changes made are done at your own risk.)
1. Configure your alert Rule Set with the Operating System Alert
Create your new rule set and create an alert under Operating System Logs. If you need help with the basics of this please consult this document first. ( Best Known Method for Monitoring, Alerting, and IPMI for LANDesk 9 This article does still apply to 9.5 and 9.6)
On the OS Log page choose the log where the events are going to be and whether you want Warning or Critical or both. Don't put anything in Match substring.
Once done finish creating the alert and publish it.
2. Modify the XML or database entry for Instance.
Next go to the LDLogon folder on your core and open AlertRules and find the alert you just created and open it. (It should look like internal.Core.#.ruleset.xml)
There are two ways to do this next step. First if you want to do this with manually editing the database then just change the <instance>*</instance> to <instance>YourSourceHere</instance>.
A. Edit XML File
If you change it only here then there are two things you need to be aware of.
1st, If you edit the alert rule again and click publish this change will be over written.
2nd, You have to distribute this by pulling it from the client using Alertsync.
To pull the alert down using Alertsync you would navigate to the LDClient folder on the target system and type in the command window
Alertsync -r http://Core_Name/ldlogon/alertrules/Your_XML_File.xml
If you want to make this a little more permanent we need to edit the database.
B. Change the Database
To change the database note monid in the XML file for your alert. Note, there may be several rules to go through, make sure you get the correct monid.
Next open up the database and run this command. (Warning: you are manually updating SQL this can cause problems if something goes wrong or you don't know what you are doing. Always back up if in doubt.)
UPDATE MonitorRules Set Instance = 'SourceName' where MonitorRules_Idn = Monid Select * FROM MonitorRules WHERE MonitorRules_Idn = 'monid'
You should see that the instance column entry has changed to what you put in as your SourceName.
Now go back into Monitoring and Alerts and edit that ruleset and click Publish. If you go back into LDLogon\AlertRules and open the XML again you'll see that <instance>*</instance> has been changed.
Close the files and now schedule your Ruleset for deployment.
3. Testing the solution
If you want to test to see if this is functioning you can waiting for the an event to trigger and then check for it in Logs on the Core. You'll notice that Instance is populated by the source of the event error or warning.
If you want to manually create an event to test use this in the command window
EventCreate /T (Error or Warning) /ID 1 /SO YOURSOURCEHERE /L Application /D "This is a test."
Make sure you put your source in and then check the logs a little later.
This solution is to help those who need to monitor for alerts from a specific source in the event log. This will allow the admin to pull all warning or errors or both without having to manually specify substrings to match from the description of the event.