Saturday, January 26, 2013 6:37 PM
In SCOM 2012 RTM network monitoring is almost zero, yes I know you have something, like some metrics are collected and couple of alerts
I was very surprised to find out is not monitoring hardware at all
So, are you aware of any improvements in SP1? or whats the road map for network monitoring ?
Saturday, January 26, 2013 10:28 PM
The information you will get on your network devices depends on wether the device is supported for extended monitoring.
Make sure you have the appropriate permissions to the device and use the correct RunAs community string on those devices.
I know there is an Excel sheet that lists the devices for Operations Manager SP0. This can be found here:
I thought more network devices woiuld be added, but this page make you believe it remains unchanged as it points to the same Excel Sheet:
Maybe someone else has some more information on this.
What get's monitored can differ per devices. More infomation on that is to be found here: http://blogs.technet.com/b/momteam/archive/2011/09/20/what-gets-monitored-with-system-center-operations-manager-2012-network-monitoring.aspx
Hope this helps,
Regards Marthijn van Rheenen
Blog: Heading To The Cloud’s
Saturday, January 26, 2013 10:39 PM
fans, power, cards, and temperature will not get monitoring, including device with extended monitoring
from my point of view these are part of basic monitoring
Sunday, January 27, 2013 7:24 AMModerator
There are no changes in SP1 - most of the SCOM changes relate to APM (extended the range of monitoring here and integrating with TFS) along with Global Service Monitor.
With regard to Marthijn comment - "I thought more network devices woiuld be added, but this page make you believe it remains unchanged as it points to the same Excel Sheet:"
My understanding is that the excel spreadsheet won't be updated. Rather than having specific certified devices, the key notes are in the middle of that link -
"Operations Manager 2012 can monitor network devices that support SNMP, and can provide port monitoring for devices that implement interface MIB (RFC 2863) and MIB-II (RFC 1213) standards. "
If the device implements RFC 2863 and 1213 then it should be certified for extended monitoring.
Road map - sadly no-one who knows can say anything publicly (that isn't already publicly available) on a forum due to non-disclosure agreements.
- Marked As Answer by MariusNY Sunday, January 27, 2013 3:09 PM
Sunday, January 27, 2013 9:34 PMMicrosoft really touted Network Monitoring but we have all come to realize its completely vapor. I've got idiots at one client site replacing SCOM 2012 with Orion because all I can offer is up down for certified devices. It's sad MS pretty much BS'd about the advancements of network monitoring in SCOM 2012 which have turned out to be totally false and worthless. It's a shame they couldn't write simple SMMP monitor MPs for the top 50 devices. Yes, that would be a lot of work but imagine the benefits for customers.
- Marked As Answer by MariusNY Sunday, January 27, 2013 11:28 PM
Monday, January 28, 2013 8:27 AMAfter running through the whole network monitoring pack in RTM there where a lot of signs that the MP was rushed out the door.
So I had to start to create my own MP that built on what MS has done, the problem here is most of what I'm doing will probably break when MS desides to update the Network Monitoring MP. Therefore I'm reluctant to spend to much time on it and wait for a updated pack.
I was realy hoping that this update would be included in SP1, to my disapointment it was not.
- Marked As Answer by MariusNY Monday, January 28, 2013 9:36 PM
Monday, January 28, 2013 9:38 PMExactly my point, not sure if I should spend time writing custom SNMP MP or wait for MS
Tuesday, January 29, 2013 1:58 AMHere's the deal. Writing snmp gets works. But, there ISP an issue with targeting groups of devices. There is a bug that forces you to target all class Nodes. This fills up the OpsMgr log with gets to EVERY SINGLE NODE. I have a premier ticket open. I told NC MS Engineer to use an snmp simulator and target an snmp monitor. He acted like that was out of his scope of duty. Here is the bottom line to everyone that asks if SCOM can handle snmp and network device monitoring. You can write snmp monitors all day and send alerts in values > static thresholds. But keep in mind the bug I mention above. You can receive traps all day as well. You end up with a console filled with interesting trap data. Good luck mining all that. You can use the Quest Dell add on scom network tools. They work. But they cost $100 per device. And I'm not completely satisfied with Quest. They are not 100% worthy. What we need is a simple MP of the top10 hot gets for the top 50 devices. Just get the damn MIBS and write the snmp monitors. It's such a no brainer. It's all in the MIBS!!!! I will pay $10,000 to anyone that writes a solid snmp netmon power pack for 2012 SP1. I'm sick of waiting. I'm sick of the network summary dashboard timeouts. Ugh. If I worked for MS shit would change. And to think I worked on the assembly line of the very first Microsoft mouse in garden grove, California. LoL :)
Tuesday, January 29, 2013 3:54 AM
Generic devices also won't pull back the Model or Vendor which makes it hard if you are integrating SCOM with SCSM, we only have Cisco devices and still can't monitor 700 of our switches as the Cisco -X Series is classed as certified. Surely it has to change!
Tuesday, January 29, 2013 2:51 PM
One of the problems here is that different vendors use different SNMP OIDs for where they store this data.
So for OpsMgr to make any sense of this on a generic basis, everyone creating network devices would have to agree on a set of standard OIDs where this type of information is stored. Then you could tie this in to the generic network device discovery function in the MP, and we would get all devices name and type stored in a form that is reusable. Though this we know is not likely to happen.
I have started to create my own classes where I can leverage discoveries in such a way that I can use some grouping knowledge. Like Firewall.Vendor and for that vendor all product names and information can be found in a given set of OIDs. Though this is alot of work, and I'm still learning about OpsMgr and MP authoring.
I would think MS is able to figure out a much better framework that can be leveraged and expanded by us when we need to reuse some of the information gathered by the Network MP, and I was hoping to see some of this in SP1.
- Edited by Lerun Tuesday, January 29, 2013 9:02 PM
Tuesday, January 29, 2013 6:48 PM
Essentially MS needs write a Quest-like extension.
Until then, SCOM network monitoring out of the box is nearly worthless, unless of course you feel that cpu and response time is all you need.
Like ACS, you get what you pay for.
Microsoft's freebies are not enterprise class.
You must pay for the real toys.
Wednesday, January 30, 2013 5:05 PMModerator
I agree there isn't very in-depth monitoring of many peripherals out-of-box, but SCOM is very extensible which enables one to discover/monitor what they want. This is by no means an excuse for MSFT not including more advanced monitoring options - it is what it is for now, until more advanced monitoring features are included out-of-box. :(
In my opinion, network monitoring in 2012 achieves (mostly) what MSFT intended to do, which is port stitching and drawing a topology of devices connecting distributed applications and services. Many devices include advanced monitoring, which help customers more quickly triage network latency issues and avoid unecessary tasks working with a network team to arrive at a network related problem.
Yeah, many devices will not receive advanced (extended) monitoring because they do not implement interface MIB (RFC 2863) and MIB-II (RFC 1213) standards, as Graham mentioned. This is unfortunate, but MSFT is not at fault for that (unless I'm completely missing something here).
It's a work in progress...just my 2 cents...
Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)