Your 8 minute guide
Starting with the basics...
Microsoft Systems Center Operations Manager (SCOM) is an IT tool which monitors infrastructure and application health. It provides a single management console for viewing application performance and is an enterprise-class application used by organizations to monitor large-scale environments.
SCCM Vs. SCOM
System Center Configuration Manager (SCCM) and System Center Operations Manager (SCOM) are both Microsoft System Center products. They are used by IT organisations to manage systems, but they serve different purposes.
SCCM is an Enterprise Management tool, used for managing client systems, installing updates, deploying software, and inventorying hardware and software.
SCOM on the other hand, is an Enterprise level, cross platform, infrastructure and service monitoring tool. SCOM can collect data from a wide array of sources - from server infrastructure and networking through to applications and cloud resources.
Both tools offer impressive reporting capabilities in their given areas, are highly scalable, and have been deployed in organisations of various sizes around the world.
How does SCOM work?
SCOM is structured in a logical and understandable way. Let's walk through some of the core concepts and explore how they relate to each other.
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.
Classes, Objects and Instances
Newcomers often ask, ‘What is SCOM monitoring?’. Well, SCOM monitors objects - pieces of infrastructure and other components, which an application is built upon. An object might be a server, or a server database, or a disk. The Service Model groups these objects into logical categories. These categories are known as classes. A class is defined with properties, such as date property, with each property being defined by its values, such as 17 May 2011. Each object within a class is called an instance of that class.
Instances of classes, and classes themselves, can have relationships. There are several different types of relationship. One relationship type is called ‘hosting’. If an instance is hosted within another instance, the former is called a hosted instance. Another relationship type is called ‘containment’. This is seen where an instance is related to another instance (but they are not required for each other), including when the health of one instance is dependent on another instance. These are the two most common types of relationship, but there are others – including ‘reference’ and ‘should manage’ relationships.
SCOM is designed to monitor applications and their health. It uses a health model to assess the health of the components within an application and to provide a picture of the application’s overall health. To clarify, a service model defines the structure of an application, whereas a health model defines how to measure and present the health of an application. The health model uses monitors (set to configurable thresholds) that will define the application health, as well as rules to collect relevant data, including performance data. This way, SCOM knows how the application should be performing, and can change the health status of the application if operating outside of normal parameters.
Monitors and Rules
Monitors check and show the health state of an instance. The health state has either 2 or 3 values, either red, amber, or green. There are three main types of monitors:
- Unit monitors, which measure a specific part of the application, such as CPU usage %
- Dependency monitors, which show a health rollup when the health of an object depends on another object
- Aggregate monitors, which show an aggregate health state across several monitors
Rules are different to monitors as they do not change an objects health state. They perform three functions:
- Collect information, such as performance or event data
- Raise an alert, including when a specific event ID is detected in an event log
- Run a command, or script on a schedule
For discovery to work, all server instances will need to have agents installed on them. An agent is a piece of software installed on the server, that collects data and feeds information back to SCOM, where it is evaluated to determine health based on the configuration of the monitors and rules. Agents can also be used to execute tasks from the SCOM console, such the collection of local user information.
SCOM does not come pre-packaged with defined service and health models. The models are built and stored in Management Packs (MPs), which are then imported into SCOM. These are often created and sold by third party vendors, though any user can create management packs either in the SCOM console directly, or via Visual Studio Authoring Extensions. One of the more popular MPs is the PowerShell Monitoring MP which adds support for PowerShell in to the SCOM’s console authoring pane.
When a Management Pack is imported into SCOM, it starts a discovery process, which locates all instances that relate to the application and arranges them into a service model. Discovery processes are run on a regular basis to ensure the service model is up to date.
An instance of SCOM is called a Management Group, which contains the monitoring configuration, service and health models, and all imported management packs. A user connects to the Management Group using the Operations Console (SCOM Console), this is the user interface for the SCOM platform. The topology of a management group consists of:
- One or more Management Servers, which perform general management group functions, such as health calculation, and agent management
- The Operations Manager Database, which contains the short-term monitoring data, and configuration settings for the Management Group
- The Data Warehouse Database, which is used for storing historical monitoring data
- The reporting server, an optional component, that reads data from the Data Warehouse and provides reporting from this data
SCOM version history
The earliest version of SCOM began life in 1998 as 'OnePoint Operations Manager'. Microsoft acquired the rights of the product in 2000, renamed it to 'Microsoft Operations Manager' and since then it has been updated with several new versions.
Read our guides below to find out more about each SCOM version.
SCOM 1801: The Low-downA handy guide to what's new in SCOM 1801
What is SCOM?New to the world of SCOM? Don't worry. We've got your back.
SCOM 2019 overviewYour five minute guide to SCOM 2019
What's new in SCOM 2016?A quick look at all the features and improvements made in SCOM 2016
More about SCOM
Now that you know a little bit about SCOM, you might want to dig a little deeper. We have searched the SCOM world top to bottom to bring you the latest and greatest content.
- Ask questions about SCOM to the experts at our Community Answers platform.
- Visit some of the most influential blogger websites in the SCOM world – Kevin Holman, Marnix Wolf and Tao Yang.
- Read feedback from SCOM users posted to Microsoft’s User Voice.
- Learn more about how SCOM can monitor your applications with our complete guide to Application Performance Management.