In this article, Kevin Greene, author of book Getting Started with Microsoft System Center Operations Manager, explains hownetwork devices play a key role in our IT environments. Without them, we wouldn’t have interconnectivity between our servers, clients, and applications and it goes without saying that their availability and performance should be monitored with OpsMgr.

Here, we will discuss the out-of-the-box network monitoring capability of OpsMgr and also learn how to discover and manage network devices using the Simple Network Management Protocol (SNMP)and ICMP.

At the start of the article, we introduced the different vendors, devices, and protocol support available for network monitoring along with some requirements and considerations to get it up and running smoothly. After discovering some devices, we will demonstrate how to best use the different network monitoring dashboards to deliver purposeful visualizations based on performance and availability.

We’ll finish the articlewith a rundown on the network monitoring reports available to you with this feature.

Here’s what you will learn:

• Network monitoring overview
• Discovering network devices
• Managing network devices
• Working with dashboards
• Network monitoring reports

(For more resources related to this topic, see here.)

Network monitoringoverview

The out-of-the-box network monitoring capability has been around since the release of the original OpsMgr in 2012 and not much has changed since then. You have the ability to perform advanced monitoring of your network devices using SNMP or basic discovery and availability monitoring using ICMP (Ping).

If you use SNMP, you can get a detailed monitoring of ports, interfaces, hardware,virtual local area networks (VLAN’s), and even Hot Standby Router Protocol (HSRP) groups. With ICMP, all you get is an indication that the IP address of the network device is responding to Ping requests with very little information about the underlying components or interfaces.

Although, the network monitoring feature of OpsMgr won’t have network administrators throwing out the specialist tools they use from the likes of Cisco, for the IT administrator and IT pro, asit’s still very useful when used in the overall context of IT service monitoring. This is because, regardless of the method used to discover and monitor your network devices, if it has an IP address, you can at least get an overview of its availability in OpsMgr and then visualize it as a part of your IT service models, reports, and dashboards.

Multi-vendor support

OpsMgr network monitoring works with any device that supports SNMP and also provides extended monitoring for devices that implement the management information base (MIB) RFC 2863 and MIB-II RFC 1213standards.

Microsoft has published an Excel spreadsheet containing a list ofnearly 850 devices from various vendors that are supported for extended monitoring in OpsMgr. If you need a reference for supported vendors, you can download the spreadsheet from the following link:

http://tinyurl.com/opsmgrnetworkdevicelist

This spreadsheet gives us the details about the SNMP Object ID (OID) device type, vendor name, model, and the components that are supported for extended monitoring.

If a vendor’s network device is supported for extended SNMP monitoring, then it will be discovered as a certified device in OpsMgr. A certified device can show monitoring information for components,such as processor, memory, fans, and chassis.

A non-certified device discovered using SNMP will be registered as a generic device in OpsMgr. This means that you won’t see advanced information on hardware components, but you’ll still get interface and availability monitoring, which is more than you’d get from an ICMP monitoring.

Multi-device support

Some of the network device types that OpsMgr can monitor include switches, firewalls, load balancers, air-conditioning units, and UPS devices, basically anything that supports SNMP or ICMP. It has the flexibility to bring all the fabric components to your datacenter under monitoring; this sets OpsMgr apart from other monitoring solutions.

Multi-protocol support

Three different versions of SNMP are supported for network device monitoring—SNMP v1, SNMP v2c, and SNMP v3. The first two versions are the most common and require an SNMP community string as a passphrase for the monitoring connection to be completed, whereas the newer SNMP v3 requires a unique username and password to be configured before you can monitor devices that support it.

For ICMP, the network devices are discovered and monitored usingInternet Protocol version 4 (IPv4);OpsMgralso provides support for Internet Protocol version 6 (IPv6) when running a recursive discovery on your network.

Additional SNMP monitoring options

If you find that your network devices are discovered as non-certified (generic) and you need to get more monitoring information from them, consider some of these options:

