Operations Manager Alert: NIC Teaming Agents Not Detected or Monitored

Table of Contents

System Center Operations Manager (SCOM) is a powerful monitoring solution designed to provide comprehensive insights into the health, performance, and availability of IT infrastructure components. A critical aspect of this monitoring involves the discovery and collection of data from agent-managed computers, including their network interfaces. When these agents reside on servers configured with Network Interface Card (NIC) teaming, issues can arise where the agents are not properly discovered or monitored, leading to significant visibility gaps in your network performance. This article outlines the common symptoms, underlying causes, and resolution strategies for such scenarios, ensuring your SCOM environment accurately reflects the state of your teamed network adapters.

Understanding the Challenge: SCOM and NIC Teaming¶

Network Interface Card (NIC) teaming, also known as Link Aggregation or Bonding, is a technique that allows multiple network adapters to be combined into a single logical interface. This configuration typically offers benefits such as increased bandwidth, fault tolerance, and load balancing, making it a common choice for critical server infrastructure. However, the specialized drivers and complex interactions involved in NIC teaming can sometimes create challenges for monitoring systems like SCOM. The proper functioning of SCOM relies heavily on accurate data collection via Windows Management Instrumentation (WMI) and performance counters. If the NIC teaming drivers do not integrate correctly with these Windows components, SCOM’s ability to discover and monitor the network adapters effectively becomes compromised.

Symptoms of Undetected or Unmonitored Agents¶

When System Center Operations Manager agents are deployed on computers utilizing NIC teaming, you might encounter specific errors indicating a failure in discovery or monitoring. These issues can prevent administrators from gaining crucial insights into network performance and availability, potentially leading to undetected bottlenecks or outages. The primary indicators of this problem manifest as event log entries and specific SCOM alerts, signaling that the monitoring scripts are unable to gather the necessary data from the teamed adapters.

One of the most frequently observed symptoms is an error logged in the Operations Manager event log on the affected agent computer. This error, often with Event ID 4001, originates from the Health Service Script source and points to a problem with WMI class access. The description typically includes a message similar to: The class name 'Win32_PerfFormattedData_Tcpip_NetworkInterface Where Name ='VLAN100:HP Network Team _1'' did not return any valid instances. Please check to see if this is a valid WMI class name.. Invalid class. This error clearly indicates that SCOM’s monitoring scripts are attempting to query WMI for network interface data, but the expected WMI classes or instances related to the teamed NIC are either missing or inaccessible. The specific name VLAN100:HP Network Team _1 refers to a hypothetical teamed adapter instance, highlighting the script’s inability to find it within the WMI repository.

In addition to event log entries, you may also observe a more direct SCOM alert within the Operations Manager console. This alert typically states: The process started at [timestamp] failed to create System.PropertyBagData, no errors detected in the output. The process exited with 0. While the exit code of ‘0’ might suggest success, the failure to create System.PropertyBagData is critical. System.PropertyBagData is essential for SCOM to encapsulate and transfer collected performance and state data. The alert further specifies the command executed, such as "C:\\Windows\\system32\\cscript.exe" /nologo "Microsoft.Windows.Server.NetwokAdapter.BandwidthUsed.ModuleType.vbs", and the working directory. It also identifies the affected workflow, Microsoft.Windows.Server.2008.NetworkAdapter.PercentBandwidthUsedTotal.Collection, and the instance name, which might be a generic “Local Area Connection” or a more specific identifier. This combination of errors confirms that the SCOM management pack’s network adapter monitoring script is failing to execute correctly, specifically when trying to gather bandwidth utilization data for the teamed interface.

Symptom Category	Event ID / Alert Message	Impact
Event Log Error	Event ID: 4001, Source: Health Service Script, Description: The class name 'Win32_PerfFormattedData_Tcpip_NetworkInterface Where Name ='...' did not return any valid instances. Invalid class.	SCOM is unable to query network interface performance data via WMI. This leads to missing network performance metrics (e.g., bandwidth usage, error rates) for the teamed NIC. Critical insights into network health and throughput for these servers are lost, making it difficult to identify network bottlenecks or issues.
SCOM Alert	The process started... failed to create System.PropertyBagData, no errors detected in the output. The process exited with 0. Workflow name: Microsoft.Windows.Server.2008.NetworkAdapter.PercentBandwidthUsedTotal.Collection.	The specific SCOM workflow designed to collect network adapter bandwidth usage is failing. This results in an absence of performance data for network adapters within SCOM, triggering alerts about the monitoring failure itself rather than the underlying network performance.

