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:
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.
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 themanagement 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 OperationsManager.
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.
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. Forexample:
<DiscoveryPropertyOverride ID="Override.For.ICMP.Only.Discovery" Enforced="false" Property="Enabled" Context="NetworkLibrary!System.NetworkManagement.IcmpOnlyGroup" Discovery="DiscoverMyDevice" > <Value>false</Value> </DiscoveryPropertyOverride>
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 performancecounters, 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 orerror 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> <NumberOfSamples>1</NumberOfSamples> <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
System.NetworkManagement.Monitoring
The main things to keep in mind when updating the SNMP workflows are:
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included utilities are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.
In a previous post, my co-worker Chris showed off our new Performance Widget and detailed how to configure it. Continuing with our series of post on Dashboards and Widgets in System Center Operations Manager 2012, today I plan on focusing on configuring the new Alert Widget.
(Like the last performance widget post, this post assumes that you have already created a dashboard using the instructions in the Dashboards post, and that you have at least one cell that does not yet have a widget.)
Step 1: In an empty dashboard cell, click on the “Click to add widget” link. This opens the New Dashboard and Widget Wizard.
Step 2: Now you are presented with a selection of the available widgets. Select Alert Widgets and then click Next.
Step 3: Once you give your widget a name and a description, you can choose a group or object for which to display alerts. The ability to select between “Groups” and “Groups and objects” allows you to change the scope of objects for which you will receive alerts. If you only want to target a certain object within a group or class, the “Groups and objects” option allows you to do so, while the “Groups” option enables you to view alerts for all objects within the group you choose.
Step 4: Next you can specify the criteria for the alerts you will receive. You may choose the Severity, Priority, and Resolution State of the alerts. For example, I will receive alerts for warnings and information of all priority, and in either the new or closed state.
Step 5: Lastly, select the columns to display for each alert. You can also decide how the alerts are sorted by default as well as how they are grouped.
One great addition to the alert widget that is not present in the alert view is the addition of the “Is Monitor Alert” column. This column allows you to see whether the alert was generated by monitor rather than a rule. In my example, I will group alerts by “Is Monitor Alert” and sort by “Last Modified”.
And there you have it. We’ve configured a dashboard with a powerful alert widget. It is a great way to quickly view the alerts you care about organized in the way you want.
If you aren’t satisfied with your configuration or if your needs change, you can always click the button which gives you the option to reconfigure, personalize, or remove your widget. Reconfiguring a widget opens a wizard with your previously chosen widget configuration and allows you to change all of options to keep up to date with your needs. Here you can change everything from the groups or objects targeted, to the name of the widget. Personalizing a widget allows you to change the display options for that widget. Here you can change which columns are displayed and how your alerts are grouped and sorted. This allows you to view the alerts within a context that is most appropriate to you, but without having to worry about the primary configuration details.
Thanks for reading, and don’t forget to keep up with the Operations Manager Team Blog for new information about widgets and dashboards!
OM Community,
System Center Operations Manager 2007 R2 now supports SQL Server 2008 R2 SP1. Note: We will have the Supported Configuration posted in the next few weeks to make this more official, but feel free to go ahead and install it.
Thanks!
Nishtha Soni | Program Manager
The Monitoring Pack for Active Directory (AD) provides both proactive and reactive monitoring of your Active Directory deployment. It monitors events that various Active Directory components and subsystems place in the Application, System, and Service event logs. It also monitors the overall health of the Active Directory system and provides alerts for critical performance issues. The monitoring that this monitoring pack provides includes monitoring of domain controllers and monitoring of health from the perspective of clients that use Active Directory resources. To monitor domain controllers, ADMP provides a predefined, ready-to-run set of processing rules, monitoring scripts, and reports that are designed specifically to monitor the performance and availability of domain controllers. Because client computers in your Active Directory environment can experience connectivity and service issues even when domain controllers appear to be operating correctly, ADMP includes the Active Directory Client Management Pack, which can help you identify such issues. The Active Directory Client Management Pack monitors the services that domain controllers provide. It provides information—in addition to the information that is collected directly on the domain controllers—about whether domain controllers are available by running transactions, such as Lightweight Directory Access Protocol (LDAP) binds and pings, against the directory service. The September 2011 revision of the Monitoring Pack for Active Directory includes the following additions:
Feature Summary
Known Issues for Localized Releases
Release History
In a previous post my friend and co-worker Dale introduced the new Dashboard capability in System Center Operations Manager 2012. He showed a screenshot of a dashboard containing a Performance Widget, but now I want to show you how to configure your own Performance Widget.
First however, I have some great news for you. The performance widget does not have the same limitation as the performance view regarding the age of historical data that can be shown. Whereas the performance view only queries the Operations database for data, which by default only stores 7 days of historical data, the performance widget gets its data from the data warehouse (OperationsDW database), which contains up to 400 days of data by default!
(This post assumes that you have already created a dashboard using the instructions in the previous post, and that you have at least one cell that does not yet have a widget.)
Step 1: click on the “Click to add widget…” link in an empty dashboard cell. This will open the New Dashboard and Widget Wizard.
Step 2: Now you will see the widgets available. Select the performance widget.
Step 3: After giving the new widget a name, select a group of objects to display performance data for:
For instance, the All Windows Computers group:
Step 4: Select the performance counter(s) that you want to see:
In order to make it easy to get a widget that shows data on the first attempt, the list of available performance counters is scoped to only those counters being collected for the objects in the group you specified in the previous step.
You have the ability to select more than one object/counter/instance to show. Just find your additional counters and add them to the list of Selected Items at the bottom.
Step 5: Specify the time range that you want to see data for.
The chart is optimized to show no more than 100 data points per line to improve querying and rendering performance. It is important to consider this when configuring the time range for the following reasons:
Step 6: Finally, configure the way you would like the chart and legend to display.
In the legend, you can specify which columns to show. If you select a column like Maximum Value, for each series the maximum value of all the displayed points will be shown in the legend.
Stay tuned…
Keep watching the Operations Manager Team Blog for more information about our out-of-the-box dashboards, how partners will ship their dashboards and the new widgets!
http://blogs.catapultsystems.com/cfuller/archive/2011/10/04/new-functionality-in-the-windows-server-core-os-mp-version-6-0-6957-0.aspx
Kevin Holman has already written up on this MP at http://blogs.technet.com/b/kevinholman/archive/2011/09/30/opsmgr-new-base-os-mp-6-0-6956-0-adds-cluster-shared-volume-monitoring-bpa-and-many-changes.aspx but I wanted to throw in my 2 cents on this topic. There are two critical items which I see in this MP which I see as large steps forward:
CSV Monitoring: I was at a client when a CSV ran out of disk space and that was close to being a really bad issue. Any insights that we can provide on CSV’s and their health in OpsMgr are extremely beneficial.
New Reports: I saw these at MMS and have been looking forward to when they will be released. Note: These are added as a separate MP which you need to download from the pinpoint site.
All thanks to Kevin Holman -some issues being reported – at least there are workarounds
http://blogs.technet.com/b/kevinholman/archive/2011/09/30/opsmgr-new-base-os-mp-6-0-6956-0-adds-cluster-shared-volume-monitoring-bpa-and-many-changes.aspx