When I talk to people about the depth of the management packs JaxMP offers, one question I get often get is "Do you think when SCOM 2012 comes out with built-in network monitoring that your management packs will still be necessary?"  My response is a always, "Absolutely!"  I usually followup with "SCOM 2012 may have network monitoring, but it is still very 'thin'.  If you need more information about errors or other specific counters, you need something more than what SCOM 2012 has to offer and no management pack has the depth that JaxMP has."

I think there is a great misconception that all you need is basic interface counters to know how a network device is performing.  This may be true in some instances, but in most, you need the whole picture.  I like to say that when Microsoft release SCOM, they didn't release only a single "Microsoft Management Pack" to cover all operating systems and applications.  There was a reason that the is a SQL 2005 Management Pack, an Exchange 2010 Management Pack, a Windows 2008 Server Management Pack, etc.  You get the picture.  Each product Microsoft has is very unique and can't be defined with a a few counters and monitors.  The problem, when it comes to network devices, is that they are all are slightly different.  Yes, they have basic counters, but they also have much more to look at.  Just as you can't tell how an Exchange 2007 server is performing just by looking at incoming and outgoing bytes on the interface, you also can't tell how your Cisco 6500 Catalyst switch is performing by looking at interface counters.

Here is a very simple scenario that I usually talk about.  If you are in a multi-site environment with WAN links (Serial, either DS1 or DS3), you can watch in/out bytes all day long and it can help you get an idea about capacity planning, but it does nothing for you when you start having intermittent connectivity problems.  This can sometimes present itself as slowness, even though your in/out counters may tell you a different story.  Where do you start to look.  Since you don't have the whole picture of the network device, you have to start elsewhere, such as a server or an application.  If you had more visibility into the network device, maybe you could eliminate it completely or maybe you can pinpoint the problem as the device.  Basic interface counters will not give you the answer.  In this situation, you need specific counters that pertain to the serial link itself and not some counter or monitor that won't help you much.  SCOM 2012 and all other management pack solutions do not have this depth.  Only JaxMP NPM Management Packs can do this.

If the device exposes it, our NPM Management Packs can get it and monitor it.  In the case of a Cisco Catalyst 6500 switch, you can monitor the actual modules and their statuses, the fans, power supplies, and temperatures on not only the modules, but the chassis itself.  In SCOM 2012, you will only be able to discover some of these object and you definitely won't be able to monitor them without some custom management pack authoring.  In the case of a Cisco 2800 series router, you will be able to monitor specifics of the DS-3 (T3) such as line status, slips, errored seconds, delayed seconds, loopback status, and much more.  Everything a telco sees on their end of the circuit, you can see too.  You can watch and track the detailed counters to now only know that is happened, but when it happened.  I can't even begin to talk about how important this is.

The bottom line is that while basic monitoring is good, it is far from a complete set of tools you need to truly troubleshoot network problems.  Sometimes, you need the flexibility and depth to see as much as possible.  This simply isn't an option, even with specialized network monitoring tools like Solarwinds and WhatsUp Gold, without extensive customization.