These symptoms collectively point to a fundamental disconnect between the NIC teaming configuration and the Windows operating system’s management interfaces, specifically WMI and performance counters. Without accurate WMI registration and accessible performance data, SCOM cannot effectively discover or monitor the network adapters, leaving a critical blind spot in your IT infrastructure monitoring. Addressing these underlying registration issues is paramount for restoring full SCOM functionality and ensuring reliable network visibility.

Root Cause: WMI Registration and Driver Integrity¶

The core of this issue lies in how NIC teaming drivers interact with Windows Management Instrumentation (WMI). WMI is a fundamental component of the Windows operating system that provides a unified way for applications and scripts to manage and monitor various aspects of the system. SCOM, being a management and monitoring platform, relies heavily on WMI to discover hardware components, collect performance metrics, and assess the health of servers and their network interfaces. When a NIC teaming solution is implemented, its drivers are responsible for registering the teamed adapter and its associated performance counters within WMI, making them accessible for monitoring tools.

The problem arises when the drivers used for NIC teaming on the agent computer fail to properly register themselves within the WMI infrastructure. Specifically, the Windows Server Operating System management pack, typically version 6.0.6958.0 or similar, contains a crucial script named Microsoft.Windows.Server.NetwokAdapter.BandwidthUsed.ModuleType.vbs. This VBScript is designed to discover and collect bandwidth utilization data from network adapters, including those configured for teaming. The script attempts to query specific WMI classes, such as Win32_PerfFormattedData_Tcpip_NetworkInterface, to retrieve the necessary performance data. If the NIC teaming driver does not correctly expose the teamed adapter’s information through these WMI classes, the script will fail to find valid instances, leading to the “Invalid class” errors observed in the event logs.

Furthermore, a common reason for inadequate WMI registration by NIC teaming drivers is their failure to properly register the associated performance counters. Performance counters are specialized data points provided by the operating system and installed applications, offering real-time insights into system activities and resource usage. SCOM often relies on these performance counters, which are exposed via WMI, to collect granular performance data. If the NIC teaming driver does not correctly integrate its performance counters with the system, or if the WMI registration for these counters is incomplete or corrupted, SCOM’s monitoring scripts will be unable to retrieve essential metrics like network bandwidth utilization. This absence of critical data prevents the successful creation of System.PropertyBagData, which is crucial for SCOM to process and store the collected information, ultimately resulting in the monitoring failures and alerts. The integrity and compatibility of the NIC teaming driver with the underlying Windows WMI and performance counter framework are therefore paramount for seamless SCOM monitoring.

Conceptual Flow of Data Collection in a Healthy SCOM Environment¶

To better understand where the failure occurs, consider the ideal flow of data from a teamed NIC to SCOM:

1. NIC Teaming Driver: The vendor’s NIC teaming driver is installed and creates a logical teamed adapter.
2. WMI Registration: The driver correctly registers the teamed adapter and its performance counters within Windows Management Instrumentation (WMI). This creates specific WMI classes and instances that represent the teamed interface.
3. Performance Counter Registration: The driver also registers its specific performance counters (e.g., bytes sent/received) with the Windows Performance Counter subsystem. These counters are then exposed via WMI.
4. SCOM Agent: The System Center Operations Manager agent runs on the server.
5. SCOM Management Pack Script: The Microsoft.Windows.Server.NetwokAdapter.BandwidthUsed.ModuleType.vbs script, part of the SCOM Windows Server OS Management Pack, is executed by the SCOM Health Service.
6. WMI Query: The script queries WMI for Win32_PerfFormattedData_Tcpip_NetworkInterface instances that correspond to the teamed NIC.
7. Data Retrieval: If WMI registration is correct, the script successfully retrieves performance data (e.g., bandwidth utilization).
8. Property Bag Creation: The script packages this data into a System.PropertyBagData object.
9. Data Transmission to SCOM: The SCOM agent transmits the PropertyBagData to the SCOM Management Server.
10. Monitoring and Reporting: SCOM processes the data, updates the health state, and makes it available for dashboards, reports, and alerts.

When the driver fails to register correctly in step 2 or 3, the script in step 6 fails to find valid instances, leading to the observed errors and preventing data from reaching SCOM.

Resolution: Addressing the Driver Discrepancy¶

