When you build a SCOM (System Center Operations Manager aka OpsMgr aka MOM) unit monitor or rule to capture Windows events, since Windows 2008 and Windows Vista clients/agents you can use the named XML parameters of the events instead of the numbered strings collection. XML representation is much better than indexing the string replacement items because different events use the same XML element and attribute names (such as TargetUserName) while the legacy string indexes often differ among different events even if they represent the same logical value.
For example, because different events would all use the TargetUserName element regardless of its position, you can also create generic event rules which could capture virtually anything happening to a particular account of your interest, such as Domain Admins group or a specific sensitive account.
Such an XML event is on the following picture - this particular one is the XML representation of an account lockout event. I have just decided to create and alert when an admin account gets locked out:
In the rule or unit monitor, you can reference the named elements instead of going for the numbered parameters as before with Windows 2003 and older. So you can pick out for example the TargetUserName or TargetDomainName or TargetSid etc. and define the conditions based on these instead of their relative numbers. Just like with the command line wevtutil you can access these named XML properties in an XPath query filter instead of using the InsertionStrings array.
Instead of using the option Specify event specific parameter to use as number in the Select an Event Property dialog box, select the option to Use parameter name not specified above and type there something similar to this:
EventData/DataItem/*[name()='EventData']/*[name=()='Data' and @Name='TargetUserName']
or you can use a shorter form
//*[name()='EventData']/*[name=()='Data' and @Name='TargetUserName']
Do not use the dolar $ signs in the expression, because you are actually filling the XPathQuery elements of Expression configuration parameter for the ConditionDetection module of the particular monitor or rule type:
On the other hand, later when you want to put the named XML attributes of the collected event into an alert, you will be using the dolar $ signs, because there you fill the AlertParameter elements which are again replaced at runtime by the workflow manager. Into the alert definition, you type something similar to the following:
$Data/Context/EventData/DataItem/*[name=()='EventData']/*[name()='Data' and @Name='TargetSid']$
The reason for this weird complex format of the XPath query is the fact that the EventData XML element has an XML namespace (xmlns) of http://schemas.microsoft.com/win/2004/08/events/event. That namespace you would either have to type for each element name or we use this XPath name() function to simlify the query. So be happy, typing the namespace would be more painful :-)
