Freigeben über

Migrating Operations Manager 2007 R2 Network Monitoring

  • Artikel

Operations Manager 2012 network monitoring functions differently than it did in Operations Manager 2007.  Monitoring for existing instances of network devices is backwards compatible, but no new devices can be added using the existing monitoring. These changes made will require changes to Management Packs that were using SNMP based workflows. 

There are three big changes made for network monitoring:

  • The base class for network devices was changed
  • Discovery and monitoring of many venders’
    network devices is available out of the box
  • The SNMP stack was changed

In Operations Manager 2012 the Microsoft.SystemCenter.NetworkDevice class is deprecated and should no longer be used.  SNMP based workflows will need to be updated to use the new class System.NetworkManagement.Node.  The section “Network Device base Object Change” goes more into detail on this change.

Discovery and monitoring for many venders’ network devices is available out of the box in Operations Manager 2012.  Network discovery now goes beyond just finding Network devices; it now discovers the internal components of the devices and has built in  monitoring for many of these components.  As a first step in updating your management packs you should see what the out of the box discovery and monitoring cover for your network devices.

The SNMP Stack change does not affect any of the existing SNMP workflows because the modules are backwards compatible.  The new stack did introduce new modules that can be used to simplify SNMP based workflows.  This is possible because the new modules were written to manage some of the common SNMP actions inside of the module, so the workflows can be cleaner.   Some of the examples below will highlight some of these syntax changes.

Network Device Base Object Change

The change of the network device base object will have the largest impact on workflows.   In Operations Manager 2007 R2 Microsoft.SystemCenter.NetworkDevice was the base of class for monitoring network devices.  In Operations Manager 2012 the base class is now System.NetworkManagement.Node.

Microsoft.SystemCenter.NetworkDevice has been deprecated, and the display name has been changed to “Legacy SNMP Network Device”.    Microsoft.SystemCenter.NetworkDevice types will not be discovered from the Operations Manager Administration pane anymore.  Management Packs based on the Legacy SNMP Network Device will continue to work for instances and workflows discovered before the upgrade to Operations Manager 2012.  The difference is no new instances of SNMP Device can be added to the
management group.  In order to discover and monitor new network devices the management packs will need to migrate to the new class.

The new base network class is System.NetworkManagement.Node, or “Node”.  It is declared in the new System.NetworkManagement.Library management pack.   Network discoveries run from the administration pane of Operations Manager 2012 will create instances of the node class.

The node class has several advantages over the Legacy SNMP Network Device.  The community string is changed from being a property on the legacy class, to being a new RunAs Account type.  This RunAs account allows you to change the community string for all network devices from one location.   The RunAs account supports both SNMP V1/V2 and SNMP V3 credentials.

Previously network devices in a management pack used Microsoft.SystemCenter.NetworkDevice as the base class:

 <ClassType ID="MyDevice" Accessibility="Public" Abstract="false" Hosted="false" Singleton="false" Base="LegacyNetworkDevice!Microsoft.SystemCenter.NetworkDevice" />

 The management pack will not be upgradable if the base of the MyDevice class is changed.  In order to keep the management pack upgradable a new class needs to be created:

 <ClassType ID="MyNewDevice" Accessibility="Public" Abstract="false" Hosted="false" Singleton="false" Base="System.NetworkManagement.Library!System.NetworkManagement.Node" />

 

This new class will cause a disjoint in the monitoring of the network device.  When the network device is discovered as the new instance of Node base class, the historical data (performance counters, health state) will be for a new instance in Operations
Manager.

The node class uses a different Key property than the legacy device.  On the legacy device the IP Address of the device was used as the key property to identify the device.  But what IP Address should be used when a device has multiple interfaces with different IP Addresses?  The Node class avoids this issue by using the DeviceKey property, which is a string. Out of the Network Discovery Rule the DeviceKey property will be a MAC address of the SNMP Management interface of the network device.  The IP Address is still available from the node class but it has been renamed to SNMPAddress.

Discovery Module Changes

Network Device discoveries should now target the Node class instead of the Legacy Device class. Instances of node will be discovered by running a Network Discovery Rule in the Administration pane of the Operations Manager console.  Before updating the old discoveries check and see if the instances discovered by the out of the box solution cover the needs.  For example, interfaces were not discovered by the 2007 discovery, but are discovered by the 2012 discovery. 

