What is most valuable?
Its flexibility, the ability to create Management Packs to monitor different programs or devices. No matter what it is you want to monitor or how you want to monitor, it can be done. You may have to create the code using VBScript or PowerShell, and XML, but it can be done. There are always lots of examples online that you can work from that will save you lots of time.
How has it helped my organization?
The company to which I am currently contracted is in the process of creating SNMP Management packages for our network devices. Very steep learning curve but the results are fantastic. Anything that can be accessed via SNMP commands, SCOM can retrieve via SNMP Gets. This fulfills the network monitoring need extremely well and now we are getting alerts that allow us to pre-empt problems before they become service issues. This is making our network much more stable.
What needs improvement?
There are always areas that can be improved in any product, but overall SCOM has matured very well over the years and appears to be at the point where only minor improvements need to be made. Since MS sends out updates regularly, these improvements can be made on the fly with very little interruption in service.
For how long have I used the solution?
I have used this solution for 10 years.
What was my experience with deployment of the solution?
I did not encounter any issues with deployment. This is one area where there is plenty of documentation. It would be nice if more companies actually retained a PME for rollouts instead of just letting their brightest take a shot at it. I have had to clean up behind a lot of best efforts that could have been avoided by just bringing a contractor in for a couple of months. It seems that the biggest mistake is putting all of the management packs available in at the same time before talking to the owners that will be getting the alerts. Off-the-shelf MPs are very verbose and need to be tuned for the environment and the way in which alerts are going to be handled.
How are customer service and technical support?
Technical support is pretty good: very responsive, good level of understanding, rare to have to go beyond second-level support.
Which solution did I use previously and why did I switch?
I chose it after investigating Nagios, SiteScope, and SolarWinds. Initially, the thing that sold me was the Authoring console for creating MPs. It made it very easy to get started and produce right away. Now that MS has discontinued it, I use Visual Studio. It didn’t take long to figure Visual Studio out and now I can produce MPs as quickly as I did with the console and with more flexibility and understanding of what is going on. Most of the other programs aren’t ready off-the-shelf to the extent that SCOM is, and require a lot more work to get alerts coming in. MS has created the basic packages with all the possible monitoring and collections that they think the average company will want to use. Many of these are disabled by default and up to the implementer to go through them to see if his/her company can benefit from them. In many cases, companies will decide that anything that isn’t actionable needs to be turned off. That’s not always a good idea, as many of the alerts are preemptive to help you fix an issue before it becomes a major problem.
What about the implementation team?
I am a contractor and work exclusively with SCOM, I have implemented at many different companies, including MS, so it’s pretty easy for me to come into an environment and know what needs to be done. Probably the most important part of the design that most companies forget about is the processes that need to be in place before you stand it up. What are we going to monitor? How are we going to handle requests for custom monitoring, and tuning or disabling of existing monitoring and collections? Who and where are we sending alerts? Are they aware of what is going to be coming at them? Did you sit down with each and every group that you are installing MPs for and go over the monitoring and collections to see what they want and don’t want? DBA’s, for example, don’t want to see endless alerts about SPNs, or even permissions. Get this worked out before installing the SQL package and the DBA group will be much easier to work with. How are you going to route alerts, are you going to send them to a ticketing application? If so you have to decide how to do that. Are you going to send all alerts and have the ticketing system decide what is an actionable alert, or are you going to create subscriptions in SCOM to handle it?
Which other solutions did I evaluate?
As compared to some of the others that I have been exposed to, SCOM has its good and bad points. Documentation is poor, but the community makes up for it with good blogs and lots of how-to examples.
What other advice do I have?
Get knowledgeable help, not someone off the street that says they know SCOM, but someone that can show a track record of working with it. You will save lots of time and money.
It is so flexible and easy to learn if the right processes are put into place.