Sampa @ Work

ACS - How to collect event 1102 (Event Log Cleared) on Vista and later

2009-06-30T20:17:28Z

Event 1102 is logged to the security event log when the security event log is cleared. This event differs from most events in the security event log in that the event source is “Microsoft-Windows-Eventlog”, not “Microsoft-Windows-Security-Auditing”.

By default, this event will be collected, but the event parameters will be stored in string fields 1-4. If you want to store these parameters in another location, you need to specify an event transform in EventSchema.xml. I’ve provided an example below that puts the parameters into the PrimarySid, PrimaryUser, PrimaryDomain, and PrimaryLogonId. You need to add this section to your existing EventSchema.xml at the same level as the other Sources.

<Source Name="Microsoft-Windows-Eventlog">
<Version MinBuild="5384" MaxBuild="9999" UniqueId="FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148">
    <Strings>
      <String Entry="-" />
      <String Entry="0x0" />
    </Strings>
    <Event SourceId="1102" SourceName="SE_AUDITID_AUDIT_ETW_LOG_CLEARED">
      <Call Name="AppendString" Param1="1" Param2="0" />
      <Call Name="AppendString" Param1="2" Param2="0" />
      <Call Name="AppendString" Param1="3" Param2="0" />
      <Call Name="AppendString" Param1="4" Param2="0" />
      <Param TypeName="typePrimarySid" />
      <Param TypeName="typePrimaryUser" />
      <Param TypeName="typePrimaryDomain" />
      <Param TypeName="typePrimaryLogonId" />
    </Event>
</Version>
</Source>

Win32ServiceInformation modules

2008-03-10T22:26:46Z

There are a number of modules that provide information about windows services.

Microsoft.Windows.ExistingWin32ServiceInformationProvider
Microsoft.Windows.Win32ServiceInformationProvider
Microsoft.Windows.ExistingWin32ServiceInformationProbe
Microsoft.Windows.Win32ServiceInformationProbe

They are distinguished from each other in two different dimensions. They can refer only to existing services, and they can be either a probe or a data source. All of them output the same data. The difference is when they will output the data. The 'Existing' versions of the modules only operate on services that are installed on the machine. They will never output State with either 'SERVICE_NOT_FOUND' or 'SERVER_NOT_FOUND'. The Provider versions will output data when the service state changes in some way, or every 10th 'Frequency' seconds. The Probe versions output data every time they are executed.

An example configuration for a Provider is:

<ComputerName>SAMPA01</ComputerName>
<ServiceName>SNMP</ServiceName>
<Frequency>60</Frequency>

The configuration for Probes is exactly the same, but without the Frequency parameter.

Internally, all of the modules read the state of the windows service in the same way. They combine the outputs of the following Win32 calls, QueryServiceStatus, QueryServiceStatusEx, QueryServiceConfig, and QueryServiceConfig2. The output data is a PropertyBag with the following properties and meanings.

Name	Type	Meaning
State	Integer	One of the following values 1 : SERVICE_STOPPED 2 : SERVICE_START_PENDING 3 : SERVICE_STOP_PENDING 4 : SERVICE_RUNNING 5 : SERVICE_CONTINUE_PENDING 6 : SERVICE_PAUSE_PENDING 7 : SERVICE_PAUSED 8 : SERVICE_NOT_FOUND 9 : SERVER_NOT_FOUND
ServiceType	Integer	This is a bit mask with the following values 0x00000001 SERVICE_KERNEL_DRIVER 0x00000002 SERVICE_FILE_SYSTEM_DRIVER 0x00000010 SERVICE_WIN32_OWN_PROCESS 0x00000020 SERVICE_WIN32_SHARE_PROCESS
StartMode	Integer	0 : SERVICE_BOOT_START 1 : SERVICE_SYSTEM_START 2 : SERVICE_AUTO_START 3 : SERVICE_DEMAND_START 4 : SERVICE_DISABLED
ErrorControl	Integer	0 : SERVICE_ERROR_IGNORE 1 : SERVICE_ERROR_NORMAL 2 : SERVICE_ERROR_SEVERE 3 : SERVICE_ERROR_CRITICAL
TagId	Integer	A unique tag value for this service in the group specified by the lpLoadOrderGroup parameter. A value of zero indicates that the service has not been assigned a tag.
ProcessId	Integer	This is the process id of the process hosting this service. It can be either it's own process, or a shared process with other services.
Name	String	This is the name of the service.
BinaryPathName	String	This is the full path to the binary that hosts this service.
LoadOrderGroup	String	This is the name of the load order group, such as "NDIS"
Dependencies	String	Dependent services for this service.
ServiceStartName	String	If the service type is SERVICE_WIN32_OWN_PROCESS or SERVICE_WIN32_SHARE_PROCESS, this member is the name of the account that the service process will be logged on as when it runs. This name can be of the form DomainName\Username". If the account belongs to the built-in domain, the name can be of the form ".\Username". The name can also be "LocalSystem" if the process is running under the LocalSystem account. If the service type is SERVICE_KERNEL_DRIVER or SERVICE_FILE_SYSTEM_DRIVER, this member is the driver object name (that is, \FileSystem\Rdr or \Driver\Xns) which the input and output (I/O) system uses to load the device driver. If this member is NULL, the driver is to be run with a default object name created by the I/O system, based on the service name.
DisplayName	String	The display name to be used by service control programs to identify the service
Description	String	The description of the service.

