Just a quick heads up on a new KB article we published today:
=====
A System Center Operations Manager 2007 (OpsMgr 2007) management server repeatedly logs events that are similar to the following:
Event Type: Information Event Source: OpsMgr Connector Event Category: None Event ID: 21042 Date: Time: User: N/A Computer: SERVERNAME Description: Operations Manager has discarded 5 items in management group <MG Name>, which came from <Agent FQDN>. These items have been discarded because no valid route exists at this time. This can happen when new devices are added to the topology but the complete topology has not been distributed yet. The discarded items will be regenerated.
The agent names in the 21042 event descriptions are servers that run Microsoft Failover Clustering or Microsoft Cluster Service.
If you capture verbose trace logs on the management server, the native trace log (TracingGuidsNative.log) contains messages that are similar to the following:
[0] [1428] [1312] [09/22/2011-14:44:13.325] [MOMConnector] [] [Verbose] [] [CConnectorSolutionImpl::onIncomingRead] [ConnectorSolutionImpl_cpp2186]Processing message of datatype 6:0, destination <FQDN of cluster node>
[0] [1428] [1312] [09/22/2011-14:44:13.325] [MOMConnector] [] [Error] [] [CConnectorSolutionImpl::validateDataItemRouting] [ConnectorSolutionImpl_cpp5148]Received a DATATYPE_CONTRIBUTOR_STATE_REQUEST from <Health Service ID>
[0] [1428] [1312] [09/22/2011-14:44:13.325] [MOMConnector] [] [Verbose] [] [CConnectorSolutionImpl::validateDataItemRouting] [ConnectorSolutionImpl_cpp5151]<Jobs><Job ID="6C8BEDC9-5332-7143-D192-84C218878A5A" BatchID="2027CBF5-B248-4A0E-8F9A-32A0F2C56E41" TaskID="4BE723CD-BA53-F7FB-6A4A-4A5F062E77EF" TargetInstanceID="<Health Service ID>" JobCategory="0" ><Overrides><Override><Path>MonitorId</Path><Value>A6C69968-61AA-A6B9-DB6E-83A0DA6110EA</Value></Override></Overrides></Job></Jobs>
[0] [1428] [1312] [09/22/2011-14:44:13.325] [MOMConnector] [] [Error] [] [CConnectorSolutionImpl::onIncomingRead] [ConnectorSolutionImpl_cpp2210]Bad routing for a data item detected
[0] [1428] [1312] [09/22/2011-14:44:13.340] [Common] [] [Verbose] [] [Common::EventLogUtil::LogEvent] [EventLogUtil_cpp321]Logging informational event 21042 with args "5", "<MG Name>","<FQDN of a different node on the same cluster>", "NULL", "NULL", "NULL", "NULL", "NULL", "NULL"
In the above trace log messages, the FQDN in the first trace message and the FQDN in the last trace log message are different physical nodes in the same failover cluster.
This is a known issue in OpsMgr 2007 that occurs when an agent that is part of a cluster runs a dependency monitor. In some cases, unit monitors that contribute to the dependency monitor state may run on a different node in the cluster. This results in an agent sending state data to another agent via the management server. When this occurs, the management server discards the state data and logs a 21042.
If the agent names in the 21042 events are cluster nodes, you can safely ignore these messages.
For the most current version of this article please see the following:
2622195: A System Center Operations Manager 2007 management server repeatedly logs 21042 events for agents on clustered servers
J.C. Hornbeck | System Center Knowledge Engineer
App-V Team blog: http://blogs.technet.com/appv/ AVIcode Team blog: http://blogs.technet.com/b/avicode ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ OOB Support Team blog: http://blogs.technet.com/oob/ Opalis Team blog: http://blogs.technet.com/opalis Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/ SCMDM Support Team blog: http://blogs.technet.com/mdm/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/