SCOM Reviews

SCOM is capable of so much that it can actually be somewhat overwhelming. But if you know how to use it effectively, one of the great things about it is that you can really tailor it to your specific environment and get as much (or as little) alerting as you need.

SCOM also provides for administrative roles and selective alerting, so if you have a team that only monitors a specific subset of servers or a specific application, you can create designated roles for them and give them limited console access for just those resources that they are responsible for.

In my previous position, there was basically no true infrastructure monitoring at all – they were relying on alerts configured per system or device, and consequently there was a lot of firefighting and working reactively to problems that occurred.

My first priority when I started was to implement enterprise monitoring and alerting, and SCOM was approved. Once it was in place and tweaked to that environment, we experienced a lot less firefighting and were able to prioritize issues as they came up. Less late nights, too.

In some ways, SCOM is a double-edged sword. It can do so much, even by default -- monitoring and alerting of everything from Windows servers and applications, to Linux machines, to network devices including routers and switches. However, because of this, you can get overwhelmed fairly quickly, and if left unchecked, you’ll get too many alerts for too many objects. When that happens, your team starts ignoring alerts because they simply can’t get to them all, and that is just as bad as not having any alerting at all.

For SCOM to be really great, I’d love to see Microsoft come up with a quick and simple way to enable common critical monitoring and alerts by default. Then, as you get more familiar with SCOM, you can gradually tweak and enable the more customized and intricate stuff.

I have been using Operations Manager for almost three years. I set up and deployed it (with assistance from a consultant) at my last job, and it was already in limited use at my current position, where I currently administer it.

SCOM can be somewhat tricky to implement.

There have been no issues with the stability.

With SCOM 2012 R2, a single management pool deployment can handle up to 150,000 objects - according to Microsoft.

Tech support and customer service depends on your relationship(s) with Microsoft, but Microsoft support, whether you like it or not, is pretty consistent across the board. If you've dealt with it previously, at least you know what to expect.

I have used and evaluated other enterprise solutions. I will say that, while Microsoft sometimes does things that seem oddly questionable, SCOM truly makes sense once you get familiar with how it works. SCOM uses management packs, which are basically pre-packaged building blocks of rules and monitors, to allow configuration and tweaking of monitoring for each service or application

SCOM can be somewhat tricky to implement, and if you’re implementing more than one System Center module, you definitely need to be careful about the order you deploy them in. However, there is good documentation online from Microsoft and other sources, so take your time and read the documentation completely to avoid having to start all over. I have worked in mainly small to mid-size environments, but scalability, from my understanding, is generally not an issue for SCOM.

In both cases I was involved in, we had a consultant work with the internal team to deploy and configure SCOM. As I mentioned before, implementation can be tricky, and it’s mainly because there are a lot of smaller details to pay attention to (specific user & group creations, proper installation order, etc.). So I would advise bringing in a consultant to do initial deployment if you don’t have the experience in-house.

I don’t know specifics about pricing and licensing, but if you’re familiar with Microsoft, you can get very good deals buying a certain level of licensing and getting System Center thrown in.

SCOM is capable of providing full-featured infrastructure monitoring, alerting and reporting, especially for Windows-centric production environments.

I have heard a lot of people say that to do SCOM right, you really should create a full-time position, or at least a full-time System Center admin who works only on System Center stuff. Because you’re only going to get out of it what you put into it. If you don’t put any time into it, it’s not going to work well for you.

We use SCOM to deploy images.

We like the deployment of the machines and the features that they have.

It's easy to use.

The management of the servers could be better.

Also, the user interface could be improved.

We have used SCOM for a couple of years.

We are using the latest version.

It's a stable solution.

It's a scalable product. We have 1,000 users in our organization.

We have plans to continue using this solution.

Technical support is fine. We have no issues with them.

We did not use any other solution. It's a group standard for us.

The initial setup is straightforward. It's easy for us.

We have a team of four to deploy and maintain it.

We completed the installation ourselves.

It took one week to deploy and customize it.

We have to pay for a license and the price is fine for us.

I would recommend this solution to others who are interested in using it.

I would rate this solution a nine out of ten.

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.

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.

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.

I have used this solution for 10 years.

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.

Technical support is pretty good: very responsive, good level of understanding, rare to have to go beyond second-level support.

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.

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?

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.

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.

Our primary use of SCOM is for monitoring deployments of Windows. It is also used for monitoring applications, and it reports information if there is a problem.

It is very good at monitoring Microsoft Server.

SCOM is not a flexible product.

The initial setup should be easier to complete.

We have been working with SCOM for three years.

This is a very stable product and we plan to continue using it in the future.

This solution is very scalable. It can change the configuration for management and performance. We have two people who use it. One is a manager and the other is an engineer.

When I need external support, I can open a case with Microsoft. I have opened between two and four support cases and I am satisfied with the support I received.

We don't use any other product for deployments. 

I would say that the initial setup is 50-50. It is not easy and it's not hard to set up. It should be easier to install. It took us between three days and a week to deploy.

The length of time for deployment depends on the size of your environment. If I am installing a new System Center Operations Manager for 100 servers, it will take maybe two weeks. The process requires implementing monitoring agents, and I need to change the configuration as well.

I deploy this product myself.

We have an enterprise agreement that includes this product as part of it.

This is a good product and I recommend it. When it comes to monitoring Microsoft servers, it is very useful.

I would rate this solution an eight out of ten.

We use it to monitor our internal work.

The feature I have found most valuable is the book feature. While we run the Sprint one we can add some setups for multiple sprints.

Some checking issues could be improved. Checking some activators. It would help if we could export in some cases, because it may be that some people want to move the screen from the book to share reports. If it was possible to embed it in a report, that would be good. In other words, I would like more customized reports.