Network Device discoveries should now target the Node class instead of the Legacy Device class.   The old network discoveries probably looked like:

 <Discovery ID="DiscoverMyDevice"
 Enabled="true" ConfirmDelivery="true"
 Priority="Normal" Target="LegacyNetworkDevice!Microsoft.SystemCenter.NetworkDevice"
 Remotable="true">

 The new discovery should look like:

 <Discovery ID="NewDiscoverMyDevice"
 Enabled="true" ConfirmDelivery="true" Priority="Normal"
 Target="NetworkLibrary!System.NetworkManagement.Node"
 Remotable="true">

 The discovery DataSourceModule also needs to have changes made to it.  The old module might have used an SNMP Probe module like:

 <ProbeAction ID="SnmpProbe" 
 TypeID="Snmp!System.SnmpProbe">
 <IsWriteAction>false</IsWriteAction>
 <IP>$Config/IPAddress$</IP>
 <CommunityString>$Config/CommunityString$</CommunityString>
 <Version>$Config/SnmpVersion$</Version>
 <SnmpVarBind> 
 <OID>.1.3.6.1.2.1.1.2.0</OID> 
 <Syntax>0</Syntax> 
 <Value VariantType="8" /> 
 </SnmpVarBind> 
 </ProbeAction>

  

The Discovery DataSourceModule should use the new SnmpProbe from System.NetworkManagement.Library. The big change in this module is removing CommunityString from a property of the Target Object, to having the community string come from the RunAs Account associated with the workflow.  Using the RunAs Account also adds support for V3 credentials, the Network Discovery Rule should manage associating the correct RunAs Account with the discovery.  One other minor change is the new module can be given a Port to connect to for SNMP.

 

 <ProbeAction ID="SnmpProbe" TypeID="NetworkLibrary!System.NetworkManagement.SnmpProbe">
 <Port>$Config/SnmpPort$</Port>
 <SNMPv3UserName>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/UserName$</SNMPv3UserName> 
 <SNMPv3AuthProtocol>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/AuthenticationProtocol$</SNMPv3AuthProtocol> 
 <SNMPv3AuthPassword>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/AuthenticationKey$</SNMPv3AuthPassword> 
 <SNMPv3PrivProtocol>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/PrivacyProtocol$</SNMPv3PrivProtocol> 
 <SNMPv3PrivPassword>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/PrivacyKey$</SNMPv3PrivPassword> 
 <SNMPv3ContextName>$RunAs[Name="NetworkLibrary!System.NetworkManagement.SnmpV3.MonitoringAccount"]/ContextName$</SNMPv3ContextName>
 <IsWriteAction>false</IsWriteAction>
 <IP>$Config/IPAddress$</IP> 
 <CommunityString>$RunAs[Name="NetworkLibrary!System.NetworkManagement.Snmp.MonitoringAccount"]/CommunityString$</CommunityString>
 <Version>$Config/SnmpVersion$</Version>
 <SnmpVarBind>
 <OID>.1.3.6.1.2.1.1.2.0</OID>
 <Syntax>0</Syntax>
 <Value VariantType="8" />
 </SnmpVarBind>
 </ProbeAction>

 

Another change is in using the SNMP varbind within ConditionDetection modules.  In Operations Manager 2007 R2 the index of the varbind was used to get the value returned for a particular object identifier.

 <SimpleExpression>
 <ValueExpression>
 <Value Type="String">/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value</Value>
 <Operator>Equal</Operator>
 </ValueExpression>
 <ValueExpression>
 <Value Type="String">$Config/ExpectedOID$</Value>
 </ValueExpression>
 </SimpleExpression>

  

In Operations Manager 2012 the SNMP varbind can be referenced by using the object identifier instead of the index.  The index can still be used as the SNMP varbind supports both methods of referencing the probe return results. 

 <Expression> <SimpleExpression> <ValueExpression> <Value Type="String">/DataItem/SnmpVarBinds/SnmpVarBind[OID=".1.3.6.1.2.1.1.2.0"]/Value</Value> </ValueExpression> <Operator>Equal</Operator> <ValueExpression> <Value Type="String">$Config/ExpectedOID$</Value> </ValueExpression> </SimpleExpression></Expression>

Another change the key property defining the class instance to associate the discovered object with.  In the 2007 discovery the legacy device used IP Address as the key property. This can be seen in the InstanceSettings of the Discovery:

 <InstanceSettings>
 <Settings>
 <Setting>
 <Name>$MPElement[Name="LegacyNetworkDevice!Microsoft.SystemCenter.NetworkDevice"]/IPAddress$</Name>
 <Value>$Config/IPAddress$</Value>
 </Setting>
 <Setting>
 <Name>$MPElement[Name="System.Library!System.Entity"]/DisplayName$</Name>
 <Value>$Config/DeviceName$</Value>
 </Setting>
 </Settings>
 </InstanceSettings>
  

