Sampa @ Work

System Center Operations Manager 2007 module information

  • Win32ServiceInformation modules

    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.

      Posted Monday, March 10, 2008 8:26 PM by sampatton | 1 Comments

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

      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>
      Posted Friday, May 18, 2007 6:10 PM by sampatton | 2 Comments

    • Application Log Monitoring

      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
      • 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
      Posted Saturday, April 21, 2007 1:51 AM by sampatton | 0 Comments

    • Property Bag

      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.

      Posted Wednesday, February 07, 2007 11:24 PM by sampatton | 0 Comments

    • First Post

      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.

      Posted Wednesday, September 13, 2006 7:30 PM by sampatton | 0 Comments

    This Blog

    Syndication

    Tags

    No tags have been created or used yet.

    © 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
    		Microsoft
    Page view tracker