How to include information from the data item that generates an alert in the alert description

2007-05-18T20:10:26Z

This works for an alert generating rule. This is an example for a generic CSV rule generated through the UI using "Create a New Rule" using "Alert Generating Rules" -> "Event Based" -> "Generic CSV Text Log (Alert)"

Here is a line from the log file that we will use for the example.

parameter1,ERROR,parameter3

To include the 1st parameter of a the Data Item, use the following expression.

$Data/EventData/DataItem/Params/Param[1]$

The full description string could look like

This is an alert about $Data/EventData/DataItem/Params/Param[1]$

The reason this works is because the data source for this rule outputs System.Event.Data data items. The data source is System.ApplicationLog.GenericCSVLog.FilteredEventProvider. It reads the specified logs and outputs System.Event.Data items. Here is an example System.Event.Data that contains information from a CSV log file. Notice that the log file parameters are nested fairly deeply in the data item. I've marked them with underline.

<DataItem type="System.Event.Data" time="2007-05-22T10:07:41.6416394-07:00" sourceHealthServiceId="A9BB62D3-BEF2-5208-E680-1EE489235408">
  <EventOriginId>{8ED89955-E479-40A9-E83A-BB4A37A48499}</EventOriginId>
  <PublisherId>{1F68E240-153F-3990-0560-2AC472836C4A}</PublisherId>
  <PublisherName>GenericCSVLog</PublisherName>
  <Channel>GenericCSVLog</Channel>
  <LoggingComputer />
  <EventNumber>0</EventNumber>
  <EventCategory>3</EventCategory>
  <EventLevel>0</EventLevel>
  <UserName />
  <RawDescription />
  <CollectDescription Type="Boolean">true</CollectDescription>
  <EventData>
    <DataItem type="System.ApplicationLog.GenericLogEntryData" time="2007-05-22T10:07:41.6416394-07:00" sourceHealthServiceId="A9BB62D3-BEF2-5208-E680-1EE489235408">
    <LogFileDirectory>d:\genericlogs</LogFileDirectory>
    <LogFileType>Generic CSV Log File Format</LogFileType>
    <LogFileName>d:\genericlogs\generic1.log</LogFileName>
    <Params>
      <Param>parameter1</Param>
      <Param>ERROR</Param>
      <Param>parameter3</Param>
    </Params>
    <DataItem>
  </EventData>
 <EventDisplayNumber>0</EventDisplayNumber>
 <EventDescription />
</DataItem>

Application Log Monitoring

2007-04-21T03:51:33Z

This is going to be a very dense introduction to application log monitoring. I'm going to have subsequent posts that cover parts of this in more depth.

Application log monitoring refers to reading log files on the local computer and processing the entries contained in them. SCOM processes a number of different log file types. These are:

Generic

This is a text file that contains one line per log entry

Generic CSV

This is a text file that contains one line per log entry, with parameters that are separated by a character. The most common separator is a comma ','.

IIS
W3C
NCSA
Binary

These are generated by Internet Information Services. See http://msdn2.microsoft.com/en-us/library/aa814382.aspx for information about these formats. IIS, W3C, and NCSA are text files, while Binary is a binary log format.

HTTP Error