The new 2012 discovery uses the DeviceKey property instead of the IP Address, so the InstanceSettings need to be updated as follows:

 <InstanceSettings>
 <Settings>
 <Setting>
 <Name>$MPElement[Name="NetworkLibrary!System.NetworkManagement.Node"]/DeviceKey$</Name>
 <Value>$Config/DeviceKey$</Value>
 </Setting>
 <Setting>
 <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
 <Value>$Config/DeviceName$</Value>
 </Setting>
 </Settings>
 </InstanceSettings>

 There is one more change for the discovery.  The 2012 network discovery rule supports discovering network devices as ICMP only.  This means some of the nodes discovered as ICMP only are missing key items necessary to monitor using SNMP.  The new discovery should be set to not attempt to discover the ICMP only nodes with SNMP.  This can be accomplished by adding an override to disable the discovery in the context of the ICMP Only group from the Network Library management pack.  For
example:

 
<DiscoveryPropertyOverride ID="Override.For.ICMP.Only.Discovery" Enforced="false" Property="Enabled" Context="NetworkLibrary!System.NetworkManagement.IcmpOnlyGroup" Discovery="DiscoverMyDevice" > <Value>false</Value> </DiscoveryPropertyOverride>

 

SNMP Probe based Workflows

The SNMP probe module has been updated inside the System.NetworkManagement.Library management pack.  An example of using this new SNMP probe module is above in the discovery DataSourceModule. 

When the SNMP stack was replaced new SNMP modules were added to the System.NetworkManagement.Library and System.NetworkMangement.Monitoring management packs.   Utilizing these new DataSourceModules and UnitMonitorTypes can simplify the workflows, because the new modules manage some of the common operations.   For example the Monitoring management pack has a DataSourceModule for getting performance
counters, using this existing module avoids the need to write a DataSource that does a probe than a condition detection to map the probe result to a performance counter:

 <Rule ID="NewSnmp.GetTemperature" Enabled="true" Target="MyTempSensor" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
 <Category>PerformanceCollection</Category>
 <DataSources>
 <DataSource ID="DS1" TypeID="NetworkLibrary!System.NetworkManagement.SnmpPerformanceDataSource">
 <Interval>300</Interval>
 <Port>$Target/Host/Property[Type="NetworkLibrary!System.NetworkManagement.Node"]/PortNumber$</Port>
 <IP>$Target/Host/Property[Type="NetworkLibrary!System.NetworkManagement.Node"]/SNMPAddress$</IP>
 <Version>$Target/Host/Property[Type="NetworkLibrary!System.NetworkManagement.Node"]/SNMPVersion$</Version>
 <SnmpVarBinds> <SnmpVarBind> <OID>.1.3.6.1.4.1.9.9.13.1.3.1.3.$Target/Property[Type="MyTempSensor"]/Index$</OID>
 <Syntax>0</Syntax> <Value VariantType="8" />
 </SnmpVarBind>
 </SnmpVarBinds>
 <ObjectName>Temperature Sensor</ObjectName>
 <CounterName>Temperature (C)</CounterName>
 </DataSource>
 </DataSources>
 <WriteActions>
 <WriteAction ID="PerfWriteToDB" TypeID="SystemCenter!Microsoft.SystemCenter.CollectPerformanceData" />
 <WriteAction ID="PerfWriteToDW" TypeID="SCDataWarehouse!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" /> 
 </WriteActions>
 </Rule>

  

