Yesterday, while looking for information about Solarwinds integration into OpsMgr I came across this little poem.
While the poem was well written – which is why I shared the link on Twitter – it contained the same sentiment I face on an almost daily basis from the networking guys around me. In fact, I have endured much abuse from some network guys over the years about OpsMgr, and was even told by a manager of a team of networking guys recently that ‘SCOM is a swear word’ in her team. And these guys always root for Solarwinds.
And yet, when I ask them to show me what makes Solarwinds superior to OpsMgr, there is always some problem (system’s down right now, forgot my logon, that kinda thing). I am sure this is not Solarwinds’ fault, as I have had the same experience with a couple of other products and their almost religious followers. But this is not a Solarwinds bashing post.
I agree, there are some things in OpsMgr we would like improved*, but from design to operations it is by far the quickest management and monitoring tool to get up and running (in my experience) and with very little effort, it provides rich information very quickly about an environment. Of course, it takes some management to really get the benefit out of the tool – but this is true regardless of which monitoring tool one implements.
Of course, there are those who believe you put OpsMgr (or Solarwinds or or or) into the environment, and all the problems will go away. They get frustrated by the ‘noise’, rather than resolving the issues detected. And yes, not every alert is relevant for every environment – which, hello, is why you have the ability to switch the stuff off.
But better than OpsMgr I am yet to see, especially if you want to cover a wide range of devices and platforms on a single pane of glass. What more do you want?
Pete Zerger (OpsMgr superhero– yes, I am fangirling) did voice the one thing that many forget:
Operational maturity. Processes, policies and procedures. If you are missing any of those, and you have never heard of ITIL, MOF, etc, you probably will not find OpsMgr to be the tool for you. Oh, you can implement it, but you will be so frustrated that within months, you either throw it out or you outsource it. And may I suggest that you outsource it, rather than throw it out. You won’t regret it long term.
* Here are some of the things I would like fixed/changed:
- Auditing in OpsMgr of changes made in OpsMgr itself, including whodunnit.
- Logging of notifications (did it go out and to who?)
- Ability to scope areas a little more, giving engineers control over their environments (including ability to create overrides) without affecting anything else
And that is it, really.