Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Filtering out undesired RILOE inventory events at the agent

Created: 18 Nov 2013 • Updated: 28 Nov 2013
Ludovic Ferre's picture
+1 1 Vote
Login to vote

The Deployment Solution Agent (7.x) comes in as an all or nothing bundle. Once installed the agent will run all of its tasks whenever it finds it suitable, without giving administrators a chance to control what should or should not be done.

The iLO inventory is one such task that the Deployment Agent runs everytime the agent is started. Given you can't disabled the inventory process you cannot either prevent the events related to running the task.

This means that if you have 10,000 computers starting on Monday morning all with the Deployment Agent installed you will get 10,000 RILOE Capture Event messages sent to the SMP.

As previously stated with the DS Agent it's an all or nothing deal, but thankfully some Agent built-in feature can be used here to prevent the undesired messages from living the workstation:

The Altiris Agent Transport Filters. These filters are normally delivered to the managed machine with its client policy and are stored in the registry under "HKLM\SW\Altiris\Altiris Agent\Transport\Filters". But any registry key that exist in the given location (whether it cames from the agent policy or not) will be read and used to filter out events that should not be sent to the SMP.

The filters are xpath queries. The query needed to filter out iLO capture event message is shown below.

Xpath event filter registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Transport\Filters]

"Connect Filter iLO capture events"="/message/to[. = '3737c829-1634-4e1c-85f6-757d532be374']"
Important note!!! The agent will clear out the filters anytime it is restarted so the registry key will have to be protected from such deletion via permission. This comes with serious caveats and cost if you already use filters, as the changes would prevent filter strings from being deleted. So this is something worth keeping in mind before experimenting this out. 
 

Sample iLO capture event message:

 
<?xml version="1.0"?>
<message>
<to>3737c829-1634-4e1c-85f6-757d532be374</to>
<priority>0</priority>
<msgId>{C11A81CF-9922-46E0-98F9-F4E032619430}</msgId>
<time>20131118151711.270000+000</time>
<from>
                <resource typeGuid="{2C3CB3BB-FEE9-48DF-804F-90856198B600}" guid="{0D9AEFAD-0EE6-49C1-9145-82169BF62791}" name="SQL-W2K8-01">
                                <key name="name.domain" value="SQL-W2K8-01.EPM"/>
                                <key name="fqdn" value="SQL-W2K8-01.EPM.local"/>
                                <key name="uniqueid" value="r/+IgVv6FE2fIRFlN5TxSg=="/>
                                <key name="uniqueid" value="uPG8ZqqMCuMYq41gEI0Z/Q=="/>
                </resource>
</from>
<body>
                <inventory>
                                <dataClass name="Agent Plugin Inventory">
                                                <data>
                                                                <resource partialUpdate="false">
                                                                                <row c1="None" c2="No Asset Tag" c3="True" c4="False" c5="True" c9="440BX Desktop Reference Platform" c10="VMware, Inc." c11="VMware Virtual Platform" hash="2S7ZjS3z7SfTo1LJren+vg=="/>
                                                                </resource>
                                                </data>
                                </dataClass>
                </inventory>
</body>
</message>
The highlighted xml above is the inventory fragment that is sent using the riloe capture item, however in many cases this data is not actively used and can be discarded.