• Check with the device vendor to see if they have authored a management pack of their own to light up extra capabilities for their hardware.
• Author your own SNMP monitoring management pack. Admittedly, this is a big suggestion to make in a beginners guide but if you’re willing to give it a go, then System Center MVP Daniele Grandini has put together an excellent series of blog posts that will walk you through this process from start to finish. You can check out the series athttp://tinyurl.com/opsmgrsnmpauthoring.
• If you’ve deployed OpsMgr 2016, then the new Network Monitoring Management Pack Generator tool (http://tinyurl.com/opsmgrmpgenerator) will help you author a custom SNMP management pack in no time. This tool (NetMonMPGenerator.exe) is located in the Server directory of the OpsMgr 2016 install location and with it you can create a management pack that monitors network device components, such as Memory, Processors, Fans, Sensors, and Power Supplies. You can download the full user guide for this tool fromhttp://tinyurl.com/mpgeneratorguide.

Requirements and considerations

There are a number of things that you’ll need to consider before you dive in to monitor your network devices, such as resource pool design, firewall rules to be configured, management packs to be deployed, and user role requirements.

Resource pools

You’ll need to create additional resource pools when designing a network monitoring architecture for your OpsMgr environments,to ensure optimal performance and scalability.

For example, if you have a large number of network devices to be monitored, it’s recommended that you assign a resource pool that includes management or gateway servers that will be specifically responsible for monitoring those devices. In this way, you can control the OpsMgr servers that are to be used to monitor agents and the ones that are exclusively monitoring your network devices.

The OpsMgr Sizing Helper tool provides guidance on how to design resource pools for network monitoring.

Firewall rules

The firewall rules between the OpsMgr servers listed in the network monitoring resource pool and the network devices to are being monitored need to be configured to allow bi-directional communication on ports 161 (UDP) and 162 (UDP) in order to support SNMP. Bi-directional ICMP traffic communication is also required to support devices that won’t be monitored using SNMP. If the Windows Firewall is configured on your OpsMgr servers, then you will need to make the changes there too, to ensure that network monitoring communication is successful.

Management packs

All core management packs required for network monitoring are deployed automatically as a part of the original OpsMgr installation and these are listed as follows:

• SNMP Library
• Network Device Library
• Network Discovery Internal
• Network Management – Core Monitoring
• Network Management Library
• Network Management Reports
• Network Management Templates
• Windows Server Network Discovery
• Windows Client Network Discovery

The last two additional management packs in this list are needed to discover the network adapters of Windows server and client computers. It’s also recommended to deploy the latest versions of core Microsoft operating system management packs to ensure that the network adapters on your agent-managed computers get monitored properly.

User roles

The user account that you use to create the network discovery rules must be a member of the Operations Manager Administrators user role, which is configurable in the User Roles section of the Administration workspace.

Understanding network discovery

The first step that you need to take to monitor and manage your network devices is to create a discovery for them. You will need to decide if you will use SNMP, ICMP, or both for discovery and then create a discovery rule to go out and find the network devices that you wish to monitor. The following sections will help you understand the process of network monitoring discovery in OpsMgr.

Discovery rules

A network discovery rule is created using the Computer and Device Management wizard from the Administration workspace of the OpsMgr console, and only one discovery rule can be assigned to each management server or gateway server. For this very reason, you will need to think about resource pool design and the placement of your management and gateway servers to ensure that they communicate with the network devices that they will be assigned to monitor.

Discovery rules can be configured to run automatically on a schedule or manually on-demand when you need to. The advantage for large organizations, of running a discovery rule on a schedule, is that you can ensure that any new network devices that have been brought online can be captured for monitoring with little effort (assuming all security requirements have been met) and any network devices that have been retired will be removed from monitoring automatically.

Discovery types

There are two types of discovery rules that you can configure – Explicit and Recursive. Here’s an explanation of both.

Explicit discoveries

An explicit network discovery rule will only attempt to discover the network devices that you explicitly specify in the wizard by IP address or FQDN. Once all the prerequisites for discovery have been met and a device has been successfully accessed, monitoring will be enabled for it and any devices that cannot be successfully accessed will be placed in the Network Devices Pending Management view for review.

An explicit discovery rule can be configured to discover and access devices using SNMP, ICMP, or a combination of them both.

Recursive discoveries

With a recursive discovery, you can first explicitly specify one or more network devices and after they are discovered OpsMgr will perform a scan to discover any other connected network devices using theAddress Routing Protocol (ARP) table, IP address table, or topology MIB of the initially discovered devices. This type of discovery grows the network map and presents all the applicable devices to you for monitoring.

Similar to the explicit discovery rule, recursive discovery can also be configured to discover and access devices using SNMP, ICMP, or both. IPv6 addresses can also be identified,however; the initial discovered device must use an IPv4 address.

With recursive discovery, you can also create a filter by using properties, such as the device type, name, and object identifier (OID) to give more control over what is or isn’t discovered.

DNS resolution of network devices

When planning your network monitoring designs, pay careful attention to the DNS resolution of your network devices. A common mistake people make when bringing their network devices under monitoring is to just use IP addresses to identify them and as a result, when OpsMgr is finished discovering the devices, they will display within the console as a list of IP addresses instead of a descriptive DNS name.

When discovering devices, OpsMgr uses a naming algorithm where it attempts DNS resolution from the following sources – where the first one in the list to succeed becomes the name of the device:

• Loopback IP
• sysName
• Public IP
• Private IP
• SNMP Agent IP

To ensure your network devices are discovered with useful DNS names, you will need to put in some work either on your corporate DNS servers by creating ‘A’ records for each network device or by creating custom entries on the local ‘hosts’ file for each OpsMgr server that will discover and manage your network devices.

If you decide to use custom entries in your local ‘hosts’ file to support DNS name resolution of your monitored network devices, remember to update the hosts file on each management and gateway server that are members of the network monitoring resource pools. If you don’t do this, then there’s a possibility that some network devices will only be discovered with their IP address.

Run as accounts

For network device discovery to be successful, a Run As account needs to be configured in OpsMgr with credentials that match the relevant access and security policies of the device to be monitored.

For SNMP v1 and SNMPv2 devices, a passphrase in the form of acommunity string is required and for SNMPv3, access credentials in the form of a username and password are needed. Read-only or read-write permissions can be configured on network devices to control how much interaction OpsMgr has with them and in nearly all cases, read-only will be sufficient.

The community string or access credentials must first be configured on the network device by someone with the relevant permissions to do so. It’s useful to discuss this requirement with network administrators before you deploy OpsMgr as this step has the potential to become a time-consuming task if there’s a lot of network devices to be configured.

Run as profiles

During installation, two new network monitoring RunAs profiles are automatically created. These profiles are used specifically for SNMP discoveries and are defined in the following table:

Profile Name	Description
SNMP Monitoring Account	Used for SNMPv1 and SNMPv2 monitoring.
SNMPv3 Monitoring Account	Used for SNMPv3 monitoring.

 

The RunAs accounts that you create or specify for network device discovery are automatically assigned to the appropriate SNMP Monitoring Run As profile.

Discovery stages

When a discovery rule kicks off, it will run through the following three stages:

Probing

This is the first discovery stage; here, the management server attempts to contact a device using the specified protocol (SNMP, ICMP or both) and uses the methods outlined in the following table:

Type	Description
SNMP Only	Successful discovery if an SNMP GET message is processed.
ICMP Only	Successful discovery if it can Ping the network device.
SNMP and ICMP	Successful discovery only if both protocols are processed.

Processing

When the Probing stage is completed, OpsMgr processes all the information returned from the device and maps out its components, such as ports and interfaces, memory, processors, VLAN membership, and HSRP groups.

Post-processing

At the final post-processing stage, OpsMgr correlates the network device ports to the servers that the ports are connected to. It inserts all relevant items into the Operational database and associates RunAs accounts to each network device.

After the three discovery stages are complete, the resource pool that you’ve specified for network monitoring in the discovery rule configuration will begin to monitor the discovered network devices.

Discovering network devices

Now that you have an understanding of the discovery process, it’s time to monitor some network devices and this section will walk you through the process. Before you begin though, ensure that all the previously discussed requirements are in place and confirm that the IP addresses or DNS names of your network devices are correct.

If you’re working through the steps in this articlein your lab and you don’t have any network devices to monitor, then take a read through Cameron Fuller’s blog post on using the free and very useful Xian SNMP Device Simulator tool from Jalasoft. This tool gives you the ability to simulate network devices using SNMP v1, v2c and v3 authentication.http://tinyurl.com/snmpsimulator.

Here’s what you need to do to begin monitoring your network devices:

From the Administration workspace in the OpsMgr console, expand the Network Management view.

Right-click on Network Management, then click Discovery Wizard as shown in Figure 6.1(you can also choose to click on the Discovery Wizard… link located above the Wunderbar).

Figure 6.1: Opening the Discovery Wizard

1. From the Computer and Device Management Wizard, select the Network Devices option as shown in Figure 6.2, then click Next to continue.

   Figure 6.2: Choosing the Network Devices wizard

2. At the General Properties dialog box, enter a name and a description for the discovery rule, select the management server or gateway server that will run the discovery andthen choose a resource pool created specifically for network monitoring as shown in Figure 6.3. Click Next to move on.

   Figure 6.3: Configuring the discovery rule.

3. From the Discovery Method dialog box, select the discovery type you want to use, as shown in Figure 6.4, we’ll choose theExplicit discovery option, then click Next to continue.

   Figure 6.4: Choosing a discovery type.

4. In the Discovery Settings dialog box, you can create a new SNMP v1/v2cRun As account or use an existing one. If you use different SNMP community strings on different network devices, then you’ll need to create separate Run As accounts for each device. Figure 6.5 shows an example of multiple Run As accounts being selected for a network discovery. Click Next to continue.

   Figure 6.5: Specifying Run As accounts.

5. From the Devices dialog box you can choose to either hit the Import button to import a text file containing the IP addresses of your network devices (very useful when you have more than a few devices to monitor), or you can click the Add button to specify an individual network device.For this example, we’ll click the Add button.

   If you choose the Import option here, then you can use a simple .txt or .csv file containing the IP addresses of each network device you wish to monitor. Make surethat each IP address is listed in its own separate line in the file.

6. In the Add a Device dialog box, input an IP address or DNS name for your network device, choose which access mode you wish to use (SNMP, ICMP or both), select the SNMP version you wish to use (you can configure an SNMP v3 account at this point if you wish), then leave the Use selected default accounts option enabled, as shown inFigure 6.6 and hit OK.

   Figure 6.6: Configuring discovery settings.

   When configuring the Access Mode setting for a device, be aware that if you leave it as the default ICMP and SNMP option, then both access types must succeed before proceeding. This means that if ICMP can’t Ping the device or SNMP can’t connect, then the discovery fails. This is useful to know in case you have an internal firewall policy that blocks ICMP (Ping) traffic. In most cases, it’s best to choose either one or the otherand not both here.

7. In Figure 6.7 you can see some network devices specified and if you want to modify the number of retries and timeout thresholds, you can click the Advanced Discovery Settings button now. When you’re happy enough to move on, click Next.

   Figure 6.7: Configuring discovery settings.

8. In the Schedule Discovery dialog box, choose to run the discovery rule on a schedule, or to just run it manually. Running the discovery rule on a schedule can be useful if you work in an environment where network devices are added and removed on a regular basis or it can also be helpful if you want to minimize discovery traffic during office hours. As shown in Figure 6.8, we’ll choose to run our discovery rule manually.

   Figure 6.8: Choosing when to run the discovery rule.

9. Click Next to move on; at the Summary dialog box, hit the Create button to create your new discovery rule.

10. If you see a warning pop up indicating that you need to distribute the new Run As accounts to the management server, click Yes to do so before clicking on the Close button to close the wizard and run the discovery rule automatically.

11. When the discovery rule is finished processing, you should be able to see the number of network devices you specified show up in the Last Discovered column as shown in Figure 6.9.

    Figure 6.9: Successful processing of a discovery rule.

Network Device Discovery Failure

From time to time, it’s not uncommon to have a device (or a number of devices) fail to be discovered. This can be a problem if you don’t know where to find a list of these failed devices. In this instance, the failed device or devices will be listed in the Network Devices Pending Management view from within the Network Devices section of the Administration workspace.

Once you’ve located the failed devices, you can use one of these options to try to rediscover them again:

• Right-click on the failed device from within the Network Devices Pending Management view and then click Submit Rediscovery.
• Rerun the discovery rule by right-clicking on the rule and selecting the Run option.

Summary

In this article, we gave you an overview of the Network Monitoring feature of OpsMgr and discussed what you need to have in place in your environment to ensure successful monitoring of your network devices.

We demonstrated how to configure a discovery rule and bring some devices under monitoring and we walked you through using the built-in tasks, dashboards and reports that are specific to this feature.

Resources for Article:

---

Further resources on this subject:

• Getting Started with Force.com [article]
• Neutron API Basics [article]
• VM, It Is Not What You Think! [article]

---