Resolving the issue of Operations Manager agents not discovering or monitoring NIC teaming configurations primarily involves addressing the underlying driver-level problem. Given that the root cause is often attributed to the NIC teaming drivers failing to properly register with WMI and performance counters, the most direct solution focuses on the source of this discrepancy. It’s important to understand that while immediate workarounds might exist, the permanent fix often requires collaboration with the hardware vendor.

The most immediate diagnostic and temporary resolution step, if you are experiencing these script failures and monitoring issues, is to temporarily disable NIC teaming on the affected agent computer. Disabling teaming can often resolve the monitoring issue immediately because the underlying individual network adapters might register correctly with WMI, allowing SCOM to monitor them without the complexities introduced by the teaming software. While this action will undoubtedly resolve the SCOM monitoring problem in the short term, it is crucial to recognize that this is merely a diagnostic measure and not a sustainable long-term solution. Disabling NIC teaming negates its benefits, such as increased bandwidth and fault tolerance, which are often critical for server stability and performance in a production environment.

The fundamental problem, namely the incorrect registration of the NIC teaming driver in WMI, needs to be addressed by the network adapter manufacturer. It is their responsibility to ensure that their drivers are fully compliant with Windows’ WMI and performance counter frameworks. When installed, a properly designed driver should seamlessly integrate itself with the operating system, making all necessary network interface details and performance metrics discoverable via standard WMI queries. Therefore, the definitive resolution involves contacting the adapter manufacturer directly. You should provide them with detailed information, including your System Center Operations Manager version, the specific driver version currently installed on the problematic servers, and the exact error messages observed (Event ID 4001, the SCOM alert messages, and the script names). This information will assist the manufacturer in diagnosing the driver-specific issue and providing a suitable solution, which might come in the form of an updated driver version, a specific hotfix, or a configuration utility designed to correct WMI registration. Always ensure that any new drivers or updates provided by the manufacturer are thoroughly tested in a non-production environment before deployment to your critical servers.

More Information and Best Practices¶

While third-party NIC teaming solutions have historically been prevalent, Microsoft integrated native NIC teaming capabilities directly into Windows Server starting with Windows Server 2012. This native solution, often referred to as Switch Embedded Teaming (SET) for Hyper-V environments, offers robust and integrated teaming functionalities. By leveraging the operating system’s built-in features, administrators can often mitigate some of the compatibility and registration issues that arise with proprietary vendor-specific teaming drivers. Using Windows Server’s native NIC teaming can potentially lead to more consistent WMI registration and better compatibility with SCOM’s default monitoring components, as Microsoft ensures its own features properly integrate with WMI and performance counters.

For environments still relying on vendor-specific NIC teaming or for ongoing SCOM agent health management, several best practices can help prevent or quickly diagnose similar issues:

1. Verify WMI Health: Regularly check the WMI repository on agent machines. Commands like winmgmt /verifyrepository can help identify WMI corruption. If corruption is found, rebuilding the WMI repository might be necessary, though this should be done with caution.
2. Check Performance Counter Integrity: Ensure that performance counters are not corrupted or missing. Tools like lodctr /q can list installed performance counters, and perfmon can be used to manually verify if network interface performance data is accessible.
3. Keep Drivers Updated: Always ensure that your network adapter drivers and any associated NIC teaming software are running the latest versions provided by the manufacturer. Driver updates frequently include bug fixes, performance improvements, and enhanced compatibility with operating system features and monitoring tools.
4. Monitor SCOM Agent Health: Implement monitoring for the SCOM agents themselves. SCOM includes management packs for agent health, which can alert you if an agent stops sending data or if its monitoring workflows are consistently failing. This proactive monitoring can help identify issues before they impact overall system visibility.
5. Understand Management Pack Versions: Be aware of the versions of the SCOM management packs you are using. Newer versions of management packs often include updated scripts and bug fixes that might improve compatibility with newer drivers or operating system features. Ensure your SCOM environment is up-to-date with the latest recommended management packs.
6. Review Manufacturer Documentation: Consult the NIC manufacturer’s documentation regarding SCOM compatibility and specific configuration requirements for their teaming software. Some vendors might offer specific instructions or utilities for ensuring proper WMI registration.

By adhering to these best practices and understanding the critical interaction between NIC teaming drivers, WMI, and System Center Operations Manager, organizations can maintain a robust and reliable monitoring environment for their network infrastructure. Proactive maintenance and prompt engagement with vendors are key to addressing complex driver-related challenges and ensuring continuous visibility into your IT operations.

---

Have you encountered similar issues with SCOM and NIC teaming? What steps did you take to resolve them? Share your experiences and insights in the comments below!