Our primary use case is to monitor the extensive system of services that we operate for clients.
Our primary use case is to monitor the extensive system of services that we operate for clients.
SCOM (System Center Operations Manager) has helped improve our organization through reporting capabilities. The reporting is very good. We're an outsourcing company, so we provide services and manage service and as a service. We have a multi-service environment, so it is complicated to monitor and maintain.
The alerting with SCOM is incredible. The product works well with multiple environment integration, and if there is an issue, the system forwards alerts to different service desk systems so that the issues are handled appropriately. There are actually numerous things the solution does for our company to automate processes, and, to top it off, it's a stable application.
I'm the operational manager for Business Connections Monitoring Toolsets. We do installations of this product. We do the configuration. We take care of changes in threshold if needed, and supply additional expertise for critical projects as needed. We monitor everything to be sure things continue to work optimally and do things like monitor hard drive space, etc.
The integration with Power BI from the SCOM database offers incredible possibilities for enhancing user experience. That integration is added value to our services because of what it can do and what we can make it do for clients.
People don't have to log on to the console to see what's going on. They get all the data through the integration between Power BI (Business Intelligence) and SCOM. It is extremely flexible and can be adjusted to meet specific operating criteria.
If I compare the SCOM solution with the CA UIM (CA Technologies Unified Infrastructure Management) products, the CA products are horrendous in comparison. It's not stable in the way that they do their aggregation and their roll-ups. Really the methodology doesn't make sense. SCOM handles these things without a problem.
Many of the features in the SCOM product have been valuable to us as an organization. Basically most of the main features like the alerting, the reporting, the discovery, the automation, the auto-discovery of products installed on a server and the grouping that it does automatically have all simplified the way we work. The automation in SCOM is incredible, and because I have some exposure now to other, similar products, I can make a good comparison between them.
The CA products — which is in direct competition with SCOM — is not as good at all. I also have exposure to SolarWinds and a local product here called Syntelligence. None of those products can touch SCOM as far as general versatility. It is just a far superior application for general monitoring.
You can expand on the SCOM automation. But its power is more than just in the segment of automating things. If services stop, you can run recovery tasks and you can use disaster recovery scripts. That is just an example. There are numerous things that you can do with this product.
There are so many features in SCOM it has possibilities that are essentially longer than your arms can reach. You can monitor third-party applications, you can monitor services, you can collect events and you can trigger reports and send alerts based on those events. It's integration capabilities are very good. For me, it is the ultimate unified solution. It is a very nice product and I love it because of the capabilities it provides. The unification of services makes it easier to deploy and maintain.
Even though I think there are ways that this product is superior to most other solutions on the market, there are quite a few things that it does not do alone. This is where the product can be improved. One of the facets is in network monitoring. In fact, it can use quite a lot of improvement in that area. That's where products — like CA Technologies Performance Manager — are much better. You can do a lot with it that you can not with the reporting in SCOM. However overall that CA product is not as well rounded and complete.
The Scrum files that you set up can be made better. For example, you may want accounts that have access to the SCOM console to have more granular access. For example, you may have a situation where you prefer that only certain engineers will be able to add agents to the server — and only the server. But you can't set up the permissions that are this granular. Likewise, it may be that you want to assign someone the right to do threshold changes or to the environment of certain places of certain management groups. It is not part of the standard solution.
With other monitoring tools, you have the ability to set the permissions granularly, which SCOM actually doesn't do. So I hope that they would add that feature and support granularity. There are other ways in which to do it, but if you can do it in the monitoring tool itself and in the administration, then it'll make things much easier and make it a far more complete, unified solution.
One more thing would be better application monitoring. Products like AppDynamics do that very well and exceed the capabilities of SCOM. What I think I would like to see is for SCOM to be more of a complete end-to-end solution so there is no need to look to other solutions or work outside of the singular product.
SCOM is stable. We have never had a problem with system stability.
I think that SCOM is a very scalable solution. It depends on what hardware or virtual environment you're running on, but the scalability of SCOM is practically endless, I think. You can certainly go very far with it.
I know of a client in a banking institution that's working on 12,000 servers and their SCOM system is humming along without fail. So scalability on the environment of SCOM itself is very good, or at least it has proven to be scalable in that instance.
Technical support from Microsoft for SCOM is always excellent.
By comparison, I've been fighting with CA Technologies and how they do things. It is not the same kind of experience. If you log requests for technical support to tell them what the problem is, they ask a few questions in the investigation. You supply them with the information and from there on you do not know the response time. Depending on the severity of the issue you report on the call, it will be handled more quickly. If it's urgent, then they react very quickly. If it is not urgent, it is not quick even if the answer is simple.
What I like about the SCOM technical support is that they tell you what causes the issue when they find the resolution. They give you a report, they tell you what caused it and what the solution is. That helps make the solution make sense and maybe can help avoid other issues in the future.
We actually have not switched to this solution from another as we are evaluating and using several at the same time. We have used SolarWinds and then there's a new product called eSight that we have to use. The latter product is from Huawei and it is their monitoring tool for their network equipment. We basically were forced to start to support it because of client need. So there are four products that we supporting in our server for various reasons.
But if I have to choose any one product for server monitoring to take care of all aspects of monitoring out of the box, SCOM is number one. That is it can do application monitoring, like SQL Server Stack Exchange, Active Directory, SharePoint, third party stats, VMware or VLAN — you name it. It's really an excellent product.
So that is why my number one choice is SCOM. Put simply, it is the most complete.
The installation of the product was the easiest thing about using it. If you just follow the instructions and do exactly what it tells you, you don't have to be a trained network surgeon to do it. You can teach a seven-year-old to do the installation. If you can read, you can do the installation. It's really that easy.
Managing the system depends on the size of the environment for the most part, but I think it depends on the environment and the client as well. When their needs are more demanding or specialized the work will be harder. We've got a client that's got nearly 2,000 servers and they have only one engineer working on the entire thing. There is no need for additional personnel.
We work on our own systems and installations.
We, as a company, are using four products for monitoring, one of which is SCOM. We use multiple products because we are an outsourcing company and not everyone needs or wants the same thing. The other products are from CA Technologies. That is Performance Management, NFA, and UIM Unified Integration Management. These products just enhance the options we have to service our clients.
As far as meeting our needs for a solution, I give it a nine out of ten. But it is interesting to rate the tool. My rating doesn't really have a context. It is mostly engineers that are using the product. In a sense, it doesn't matter what monitoring tool you use, the success of a monitoring tool is dependent on the engineers using it. The engineer has to make it work.
I'm really not aware of the total number of users that we service and with SCOM I don't really need to know. I don't know much about the actual numbers except that we've got 28 clients. Each of the 28 clients has a different number of employees and different engineers that are working on different environments to solve different issues. If I had to guess, I'd say there are really only 100 to 120 only. I wish it was more, and I think we can easily scale to meet additional demand. But the point is that we are responsible for monitoring and identifying issues in a variety of environments, and that is exactly what SCOM helps us do, with efficiency.
We basically use everything we can that is included in the package and have found a real use for every module that's available. That said, we don't do a lot of network monitoring. Server monitoring, absolutely. That we use extensively. Reporting, we use a lot, event collections we use quite extensively. But we bring to the clients what they need most.
We have confidence in the solution and we are going to put all or most of the clients on to Scrum 2019 if they are willing to accept the upgrade path. We are busy working on that in a project to upgrade it to 2019. It all depends on how well test upgrades go and the willingness of clients to enhance their services. We need to test it in the development area first, and then, depending on the type of environment that is running, we have to plan the upgrade in the proper sequence. Say the environment is a 2012 version, the upgrade path is to 2016, from 2016 to 1801, from 1801 to 1807 and then you must make sure that you're on the correct sequel version for 2019. But to do it at all depends on the license agreement that the particular clients have with Microsoft. Right now we are busy taking the environment up to 1807 and then we going to upgrade the sequel version, and then from there, we can go to 2019.
So we are busy the whole time trying to better service our clients. We do our UI updates quite often. We are quite busy with our upgrade paths and testing to make sure everything goes smoothly for the clients in the implementation.