The energy last year at the Microsoft Management Summit was just incredible, and the new release of SCOM seemed to be really impressive…At first glance. SCOM is still the same. It’s powerful. It can manage many different capabilities and it’s a part of the System Center suite. However, SCOM Issues persist.
As you may know, SCOM 2012 added several new features to monitor new applications such as SharePoint web page performance and .NET Application Monitoring (thank you AVICode, now a part of Microsoft!). The reporting also included some new Dashboards as well.
Ok, so is this really beneficial to Exchange and SharePoint administrators?
Pains and Limitations
SCOM is still limited, therefore SCOM issues still exist…
SCOM 2012 is just as complex to configure, run and maintain as SCOM 2007. Installation and configurations are more difficult, which is why you still need a SCOM expert in your company to set it up, configure it for your minimal requirements and fine-tune it to get the most out of it. You can be sure that having and maintaining experts, scripts, and a dedicated team demands a significant amount of costs for maintenance…
The problem with a dedicated team is that they don’t have the same objectives as an Exchange or SharePoint team. Thus, having the Exchange or SharePoint infrastructure monitored by an external team isn’t the best option for your company. Exchange and SharePoint both need to be monitored by someone or something that fully understands the application. The following are some SCOM issues
Typically, the first issue that often occurs is the overabundant amount of alerts that appear within SCOM. As it monitors everything, it alerts on everything. Even if the correlation engine here is supposed to filter alerts and made this process clear, and you can ask anyone, overabundant alerts is a serious pain.
Proactive monitoring and service tracking should be included in SCOM, but it isn’t because of the philosophy of SCOM…SCOM is a System monitoring tool. It focuses primarily on servers. Objects like Database Availability Group or Client Access Server Array are not of its central concern. Moreover, it is really complex for a SCOM administrator to define accurate performance thresholds on complex environments like Exchange or SharePoint. Thus, this brings us back to the division between platform experts and system experts.
The last problem that everybody knows in SCOM 2012 is its reporting. Well, it depends on what an administrator needs. If you are looking for out-of-the-box reports, then it’s an acceptable method, as SCOM provides a set of pre-configured reports. But it is really limited because cannot cross two different reports. You also can’t tune your reports without any advanced knowledge on SSRS and/or Report Builder.
Imagine that you would like some statistics of a Client Access Server as well as statistics of mailboxes in the same report. It is not possible, as it is, out of the box. That is why you need an additional team, or your SQL experts or SCOM experts, and so on.
Moreover, it would be difficult to make a forecast on several critical statistics or manage capacity planning.
Of course, we are only talking about SCOM issues and limitations here but keep in mind that SCOM has lots of advantages. It is a very useful operations manager…But when it comes to monitoring, SCOM has many shortcomings that make your life more difficult than it needs to be. The learning curve is not as easy as it should be and sometimes it is frustrating because SCOM is such a great tool and we want to take the most out of it.
We would love to hear about your personal experiences with monitoring on SCOM 2012. What other problems have you encountered? Have you run into any of the issues mentioned in this article?