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>
🙁
Great find Johnathan! Thanks for sharing this.