How to Capture Windows System Events in Resource Manager – Zenoss

Applies To

Zenoss 4.2.3 or later
Zenoss Windows ZenPack 2.2 or later
Windows Devices: Powershell Version 2 or later
Windows Devices: .Net Version 4 or later

Summary

Resource Manager Administrators may wish to capture certain Windows server system events in the Resource Manager event console. Resource Manager offers considerable flexibility in choosing which events to capture and even which servers to monitor for the events. The options range from capturing all events from all servers to a pinpoint search for a specific event from a particular server and everything in between.

Procedure

Familiarity with the following concepts will be helpful for setting up Resource Manager to capture Windows events:

Creating and Binding Resource Manager Templates
Powershell ScriptBlock syntax for the Where-Object Powershell commandlet
The Windows eventcreate command (for setup and testing purposes)

Testing templates

Before attempting to trap “real” production events from Windows servers, it is helpful to create a test template in Resource Manager designed to capture a specific, manually generated Windows event to verify that the configuration is correct. When this process is complete, administrators can clone or modify the test template to begin capturing “real” Windows events. For the test event, this article will demonstrate an example based on generating a specific test event with the following attributes:

The Windows log the event is generated in: Application
Event severity: Warning
Event Source (this means the process generating the event): TestProgram
Event ID: 101
Event Message: “The print spooler is down.”

Before beginning the procedure, verify that at least one test server is available that:

Is currently being monitored by Resource Manager
Has .Net version 4 or higher installed
Has PowerShell version 3 or higher installed (Windows 2008 and Windows 2012).

Note: All servers from which event capture by Resource Manager is desired must meet these requirements.

Creating a new event log monitoring template

Create a new EventLog monitoring template in the /Server/Microsoft device class:
1. In the Resource Manager UI, navigate to Advanced > Monitoring Templates.
2. In the left pane, click the Plus Sign (+) at the bottom to launch the Add Template dialog.
3. Enter a Name: for the new template, for example, Windows_Event_Test.
4. Set the Template Path: select the device class /Server/Microsoft from the drop-down list.
5. Click Submit to save and close the Add Template dialog. The new, empty template should open automatically in the right pane.
Add a data source to the new monitoring template:
1. Verify the new template, in this case, Windows_Event_Test is open. Scroll down the list in the left pane and verify the highlighted name.
2. Add a new datasource to the template. In the right pane, under the Data Sources heading, click the Plus Sign (+) to launch the Add Data Source dialog.
3. Enter a name for the new data source. In the Name: field, enter a name, test for example.
4. Set the data source Type: Select Windows EventLog for the data source Type.
5. Click Submit to save and close the Add Data Source dialog.
Edit the new test data source:
1. In the right pane, double-click the new data source, test for example, to open the Edit Data Source dialog.
2. Enter a value in the EventLog: For the test event, the correct value is Application.
3. Enter a value in the Event Query. The format of the query must be { $$_.[Powershell script block for the Where-Object commandlet] }. Note that in order to create the Powershell script block for Windows 2003 servers, it will be necessary to be familiar with the .Net EventLogEntry Class (http://msdn.microsoft.com/en-us/library/vstudio/system.diagnostics.eventlogentry) and with the Where-Object Powershell commandlet Syntax (http://technet.microsoft.com/en-us/library/hh849715.aspx).
  For Windows 2008 and later, the EventLogRecord class is used instead. For these servers, it will be necessary to be familiar with the .Net EventLogRecord Class (http://msdn.microsoft.com/en-us/library/system.diagnostics.eventing.reader.eventlogrecord).
4. For Windows 2003 servers, the query takes the form:
  { $$_.[EventlogEntryClass] [Where_Object selection] }.
  
  For Windows 2008 and later, the query takes the form: { $$_.[EventLogRecordAttribute] [Where_Object selection] }.
  
  To capture the test event detailed above in the article (which will be generated on Windows servers in subsequent steps in this article), enter the following in the Event Query field of the template data source to filter a string value (these queries apply to any version of Windows):
```
{ ($$_.Message.Contains('print spooler') -eq $$true) or ($$_.Message -Contains 'The print spooler is down.')}
```
  Note: Care should be taken when using the -Contains, -CContains, -CNotContains, etc. operators as they look for an exact match of the field. Use the string .Contains method when filtering for a specific word within the field.
  
  Note that this particular query searches the Message field of the event for content, but other fields could be searched to find the event using a different query. Also note that the Where_Object query here specifies a query that i) is not case sensitive and ii) must only contain the specified text (as opposed to matching it exactly). These are just two of many options that can be specified for the query.
5. Verify the Enabled check box is selected.
6. Click Save to save the changes and exit the dialog.
Bind your new EventLog monitoring template to an individual Windows server or to the /Server/Microsoft/Windows class.

For a review of template binding, see Section 6.2.3 of the Zenoss Service Dynamics Resource Manager Administration Guide, available at http://www.zenoss.com/resources/documentation.
Note: When deploying the template for production use, note that the level of template binding within Resource Manager determines which systems are queried for events. Binding to the entire class will query all Windows servers. In contrast, binding to a sub class of /server/microsoft/windows allows only a subset of servers to be queried. Finally, for the most targeted option of querying, the template could be bound only to individual servers.
Restart zenpython to pick up the changes. If the target servers are monitored by the localhost collector, complete these steps:
1. Navigate to Advanced > Daemons
2. Locate zenpython in the right pane.
3. Click the Restart button.
4. For any collectors monitoring target Windows servers, repeat the process by navigating to Advanced > Collectors > [collector name] and clicking on Daemons on the left.
5. Locate the [collector name]_zenpython daemon in the right pane and click the Restart button.
Test the new template by generating an event manually on a monitored Windows Server. Log on to a monitored Windows Server that meets the system requirements detailed above and issue the following command at the Windows command prompt to manually generate the test event:
```
eventcreate /L Application /T WARNING /SO Rich /ID 101 /D "The print spooler is down."
```
Confirm that the event appears in the Windows event viewer.
Wait an appropriate amount of time for Resource Manager to poll the Windows server for the event (note that this cycle time is configurable in the template data source). If Resource Manager is correctly configured, the event should appear in the Resource Manager event console.

Creating your own templates

When a test has been successfully completed, edit the test template or create a new template to capture target events on Windows machines. Bind the new template to the class or device(s) desired. There is a virtually unlimited number of queries that can be created. Here are two additional examples of script blocks that can be used to query for events.

To target events originating from the User Profile Service, by searching for a non-case-sensitive match of “User Profile Service” in the Source event field:
{ $$_.Source -cne 'User Profile Service' }

To target all events with a Warning or higher severity:

For Windows 2003:
```
{ $$_.EntryType -le [System.Diagnostics.EventLogEntryType]::Warning }
```
Note: This query is structured to look for “less than,” although we are looking for events “greater than” in severity. This is because EntryType is an enumeration where the integer values map to 1 = Error, 2 = Warning, etc. This means lower numbers indicate higher severity.
For Windows 2008 & Later:
```
{ $$_.Level -le [System.Diagnostics.Eventing.Reader.StandardEventLevel]::Warning }
```
Note: The event level above is an enumeration (http://msdn.microsoft.com/en-us/library/system.diagnostics.eventing.reader.standardeventlevel.aspx), but there is also a string field that contains the display name. The same is true for other event attributes:
```
keywords, opcode, task
```
.

For additional information, see the Microsoft Developer Network article: EventLogEntryType Enumeration.