System Center Operations Manager, more popularly known as SCOM, or OpsMgr, is a monitoring solution by Microsoft. SCOM is a part of the “System Center” suite, which is a complete deck of tools that helps you create, manage, monitor, and automate your infrastructure and workflows end-to-end.
SCOM is an all-around monitoring solution for businesses of all shapes and sizes. Whether you have 100 servers or 5000, or work in education, health, finance, manufacturing, energy, or technology – SCOM can help monitor your infrastructure. While Windows stack technologies such as Operating System, Exchange, SQL, Active Directory, etc. are SCOM’s strongest points, SCOM can also perform monitoring of your network devices or Non-Microsoft products/technologies such as Oracle, VMWare, Citrix, etc very efficiently.
SCOM also has built-in capabilities for Linux monitoring. In fact, most customers who use SCOM to monitor their OS have around a 70/30 split of Windows/Linux Operating Systems under monitoring.
If you have another tool of your choice for network/Linux monitoring already in place, that is fine too. Many customers who have a large environment choose to have multiple monitoring tools to monitor different aspects of the business. SCOM is often used alongside monitoring tools such as SolarWinds (for network monitoring), specialist APM tools such as DynaTrace, log analytics tools such as Splunk, and IT Service Management tools such as ServiceNow or Microsoft’s own Service Manager (SCSM).
SCOM is a natively-installed tool – meaning you have to install SCOM and its components on dedicated servers on your own infrastructure. However, this does not mean that SCOM cannot monitor cloud resources. Over the years, as seen in the release of SCOM 2019, SCOM has developed the ability to monitor your cloud infrastructure equally well. See how to monitor your Azure resources with SCOM.
SCOM is largely an agent-oriented monitoring tool. This means that in order to monitor your infrastructure, you need a piece of software called an “MMA” or “Microsoft Monitoring Agent” installed on them. Agentless monitoring is also possible, but with limitations and not recommended unless absolutely necessary.
These agents run workflows on the servers they’re installed on and generate data. This “raw” data is then forwarded to the SCOM Management Server for processing and then inserted into databases. To understand this better, let’s go over some SCOM terminology:
An instance of SCOM is called a Management Group. This simply is the collection of your whole SCOM setup. At minimum, a Management Group consists of a Management Server, an Operational Database and a Data Warehouse.
This is a piece of software installed on the server/device that needs to be monitored. It runs workflows locally on the server it’s installed on and sends the data back to the Management Server.
A Management Server is where the data is processed. When you open an Operations Console to connect to your SCOM Management Group, what you connect to is the Management Server. This is the central point of administration for SCOM. There can be one or more Management Servers in a Management Group. In fact, it is recommended to have more than 1 management servers to ensure high availability of your Management Group.
There are two main databases that are installed while installing SCOM, an Operational Database and a Data Warehouse.
Operational Database contains the configuration data for your Management Group. Any changes you make to your settings or changes in the monitoring workflows are stored here. The OpsDB retains the data for the short term – 7 days by default.
Data Warehouse is designed to store the monitoring data collected by the agents for the long term. All the historical data that is used for reporting is called from this database. The Management Server writes data on both the databases at the same time, so the DW always contains the most recent data.
A Gateway server is used to monitor the data that lies outside the Kerberos boundaries of the domain where the SCOM Management Server(s) is/are installed. This server basically acts as a “proxy” Management Server for the agents behind the trust boundary. These agents send their data to the Gateway Server which in turn sends the data back to the main Management Server for processing.
The greatest benefits of having a GW server is to minimize the network security vulnerability as it allows only one port to be opened (on the GW server towards the MS) and also reduce the number of SSL certificates required to be issued for secure communication across the trust boundaries.
This is what a simple SCOM Management Group looks like:
Management Packs (or MPs), essentially, are the brain of SCOM and the core of its monitoring. All the monitoring logic and preferences come from and go into Management Packs. MPs are basically the collection of Rules, Monitors, Discoveries, Reports, and all the workflows that are necessary for successfully monitoring a particular technology, product or infrastructure. For example, a SQL MP will monitor SQL databases, an AD MP will monitor the Active Directory, a Windows OS MP will contain the logic to monitor Windows Operating System, and so on.
SCOM is designed to monitor applications. An author creates a model of an application, called a Service, in the Distributed Application (DA) Designer. This contains all the components that make up the application, creating the relationships between them, giving the end user a top-level object, which displays the health.
Now that we’re familiar with what SCOM is, how it works and its terminologies, let’s talk about its practical usability, with some pros and cons.
Thankfully, most of the limitations mentioned above can be overcome – you can easily make your SCOM great again! 😉
If you’re convinced SCOM is the right tool for you, and want to give it a shot – there are a few add-ons that are an absolute must to make your SCOM truly effective and practical.
SCOM is an amazing product by itself, and also very powerful. However, it still is lacking in some aspects, most noticeably with visualizing the data it has collected. SCOM does an incredible job of collecting the data with its Rules and storing it in the Data Warehouse, but it’s often a challenge out-of-the-box to visualize that data, analyse it, as well as extract and share it with the relevant parties. This is where SquaredUp picks up the game.
What SquaredUp does is it sits on top of your existing SCOM (preferably on a dedicated server), and makes managing it a whole lot easier. It is important to know that SquaredUp in itself is NOT collecting any data from the servers, but is using the data SCOM has already collected. This data can then be displayed to the users in a pleasant and easily readable format, which is also interactive. It is incredibly easy to build a dashboard, or a set of them, with SquaredUp and the coolest part is that the dashboards can be drilled down to the unit level so that you can identify the exact source of the alert and isolate the problem.
To understand what SquaredUp can do in the practical world, read through the experience of using SquaredUp for SCOM – as told by one of our users himself!
SquaredUp is not only limited to SCOM dashboards. It also has something MUCH cooler to offer. Introducing to you Enterprise Application Monitoring (EAM), using VADA (Visual Application Discovery and Analysis). What VADA does is it leverages the SCOM agents you’ve already installed, uses them to discover application dependencies automatically and lays it all out for you to see in a friendly, simple diagram illustration.
Cookdown is another option that really makes the SCOM admin’s life MUCH easier. Like mentioned earlier, SCOM is sometimes very noisy and filled with alerts you may not be concerned with. This introduces a significant administrative overhead, both to the admin and the ITSM team.
Tuning of your Management Packs is thus very important, but also can be very tedious sometimes. What if there was a simple way to tune these Management Packs easily and with a friendly UI? Folks at Cookdown wondered the same, and came up with EasyTune!
As suggested by the name, EasyTune makes it very quick and easy to tune your Management Packs to the level of depth you prefer, and reduce the unnecessary stream of alerts. What’s even better is that – it’s free! Check them out here:
Cookdown also offers a free Powershell Management Pack, that replaces the bothersome and outdated dependency on VBScript in SCOM and replaces it with Powershell! An absolute must in any SCOM deployment, if you ask me! You can get it here:
You will have to work with custom authoring of Management Packs frequently to effectively monitor your custom applications. Sometimes, you need to take a peek inside a Management Pack to look at its contents and plan out your tuning. SCOM console does not offer this natively and the only traditional way to do that is to look at the raw XML. This is very inconvenient, and may throw you into a loop of infinite scrolling up and down the file.
MPAuthor by Silect makes this very easy, and lays out all the contents inside the Management Pack in a nice graphical and navigate-able UI. Again, a must to fulfill your authoring needs:
Now that you’re educated about SCOM, it’s capabilities, goods and not-so-goods, and the necessary add-ons to make your monitoring a whole lot easier and smoother, go on and try it yourself! 😊