Latest posts by Paul Schnackenburg (see all)
- Project Honolulu - A new way to manage Windows Server - Wed, Nov 22 2017
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
Because big organisations often separate the network administration from server operations it can sometimes be difficult to efficiently narrow down if a particular problem is due to the network, the OS, the application or hardware. The new native Network monitoring feature is designed to increase visibility and help IT admins solve problems quicker, it’s not designed to replace specialist network monitoring tools that are probably already part of the network administrator’s toolkit.
Whilst SCOM 2007 R2 offers basic network device monitoring it doesn’t extend to the port level (unless you manually do the work for each individual device based on its Object Identifier (OID)). SCOM 2012 offers support for SNMP 1.0, 2.0 and 3 (but not Netflow) and works with both IPv4 and IPv6. Initial device discovery requires IPv4 addresses on devices so if you have a pure IPv6 network with no IPv4 address allocation this will be an issue. Devices in this context can be switches, routers, load balancers and firewall as well as any other network connectivity gadget that responds to SNMP monitoring.
Make sure your discovery rule(s) is properly scoped to find all the devices you want as you can only have one rule per server.
Discovery of devices can either be explicit where you define (by IP address or ranges) the devices; or recursive in which case SCOM 2012 will glean information from one device to attempt to find other devices. During discovery all SNMP community strings you’ve entered for a Run As account are tried until a correct one is found, be aware that some devices will generate an SNMP trap if too many invalid credentials are tried. The SNMP stack is now native to SCOM 2012 in contrast to SCOM 2007 R2 which used the SNMP stack of the OS. To monitor across firewalls you need to allow SNMP (UDP) and ICMP bi-directionally and port 161 and 162 have to be open (including on the Windows Firewall on management servers). SCOM provides the required firewall rules for Windows Firewall but doesn’t enable them by default.
Beyond the basic monitoring there’s extended monitoring where processor and memory utilization and memory fragmentation along with other device specific objects are tracked if the device is supported by SCOM 2012. To date there are more than 80 vendors on the list and over 800 devices, see the Excel spread sheet here. When a device supports SNMTP traps for system changes (card added, changes to chassis configuration) SCOM 2012 will listen for them. The supported information for each interface depends on how the device manufacturer has implemented monitoring; Management Information Base (MIB) based on RFC 2863 and MIB-II RFC 1213 provides deeper information.
Deep information about each monitored device is only a mouse click away.
In strictly controlled environments where even read only SNMP monitoring is restricted you can opt for ICMP only which will let you know whether a device is responsive or not. If a node is down, all other monitoring is suppressed so that you’re not flooded with alerts about ports and links being down.
But the coolest part of Network Monitoring has to be the port stitching feature that shows which agent monitored node is connected to each port. SCOM will also discover all VLANs and what switches participate in each VLAN, note that only connected ports will be monitored unless you manually add ports to the Critical Network Adapters Group in which case it will always be monitored. For routers it will identify which Cisco Hot Standby Router Protocol (HSRP) groups they participate in. The end result is clear network diagrams that show exactly what systems are connected to witch switch port as well as visually indicating where a problem might lie.
SCOM 2012 has over 200 new items of knowledge for network monitoring and will report on packet errors per switch port for instance. At RC the recommended scalability numbers are about 500 devices per Management Server and about 2000 devices per Management Group; however there’s a comprehensive sizing guide forthcoming. Be aware that you can only have one discovery rule per Management Server so make sure it encompasses all the devices you need to find.
There are four dashboards built in for network monitoring with the Network Vicinity Dashboard providing a visual representation of connected devices within one hop to the selected node, you can increase the number of hops up to five. Be aware that this dashboard won’t identify teamed NICs as such, nor will it show Unix / Linux computers and VMs will be associated with the same network device as the host; the Hyper-V switch does show up as an SNMP device.
The Network Summary Dashboard lets you easily spot the device with the slowest response, highest CPU or interfaces with the highest utilization, most send/receive errors or nodes with the most alerts. From this dashboard you can then pivot into the Network Node Dashboard that lets you view availability statistics for the last 24 or 48 hours, last seven days or last month; this dashboard also shows other utilization statistics for the node. The Network Interface Dashboard drills down to an individual port and lets you see packet statistics for the last 24 hours as well as alerts and interface properties.
There are also five new network monitoring reports and some new tasks in the console such as opening a Telnet session to a device, doing a quick SNMP “get” or performing an SNMP walk of a device. Note that if you’ve authored management packs for network monitoring in SCOM 2007 R2 these will need updating to work with the new functionality, see here for more information.
In the next part of this eight part SCOM 2012 RC overview we’ll look at another crucial piece of the IT puzzle that needs monitoring – applications.