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.
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.
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.
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 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:
Rules are different to monitors as they do not change an objects health state. They perform three functions:
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:
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.
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.
© Squared Up Ltd. 2019