I was creating a custom event data source module today, using the Microsoft.Windows.BaseEventProvider, and ran into a problem.

After importing the pack into the management group, I saw these events on all targeted agents.

Log Name:      Operations Manager
Source:        HealthService
Date:          5/15/2014 4:38:34 PM
Event ID:      4511
Task Category: Health Service
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      sql01.scomskills.com
Description:
Initialization of a module of type "CrimsonDataSource" (CLSID "{B98BD20C-3CC8-4AFE-9F68-5702C74D73DB}") failed with error code The parameter is incorrect. causing the rule "Scomskills.CustomModules.Rule.FileSizeScriptException" running for instance "SQL01.scomskills.com" with id:"{6898E94D-1E65-E33B-F8DF-7BF9A124CF6F}" in management group "2012-SP1".

It ended up being that the Microsoft.Windows.BaseEventProvider required ComputerName as configuration, even though ComputerName is marked as optional configuration.

Digging in a little further, event details above call out CrimsonDataSource CLSID {B98BD20C-3CC8-4AFE-9F68-5702C74D73DB}.

Taking a look at the module implementation, we can see this is exactly the class id referenced:

<DataSourceModuleType ID="Microsoft.Windows.BaseEventProvider" Accessibility="Public">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>Microsoft.Windows.ComputerNameSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="ComputerName" type="ComputerNameType" minOccurs="0" maxOccurs="1" />
    <xsd:element name="LogName" type="xsd:string" />
    <xsd:element name="AllowProxying" type="xsd:boolean" minOccurs="0" maxOccurs="1" />
  </Configuration>
  <ModuleImplementation>
    <Native>
      <ClassID>B98BD20C-3CC8-4AFE-9F68-5702C74D73DB</ClassID>
    </Native>
  </ModuleImplementation>
  <OutputType>Microsoft.Windows.EventData</OutputType>
</DataSourceModuleType>

 

Another interesting part is that Microsoft.Windows.ComputerNameSchema is referenced as an included schema. The interesting part here is, when a schema type is included in a data source module, this automatically precludes that xsd element from being optional – in this case, ComputerName.

<SchemaType ID="Microsoft.Windows.ComputerNameSchema" Accessibility="Public">
  <xsd:simpleType name="ComputerNameType">
    <xsd:restriction base="xsd:string">
      <xsd:minLength value="0" />
      <xsd:maxLength value="260" />
    </xsd:restriction>
  </xsd:simpleType>
</SchemaType>

 

If the included schema type had a minOccurs flag, ComputerName would in fact be optional in the data source. But this is not the case in this example.

I suppose the point to this entire post is:

Beware of "optional" configuration, because it may actually be required and result in a broken data source if it’s missing.

In these cases, it is minimally required to pass in empty configuration, as demonstrated below.

<DataSource ID="DS1" TypeID="Windows!Microsoft.Windows.BaseEventProvider">
  <ComputerName />
  <LogName>Operations Manager</LogName>
</DataSource>

 

 

🙁