OMS – OMS, is it SCOM in the cloud?

I can recall many instances whilst attending conferences and talking with customers or colleagues whereby misunderstandings have caused a significant amount of confusion.

“Operations Management Suite is SCOM in the cloud”

This is a one that has been doing the rounds lately, but it is correct? To answer the question we need to do a bit of digging into the past. André Malraux once said,

“Who wants to read in the future, must scroll in the past.”.

System Center Operations Manager (SCOM) was and is the Microsoft monitoring solution for homo- and heterogeneous IT environments. SCOM was originally developed by NetIQ, then purchased in 2000 by Microsoft. It carries with it a 17-year evolution, which started when the product was called Microsoft Operations Manager (MOM). In 2007 «MOM» was completely rewritten on a flexible and extensible framework SCOM was born. The development has continued ever since and the latest available version is SCOM 2016.
About 6 years ago, Microsoft began to experiment with System Center Advisor, an agent-based assessment and best practice analyzer solution based in the cloud. It provided the ability to analyze different workloads such as Windows operating system, SQL Server, Active Directory and Hyper-V components, detect changes to IT infrastructure, and propose Microsoft best practices from in the form of alarms. Between 2012 and 2013 the range of supported technologies was extended to include Exchange, SharePoint and Lync. Initially a separate solution, it quickly became integrated into SCOM 2012 SP1 by means of a connector. The newly generated information retrieved from Azure became available both on-premise within SCOM and in the cloud through System Center Advisor extension. By SCOM 2012 R2, the connector came pre-bundled as part of the suite. In 2014 System Center Advisor was transformed, gone was the Silverlight-based web application and in came a new HTML 5 based web app with a host of new capabilities. This meant that the Best Practice Analyzer System Center Advisor could be integrated into a new product called Azure Operational Insights, the range of capabilities for which could be greatly expanded by the use of so-called Intelligence Packs (IP). The following packs were released as part of the initial deployment:

• Configuration Assessment
• Malware Assessment
• Capacity Planning
• Change Tracking
• Log Management
• SQL Assessment
• System Update Assessment

A new key feature acted like a cloud-based «data pot» whereby data was collected using an agent and could be analyzed with a PowerShell-like syntax within Azure Operational Insights Search Data Explorer.  A connection to SCOM was also ensured by a SCOM connector. In addition, the Operational Insights product is now the foundation for today’s current Operations Management Suite (OMS). Operational Insights Search Data Explorer is called Azure Log Analytics and Intelligence Packs are called solution (packs).
Since we now know the background of both products, I would like to juxtapose their facts, in order to be able to answer the question objectively.

Concept
SCOM consists of an extensible hierarchical object model. This means that components that are to be monitored in SCOM can be discovered (Discovery) by means of management packs (XML files) and placed into a hierarchy (service model) using relationships. Sensors (monitors) can move a subordinate object, into a healthy state, or into a faulty (unhealthy) state and visually represent it. The health state can be passed to its parent object (rollup). This model is described as a health model and has many advantages as well as certain disadvantages.

OMS works with so-called flat data, this means the data exists as data records in a large data pot. There are no objects or relationships among the collected data. For example, solution 1 collects disk information from computer X. At the same time solution 2 collects information on the same disk, BUT there is no relationship nor knowledge of the status between the disk data from solution 1 and solution 2. OMS does not (yet) have any service model and therefore also no health model.

Agents
SCOM and OMS by means of the Microsoft Monitoring Agent are available to collect infrastructure data. While SCOM is instructed to require the agent to send its data to a management or gateway server, OMS can send its data to the cloud via SCOM Management Groups or a stand-alone agent. The intelligence gleaned from the data is provided by management packs those developed by Microsoft, 3^rd Parties or experienced administrators. Management packs include classes, relationships, discoveries, rules, thresholds, views for the console, reports, etc. This extensibility allows for support of almost any application through the creation of additional Management Packs, however, this requires quite a high level knowledge in the application and developer know-how.
OMS in comparison has logic for collecting the data is packaged in solutions. A solution contains basically two parts, a part for collecting data and another for visualizing the data. Data can be sent to OMS via SCOM using Management Packs or via the Log Analytics HTTP Data Collector API. This REST API can be queried via PowerShell, C# or any other programming language the data transfer is based on standard JSON-formatted requests.
The online View Designer lets you build modern dashboards in Azure Log Analytics, see the Visualization section for more details. Finally, the solution is packaged and distributed in the form of Azure Resource Manager (ARM) templates.
An important difference between in the two solutions is the ability to define what data specifically is collected from each individual agent. SCOM offers a highly granular targeting mechanism. This means that rules or monitors can be executed on dedicated objects. OMS does not currently offer the possibility to run solutions on dedicated target systems.