I would definitely like to see the ability to go through the total life-cycle in the next release of SCOM, to cover everything. But in some cases, especially retrospectively, this is not happening, or not happening well. I'd like to see the retrospective outcome in the knowledge base. It would be good if it could accommodate some learning out of the box, together with information from the recording session. There are levels to it, but some of the records we keep often go to quickly deliver the project. But in most cases, they skip the retrospective part and lessons learned. It would be good to declare something in the knowledge base where people can easily put it and access their input of lessons learned. We've yet to see that in previous projects. But I'd like to get to the level where whenever a new person starts a project, they could visit the knowledge base and the retrospective section, and get some knowledge out of the box, which was not covered in the process.

On a scale of one to ten I would definitely rate SCOM an 8. That's because people should have some customization option on the dashboards for whenever they put multiple lists into it. Beyond customizing the content, there should be the ability to customize the colors so that they can engage some priority and mark challenges separately.

I have been using SCOM for almost three years.

There are less than 100 people in my organization using SCOM. It is not widely used in the company. Just some individuals from different departments.

Before SCOM we were using Microsoft Project or Excel. The advantages of SCOM are that it is definitely user friendly and a more appropriate solution for what we need.

The initial setup did not take more than five minutes. It was activated in general, initially. 

The setup was implemented with help from our internal colleagues.

One thing I would recommend to anyone considering this solution is to give more people access to it so that whenever people want to use the solution they can get information from past experiences and what's currently going on. Say for example I raised one concern in your query box, I don't know how it's progressing because it doesn't record that. You should give some ticket number to it and update it. In other words, sharing feedback even on issues you are not directly working on.

My primary use case for SCOM is to monitor service availability and performance, such as operating systems. We also integrate some Linux based operating systems to monitor our databases. We also monitor the Microsoft Exchange. We are having some difficulties in the case of the monitoring a couple of our networking devices, so I wouldn't say that monitoring networking devices is also part of the primary use cases. 

I also have Internet Information Server and Application Service from Microsoft Monitor.

Availability monitoring is the feature I have found most valuable, as well as the capacity and ability to send notifications. There is a mechanism to set up a notification from the SCOM and whenever there is a drop in the availability the notification alerts not only for availability but for other issues as well.

You can align thresholds according to the speed of your environment and you can have a threshold related notification, which is one of the useful features.

In terms of features that could be improved, I would say the agent integration into the operating system. We are having difficulties integrating Linux into some of the networking devices. We have not seen the collected data so it makes it challenging.

I would also say that agentless monitoring needs to be included. Something like this is pretty difficult if you don't have a particular agent.

It's not so easy if you have to use something like a proxy to implement a work around. They should include a solution for discovering devices and something like an agentless monitoring solution for a particular device - just to understand what your environment looks like.

I'm not saying that they should provide all the information for the device, but at least availability and partial monitoring based on SNMP. Because I know that other solutions have it. Maybe Service Center Operations Manager has already provided those things in the latest version, but I'm not familiar with it.

I have been using Microcoft SCOM for roughly five years.

Our whole department that maintains SCOM is five people, so the IT department is pretty small and it's relatively integrated. Plus, we have only two dedicated System Administrators. Basically, a few people are doing many things.

We are doing the usual maintenance, patching, and updating. Alignment and configuration are also needed because we are trying to support a higher version of the application, Exchange 2016, with the previous 2012 version of Service Center Operations Manager. It's quite difficult and some type of maintenance is performed internally as we try to align as much as possible. 

Generally speaking, SCOM is stable from an operations point of view. Once it's set up and established and all the configuration is in place, there is no significant amount of time needed for stability or to support the availability of the solution itself. It's relatively simple to support.

In terms of scalability, we increased the amount of supported devices from 50 to 150, but it's not a significant scale. I couldn't say yet how it would behave for a thousand or 2,000 devices.

We have a pretty simple setup for SCOM, we are not using any kind of clustering or virtualization.

Microsoft support can vary. It's great for people that are used to other types of support. Meaning, software vendors usually provide a little bit more focused and dedicated Microsoft support teams. For general support, it's okay from my perspective. But to really understand the deep and the intense nature of your issue, it's a little bit tricky to get to that level.

Overall, technical support needs some alignment. The technical support should be separated from general support. They should start with the general support for people that are end-users or a single user in a simple environment. Then, to reach to the real technical integration-related support later because it's a little bit tricky. Usually, we use our integration partner as someone that is really dealing with those kinds of discussions with the vendor. But if you go directly as a single enterprise, it will be a little bit challenging.

In my previous work I had experience with Network Node Manager, a new solution from HP. It's more focused on agentless monitoring. Also, there is a capability for a monitoring device without any kind of agent installed, which is a little bit more professional. It's not the general solution for monitoring, so I wouldn't say that are comparable. My perception is that Microsoft is just focused on the software stack layer they provide. While Network Node Manager is more of an umbrella, it's much more focused on enterprise level devices and environments. So they should not be compared.

As far as I can remember, the initial setup was pretty simple, but we started with pretty easy devices to monitor. We started with a couple of servers and almost all of them had the same version of the operating system. So it was simple to figure out how things were progressing.

I would say it took a couple of days or a week for the whole setup. It took about five days to install all the servers, and installation and all the integration, and the checks probably took a week.

Initially we implemented on our own. But for a couple of integrations, we used integrators for support, especially for particular application servers and installations, Exchange and partially for SQL Server.

My recommendation to anyone looking to use SCOM is that they should start with the latest version because it's pretty difficult to update later. From an operational perspective and regarding migrating many devices and whole environments, it's better to start with the latest version for Service Center Operations Manager.

On a scale of one to ten I would rate Microsoft SCOP a seven.