SCOM Reviews

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.

We use SCOM mostly for server performance monitoring in historical metrics.

I like the historical reporting of observer metrics. It's a fairly user-friendly solution.

It'll help if they can provide real-time or closer to real-time monitoring.

I've been using SCOM for at least five years.

SCOM is a stable solution.

SCOM is scalable, and it's easy to add resources.

I believe we have had issues. I'm not the primary administrator of it, but in general, I think they've been able to get back to us relatively quickly.

The pricing is good, and it's part of their system center suite. I believe we pay for the license on a yearly basis.

I would tell people looking to implement this solution that it's great for any historical tracking. But if they're looking for real-time, within-the-minute monitoring of servers from a console, then I would say that it falls short there.

On a scale from one to ten, I would give SCOM a seven.

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.

The flexibility which Operations Manager (SCOM) gives to monitor anything in any way is the main valuable feature to me. A big second would be the amount of management packs for Microsoft and other products which can be plugged in and give you a fast start to your monitoring.

In every case so far we managed to move from a slow reactive type of non-monitoring toward a proactive monitoring for different layers within the organization and real insights into their IT environment from different angles. Including helpdesk, system admins, IT management, company management, departmental staff and managers. Creating good dashboards makes the monitoring come more alive as well and move it over and above a long list of mixed alerts.

Areas for improvement in my opinion are the resource footprint of the SCOM infrastructure side, the web console (drop Silverlight please!) and a few of the management packs.

I have been using MOM and SCOM since the year 2002.

During the years we did see deployment issues. Often related to people not reading the documentation and not installing the prerequisites correctly (for instance SQL). In some cases it was related to in-place upgrades between major versions, which we have been warning against for years in the community. And one of the previous versions had some bugs in the command-based setup version in not accepting one of the setup parameters correctly (which the setup wizard did do correctly).

The stability of the product is fine as long as the scaling is done right according to the types and amounts of monitored objects. There are calculation models for it, but experience in designing SCOM implementations helps a lot with that.

We did encounter scalability issues when monitoring a large amount of network devices which turned out to have more monitored objects than expected (for instance a switch stack which is seen as one switch but turns out to have a few more ports and interfaces than a simple switch). In such cases a scale out or a second management group might provide what is needed.

SCOM is part of the System Center Suite and part of the datacenter management solutions provided by Microsoft. The amount of customer service depends on the amount of licenses and software assurance for instance you aquire.

Technical suport is given by Microsoft for their products through the usual channels. Next to that there are the Technet Forums where also a lot of community members answer questions. There are a lot of blogs run by community members and community leaders and MVP's which provide a lot of information.

Yes we used several products and also customers we are new to have existing solutions. Often a whole lot of them. The reason for switching is always to try to get as much as possible monitoring and dashboarding and reporting and alerting and therefore insights into as few products as possible. This is one of the reasons we standardize to SCOM.

The initial setup is very simple if you follow the documentation, best practices setup guides and use the sizing calculation models. Install the prerequisites right the first time and the rest flows from there.

We are a consultancy for the System Center products and I specialize in SCOM. I usually work with one or more people at a customer to get the basics done and installed and next work with the rest of the organization to make it friendly and accessible for all.

I think this depends on the organization and their wishes. In general a lot of organizations of a certain size already have the System Center licenses. The ROI comes from reacting more proactively to upcoming disruptions, current disruptions (and being able to inform users calling helpdesk) and being in control.

SCOM comes as part of the System Center stack. So if you buy one product you will have them all. Some organizations already have the licenses needed. Some have special pricing (education organizations for instance).

Yes other products are in evaluation. There are several big monitoring products which have been around for years and years. And there are niche players for monitoring specific parts of the infrastructure. With those last you may get deeper insights into one aspect, but lose the ability to add it all together.

I do like this product a lot and have followed its advances since the MOM2000 version and continue to do so toward the 2016 version and beyond. One thing to notice lately is there are more possibilities when combined with Microsofts OMS solution in a hybrid scenario to get even more value out of both products.