An Example of UnitMonitor change using UnitMonitorType System.NetworkManagement.HealthStateSNMPMonitorType.  In this example the -1 for HealthStateSuccess is used to indicate any value returned that is not in either the warning or
error conditions:

 <UnitMonitor ID="NewCheckMyTemperatureStatus" Accessibility="Public" Enabled="true" Target="MyTempSensor" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="System.NetworkManagement.Monitoring!System.NetworkManagement.HealthStateSNMPMonitorType" ConfirmDelivery="true">
 <Category>AvailabilityHealth</Category>
 <AlertSettings
 AlertMessage="TempSensorStatus_AlertMessageResourceID">
 <AlertOnState>Warning</AlertOnState>
 <AutoResolve>true</AutoResolve>
 <AlertPriority>Normal</AlertPriority>
 <AlertSeverity>MatchMonitorHealth</AlertSeverity>
 <AlertParameters>
 <AlertParameter1>$Target/Property[Type="System!System.Entity"]/DisplayName$</AlertParameter1>
 <AlertParameter2>$Target/Host/Property[Type="System!System.Entity"]/DisplayName$</AlertParameter2>
 </AlertParameters>
 </AlertSettings>
 <OperationalStates>
 <OperationalState ID="SuccessState" MonitorTypeStateID="MTSDeviceSuccess" HealthState="Success" />
 <OperationalState ID="WarningState" MonitorTypeStateID="MTSDeviceWarning" HealthState="Warning" />
 <OperationalState ID="ErrorState" MonitorTypeStateID="MTSDeviceError" HealthState="Error" />
 </OperationalStates>
 <Configuration>
 <Interval>600</Interval>
 <ObjectIndex>$Target/Property[Type="MyTempSensor"]/Index$</ObjectIndex>
 <OID>.1.3.6.1.4.1.9.9.13.1.3.1.6.$Target/Property[Type="MyTempSensor"]/Index$</OID>
 <HealthStateSuccess>-1</HealthStateSuccess>
 <HealthStateWarning>(2)</HealthStateWarning>
 <HealthStateError>(3|4)</HealthStateError>
 </Configuration>
 </UnitMonitor>

 There are also some minor changes to SNMP trap based workflows but the new workflows look similar to before.  The biggest change is the Community String now comes from the RunAs account instead of from a property on the legacy device.

 <Rule ID="NewSnmp.ConfigurationChangeAlert" Enabled="true" Target="MyNewDevice" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100"> <Category>ConfigurationHealth</Category> <DataSources> <DataSource ID="SnmpTrap" TypeID="NetworkLibrary!System.NetworkManagement.SnmpTrapProvider"> <IP>$Target/Property[Type="NetworkLibrary!System.NetworkManagement.Node"]/SNMPAddress$</IP> <CommunityString>$RunAs[Name="NetworkLibrary!System.NetworkManagement.Snmp.MonitoringAccount"]/CommunityString$</CommunityString> <AllTraps>false</AllTraps> <OIDProps> <OIDProp>.1.3.6.1.4.1.9.9.43.2.0.1</OIDProp> </OIDProps> </DataSource> </DataSources> <WriteActions> <WriteActions> <WriteAction ID="WriteToDB" TypeID="Microsoft.SystemCenter.Library!Microsoft.SystemCenter.CollectEvent" /> </WriteActions> </WriteActions> </Rule>

 

Check out the module types in the Network Library and Monitoring management packs to see where you can leverage existing modules types and avoid writing new DataSourceModules and new UnitMonitorTypes:

System.NetworkManagement.Library

  • ProbeActionModuleType  System.NetworkManagement.SnmpProbe
  • DataSourceModuleType  System.NetworkManagement.SnmpDataSource
  • DataSourceModuleType  System.NetworkManagement.SnmpEventDataSource
  • DataSourceModuleType System.NetworkManagement.SnmpPerformanceDataSource
  • DataSourceModuleType  System.NetworkManagement.SnmpTrapProvider
  • DataSourceModuleType System.NetworkManagement.SnmpTrapEventProvider
  • UnitMonitorType System.NetworkManagement.SnmpProbe.2SingleEvent2StateMonitorType
  • UnitMonitorType System.NetworkManagement.SnmpProbe.SingleEventManualReset2StateMonitorType
  • UnitMonitorType System.NetworkManagement.SnmpProbe.SingleEventTimer2StateMonitorType
  • UnitMonitorType System.NetworkManagement.SnmpTrapProvider.2SingleEvent2StateMonitorType
  • UnitMonitorType System.NetworkManagement.SnmpTrapProvider.SingleEventManualReset2StateMonitorType
  • UnitMonitorType System.NetworkManagement.SnmpTrapProvider.SingleEventTimer2StateMonitorType 

System.NetworkManagement.Monitoring

  • UnitMonitorType System.NetworkManagement.HealthStateSNMPMonitorType
  • UnitMonitorType System.NetworkManagement.ThresholdMonitor

Summary

The main things to keep in mind when updating the SNMP workflows are:

  1. Operations Manager 2007 R2 Management Packs will continue to work on previously discovered instances, all the monitoring changes are backwards compatible.  Only the discovery of new instances of Microsoft.SystemCenter.NetworkDevice will not happen on Operations Manager 2012.
  2. Check and see if the out of the box Network Discovery and Monitoring covers the needs of your management pack.
  3. Migrate the Microsoft.SystemCenter.NetworkDevice class to the System.NetworkManagement.Node class.  This will mean you need to create new classes, new discoveries, new rules, and new workflows.
  4. The new Management pack will not be backwards compatible for Operations Manager 2007 because the new Network Library Management Pack will not be available on Operations Manager 2007.  The best way to manage this is to create a new management pack that can be installed alongside or in addition to your existing management pack.
  5. Look at using some of the new SNMP Module types to simplify the workflows in your management pack.  It is much easier to utilize an existing DataSourceModule then it is to implement a new DataSourceModule.  In my experience updating an existing workflow to the new methods is expensive, and it is easier to create a new workflow using the new modules.

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included utilities are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.