This is a text file generated by the http.sys driver. It is quite similar to the W3C format, but with different fields. See http://support.microsoft.com/kb/820729 for informat about this format.

Monitoring is done by one of the following modules, depending on the type of log file to be monitored.

System.ApplicationLog.BinaryLogReader
System.ApplicationLog.IISLogReader
System.ApplicationLog.NCSALogReader
System.ApplicationLog.W3CLogReader
System.ApplicationLog.GenericLogReader
System.ApplicationLog.GenericCSVLogReader
System.ApplicationLog.HTTPErrorLogReader

The modules output one of the following data types.

System.ApplicationLog.InternetLogEntryData

This is output for the IIS, W3C, NCSA, and Binary log file types

System.ApplicationLog.GenericLogEntryData

This is output for the Generic and GenericCSV log file types

System.ApplicationLog.HTTPErrorLogEntryData

This is output for the HTTP Error log file type

The fields of System.ApplicationLog.InternetLogEntryData are listed below. Not all of the modules fill out all of the fields, because the log file formats don't all have every field.

LogFileDirectory
LogFileType
LogFileName
Date
Time
ClientIP
UserName
SiteID
ServerName
ServerIP
ServerPort
Method
URIStem
URIQuery
ProtocolStatus
WindowsStatus
BytesSent
BytesReceived
BytesTransferred
TimeTakenInMS
ProtocolVersion
ProtocolSubstatus
HostHeader
UserAgent
Cookie
Referrer

The fields of System.HTTPErrorLogEntryData are listed below.

LogFileDirectory
LogFileType
LogFileName
Date
Time
ComputerName
ClientIP
ClientPort
ServerIP
ServerPort
ProtocolVersion
Verb
CookedURL
UserAgent
Cookie
Referer
Host
ProtocolStatus
BytesSent
BytesReceived
TimeTaken
SiteID
ReasonPhrase
QueueName

The fields of System.GenericLogEntryData are listed below. NOTE: The Generic log type has only one Param field. The Generic CSV log type has one Param entry per parameter in the log file.

LogFileDirectory
LogFileType
LogFileName
Params

Param
Param
...
Param

Property Bag

2007-02-08T02:24:13Z

The System.PropertyBagData data type is used by several modules. A partial list of the modules is below.

Microsoft.Windows.LdapProbe
Microsoft.Windows.Win32ServiceInformationProbe
Microsoft.Windows.DependentNTServiceStateProbe
Microsoft.Windows.WmiEventProvider

This is just a partial list. The property bag is used in many modules because it is very flexible. It consists conceptually of a set of collections of name value pairs called properties. There is a default collection, which is all that most modules or scripts make use of, and there can also be named collections. The values are actually stored as Variants, so each property has a Name, VariantType, and a value.

Here is a sample property bag in XML form. It has the properties Computer, User2, and Bool in it's default collection. It has a named collection "TargetInstance" which has two properties, InsideUser and IntInside.

<DataItem type="System.PropertyBagData" time="2005-08-17T11:23:51.0870595-07:00">
    <Property Name="Computer" VariantType="8">SAMPATTON01</Property>
    <Property Name="User" VariantType="8">SamPattonOutside</Property>
    <Property Name="User2" VariantType="8">SamPatton2</Property>
    <Property Name="Bool" VariantType="11">true</Property>
    <Collection Name="TargetInstance">
        <Property Name="InsideUser" VariantType="8">SamPattonInside</Property>
        <Property Name="IntInside" VariantType="3">17</Property>
    </Collection>
</DataItem>

The XML version of the data type is important because rules and monitors access the data in a data type using XPath. A couple examples are below.

To access the Computer field, the XPath is Property[@Name='Computer']

To access the IntInside field, the XPath is Collection[@Name='TargetInstance']/Property[@Name='IntInside']

The queries above would evaluate to SAMPATTON01 and 17 respectively.

There is one more field in the property bag, the ConversionType. This field is only important for script generated property bags. I'll be adding more to this entry to cover that at a later time.

First Post

2006-09-13T21:30:49Z

My name is Sam Patton. I'm a developer on System Center Operations Manager 2007 at Microsoft. My main area are the WMI modules, the LDAP modules, and the mapping modules.

My goal in writing this blog is to give people a better understanding of the internal workings of the modules and how to use them more efficiently.