Visualization
The possibilities in SCOM to visualize data without a third-party tool are very modest and probably considered among many as a weakness of the product. An overview of current infrastructure information can be viewed through views in the console and refined by dashboards and widgets. The available web console provides a limited representation for end users and application managers. Long-term data can be evaluated using SQL Server Reporting Services (SSRS) reports.
OMS is based on HTML 5, a widely supported, current technology, easily customized to the needs of the solution. Data can be queried using Log Search queries which then can be displayed directly in the portal using the View Designer. OMS currently comes with predefined views in a modern form, the selection is currently somewhat limited.

Interfaces
SCOM does not support receiving data from unknown sources. Valid means or inserting data are via PowerShell, management pack authoring, Software Development Kit (SDK) or a Custom Connector.
In contrast, OMS has been developed to support modern standards and therefore offers a powerful REST API, which can be easily accessed via scripting or a programming language.

Data analysis
For long-term data analysis, SCOM offers a SQL Server-based data warehouse. This means a database that stores monitoring data as raw and aggregated data points in the database and can be evaluated using reporting tools.
OMS takes a new approach. The collected data is stored in Azure Storage and is not aggregated. Using a proprietary search language, the data can be searched and analyzed. The search queries can be stored and reused for various purposes, such as visualization and alerting.

Alerting
An important component of any monitoring tool is alerting. Alerting defines, being able to define thresholds, and triggering alerts as soon said thresholds have been surpassed. SCOM offers monitors and rules that can do just that, from the beginning SCOM has been developed from the monitoring perspective.
OMS however, offers a different and far more reduced approach than SCOM. The basis in Azure Log Analytics is always a search query. Based on said query, metrics can defined, which trigger an alert, email, a Webhook or even start an Azure Automation runbook.

Interoperability
Support for heterogeneous IT infrastructures is becoming increasingly important for there are few Microsoft only environments. UNIX / Linux serve many crucial functions in the data center and for a growing monitoring solution it is considered a must that the solution can support both Microsoft and UNIX / Linux simultaneously. Further support for network components and Azure workloads are also deemed important. SCOM and OMS offer both agents and support for Windows and UNIX / Linux.
SCOM provides a well-engineered solution in all areas, it has been well-developed for monitoring on-premise components and can support to some extent some Azure workloads.
OMS supports a variety of monitoring capabilities for Microsoft, UNIX and Linux. Network monitoring, can be achieved using SNMP traps forwards via UNIX / Linux machines. Since it is a part of Azure, OMS offers a wide range of support for many different Azure workloads.

Administration and security
Having all this data is brilliant but without easy secure administration it can be somewhat for nothing. Since SCOM is and always has been an on-premise monitoring solutions, it comes with the additional administration generally associated with that. Many servers and moving components need to be maintained, patched and secured. The ever-growing amounts of data kept in 2 separate databases also need to be maintained and secured. From a security perspective only SCOM Administrators should have unrestricted access to these systems and its data, but this is rarely so. Regardless of the fact, daily users are not accessing this system, SCOM needs to be treated with the same careful planning and consideration as any highly available application.

OMS tries to alleviate some of this administrative burden by implementing a completely different approach. OMS is “software as a service” (SaaS) fully managed by Microsoft. This means capacity/resource planning, maintenance and expansion of the product, all this is done as part of the paid service. From a security point however, the data collected no longer under the control of the business as it previously was with an on-premise solution, data is stored in the cloud and as such can could compliance issues in some countries. Microsoft have many types of accreditation when it comes to storing and maintaining data such as FIPS 140-2, ISO 27018 compliance among others.

Is OMS SCOM in the cloud? Let’s look back. SCOM was created at a time when cloud wasn’t a topic of discussion, with the goal of monitoring local IT systems. SCOM’s only task is monitoring, it does it well and it shows that it has been slowly perfected over many years of development.
OMS was born in the cloud and is still a relatively young product. Born first as an assessment solution, then expanded to a data analysis and management tool which has the ability to alert if a state deviates from a configured value. OMS has a completely different architectural approach to SCOM and also a different background. Because of the potential of the cloud and modern architecture, OMS has almost unlimited potential. This includes managing cloud resources, analyzing data, visualization of data and alarming. The monitoring possibilities still have a way to go before they can compare with that of SCOM. SCOM, in turn is focused on monitoring, but it is now starting to show signs of age as an on-premise solution with its inability to cope with today’s modern cloud infrastructures. So, we can clearly say OMS is NOT SCOM in the cloud, but it could be. Both tools have their strengths in areas that the other tool does not. Today the combination of both tools by means of connectors allows for the best of both worlds and IT departments should strongly consider pursuing that goal.

I hope this helps you to understand each technology, history and where it might be in one or two years.