Whats New in Operations Manager 2019

Contents
Overview
Operations Manager key concepts
Get Started
Operations Manager 2016 build versions
Features deprecated
Release notes
What's new in Operations Manager
Walkthrough: Installing Operations Manager on a Single Server
Installing Operations Manager from the Command Prompt
Enable service logon
Turn on/off telemetry settings
How To
Plan
System requirements
Supported versions of UNIX and Linux
Planning a management group design
SQL Server design considerations
Resource pool design considerations
Design integration with other enterprise management products
Designing for high availability and disaster recovery
Agent deployment planning
Security
Configuring a firewall for Operations Manager
Configure TLS 1.2 encryption
Configure antivirus exclusions
Service, user, and security accounts
Run As accounts and Profiles
Security credentials to access UNIX and Linux computers
Authentication and data encryption in Operations Manager
Data encryption for Web console and Reporting server connections
Security considerations monitoring Microsoft Azure and Office 365
Deploy
Single-Server deployment of Operations Manager
Distributed deployment of Operations Manager
How to install an Operations Manager management server
How to install the Operations console
How to install the Operations Manager Web console
How to install an Audit Collection Services(ACS) Collector and database
How to install the Operations Manager Reporting server
Connect to the Data Warehouse across a firewall
How to install a gateway server
Upgrading System Center Operations Manager
Pre-Upgrade tasks when upgrading Operations Manager
How to upgrade a single-server management group
How to upgrade a management server - Upgrading a distributed management
group
How to upgrade an ACS Collector
How to upgrade a gateway server
How to upgrade an Operations console
How to upgrade an agent
How to upgrade agents in a parallel deployment
How to upgrade a Web console
How to upgrade reporting
How to upgrade 1807 databases to SQL Server 2017
How to upgrade to version 1807
How to upgrade from the evaluation version of Operations Manager
Post-upgrade tasks when upgrading Operations Manager
Manage
Quick reference to Operations Manager tasks
Operations Manager monitoring scenarios
Managing discovery and agents
Discover and install agent on Windows
Discover and install agent on UNIX and Linux
Install Windows agent manually with MOMAgent.msi
Install agent on Nano Server
Configuring Windows agents
Configure agent failover to multiple gateway servers
Install agent on UNIX and Linux from command line
Install agent on Linux from command line
Manage certificates for UNIX and Linux computers
Repair Windows agent
Process manual agent installations
Applying overrides to object discoveries
Upgrading and uninstalling agent on UNIX and Linux computer
Manually uninstalling Agents from UNIX and Linux computers
Uninstall agent on Windows computer
Configure and use Active Directory Integration for agent assignment
Using management packs
What is in an Operations Manager management pack?
Management packs installed with Operations Manager
Management pack lifecycle
Management pack templates
About Management pack templates
Creating Management pack templates
.NET application performance monitoring template
How to configure monitoring for .NET applications
Using exception handlers to define critical exceptions
Authoring strategies for .NET application monitoring
Application monitoring using the default settings
OLE DB data source template
Process Monitoring template
TCP port template
UNIX or Linux log file
UNIX or Linux process
Web Application Availability Monitoring template
Web Application Transaction Monitoring template
How to replace parameters in a URL request
Windows Service template
Using classes and groups for overrides
How to import, export, and remove a management pack
Create a management pack for overrides
How to override a Rule or Monitor
How to enable a Rule or Monitor
How to add knowledge
Management Pack assessment
Selecting a Management Pack File
Using the Operations Manager consoles
Comparing the Operations and Web console
How to connect to the Operations and Web console
Operations console refresh improvements
Using Health Explorer
Using My Workspace
Finding data and objects in the consoles
Using advanced search
Using the Monitoring workspace
Using the Administration workspace
Using the Authoring workspace
Using the Reporting workspace
Using reports
Operations Manager report library
How to create reports
How to run, save, and export reports
How to configure and modify report schedules
Monitor failover clusters
Not monitored and gray agents
How to view all rules and monitors running on agent-managed computer
Configure SharePoint to view Operations Manager data
Using views and dashboards
View types
Dashboards overview
Web console dashboards
Overview
Create dashboard with Alert widget
Create dashboard with State widget
Create dashboard with Perf widget
Create dashboard with Topology widget
Create dashboard with Tile widget
Create dashboard with Custom widget
Create dashboard with PowerShell widget
Manage dashboard and widget config
Viewing effective configuration of workflows
Using My Workspace in Web console
Standard views
Creating and scoping views
Personalize a view
Subscribing to alert notifications
How to create and configure the notification action account
How to enable an email notification channel
How to enable an instant message notification channel
How to enable text message(SMS) notification channel
How to enable a command notification channel
How to create notification subscribers
How to create notification subscriptions
How to customize message content for notifications
How to subscribe to notifications from an alert
Using the Visio add-in and SharePoint Visio Services Data Provider
Install the Visio add-in
Install and configure the Visio Services data provider
Configure the Operations Manager data source in Visio
View an Operations Manager distributed diagram in Visio
Link to Operations Manager objects in a new or existing Visio document
Build a simple monitoring dashboard using the Visio Web Part
Publish a Visio diagram to SharePoint Server
Change the way Health State is represented in Visio
Troubleshooting the Visio add-in
Security in Operations Manager
How to configure Report Server authentication
How to configure Web console authentication
Implementing user roles
Operations associated with User Profile roles
How to create a new Action account
How to control access by using the Health Service Lockdown tool
Managing Run As Accounts and Profiles
Distribution and targeting for Run As Accounts and Profiles
How to create a Run As Account and associate with a Profile
How to configure Run As accounts and profiles for UNIX and Linux access
Accessing UNIX and Linux computers
How to set credentials for accessing UNIX and Linux computers
How to configure sudo elevation and SSH keys
Configure Kerberos authentication for Linux computers
Required capabilities for UNIX and Linux computers
Configuring SSL ciphers
Administering and configuring the UNIX/Linux agent
Troubleshoot monitoring the UNIX/Linux agent
Agentless monitoring
Client monitoring using Agentless Exception Monitoring
Monitoring .NET applications
Viewing and investigating alerts for .NET apps
Viewing and investigating alerts for .NET apps
Working with the Application Diagnostics console
Working with events using Application Diagnostics
Prioritizing alerts using Application Advisor
Configure grooming settings for .NET APM events
Working with sensitive data for .NET applications
Monitoring Java Applications
Monitoring Java applications with Operations Manager
Configure monitoring of Java applications
Monitoring networks with Operations Manager
How to discover network devices
Network device discovery settings
Run As accounts for network monitoring
How to delete or restore a network device
How to configure monitoring of network devices
Viewing network devices and data
Reports for network monitoring
Monitoring Web application transactions
How to edit settings or requests for a web application
Web application properties
Web application request properties
Monitor Linux log files
Overview of Linux log file monitoring
Sample configuration file
Sample management pack
Monitoring service level objectives
Create a service level dashboard
Running a service level tracking report
Connecting Operations Manager with other management systems
How to configure a product connector subscription
Monitoring Operations Manager from a second management group
Manage Alerts
How heartbeats work
Resolving heartbeat alerts
Configure ping computer recovery task from gateway servers
How an alert is produced
Viewing active alerts and details
Examine properties of alerts, rules, and monitors
Impact of closing an alert
How to close an alert generated by a monitor
How to reset health
Using health explorer to investigate problems
How to set alert resolution states
How to configure automatic alert resolution
Data driven alert management
Enable recovery and diagnostic tasks
Suspend monitoring temporarily by using maintenance mode
Creating and managing groups
Running tasks in Operations Manager
Connecting management groups in Operations Manager
Using Operations Manager shell
How to create and manage resource pools
Maintaining Operations Manager infrastructure
Monitoring the health of the Management Group
How and when to clear the cache
How to configure Operations Manager to communicate with SQL Server
Scheduled maintenance in Operations Manager
How to move the Reporting server role
How to move the Operational database
How to move the Reporting data warehouse database
How to configure grooming settings for the Operations Manager database
How to configure grooming settings for the Reporting data warehouse database
Operations Manager
2 minutes to read
Welcome to System Center - Operations Manager. Operations Manager provides infrastructure monitoring that is
flexible and cost-effective, helps ensure the predictable performance and availability of vital applications, and offers
comprehensive monitoring for your datacenter and cloud, both private and public.
Operations Manager documentation

Getting Started with System Center - Operations Manager
Written for customers who are either new to Operations Manager or are looking for “What’s New”
information.
Planning for System Center - Operations Manager
Review information to help you plan the deployment of Operations Manager into your organization
Deploying System Center - Operations Manager
Read these topics to learn how to deploy Operations Manager in your environment.
System Center - Operations Manager Operations Guide
Read these topics once you have Operations Manager up and running and are looking to start monitoring
your environment, as well as procedures for day to day operations.
Management Pack Authoring Guide for Operations Manager
The Management Pack Authoring Guide for Operations Manager provides information on creating custom
monitoring for your service or application.
Operations Manager key concepts
10 minutes to read
Operations Manager, a component of Microsoft System Center, is software that helps you monitor services,
devices, and operations for many computers from a single console. This topic explains basic concepts about
Operations Manager for the administrator who manages the Operations Manager infrastructure and the operator
who monitors and supports the IT services for your business.
What Operations Manager does

Businesses, small and large, are typically dependent on the services and applications provided by their computing
environment. IT departments are responsible for ensuring the performance and availability of those critical
services and applications. That means that IT departments need to know when there is a problem, identify where
the problem is, and figure out what is causing the problem, ideally before the users of the applications encounter
the problems. The more computers and devices in the business, the more challenging this task becomes.
Using Operations Manager in the environment makes it easier to monitor multiple computers, devices, services,
and applications. The Operations console, shown in the following image, enables you to check the health,
performance, and availability for all monitored objects in the environment and helps you identify and resolve
problems.
NOTE
To learn more about the Operations Manager consoles, see Comparing the Operations Manager Consoles in the Operations
Guide.
Operations Manager will tell you which monitored objects are not healthy, send alerts when problems are
identified, and provide information to help you identify the cause of a problem and possible solutions. As the
administrator, you configure what will be monitored by selecting computers and devices to be monitored and
importing management packs that provide monitoring for specific features and applications. To decide which
objects to monitor and what to monitor for, you need to understand the features that comprise the Operations
Manager infrastructure and how Operations Manager works.
The Operations Manager infrastructure

Installing Operations Manager creates a management group. The management group is the basic unit of
functionality. At a minimum, a management group consists of a management server, the operational database,
and the reporting data warehouse database.
The management server is the focal point for administering the management group and communicating
with the database. When you open the Operations console and connect to a management group, you
connect to a management server for that management group. Depending on the size of your computing
environment, a management group can contain a single management server or multiple management
servers.
The operational database is a SQL Server database that contains all configuration data for the
management group and stores all monitoring data that is collected and processed for the management
group. The operational database retains short-term data, by default 7 days.
The data warehouse database is a SQL Server database that stores monitoring and alerting data for
historical purposes. Data that is written to the Operations Manager database is also written to the data
warehouse database, so reports always contain current data. The data warehouse database retains long-
term data.
When Operations Manager reporting functionality is installed, the management group also contains a Reporting
server which builds and presents reports from data in the data warehouse database.
These core components of a management group can exist on a single server, or they can be distributed across
multiple servers, as shown in the following image.
For information about installing management group features, see Operations Manager Deployment Guide.
Management servers
The role of the management server is to administer the management group configuration, administer and
communicate with agents, and communicate with the databases in the management group.
The management group can contain multiple management servers to provide additional capacity and continuous
availability. When two or more management servers are added to a management group, the management servers
become part of a resource pool and work is spread across the members of the pool. When a member of the
resource pool fails, other members in the resource pool will pick up that member’s workload. When a new
management server is added, the new management server automatically picks up some of the work from existing
members in the resource pool. All members in the resource pool will manage a distinct set of remote objects; at
any given time, two members in the same pool will not manage the same object at the same time.
A specialized type of management server is the gateway server. A gateway server enables the monitoring of
computers in untrusted domains. For more information, see Planning a management group design.
Agents
An Operations Manager agent is a service that is installed on a computer. The agent collects data, compares
sampled data to predefined values, creates alerts, and runs responses. A management server receives and
distributes configurations to agents on monitored computers.
Every agent reports to a management server in the management group. This management server is referred to as
the agent's primary management server.
Agents watch data sources on the monitored computer and collect information according to the configuration that
is sent to it from its management server. The agent also calculates the health state of the monitored computer and
objects on the monitored computer and reports back to the management server. When the health state of a
monitored object changes or other criteria are met, an alert can be generated from the agent. This lets operators
know that something requires attention. By providing health data about the monitored object to the management
server, the agent provides an up-to-date picture of the health of the device and all the applications that it hosts.
An agent can be configured to act as a proxy agent. A proxy agent is an agent that can forward data to a
management server on behalf of a computer or network device other than its host computer. For example, an
agent that is installed on the physical node of an SQL cluster can be enabled to act as proxy to monitor the cluster
resource. Proxy agents enable monitoring of computers and devices on which an agent cannot be installed. For
more information, see Agentless Monitoring.
Services
On a monitored computer, the Operations Manager agent is listed as the Microsoft Monitoring Agent service. The
Microsoft Monitoring Agent service collects performance data, executes tasks, and so on. Even when the service is
unable to communicate with the management server it reports to, the service continues to run and queues the
collected data and events on the disk of the monitored computer. When the connection is restored, the Microsoft
Monitoring Agent service sends collected data and events to the management server.
NOTE
The Microsoft Monitoring Agent service is sometimes referred to as the Health Service.
The Microsoft Monitoring Agent service also runs on management servers. On a management server, the service
runs monitoring workflows and manages credentials. To run workflows, the service initiates MonitoringHost.exe
processes using specified credentials. These processes monitor and collect event log data, performance counter
data, Windows Management Instrumentation (WMI) data, and run actions such as scripts.
Management servers also run the System Center Data Access service and the System Center Management
Configuration service.
The System Center Data Access service provides access for the Operations console to the operational database
and writes data to the database.
The System Center Management Configuration service manages the relationships and topology of the
management group. It also distributes management packs to monitored objects.
Management packs
The workflows that the System Center Management service runs are defined by management packs. Management
packs define the information that the agent collects and returns to the management server for a specific application
or technology. For example, the BizTalk Server Management Pack contains rules and monitors that collect and
evaluate events and operations that are important to ensuring the health and efficiency of the BizTalk Server
application.
After Operations Manager installs an agent on a computer, it sends an initial configuration to the agent. The initial
configuration includes object discoveries from management packs. The management pack defines the types of
objects, such as applications and features, that will be monitored on computers that have been discovered by
Operations Manager. Agents send data to the management server that identifies the instances of objects
discovered on the computer. The management server then sends the agents the elements of management packs
that apply to the discovered objects for each computer, such as rules and monitors.
A rule defines the events and performance data to collect from computers and what to do with the information
after it is collected. A simple way to think about rules is as an If/Then statement. For example, a management pack
for an application might contain rules such as the following:
If a message indicating that the application is shutting down appears in the event log, create an alert.
If upload of a source file fails, collect the event that indicates this failure.
As these examples show, rules can create alerts and collect events or performance data, which the agent sends to
the management server. Rules can also run scripts, such as allowing a rule to attempt to restart a failed application.
Discovered objects have a health state, which is reflected in the Operations console as green (successful or
healthy), yellow (warning), or red (critical or unhealthy). Monitors define the health states for particular aspects of
the monitored object. For example, a monitor for disk drive capacity might define green as less than 85 percent full,
yellow as over 85 percent full, and red as over 90 percent full. A monitor can be configured to generate an alert
when a state change occurs.
How objects are discovered and monitored

The following image is a simplified illustration of how objects are discovered and monitored.
1. The administrator configures Operations Manager to search for computers to manage. For more
information about discovering computers, see Agent deployment planning.
2. Computers that meet the specified criteria and are not already managed are identified.
3. An Operations Manager agent is installed on the discovered computer.
4. The agent requests configuration data, and then the management server sends the agent configuration data
from installed management packs that includes classes to be discovered. For example, if the Windows
Server operating system management packs are installed, the management server will send the agent the
operating system classes.
5. The agent compares the configuration data to the computer, identifies any objects that it discovers, and
returns the information to the management server. For example, the agent will return to the management
server that an instance of Windows Server 2016 operating system is on the computer.
6. The management server sends the agent all monitoring logic from installed management packs that applies
to the discovered objects. For example, the agent will receive all monitoring logic that applies to Windows
Server 2016.
7. The agent applies the monitoring logic, such as rules and monitors, runs workflows, and returns data to the
management server.
8. As changes occur to discovered objects, such as applications being added or uninstalled, the agent sends the
updated information to the management server, which then sends updated monitoring logic.
NOTE
Operations Manager can also discover and monitor network devices, computers running UNIX and Linux operating systems,
and provide agentless monitoring. For more information, see Operations Manager Monitoring Scenarios in the Operations
Guide.
Communication between agents and management servers

The Operations Manager agent sends alert and discovery data to the primary management server, which writes
the data to the operational database. The agent also sends events, performance, and state data to the primary
management server for that agent, which writes the data to the operational and data warehouse databases
simultaneously.
The agent sends data according to the schedule parameters for each rule and monitor. For optimized collection
rules, data is only transmitted if a sample of a counter differs from the previous sample by a specified tolerance,
such as 10%. This helps reduce network traffic and the volume of data stored in the operational database.
Additionally, all agents send a packet of data, called a heartbeat, to the management server on a regular schedule,
by default every 60 seconds. The purpose of the heartbeat is to validate the availability of the agent and
communication between the agent and the management server. For more information on heartbeats, see How
Heartbeats Work in Operations Manager.
For each agent, Operations Manager runs a health service watcher, which monitors the state of the remote Health
Service from the perspective of the management server.
Other resources for Operations Manager
Main page for System Center - Operations Manager
Review the design and deployment considerations and recommendations for Operations Manager in the
Planning Guide
To learn how to install Operations Manager and deploy a management group, see Deploying System Center
- Operations Manager
To learn how to use Operations Manager after the management group is set up, see System Center -
Operations Manager Operations Guide
To learn how to create a management pack, see Author’s Guide for Operations Manager for System Center
Operations Manager Community
Getting Started
2 minutes to read
Welcome to Microsoft System Center - Operations Manager. The following topics provide information to help you
get started learning about Operations Manager in order to develop an effective architecture design plan that
supports your requirements, a deployment strategy to successfully perform an installation of Operations Manager
in your environment, and finally operational guidance so you can successfully use, manage and maintain your
deployment.
Getting started topics

To learn what's new in System Center - Operations Manager, first review What's New in Operations Manager
Understand the minimum System Requirements for Operations Manager for each Operations Manager
component and any other considerations that apply.
Before deploying Operations Manager, you first start by understanding the Planning Considerations for the
different roles, security configuration, guidance for an optimal SQL Server configuration, and more.
Install Operations Manager in a simple or distributed configuration in your environment by following the
Deploying System Center - Operations Manager deployment guide.
After installing Operations Manager, review the Operations Manager Operations Guide to learn how to effectively
use, integrate with your existing ITSM processes, and support Operations Manager in your environment.
System Center 2016 - Operations Manager build
versions
2 minutes to read
This article describes how to determine your current Microsoft System Center 2016 - Operations Manager version
number and the corresponding update rollup. Each update rollup (UR ) release has a link to a support article
describing the UR changes as well as links to the package downloads.
NOTE
All System Center Operations Manager update rollups are cumulative. This means you do not need to apply them in order,
you can always apply the latest update. If you have deployed System Center 2016 - Operations Manager and never applied
an update rollup, you can go proceed to install the latest one available.
Build versions
The following table lists the release history for Operations Manager 2016.
BUILD NUMBER KB RELEASE DATE DESCRIPTION
7.2.11719.0 September 2016 General Availability release
7.2.11759.0 KB3190029 October 2016 Update Rollup 1
7.2.11822.0 KB3209591 February 2017 Update Rollup 2
7.2.11878.0 KB4016126 May 2017 Update Rollup 3
8.0.10977.0 KB4024941 October 2017 Update Rollup 4 1
1 All System Center Operations Manager update rollups are cumulative. This means you do not need to apply them
in order, you can always apply the latest update. However, there is one exception to this upgrade behavior. If you
want the ability to uninstall UR4, you should make sure you have previously applied UR2 or UR3, which fixed an
uninstall issue. Update rollups subsequent to UR4 can be uninstalled without previous rollups being applied.
Next steps
See How to monitor the health of the management group to verify all components are operating normally after
performing an update.
Features deprecated from System Center Operations
Manager 1801
2 minutes to read
The features and capabilities listed below are included in System Center Operations Manager 1801 but planned to
be removed in a future release. Applications, code, or usage that depends on these features will continue to
function in this release until otherwise specified. This list is subject to change in subsequent releases and may not
include every deprecated feature or capability.
Silverlight based Web console

Status: Deprecated.
Replacement: A new HTML based Web console is available with System Center Operations Manager 1801. You
can still access Silverlight based dashboards with Internet Explorer with the URL
http://<servername><:port>/dashboard .
Agent for Nano Server

Status: Deprecated.
Replacement: None
Next Steps
See the introductory information or important concepts about Operations Manager
Release notes for System Center Operations Manager
16 minutes to read
This article lists the release notes for System Center 2019 - Operations Manager.
Operations Manager 2019 release notes

The following sections summarize the release notes for Operations Manager 2019 and include the known issues
and workarounds.
Health Service with Log on type as Service by default

Description: With Operations Manager 2019, Log on as a Service feature is enabled by default. This change
impacts all the service accounts and Run As accounts, they must have Log on as a Service permission.
Workaround: Enable log on as a service permission for these accounts. Learn more.
User experience changes in maintenance mode

Description: The following are the user experience changes with Operations Manager 2019 maintenance mode.
These changes are applicable to both Windows and Linux\Unix monitoring:
As an entity enters the maintenance mode, monitor-based active alerts on it will be automatically resolved.
In earlier releases, these alerts get automatically resolved when the entity exits the maintenance mode.
On-demand monitors and regular monitors now behave similarly when target entity enters and exits the
maintenance mode.
Workaround: None
Support for x64 components

Description: Operations Manager 2019 supports only x64 components, x86 components aren't supported. If you
try to push install the agent from the console to a x86 computer, the following error message appears:
The system cannot find the path specified.
Workaround: None
Upgrade to reporting server fails the prerequisites check

Description: While attempting to do an upgrade of System Center 2016/1801/1807 - Operations Manager
reporting server to version 2019, the prerequisites check reports the following error:
Management Server Upgraded Check - The management server to which this component reports, has not been
upgraded.and the upgrade cannot proceed.
This error occurs in a distributed management group scenario, where the reporting server is on a server that is
different from one or more management servers in the management group.
Workaround: Install the System Center 2016/1801/1807 - Operations Manager Operations console on the server
that is hosting the reporting server role, and then retry upgrading the reporting server role to version 2019. Once
the upgrade is successful, you can uninstall the upgraded Operations console from the reporting server.
Internet Explorer compatibility view
Description: The HTML5 Web console doesn't support Internet Explorer compatibility View.
Workaround: None
OpenSSL 1.1.0 version support

Description: On Linux platforms, OpenSSL 0.9.8 support is dropped.
Workaround: We have added support for OpenSSL 1.1.0.
Performance monitoring for VMM server fails with Access denied

message
Description: Service users do not have permission to access VirtualMachineManager-Server/Operational event
log. Workaround: Change the Security Descriptor for operational event log registry with the command below, and
then restart event log service and health log service.
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-

VirtualMachineManager-Server/Operational /v ChannelAccess /t REG_SZ /d O:BAG:SYD:(D;;0xf0007;;;AN)
(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;NS)(A;;0x1;;;IU)(A;;0x1;;;SU)"
This command will add the service user to the list of allowed users, who can access VirtualMachineManager-
Server/Operational event log.
Operations Manager 2019 does not support HPUX library

Description: Operations Manager 2019 does not support HPUX. However, HPUX library is available in the list of
management packs delivered for Operations Manager 2019.
Workaround: Ignore this. HPUX is removed from the latest pack on the DLC, here.

The following sections summarize the release notes for Operations Manager 1807 and include the known issues
and workarounds. For more information about version 1807 and what issues are addressed, see KB4133779.
Log rotation for Linux agent

Description: Under certain scenarios, the SCX logs fill up frequently, which eventually consumes all available free
space on the system disk. As a result, the system becomes unresponsive unless the logs are cleaned up manually.
To address this issue, we have introduced a logrotate feature for SCX agent. This will help you rotate old logs and
save disk space.
Prerequisite: Logrotate is located in /usr/sbin/logrotate by default on Linux platforms.
Workaround: During scxagent installation we push the following logrotate conf file to /etc/logroate.d location.
/var/opt/microsoft/scx/log/*/scx.log
{
rotate 5
missingok
notifempty
nodatext
compress
size 50M
copytruncate
postrotate
/usr/sbin/scxadmin -log-rotate
all
}
You can change the default values to support your requirements. The default configured values will rotate the
scx.log file if scx.log file size reaches 50 MB. We have included one cron config file at /etc/cron.d location. With
this configuration, the logrotate process executes every four hours. To customize the configuration, you need to
modify these two files. Review the man page for cron and logrotate for further details.
NOTE
If SELinux is already installed, SCX installer pushes a SELinux module that will enable logrotate. For scenarios where SElinux is
enabled after agent installation, you have to import SELinux module for logrotate to work.
Support for SQL Server 2017

Description: With version 1807, SQL Server 2017 is supported only if it is upgraded from SQL Server 2016. A
fresh installation of SQL Server 2017 with version 1807 is not supported. If you already have version 1801
deployed with SQL Server 2016, you need to apply Operations Manager version 1807 before performing an
upgrade to SQL Server 2017.
Workaround: Before upgrading to SQL Server 2017, review the following article about the upgrade process -
Upgrade Operations Manager 1807 databases to SQL Server 2017.
Supportability with Internet Explorer Compatibility View

Description: The HTML5 Web console does not support Internet Explorer Compatibility View.
Workaround: None
Support for Operations Manager and Service Manager console

coexistence
Description: With System Center version 1801, installing the Service Manager console on a Operations Manager
management server wasn't supported. This would cause the SDK service to prematurely stop.
Workaround: To co-locate the Operations Manager and Service Manager console on the same computer, they
must be running version 1807.
Upgrade to Operations Manager version 1807

To understand the requirements and steps to successfully upgrade your Operations Manager version 1801
management group to version 1807, review How to upgrade to Operations Manager version 1807.

Description: On Linux platforms, OpenSSL 0.9.8 support is dropped.
Workaround: We have added support for OpenSSL 1.1.0.

The following sections summarize the release notes for Operations Manager 2016 and includes the known issues
and workarounds.
SharePoint integration with Operations Manager has to be recreated

Description: While using SharePoint to view Operations Manager data, the existing Web Console Dashboard
URLs provided will not work and these Web parts have to be recreated with the steps below.
Workaround: Perform the following steps to set up SharePoint to view Operations manager data:
1. Create a new page on SharePoint in which you want to display the Dashboard.
2. Open the page and click edit and insert a new Web Part.
3. In Web Part, under categories select “Media and Content” and under that select “Page Viewer” and click add.
4. Edit the Web Part and select Web Page and enter the URL of the Operations Manager Web console dashboard.
5. Append “&disabletree=true” at the end of the dashboard URL for disabling the tree view getting displayed on
the SharePoint page
6. Configure the appearance, layout, and Advance attribute of the SharePoint page.
Web Console might not work due to IIS becoming corrupt

Description: Web Console might throw an error “Could not load type
‘System.ServiceModel.Activation.HttpModule”.
Workaround: Add “HTTP Activation” to the role services of the OS. Then, on Server 2012 – run the following in
an elevated command prompt: “C:\Windows\Microsoft.NET\Framework64\v4.0.30319>aspnet_regiis.exe -r”.
Anomalies in handling tables and bullets in Knowledge Articles

Description: If tables are inserted in a knowledge article, when re-editing the knowledge article the borders are
not applied to the table. Similarly, if bullets are added in the knowledge article it gets converted to numeric bullets
while re-editing. And, if there is a single bullet in the article then the article doesn’t get saved in the MP and the
console throws error.
Workaround: None.
MSI-based installation does not work for Nano agent

Description: MSI-based installation is not supported for Nano agent. The agent can be installed from Discovery
Wizard\PowerShell installer scripts.
Workaround: None.
Issues with uninstalling an update for Nano agent

Description: Uninstalling an update to Nano agent is not possible.
Workaround Only option is to uninstall the Nano agent, then install the RTM version + desired update.
Issues with updates of Nano agent
Description: Updates to Nano agent will not be pushed from Windows Update. To update Nano agent, you need
to either download the available update and install using the PowerShell update scripts; or trigger a repair from an
updated Management server.
Workaround: None.
Unable to override the path or folder for Nano agent installation

Description: Nano agent is always installed to the following path: ‘%SystemDrive%\Program Files\Microsoft
Monitoring Agent’; the agent installation folder cannot be overridden.
Workaround: None.
Inconsistencies in push install experience of Nano agent

Description: The Discover Wizard status dialog closes but agent stays in pending state in console for some time
until the installation fails or completes successfully. Installation may fail, and to help troubleshoot, refer to the setup
log file.
Workaround: None.
Inconsistencies in push uninstall experience of Nano agent

Description: When performing a Push uninstall from the Operations console, the status dialog (which shows
progress status) shows the uninstall completed successfully, but the agent uninstall is still being performed.
Uninstall may fail and refer to the setup log file for further information to troubleshoot.
Workaround: None.
ACS is not working for Nano agent

Description: ACS is not working for Nano agent, in some cases. There are issues in certain scenarios.
Workaround: None.
Client-side monitoring (CSM) alerts might stop flowing from the

System Center Operations Manager management server
Description: The update sequence of System Center Operation Manager management server may cause an issue
with the client-side monitoring alerts collection from the management server. System Center Operations Manager
agents are not affected. Likelihood of occurrence: Medium.
Workaround: Restart the "Microsoft Monitoring Agent" service on System Center Operations Manager
management server.
If after updating System Center Operations Manager server or agent,

Application performance monitoring (APM) events, client-side
monitoring (CSM) events, and APM alerts might stop flowing from the
monitored hosts
Description: The update sequence of System Center Operations Manager agent may cause an issue with the
following:
• Client-side monitoring (CSM ) events and alerts collected on the host.
• Application Performance Monitoring (APM ) events and alerts collected on the host. System Center Operations
Manager management server is not affected.
Workaround: Restart the "Microsoft Monitoring Agent" service on the System Center Operations Manager agent-
managed computer that is experiencing the issue.
Application performance monitoring (APM) for Windows services is not

supported in System Center - Operations Manager on computers
where Application Insights Status Monitor is installed.
Description: Application performance monitoring (APM ) workflow fails to process monitoring configuration for
.NET Windows services on the computer if Application Insights Status Monitor and the System Center -
Operations Manager agent are both installed.
Workaround: Uninstall Application Insights Status Monitor.
Namespace values for performance tracking will be ignored

Description: Setting the Namespace value for performance tracking when tracking a custom namespace in .NET
Applications Performance Monitoring (APM ) will be ignored.
Workaround: Set both the exception tracking and performance tracking settings to include the same custom
namespaces.
When using sudo elevation with Solaris operating systems, it requires a

configuration change if sudo executable is not in an expected path
Description: If you want to use sudo elevation on a computer running Solaris, and the sudo executable is not in
the expected path, you need to create a link to the correct path. Operations Manager will look for the sudo
executable in the path /opt/sfw/bin, and then in the path /usr/bin. If sudo is not installed in one of these paths, a
link is required.
Workaround: The UNIX and Linux agent installation script creates the symbolic link
/etc/opt/Microsoft/scx/conf/sudodir to the folder expected to contain sudo. The agent uses this symbolic link to
access sudo. The installation script automatically creates the symbolic link, so no action is needed for standard
UNIX and Linux configurations. However if sudo is installed in a non-standard location, you should change the
symbolic link to point to the folder where sudo is installed. If you change the symbolic link, its value is maintained
for uninstall, re-installation, and upgrade operations with the agent.
Operations Manager Console will stop responding if you attempt to

resolve a dependency while importing a management pack
Description: When you click Import Management Packs from the Administration workspace of the Operations
Manager Operations console, the console will display the Resolve button if the Management Pack is dependent on
another Management Pack. If you click Resolve, you see the Dependency Warning. If you click the Resolve
button in the Dependency Warning dialog, the Operations console will stop responding.
Workaround: Install the Update for System Center 2016 - Operations Manager. See the Knowledge Base article
3117586 for specific instructions.
Telemetry data may be erroneously sent when the "Usage and

Connectivity Data" setting is set to "False"
Description: If two operators have Operations Manager consoles open and one sets the Usage and Connectivity
Data setting to "Do not send data" data may continue to flow to Microsoft until the second user closes and reopens
their instance of the Operations manager console.
Workaround: Restart all Operations Manager console sessions after making changes to the Usage and
Connectivity setting.
Description: When a new component such as a management server or gateway server are added to an existing
Operations Manager environment, usage information about the setup process is sent to Microsoft even though the
Usage and Connectivity Data setting is set to "Do not send data". After the component is added, no further usage
data will be sent to Microsoft from the component.
Workaround: None
Namespace values for performance tracking will be ignored

Description: Setting the Namespace value for performance tracking when tracking a custom namespace in .NET
Applications Performance Monitoring (APM ) will be ignored.
Workaround: Set both the exception tracking and performance tracking settings to include the same custom
namespaces.
Operations Manager web console is not compatible with Microsoft

Edge web browser
Description: When you open the Operations Manager web console from the Windows 10 Start Menu the console
will open in the Microsoft Edge web browser. This will result in an error.
Work around: Open the Operations Manager web console with Internet Explorer. Internet Explorer is available
from Windows Accessories sub-menu.
Launching the Operations Manager Web Console may result in a blank

screen
Description: When you first open the Operations Manager web console you may encounter a blank screen.
Work around: To resolve the issue:
1. Click on "Configure" button.
2. When prompted to Run or Save SilverlightClientConfiguration.exe, click Save.
3. Run SilverlightClientConfiguration.exe.
4. Open the file properties of exe (right-click) and open the Digital Signatures tab.
5. Select the certificate with Digest Algorithm as sha256 and click on Details.
6. In the Digital Signature Details dialog box, Click on View Certificate.
7. In the dialog box which appears next, click on Install Certificate.
8. In the Certificate Import Wizard, Set store location as - Local Machine. Click Next.
9. Select the option - "Place all certificates in the following store" Browse to Trusted Publishers.
10. Click Next and then Finish.
11. Refresh the Browser
The following sections summarize the release notes for Operations Manager 1801 and includes the known issues
and workarounds.
Telemetry for HTML5 dashboards

Description: System Center Operations Manager collects diagnostics and usage data about itself, which is used by
Microsoft to improve the installation experience, quality, and security of future releases. With the release of the new
HTML5 dashboards, usage telemetry is collected with Application Insights, not from the Usage and Diagnostic
feature in the management group. For more information on what user telemetry is collected by Application
Insights, see Usage analysis with Application Insights.
Workaround: Disable the Diagnostic and Usage data collection setting in the Operations console from the
Administration workspace under Settings\Privacy.
Edit Company Knowledge

Description: If the company knowledge of an alert/monitor/rule is already saved while editing in the Operations
console and then the company knowledge of the same alert/monitor/rule is edited and saved using the new
HTLM5 dashboards in the Web console, the content that was saved originally using the Operations console is
overridden with the content saved through the Web console.
Workaround: None
Access Silverlight dashboards in Web Console using a different URL

Description: With HTML5 dashboards in Operations Manager 1801, the entire Web console is HTML based.
Silverlight dashboards cannot be displayed in the Web console. To access existing Silverlight dashboards, you have
to access using the following URL using Internet Explorer with Silverlight enabled -
http(s)://<Servername>/dashboard .
Attempting to upgrade Reporting server fails prerequisites check

Description: While attempting to perform an upgrade of System Center 2016 - Operations Manager Reporting
server to version 1801, the prerequisites checker will report the following error: Management Server Upgraded
Check - The management server to which this component reports has not been upgraded. and the
upgrade cannot proceed. This error occurs in a distributed management group scenario where the Reporting
server is on a server separate from one or more management servers in the management group.
Workaround: Install the System Center 2016 - Operations Manager Operations console on the server hosting the
Reporting server role and then retry upgrading the Reporting server role to version 1801. Once the upgrade is
successfully completed, you can uninstall the upgraded Operations console from the Reporting server.
Application Performance Monitoring (APM) agent-component can

crash IIS App Pools
Description: The Application Performance Monitoring (APM ) feature in System Center Operations Manager
version 1801 agent can cause a crash with IIS Application pools and may crash the SharePoint Central
Administration v4 application pool running .NET Framework 2.0 and prevent it from starting. This behavior can
occur on an IIS web server even if the APM feature has not been enabled and configured after the agent is
installed.
Workaround: If the APM feature is not required on the server, reinstall the agent and include the NOAPM=1
parameter on the setup command line to prevent the APM feature from being included. Alternatively, you can
reconfigure the agent already installed using Windows Installer repair option and remove the APM component -
msiexec.exe /fvomus "\MOMagent.msi" NOAPM=1. For IIS web servers where the agent is already installed
but the APM feature has not been enabled and configured, grant the application pool account Read access
permission to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Operations
Manager\12\APMAgent. This permissions issue prevents the APM feature from being able to read that key and
may cause the application pool process to crash.
In-place upgrade from Operations Manager 2016 will fail if ACS

Linux/UNIX MP installed
Description: If you have already installed the Audit Collection Services (ACS ) Linux/UNIX management packs,
and you are attempting to upgrade from Operations Manager 2016 RTM to the latest update rollup, the upgrade
will fail and results in removal of the management server role.
Cause: There is an issue with the installer package during the upgrade process, where setup tries to upgrade the
ACS management pack but it has a dependency on the Microsoft.Linux.Universal.Library.MP. If this dependency
management pack is not upgraded, importing the ACS MP will fail during the process and the following error is
displayed:
Error:Found error in 2|Microsoft.ACS.Linux.Universal|7.7.1124.0|Microsoft.ACS.Linux.Universal|| with message:

Could not load management pack <ID=Microsoft.Linux.Universal.Library, KeyToken=31bf3856ad364e35,
Version=7.7.1103.0>. The management pack was not found in the store.
: Version mismatch. The management pack (<Microsoft.Linux.Universal.Library, 31bf3856ad364e35, 7.6.1064.0>)
requested from the database was version 7.7.1103.0 but the actual version available is 7.6.1064.0.
The upgrade failure will cause setup to roll back and leave the management server in an inconsistent state where
the feature will need to be reinstalled.
Workaround: Before performing the upgrade of the management server, upgrade
Microsoft.Linux.Universal.Library management pack or delete the ACS management pack in the management
group.
Next steps
What's new in Operations Manager
What's New in Operations Manager
21 minutes to read
This article details the new features supported in System Center 2019 - Operations Manager.
New features in Operations Manager 2019

See the following sections for detailed information about the new and updated features in System Center 2019 -
Operations Manager. Features and updates introduced in Operations Manager version 1801 and 1807 are
included in version 2019.
Service log on is enabled by default in Operations Manager 2019

Operations Manager 2019 supports hardening of service accounts and does not require Interactive and Remote
Interactive Log On rights for service accounts.
Operations Manager 2019 uses Service Log on as the logon type, by default. Learn more.
Improved experience for HTML5 dashboard

The Web console has been redesigned and is now a fully functional HTML -based console, and no longer has a
dependency on Silverlight. The new dashboards have been redesigned with:
Modern user interface
Simplified widget and dashboard authoring
Accessible from multiple browsers
Enhanced troubleshooting experience with drill-down pages
Extensibility with a custom widget using a new REST API
Capability to export and share dashboards
New All option to select all objects while creating/editing Alerts widget.
Network authentication is enabled with the enhanced web console. Learn more.
Enhanced experience for alerts raised by monitors

The alert closure experience for the alerts generated by a monitor has been revamped to be more meaningful and
impactful to your service availability goals.
When you view an alert's detail in alerts view, you can see whether the alert was generated by a rule or a monitor.
If the alert was generated by a monitor, as a best practice, you should allow the monitor to auto resolve the alert
when the health state returns to healthy.
In earlier versions of Operations Manager, if you closed the alert while the object is in a warning, critical or
unhealthy state, the problem remains unresolved, and no further alerts are generated unless the health state for
the monitor has also been reset, which again is a manual task.
This behavior, which often led to closure of critical alerts without resolving the underlying problem, is fixed with
Operations Manager 2019. An alert generated by a monitor cannot be closed unless the health state of the
corresponding monitor is healthy.
Notifications and subscriptions enhancement

The existing alert notifications and subscription experience in Operations Manager has been enhanced to deliver
more value to the end user. These enhancements can be broadly categorized into the following two areas:
Intuitive Email notifications - Operations Manager 2019 supports email notifications in HTML format.
Learn more.
Enhanced Criteria Builder - You may now use the regular expressions to build a complex yet useful
subscription criteria. Learn more.
Management server failover support for Linux and UNIX monitoring

Failover of the management server in a resource pool supporting monitoring of a workload ensures high
availability and fault tolerance. In earlier versions of Operations Manager, when a primary management server
fails and another management server takes over the role of the primary management server in the pool, the
existing monitor-based alerts in Operations Manager are closed and new alerts are created for the same condition.
In deployments where the Operations Manager is integrated with an incident management system, these new
alerts lead to new tickets or incidents being created.
This issue of alerts/tickets being created during failover or load balancing of management server has been
addressed in Operations Manager 2019. With this fix, when the primary management server fails over, the alerts
do not get recreated. Only the repeat count of the existing alerts is incremented.
Linux agent installation changes

With Operations Manager 2019, there are changes in the Linux agent package bundling. This bundle now consists
of scx and omi shell bundles only. Post agent installation, a new user called omi will be created on the agent
computer. If you want to use the Log Monitoring feature, you must install Linux Log Monitoring management
pack, provided in Operations Manager 2019.
This change is introduced to ensure omsagent user is created only when you use the Log File Monitoring feature.
Learn more.
To use the Log Monitoring feature, you must install the Linux Log Monitoring management pack, included in
Operations Manager 2019. Learn More.
Improvement in agent initiated maintenance mode

Agent initiated maintenance mode is a crucial feature to suspend monitoring when the monitored object is taken
offline for maintenance. With Operations Manager 2019, maintenance mode is triggered based on an event, as
opposed to being registry-based as used in earlier releases. With the registry-based approach, there was a
probability that a management server might not be able to read the agents registry before the agent computer is
shutdown. In such cases, false alerts are generated.
With event-based agent-initiated maintenance mode, as events are almost real time, a management server
immediately reads the maintenance mode event from the agent computer and would never miss processing the
maintenance request.
NOTE
You can turn off your computer right after running this command. An event will notify the management server to suspend
monitoring on this computer.
Ability to enable scheduled maintenance mode with SQL Always on

Scheduled maintenance mode has been a feature of Operations Manager since the 2016 release. In earlier
releases, if Operations Manager deployments had SQL Always on enabled for high-availability, the schedules were
inaccessible when the SQL Server failover occurs in the availability group.
Operations Manager 2019 introduces a fix for this issue to ensure scheduled maintenance mode capability works
as expected, even when SQL Server failover occurs.
Microsoft Monitoring Agent operating system

The following versions of Windows operating system are supported for the Microsoft Monitoring Agent
connecting to Operations Manager:
Windows Server 2019 - Standard, Standard (Desktop Experience), Datacenter, Datacenter (Desktop
Experience), Server Core
Windows Server 2016 - Standard, Standard (Desktop Experience), Datacenter, Datacenter (Desktop
Windows Server 2012 R2 - Standard, Standard (Desktop Experience), Datacenter, Datacenter (Desktop
Windows Server 2012 - Standard, Datacenter, Server Core
Windows 10 - Enterprise, Pro
NOTE
Operations Manager 2019 supports only x64 agent.
File system: %SYSTEMDRIVE% must be formatted with the NTFS file system
Windows PowerShell version: Windows PowerShell version 2.0, or Windows PowerShell version 3.0
Microsoft .NET Framework: V3.5 or later.
New Linux operating systems support

The following new platforms are supported for monitoring in Operations Manager 2019. Learn more
SUSE Linux Enterprise Server 15
openSUSE Leap 15
Ubuntu 18
Debian 9
SUSE 12 PPC
HTML 5 Web Console - client browsers

For HTLM5 web console, the following client web browsers are supported:
Internet Explorer version 11
Microsoft Edge version 40 and later
Google Chrome version 67 and later
For additional requirements, see Operations Manager 2019 system requirements.
SQL Server 2017 support

Operations Manager 2019 supports a new installation of SQL server 2017.
The following versions of SQL Server Enterprise & Standard Edition are supported for a new or upgraded
installation of System Center 2019 - Operations Manager to host Reporting Server, Operational, Data Warehouse,
and ACS database:
SQL Server 2017 and Service Packs as detailed here
For information about SQL Server Design Considerations, see related documentation.
In-place upgrade
Operations Manager 2019 supports an in-place upgrade from the following versions:
System Center 2016 Operations Manager
URL monitoring enhancements for server certificate errors

The existing URL monitoring capability has been enhanced. With this improvement, Operations Manager will not
ignore the server certificate errors (like server certificate CN, expiry date, untrusted CA, and wrong usage) by
default. If you wish to monitor websites that do not have a valid SSL certificate, select Ignore Server Certificate
Errors checkbox in your Web application Properties. Learn more.
Updates and Recommendation feature for Linux

Updates and Recommendations feature, which was available for Windows workloads, is now extended for
Linux workloads. This feature helps you to proactively identify workloads, deployed on your Linux computers that
were not monitored by Operations Manager or are not monitored using the latest version of Management Pack
(MP ). Learn more.
If there are MPs in the catalog that are designed to monitor those workloads, they will be displayed on the
Updates and Recommendations page. You will also find a list of any updates that are available for the
management packs that are installed in your management group.
A new capability, Machine Details allow administrators to view the agent computer's name and the operating
system installed on it.
Support for latest Application Servers

Operations Manager 2019 supports latest Application Servers. Learn more.
Support for client-side monitoring on multiple browsers

With Operations Manager 2019, client-sider-monitoring supports the following web browsers in addition to
Internet Explorer:
Microsoft Edge (version 42 or higher)
Google Chrome (version 68 or higher)
Enhanced support for Application Performance Monitoring

Application Performance Monitoring can now monitor websites that are created with SharePoint 2016.
NOTE
The following features/feature updates were introduced in Operations Manager 1807, included in 2019.
Configure APM component during agent install or repair

You can now disable the APM component when you deploy the Operations Manager agent from Discovery
wizard in the console, when performing a repair of the agent from the Operations console, and similarly
controlling behavior when using the PowerShell cmdlets Install-SCOMAgent and Repair-SCOMAgent. Learn
more.
Linux log rotation

To prevent the SCX logs from growing and consuming all available free space on the system disk, a log rotation
feature is now available for the SCX agent. Learn more.
Operations Manager and Service Manager console coexistence

The Operations and Service Manager consoles, as well as PowerShell modules can be installed on the same
system.

On Linux platforms, OpenSSL 0.9.8 support is dropped, and added support for OpenSSL 1.1.0 to support TLS 1.2.
Auto detection of Pseudo FS and drop Enumeration

The UNIX and Linux agents have been enhanced to detect pseudo file system dynamically and ignore
enumeration.
NOTE
The following features/feature updates were introduced in Operations Manager 1801, included in 2019..
Linux monitoring
You can now use a Linux agent with FluentD support for log file monitoring at par with Windows Server. This
update provides the following improvements over previous log file monitoring:
Wild-card characters in log file name and path.
New match patterns for customizable log search like simple match, exclusive match, correlated match, repeated
correlation, and exclusive correlation.
Support for generic Fluentd plugins published by the fluentd community. Learn more.
System Center Visual Studio Authoring Extension (VSAE) support for

Visual Studio 2017
Visual Studio Authoring Extension (VSAE ) is now updated to be compatible with Visual Studio(VS ) 2017.
Management Pack (MP ) developers can continue using it with the latest version of Visual Studio to create custom
management packs and use one of the MP templates provided, or edit an existing MP.
Enhanced SDK client performance
We have introduced performance improvements in the Operations console that typically prevent the console from
responding while a new management pack is being imported or deleted, or a configuration change to an MP is
saved.
Linux Kerberos support

Operations Manager can now support Kerberos authentication wherever the WS -Management protocol is used by
the management server to communicate with UNIX and Linux computers, providing greater security by no longer
needing to enable basic authentication for Windows Remote Management (WinRM ).
Service Map integration

Service Map automatically discovers application components on Windows and Linux systems and maps the
communication between services. It automatically builds a common reference map of dependencies across your
servers, processes, and third-party services. Integration between Service Map and System Center Operations
Manager allows you to automatically create distributed application diagrams in Operations Manager that are
based on the dynamic dependency maps in Service Map. For more information on planning and configuring
integration, see Service Map integration with System Center Operations Manager.
Enter product key from the Operations console

In previous versions of Operations Manager, you had to upgrade from the evaluation version to a licensed version
using the PowerShell cmdlet Set-SCOMLicense after initial deployment of a new management group. Registering
the product key can now be performed during or after setup in the Operations console. The PowerShell cmdlet
Set-SCOMLicense has been updated to support registering the license key remotely from a management server.

The content in the following sections describe new features in System Center 1807 - Operations Manager.
NOTE
To view the bugs fixed and the installation instructions for Operations Manager 1807, see KB article 4133779.
Configure APM component during agent install or repair

In System Center Operations Manager version 1801 agent, the Application Performance Monitoring (APM )
feature could cause a crash with IIS Application pools and could crash the SharePoint Central Administration v4
application pool running .NET Framework 2.0, preventing it from starting. You can now disable the APM
component when you deploy the Operations Manager agent from Discovery Wizard in the console, when
performing a repair of the agent from the Operations console, and similarly controlling behavior when using the
PowerShell cmdlets Install-SCOMAgent and Repair-SCOMAgent.
Linux log rotation

To prevent the SCX logs from growing and consuming all available free space on the system disk, a log rotation
feature is now available for the SCX agent.
HTML5 Web console enhancements

The following improvements are provided in the Web console for version 1807:
Added the PowerShell widget
Includes an effective configuration widget in the Monitoring objects detail page showing the running rules and
monitors and override settings applied
Network node/network interface drill-down is now available as a tab when you select a network device and
drill-down to the Monitoring objects detailed page. It delivers the same experience as what is available in the
Operations console.
Alert widget enhancement includes an improved layout and presentation of alert details. You can modify the
resolution state and drill down to the Monitoring object details page for the alert source.
The monitoring tree can be hidden when a dashboard is integrated with SharePoint.
The size of the health icon can be changed in the Topology widget.
Managing maintenance schedules can be accomplished in the Web console matching the experience in the
Operations console.
User and operators can create dashboards in My Workspace.
Support for SQL Server 2017

With version 1807, upgrading from SQL Server 2016 to SQL Server 2017 is supported. To understand the
requirements and steps to successfully upgrade your Operations Manager version 1801 management group to
version 1807, review How to upgrade to Operations Manager version 1807.
Operations Manager and Service Manager console coexistence

The Operations and Service Manager version 1807 consoles, as well as PowerShell modules can be installed on
the same system.

On Linux platforms, OpenSSL 0.9.8 support is dropped and we have added support for OpenSSL 1.1.0.
Ubuntu 18 and Debian 9 support

These Linux platforms are added to our support matrix for monitoring UNIX and Linux computers.
Auto detection of Pseudo FS and drop Enumeration.

The UNIX and Linux agent has been enhanced to detect pseudo file system dynamically and ignore enumeration.

The contents in the following sections describe new features in System Center 1801 - Operations Manager.
Enter product key from the Operations console

In previous versions of Operations Manager, you had to upgrade from the evaluation version to a licensed version
using the PowerShell cmdlet Set-SCOMLicense after initial deployment of a new management group. Registering
the product key can now be performed during or after setup in the Operations console. The PowerShell cmdlet
Set-SCOMLicense has been updated to support registering the license key remotely from a management server.
Linux monitoring
You can now use a Linux agent with FluentD support for log file monitoring at par with Windows Server. This
update provides the following improvements over previous log file monitoring:
Wild-card characters in log file name and path.
correlation, and exclusive correlation.
Support for generic Fluentd plugins published by the fluentd community.
Improved HTML5 dashboarding experience

The Web console has been redesigned and is now a fully HTML -based console and no longer has a dependency on
Silverlight. The new dashboards have been redesigned with:
Modern user interface
Simplified widget and dashboard authoring
Accessible from multiple browsers
Enhanced troubleshooting experience with drill-down pages
Extensibility with a custom widget using a new REST API
Export and share dashboards
Network authentication is enabled with the new web console.
System Center Visual Studio Authoring Extension (VSAE) support for

Visual Studio 2017
Visual Studio Authoring Extension (VSAE ) is now updated to be compatible with Visual Studio(VS ) 2017.
Management Pack (MP ) developers can continue using it with the latest version of Visual Studio to create custom
management packs and use one of the MP templates provided, or edit an existing MP.
Enhanced SDK Client performance

We have introduced performance improvements in the Operations console that typically prevent the console from
responding while a new management pack is being imported or deleted, or a configuration change to an MP is
saved.
Updates and recommendations for third-party Management Packs

In System Center 2016, we released the MP Updates and Recommendations feature, which has been extended to
include discovery and downloads of third-party management pack updates, based on feedback from customers.
Linux Kerberos support

the management server to communicate with UNIX and Linux computers, providing greater security by no longer
needing to enable basic authentication for Windows Remote Management (WinRM ).
Service Map integration

Service Map automatically discovers application components on Windows and Linux systems and maps the
communication between services. It automatically builds a common reference map of dependencies across your
servers, processes, and third-party services. Integration between Service Map and System Center Operations
Manager allows you to automatically create distributed application diagrams in Operations Manager that are
based on the dynamic dependency maps in Service Map. For more information on planning and configuring
integration, see Service Map integration with System Center Operations Manager.

The content in the following sections describe the new features in System Center 2016 - Operations Manager.
Improve desktop console performance

With the release of System Center 2016 - Operations Manager, performance improvements have been
implemented with state and diagram views in the Operations console to improve load performance (these
improvements are in addition to the alert view optimizations).
Send E-mail notifications with external authentication

Operations Manager now supports sending notifications from an e-mail server, either within the organization or
external and configuring a Run As account to authenticate with that external messaging system.
Non Silverlight Web console (except Dashboard views)

With the release of System Center 2016 - Operations Manager, the Silverlight dependency is removed from all the
Web console views except Dashboard views. This feature provides the following value:
No more Silverlight prerequisite to access Operations Manager Web console
Operations Manager Web console can be accessed from multiple web browsers like Edge, Chrome, and Firefox
Performant experience
NOTE
Dashboard views are still dependent on Silverlight, which can be accessed through Internet Explorer with Silverlight plug in.
Access Schedule Maintenance Mode from Monitoring pane and

maintenance mode from client side
Schedule Maintenance mode is a feature released in System Center 2016 - Operations Manager to suspend
monitoring of an object during regular software or hardware maintenance activities, such as software updates or
hardware replacements. Entities can be put to maintenance in older versions of Operations Manager, but they
cannot be put into maintenance mode at a future time. The newly created Maintenance Mode Scheduling wizard
gives the ability to choose different types of entities to put into maintenance and to schedule maintenance at a
future time.
With the release of System Center 2016 - Operations Manager, Operators can access the “Maintenance
Schedules” feature from the monitoring pane without the dependency on administrators to schedule maintenance
at a future time. Server administrators can set the agent-managed computer in maintenance mode directly from
the computer itself, without needing to perform this from the Operations console. This can be performed with the
new PowerShell cmdlet Start-SCOMAgentMainteannceMode.
Management Pack Updates and Recommendations

Operations Manager can assess Microsoft and partner management packs. Operations Manager includes a new
feature called Updates and Recommendations, to help you proactively identify new technologies or components
(that is, workloads) deployed in your IT infrastructure that were not monitored by Operations Manager or are not
monitored using the latest version of a management pack. For more information about Updates and
Recommendations, see Management Pack Assessment.
Alert data management

With the release of System Center 2016 – Operations Manager, you get better visibility of the alerts being
generated in your management group, which helps you reduce alerts that you don't consider actionable or
relevant.
This feature provides the following benefits:
Identify the number of alerts each management pack has generated.
Identify the number of alerts generated by a monitor/rule with in each management pack.
Identify different source/s (along with alert count) which have generated an alert for a particular type of
alert.
Filter the data for the desired duration so that you can understand what was happening during a particular
period of time.
This information enables you to make informed decisions on tuning the thresholds or disabling the alerts,
which you consider noisy.
This feature is available for members of the Operations Manager Administrators role from the Tune Management
Packs screen in the Operations console.
Extensible network monitoring

In System Center 2016 - Operations Manager, included is a new tool that allows you to create a custom
management pack to monitor generic network devices (non-certified as of Operations Manager 2012 R2) and
include resource utilization metrics, such as processor and memory. Or you can create extended monitoring
workflows for an existing network device already monitored by your management group. This tool enables
customers to generate a management pack for their network devices to get extended network monitoring.
Additionally, this tool enables customers to add monitoring of additional device components such as fan,
temperature sensor, voltage sensor, and power supply.
Monitoring Nano Server and workloads

System Center 2016 – Operations Manager includes support to monitor Nano Server.
Discover a Nano Server and push Nano-compatible agent to the server from the console
Monitor Internet Information Services (IIS ) and Domain Name System (DNS ) roles
Supports ACS security audit event collection
Support Active Directory Integration for managing agent assignment
Deploy the Nano-compatible agent manually using a PowerShell script included in this release
Manage updating the Nano-compatible agent directly from the console as you do today with the Windows
agent, or manually on Nano Server using a PowerShell script included in this release
For specific instructions on how to configure System Center 2016 - Operations Manager to monitor Nano Server,
see Monitoring Nano Server.
Scalability improvement with Unix/Linux agent monitoring

Operations Manager includes improved scalability in how many Unix/Linux agents that can be monitored per
Management server. You can now monitor up to 2X the number of Unix/Linux servers per management server,
against the previously supported scale.
Operations Manager now uses the new Async Windows Management Infrastructure (MI) APIs instead of
WSMAN Sync APIs, which Operations Manager uses by default. To leverage this improvement, you need to create
the new Registry key “UseMIAPI” to enable Operations Manager to use the new Async MI APIs on management
servers monitoring Linux/Unix systems. Perform the following steps:
1. Open the Registry Editor from an elevated Command Prompt.
2. Create registry key UseMIAPI under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
Operations Manager\3.0\Setup.
If you need to restore the original configuration using the WSMAN Sync APIs, you can delete the UseMIAPI
registry key.
Extend Operations Manager with Operations Management Suite

With Microsoft Operations Management Suite you can extend your management capabilities by connecting your
Operations Management infrastructure to management and analysis services provided through your Azure
account. The main scenarios for connecting System Center 2016 - Operations Manager to Microsoft Operations
Management Suite include:
Configuration Assessment
Alert Management
Capacity Planning
For more information, review the Microsoft Operations Management Suite documentation.
Partner Program in Administration pane

Customers can view certified System Center Operations Manager partner solutions directly from the console.
Customers can obtain a view of the partner solutions and visit the partner websites to download and install the
solutions.
What’s new in System Center 2016 Operations Manager UNIX/Linux

monitoring
New Management Packs and providers for Apache HTTP Server and MySQL/MariaDB database server
monitoring.
The Operations Manager agents for UNIX and Linux include Open Management Infrastructure (OMI)
version 1.1.0. OMI is now packaged separately (in a package named omi) from the Operations Manager
agent providers (in a package named scx).
Shell command and script rules and monitors are multi-threaded in the agent and will run in parallel.
New UNIX/Linux Script templates have been added for:
Two-state monitors
Three-state monitors
Agent tasks
Performance-collecting rules
Alert-generating rules
These templates allow you to copy and paste a monitoring script into a template for simple integration with
Operations Manager monitoring. The script can be shell, perl, Python, Ruby, or any other script language with a
corresponding interpreter specified by the script’s shebang.
Recovery and diagnostic task templates are now available to create recovery and diagnostic tasks with shell
commands and scripts
Default credentials can now be used when discovery UNIX and Linux computers with the Discovery Wizard
or PowerShell
Discovery of logical disks (file systems) for UNIX and Linux agents can be filtered by file system name or
type. Discovery rule overrides can be used to exclude file systems that you do not wish to monitor.
Next steps
Know the system requirements for Operations Manager
Walkthrough Installing Operations Manager on a
Single Server
8 minutes to read
This walkthrough guides you through an installation of System Center - Operations Manager on a single server.
The features installed include the following:
Management server
Operations console
Web console
Reporting server
Prerequisites
You must ensure that your server meets the minimum supported configurations for System Center Operations
Manager. For more information, see System Requirements for System Center Operations Manager.
Required SQL Server Components
Database Engine Services - Full-Text and Semantic Extractions for Search (as called in SQL Server 2012 and
later)
Reporting Services - Native
To install the single server management group configuration
1. Log on to the server by using an account that has local administrative credentials.
2. On the System Center Operations Manager installation media, run Setup.exe, and then click Install.
3. On the Getting Started, Select features to install page select the Management server, Operations
console, Web console, and Reporting server features. To read more about each feature and its
requirements, click Expand all, or expand the buttons next to each feature. Then click Next.
4. On the Select installation location page, accept the default value, type in a new location, or browse to
one. Then click Next.
NOTE
For System Center 2016 - Operations Manager, the default path is C:\Program Files\Microsoft System Center
2016\Operations Manager. For current branch, the default path is C:\Program Files\Microsoft System
Center\Operations Manager.
5. On the Prerequisites page, review and resolve any warnings or errors, and then click Verify Prerequisites
Again to recheck the system.
NOTE
Installation of the web console requires that ISAPI and CGI Restrictions in IIS be enabled for ASP.NET 4. To enable this,
select the web server in IIS Manager, and then double-click ISAPI and CGI Restrictions. Select ASP.NET v4.0.30319,
and then click Allow.
6. If the Prerequisites checker does not return any warnings or errors, the Prerequisites, Proceed with
Setup page appears. Click Next.
7. On the Configuration, Specify an installation option page, select Create the first Management
server in a new management group, type in a name for your management group and then click Next.
NOTE
After the management group name is set, it cannot be changed. The Management Group name cannot contain the
following characters:, ( ) ^ ~ : ; . ! ? " , ' ` @ # % \ / * + = $ | & [ ] <>{}, and it cannot have a leading or trailing space.
It is recommended that the Management Group name be unique within your organization if you plan to connect
several management groups together.
8. On the Configuration, Please read the license terms page, review the Microsoft Software License Terms,
select I have read, understood, and agree with the license terms, and then click Next.
9. When the Configuration, Configure the operational database page opens, in the Server name and
instance name box, type the name of the server and the name of the SQL Server instance for the database
server that will host the operational database. If you installed SQL Server by using the default instance, you
only have to enter the server name. If you changed the default SQL Server port, you must type in the new
port number in the SQL Server port box.
If you type an invalid SQL Server and instance name, you see a red circle with a white X in it appear to the
left of the Server name and instance name and SQL Server port.
The white X appears under the following circumstances:
You entered an instance of SQL Server or a SQL Server port value that is not valid or that does not
exist.
The instance of SQL Server that you specified does not have the required configuration or features.
You entered a value that is out-of-range (for example, port 999999).
You entered an illegal character for that box (for example, server\instance%)
You can hover the cursor over the Server name and instance text box to view additional
information about the error.
10. After you type the correct value for the SQL Server database server name, click the SQL Server port box so
that Setup will attempt to validate the values you typed for the SQL Server name and for the port number.
11. In the Database name, Database size (MB )Data file folder, and Log file folder box, we recommend
that you accept the default values. Click Next
NOTE
These paths do not change if you connect to a different instance of SQL Server.
IMPORTANT
You might receive a message about having the wrong version of SQL Server, or you might encounter a problem with
the SQL Server Windows Management Instrumentation (WMI) provider. To resolve this problem, open a Command
Prompt window, select Run as administrator, and then run the following command. In the command, replace the
<path> placeholder with the location of SQL Server:
mofcomp.exe “<path>\Microsoft SQL Server\100\Shared\sqlmgmproviderxpsp2up.mof”
NOTE
The SQL Server model database size must not be greater than 100 MB. If it is, you might encounter an error in Setup
regarding the inability to create a database on SQL due to user permissions. To resolve the issue, you must reduce
the size of the model database.
12. When the Configuration, Configure the data warehouse database page opens, in the Server name
and instance name box, type the server name and the name of the instance of SQL Server for the
database server that will host the data warehouse database.
13. Because this is a single-server installation, accept the default value of Create a new data warehouse
database.
14. In the Database name, Database size (MB )Data file folder, and Log file folder boxes, we recommend
that you accept the default values. Click Next.
IMPORTANT
<path> placeholder with the location of SQL Server:
mofcomp.exe “<path>\Microsoft SQL Server\100\Shared\sqlmgmproviderxpsp2up.mof”.
NOTE
15. On the Configuration, SQL Server instance for reporting services page, select the SQL Server
database instance from the drop-down list. This drop-down list contains the SQL Server database instance
name that was created when you installed SQL Server 2014 Service Pack 2 or SQL Server 2016 and should
be the name of the server on which you are installing System Center 2016 - Operations Manager. Click
Next.
16. On the Configuration, Specify a web site for use with the Web console page, select Default Web Site
or the name of an existing website. Select the option Enable SSL only if the website has been configured to
use SSL, and then click Next.
17. On the Configuration, Select an authentication mode for use with the Web console page, select your
option, and then click Next.
18. On the Configuration, Configure Operations Manager accounts page, we recommend that you use
Domain Account option for the Management Server Action Account, System Center Configuration
service and System Center Data Access service, the Data Reader account, and the Data Writer
account.
Enter the credentials for a domain account in each field. The error icon will disappear after account
validation. Click Next.
19. On the Configuration, Diagnostic and Usage Data page, review the information and then click Next.
20. If Windows Update is not activated on the computer, the Configuration, Microsoft Update page appears.
Select your options, and then click Next.
21. Review the options on the Configuration, Installation Summary page, and click Install. Setup continues.
22. When Setup is finished, the Setup is complete page appears. Click Close and the Operations console will
open.
To install the Operations Manager single server management group configuration from the Command Prompt
2. Open the Command Prompt by using the Run as Administrator option.
NOTE
Setup.exe requires administrator privileges because the Setup process requires access to system processes that can
only be used by a local administrator.
3. Change the path to where the System Center Operations Manager setup.exe file is located, and run the
following command.
IMPORTANT
Use the /WebConsoleUseSSL parameter only if your website has Secure Sockets Layer (SSL) activated.
For a default web installation, specify Default Web Site for the /WebSiteName parameter.
IMPORTANT
The following command assumes that you specified the Local System for the Management server action account (
/UseLocalSystemActionAccount ) and Data Access service ( /UseLocalSystemDASAccount ). To specify a domain\user
name for these accounts, you must provide the following parameters instead.
/ActionAccountUser: <domain\username> /ActionAccountPassword: <password>
/DASAccountUser: <domain\username> /DASAccountPassword: <password>

setup.exe /silent /install
/components:OMServer,OMConsole,OMWebConsole,OMReporting
/ManagementGroupName: "<ManagementGroupName>"
/SqlServerInstance: <server\instance>
/SqlInstancePort: <SQL instance port number>
/DatabaseName: <OperationalDatabaseName>
/DWSqlServerInstance: <server\instance>
/DWSqlInstancePort: <SQL instance port number>
/DWDatabaseName: <DWDatabaseName>
/UseLocalSystemActionAccount /UseLocalSystemDASAccount
/DatareaderUser: <domain\username>
/DatareaderPassword: <password>
/DataWriterUser: <domain\username>
/DataWriterPassword: <password>
/AcceptEndUserLicenseAgreement: [0|1]
/WebSiteName: "<WebSiteName>" [/WebConsoleUseSSL]
/WebConsoleAuthorizationMode: [Mixed|Network]
/SRSInstance: <server\instance>
/SendODRReports: [0|1]
/EnableErrorReporting: [Never|Queued|Always]
/SendCEIPReports: [0|1]
/UseMicrosoftUpdate: [0|1]
Verifying the installation

To confirm the health of the management server
1. In the Operations console, select the Administration workspace.
2. In Device Management select Management Servers. In the results pane, you should see the
Management server that you just installed with a green check mark in the Health State column.
To confirm the health of Operations Manager reports
1. In the Operations console, in the navigation pane, click the Reporting button.
NOTE
After initial deployment, it can take up to 30 minutes for reports to appear.
2. Click Microsoft ODR Report Library, and then double-click any of the reports listed. The selected report is
generated and displays in a new window.
By default, you should see the following reports:
Alerts Per Day
Instance Space
Management Group
Management Packs
Most Common Alerts
NOTE
Selecting the Management Packs report is particularly useful at this point because it provides you with a full
inventory of the management packs that have been installed on your server.
3. Close the report window.

Next steps
Now that you have installed System Center Operations Manager, you can deploy agents and start monitoring your
applications, servers, and network devices. For more information, see Agent deployment planning and Operations
Manager Monitoring Scenarios.
Installing Operations Manager from the Command
Prompt
3 minutes to read
You can install features of Operations Manager by using the setup.exe command in the Command Prompt
window. Gateway and agent installations require the use of MOMGateway.msi and MOMAgent.msi. You must
ensure that all servers meet the minimum supported configuration requirements for System Center Operations
Manager. For more information, see System Requirements.
Command-line parameters
The following table lists the command-line parameters for installing features of Operations Manager.
NOTE
If the parameter contains a colon, a value is required. Otherwise, it is simply a switch.
PARAMETER VALUE
/silent Does not display the installation wizard.
/install Runs an installation. Use /components to indicate specific

features to install.
/InstallPath Runs an installation specifying an alternative location, to

Change the default path for install to another drive. For
example:
/InstallPath: "D:\Program Files\System
Center\Operations Manager"
to change from the default location of drive C.
/components OMServer: install a management server.
OMConsole: install an Operations console.
OMWebConsole: install a web console.
OMReporting: install a Reporting server.
/ManagementGroupName: The name of the management group
/ManagementServicePort: Change the Management Server port on install
/SqlServerInstance: The SQL server and instance <server\instance> or Always

On availability group listener.
/SqlInstancePort: The SQL server instance port number.
/DatabaseName: The name of the Operational database.

PARAMETER VALUE
/DWSqlServerInstance: The data warehouse server and instance <server\instance>

or Always On availability group listener.
/DWSqlInstancePort: The SQL server instance port number.
/DWDatabaseName: The name of the data warehouse database.
/UseLocalSystemActionAccount Used to specify the Local System for the Management server
action account.
/ActionAccountUser: The domain and user name of the Management server action
account.
Used if you do not want to specify the Local System
/ActionAccountPassword: The password for the Management server action account.
Used if you do not want to specify the Local System.
/UseLocalSystemDASAccount Used to specify the Local System for the Data Access service
account.
/DASAccountUser: The domain and user name of the Data Access service
account.
/DASAccountPassword: The password for the Data Access service account.
/DataReaderUser: The domain and user name of the data reader account.
/DataReaderPassword: The password for the data reader account.
/DataWriterUser: The domain and user name of the data writer account.
/DataWriterPassword: The password for the data writer account.
/EnableErrorReporting: Never: Do not opt in to sending automatic error reports.
Queued: Opt in to sending error reports, but queue the

reports for review before sending.
Always: Opt in to automatically send error reports.
/SendCEIPReports: 0 : Do not opt in to the Customer Experience Improvement

Program (CEIP).
1 : Opt in to CEIP.
/UseMicrosoftUpdate: 0 : Do not opt in to Microsoft Update.
1 : Opt in to Microsoft Update.

PARAMETER VALUE
/AcceptEndUserLicenseAgreement: 0 : Do not accept the End User License Agreement (EULA).
1 : Accept the End User License Agreement (EULA).
When performing a clean installation of System Center

Operations Manager, this switch is needed for all management
servers. It is also needed for other scripted installations.
/ManagementServer Used to specify the name of the management server

associated with a web console and/or Reporting server that is
not installed on a management server.
/WebSiteName: The name of the website. For default web installation, specify
"Default Web Site".<br
Used for web console installations.
/WebConsoleUseSSL Specify only if your website has Secure Sockets Layer (SSL)
activated.
/WebConsoleAuthorizationMode: Mixed: Used for intranet scenarios.
Network: Used for extranet scenarios.
/SRSInstance The reporting server and instance (<server\instance>).
Used for Reporting Server installations.
/SendODRReports: 0: Do not opt in to sending operational data reports.
1: opt in to sending operational data reports.
Used for Reporting Server Installations.
/uninstall Uninstalls Operations Manager. Use /components to indicate

specific features to uninstall. If /components is not specified,
it will uninstall all features of Operations Manager on the
server.
Next steps
See Distributed Deployment of Operations Manager to understand the sequence and steps for installing each
one of the features across multiple servers in your management group.
Enable Service Log on for run as accounts
3 minutes to read
Security best practice is to disable interactive and remote interactive sessions for service accounts. Security teams,
across organizations have strict controls to enforce this best practice to prevent credential theft and associated
attacks.
System Center 2019 - Operations Manager supports hardening of service accounts and does not require granting
the Allow log on locally user right for several accounts, required in support of Operations Manager.
Earlier version of Operations Managers has Allow log on locally as the default log on type. Operations Manager
2019 uses Service Log on by default. This leads to the following changes:
Health service uses log on type Service by default. Operations Manager 1807 and earlier versions, it was
Interactive.
Operations Manager action accounts and service accounts now have Log on as a Service permission.
Action accounts and Run As accounts must have Log on as a Service permission to execute
MonitoringHost.exe. Learn more.
Changes to Operations Manager action accounts

The following accounts are granted Log on as a Service permission during the Operations Manager 2019
installation, and during upgrade from previous versions:
Management Server Action account
System Center configuration service and System Center data access service accounts
Agent action account
Data Warehouse Write account
Data Reader account
After this change, any Run As accounts created by Operations Manager administrators for the management
packs (MPs) require the Log on as a Service right, which administrators should grant.
View log on type for management servers and agents

You can view the log on type for management servers and agents from the Operations Manager console.
To view the log on type for management servers, go to Administration > Operations Manager Products>
Management servers.
To view the log on type for agents, go to Administration > Operations Manager Products> Agents.
NOTE
Agent/gateway that is not yet upgraded, display Log on type as Service in console . Once the agent/gateway is upgraded,
the current log on type will be displayed.
Enable service log on permission for Run As accounts

Follow these steps:
1. Sign in with administrator privileges to the computer from which you want to provide Log on as Service
permission to a Run As accounts.
2. Go to Administrative Tools and click Local Security Policy.
3. Expand Local Policy and click User Rights Assignment.
4. In the right pane, right-click Log on as a service and select Properties.
5. Click Add User or Group option to add the new user.
6. In the Select Users or Groups dialogue, find the user you wish to add and click OK.
7. Click OK in the Log on as a service Properties to save the changes.
NOTE
If you are upgrading to Operations Manager 2019 from a previous version or installing a new Operations Manager 2019
environment, follow the steps above to provide Log on as a service permission to Run As accounts.
Change log on type for a health service

If you need to change the log on type of Operations Manager health service to Allow log on locally, configure the
security policy setting on the local device using the Local Security Policy console.
Here is an example:
Coexistence with Operations Manager 2016 agent
With the log on type change that is introduced in Operations Manager 2019, the Operations Manager 2016 agent
can coexist and interoperate without any issues. However, there are a couple of scenarios that are affected by this
change:
Push install of agent from the Operations Manager console requires an account that has administrative
privileges and the Log on as a service right on the destination computer.
Operations Manager Management Server action account requires administrative privileges on management
servers for monitoring Service Manager.
Troubleshooting
If any of the Run as accounts do have the required Log on as a Service permission, a critical monitor-based alert
appears. This alert displays the details of the Run As account, which does not have Log on as a Service
permission.
On the agent computer, open Event Viewer. In the Operations Manager log, search for the event ID 7002 to view
the details about the Run As accounts that require Log on as a Service permission.
PARAMETER MESSAGE
Alert Name Run As account does not have requested log on type.
Alert Description The Run As account must have the requested log on type.
Alert Context Health Service could not log on, as the Run As account for
management group (group name) has not been granted the
Log on as a service permission.
Monitor (add monitor name)
Provide Log on as a Service permission to the applicable Run As accounts, which are identified in the event
7002. Once you provide the permission, event ID 7028 appears and the monitor changes to healthy state.
Manage telemetry settings in Operations Manager
5 minutes to read
This article provides information about how to manage the telemetry (Diagnostics and utility data) settings in
System Center - Operations Manager (SCOM ).
By default, Operations Manager sends diagnostic and connectivity data to Microsoft. Microsoft uses this data to
provide and improve the quality, security, and integrity of Microsoft products and services.
Administrators can turn off this feature at any point of time. Learn more about data collected by Operations
Manager
Turn on/off telemetry from console

1. In the Operations Manager console, click Settings in the Administration pane.
2. Under Type: General, double-click Privacy.
Diagnostic and Usage Data Settings options page appear.

3. Select the diagnostic and usage data sharing preference from the options displayed, and click OK.
NOTE
We recommend you to read the Privacy Statement before you select the option.
To turn on telemetry, select Yes, I am willing to send data to Microsoft.
To turn off telemetry, select No, I prefer not to send data to Microsoft.
Telemetry data collected

DATA RELATED TO DATA COLLECTED
Setup Version of installed SCOM
Version of the installed SCOM update rollup on different

SCOM core components
SCOM management group identifier (To weed out duplicates)
Unique machine identifier
Operating system on which different SCOM core components

are launched
Language of the SCOM installation
CPU and memory values of different SCOM servers
Number of SCOM web servers installed
Is reporting server installed
Is ACS installed
Number of gateways in the SCOM environment
Number of management servers in the SCOM environment
Is Operational Insights account setup
Device monitoring Number of Unix/Linux computers monitored
Number of Windows computers monitored
Number of network devices monitored
Unix/Linux favors monitored
Network devices being monitored - their type, model number,

and certification status
Number of applications for which APM is active
Type of workloads for which APM is enabled
Number of distributed applications
Number of computers on which ACS is implemented
Maximum number of concurrent Web console sessions
Number of new SSRS reports present
Number of uncanned SSRS reports present
Frequency of canned reports use
Frequency of each PowerShell command use
Features used in the administration console
Complete Heatmap
Management packs Number of management packs in the SCOM environment
Number of non-Microsoft signed packs
Management packs installed/version/manufacturer (Microsoft

and NonMicrosoft)
Table names and row counts in the operational database
Table names and row counts in the data warehouse database
Details of partner products installed
Details of the Microsoft MP import failures and error involved
SCOM Console Time taken for the windows console to launch
Time taken for each of the monitoring screens to launch
Time taken for each of the administration screens to launch
Number of times network vicinity dashboard is launched
Number of times the data warehouse jobs are failing
Number of times the web console is being launched
Number of times the Maintenance mode task and SMM SDK

calls are made for create and edit to determine adoption of
new feature
Updates and recommendations Number of times the Updates and Recommendations link
clicked/refreshed
Number of times the online catalog was down while loading

Updates and Recommendations view
Time taken to load the Updates and Recommendations view
Number of workloads in Updates and Recommendations view

has Updates available status

have Not installedstatus

has Partially installed status
Number of workloads shown in Updates and

Recommendation
Number of times Get MP link is clicked in Updates and

Recommendations view
Number of times Get All MPs link is clicked in Updates and

Number of times View Guide link is clicked in Updates and

Workload selected in Get MP call in Updates and

Workloads selected in Get All MPs call in Updates and

Workload install status in Get MP call in Updates and

Workloads install status in Get All MPs call in Updates and

Time taken to install workload in Get MP call in Updates and

Recommendationsview
Time taken to install workloads in Get All MPs call in Updates

and Recommendations view
Is the installation fresh or upgrade
TotalSetuptimeInMinutes
Is setup silent
Is error reporting enabled
Is the Microsoft update true or false
Is the setup 64 bit
SetupDefaultInstallPath
Install result - success or failure

Database Whether the management server installation is fresh or
upgrade
Whether the database (DB) installation is fresh or upgrade
Whether the data warehouse (DW) installation is fresh or

upgrade
Default DB Name
DB Size in MB
DB Port
Is DB Local
DW Port
Is DW local
Is the SDK service using the local system account
Is the agent using the local system account
Console Settings Web console default website
Web console authorization mode
Web console SSL enabled
Count of maintenance schedules
Count of active alerts
User role
Console version
If users are enabling daily health report
If users are enabling computer discovery
If users are discovering entire domain, or the selected one
If users are enabling Auto-Select for updates
Telemetry on/off notifications
Click count on Tune Management Pack View
Click count, total days, minimum alert count, and total result
set
Click count, MP name, alert name, and alert count
Click count of View or edit the settings of this monitor
Click count of View or override sources
Click count, source MP name and override MP name
Nano servers count (not applicable for SCOM 1801)

Alert view click count
Health explorer click count on alert view action menu
Open command window click count on alert view action menu
Start maintenance mode click count on alert view action menu
End maintenance mode click count on alert view action menu
Edit maintenance mode click count on alert view action menu
Time spent on alert view
Total number of items displayed on alert view
Performance view click count
Time spent on performance view
State view click count
Time spent on state view
Total number of items displayed on state view
Data collected through UTC

SQL configuration of the SCOM environment (version/SP version/SQL Always ON/Cluster)
Microsoft alerts that are marked as not useful and the reason
Number of widgets, views, dashboards created in Monitoring pane
Number of dashboards in My Workspace
Time taken to load the Scheduled Maintenance summary screen
Average number of entities that are set to maintenance mode through Maintenance mode task and Scheduled
Maintenance mode screen
System Center ID the SCOM environment reside in
Selected features
HTML5 dashboards data collected through App Insights
All API exceptions
User feedback
Edited widget
Authored widget
launched widget
Action clicked
Personalized widget
Instances when action View in Full Screen is clicked
Dashboard edits
Instances of drill-down page launch
Instances of task pane launch
Instances of My Workspace launch
Usage of Windows Authentication
Usage of Alternate Credentials
Instances of Add to MyWorkspace action
Count of alerts per widget
Count of performance legends per widget
Count of rows per state widget
Count of icons in topology widget
Widget count in a dashboard
Next steps
Plan agent deployment
Operations Manager Planning Guide
2 minutes to read
By deploying System Center Operations Manager in your environment, you can provide your organization with a
monitoring service that ensures IT and business service owners are able to effectively monitor and report on the
availability and performance metrics of their services across on-premises, service provider, and cloud
environments. After you identify the deployment tasks and current environment for your organization, you can
create the Operations Manager deployment strategy that meets your organization’s service operations needs.
About this guide

This guide provides recommendations to help you develop an Operations Manager deployment strategy based on
the requirements of your organization and the particular design that you want to create. This guide is intended for
use by infrastructure specialists or system architects. Before you read this guide, you should have a good
understanding of how Operations Manager works on a functional level. You should also have a good
understanding of the organizational and business requirements that need to be considered in your deployment
strategy.
This guide describes sets of tasks for several possible starting points of a System Center Operations Manager
deployment. The guide helps you determine the most appropriate deployment strategy for your environment.
The strategies that are presented in this guide are appropriate for many common Operations Manager
deployments, and they have been tested and validated for environments that contain up to the capacity limits
stated in the System Requirements article.
Planning guide topics

System Requirements for Operations Manager
Provides information about the supported operating systems, hardware configurations, software
requirements, installation combinations, and other important design planning considerations that are
summarized and recommended for Operations Manager.
Supported Versions of Linux and UNIX
Provides the supported and required UNIX and Linux operating systems and package dependencies for
Operations Manager.
Review the Cloud Monitoring guide
Provides information to help you plan your cloud monitoring strategy, which includes monitoring platform
considerations and recommendations, in order to effectively monitor workloads transitioning to Azure.
Planning a Management Group Design
Describes the components that an Operations Manager management group is composed of, such as a
management server, a SQL Server hosting the operational and data warehouse databases, and the
Operations Manager Operations console. This section also includes important design considerations for
each component.
SQL Server Design Considerations
Describes the most appropriate high availability, disaster recovery, and performance configuration for SQL
Server hosting the Operations Manager databases in order to achieve optimal performance and scale in
medium to enterprise deployments.
Resource Pool Design Considerations
This section provides information to help you make design decisions and to understand the behavior and
deployment options with resource pools to provide high availability for the monitoring of network devices,
Linux and UNIX computers, and other workloads in Operations Manager.
Design for High Availability and Disaster Recovery
Describes the supported and most appropriate high availability and disaster recovery options for your
Operations Manager management group to maintain minimum functionality and continued operational
insight of the IT services monitored.
Integration with other enterprise management products
Integration with other ITSM management, monitoring solutions, or custom solutions that extend
Operations Manager to support your service operations framework are discussed with design
recommendations.
Monitoring Agent Overview and Deployment Considerations
Provides an overview of the Windows and UNIX/Linux agent and the software, security and deployment
requirements and considerations that you need to understand before proceeding with your deployment of
Operations Manager.
Security Design
This section provides you with security-related information as it pertains to the planning of security
accounts, roles and privileges required for your deployment of Operations Manager.
System requirements for System Center Operations
Manager
45 minutes to read
This article details the system requirements for System Center 2019 - Operations Manager.
System requirements for System Center 2019 - Operations Manager

The following sections describe general performance and scalability guidance for System Center 2019 -
Operations Manager. These sections also provide recommendations for hardware configurations for a variety of
workloads. Because System Center Operations Manager is built to be flexible and scalable, the hardware
requirements for specific scenarios may differ from the guidelines that are presented here. A discussion of the
factors that affect the performance of each Operations Manager component is detailed in other sections of the
planning guide so that they can be adapted to specific requirements.
Capacity limits for Operations Manager

This information helps you understand the performance and scalability characteristics of the various Operations
Manager components supporting a management group.
MONITORED ITEM RECOMMENDED LIMIT
Simultaneous Operations consoles 50
Agent-monitored computers reporting to a management 3,000

server
Agent-monitored computers reporting to a gateway server 2,000
Agentless Exception Monitored (AEM)-computers per 25,000

dedicated management server

management group
Collective client monitored computers per management 2,500

server
Management servers per agent for multihoming 4
Agentless-managed computers per management server 10
Agentless-managed computers per management group 60
Agent-managed and UNIX or Linux computers per 6,000 (with 50 open consoles); 15,000 (with 25 open
management group consoles)
UNIX or Linux computers per dedicated management server 1,000

UNIX or Linux computers monitored per dedicated gateway 200

server
Network devices managed by a resource pool with three or 1,000

more management servers
Network devices managed by two resource pools 2,000
Agents for Application Performance Monitoring (APM) 700
Applications for Application Performance Monitoring (APM) 400
URLs monitored per dedicated management server 3,000
URLs monitored per dedicated management group 12,000
URLs monitored per agent 50
Upgrade sequence
If you are upgrading an installation of System Center 2016/1801/1807 - Operations Manager that is integrated
with one or more System Center components, it is important that you upgrade in the following order.
1. Orchestrator - if you have the Operations Manager integration pack installed to support runbooks that perform
automation against your Operations Manager management group.
2. Service Manager - if you configured the connectors to import alert and configuration item data of objects
discovered and monitored from Operations Manager.
3. Data Protection Manager - if you have configured the central console to centrally manage your DPM
environment.
4. Operations Manager
5. Virtual Machine Manager - if you have configured integration with Operations Manager to monitor the health
of your VMM components, the virtual machines and virtual machine hosts.
Hardware requirements
Use this information to evaluate if your hardware environment is ready to support the installation of or upgrade to
System Center 2019 - Operations Manager, considering the minimum hardware requirements for processor,
memory, and disk space. You should use the information here whether you are deploying one or multiple
components and for more specific information to help plan the amount of infrastructure needed for a new
Operations Manager deployment, see Operations Manager Sizing Helper
NOTE
While the Operations Manager 2012 Sizing helper has not been updated to reflect the 2016 and higher release of
Operations Manager, the information provided is still valid to help you estimate for your design requirements. However, the
number of UNIX/Linux computers per management and gateway server, as noted in the Unix or Linux Monitoring section
is not correct. The number of UNIX/Linux computers per server has increased and is noted in the monitored item capacity
table earlier in this article.
OPERATIONS MANAGER
SERVER ROLE X64 PROCESSOR (MIN) MEMORY (MIN) DISK SPACE (MIN)
Management Server 4-Core 2.66 GHz CPU 8 GB 10 GB
Gateway Server managing 4-Core 2.66 GHz CPU 8 GB 10 GB

up to 2000 agents
Gateway Server in resource 8-Core 2.66 GHz CPU 32 GB 10 GB

pool managing up to 500
network devices
Gateway Server in resource 4-Core 2.66 GHz CPU 4 GB RAM 10 GB

UNIX/Linux computers
Web Console server 4-Core 2.66 GHz CPU 8 GB 10 GB
SQL Server Reporting 4-Core 2.66 GHz CPU 8 GB 10 GB

Services server
Software requirements for Operations Manager components

Server operating system
The following versions of Windows Server operating system are supported for the following Operations Manager
components.
WINDOWS SERVER WINDOWS SERVER

2016 STANDARD, WINDOWS 2016 2019 STANDARD, WINDOWS SERVER
COMPONENT DATACENTER SERVER CORE DATACENTER 2019 SERVER CORE
Operations yes yes yes yes

Manager
Management Server

Manager Gateway
Server
Operations yes yes

Manager Web
Console
Operations yes yes

Manager ACS
Collector
Operations yes yes (with FOD) yes yes (with FOD)

Manager Operations
console

Manager
Operational, Data
Warehouse,
ACS database
WINDOWS SERVER WINDOWS SERVER
2016 STANDARD, WINDOWS 2016 2019 STANDARD, WINDOWS SERVER
COMPONENT DATACENTER SERVER CORE DATACENTER 2019 SERVER CORE
Operations yes yes

Manager Reporting
server
Operations Manager operational, data warehouse, and ACS audit database

Operating System: See Server Operating System requirements.
Microsoft SQL Server: See SQL Server Requirements.
Management server/Gateway server
Windows PowerShell version: Windows PowerShell version 2.0, or Windows PowerShell version 3.0.
Windows Remote Management: Windows Remote Management must be enabled for the management server.
.NET Framework 4 or .NET Framework 4.5 is required.
Operations Manager console
Microsoft Report Viewer 2015 runtime.
NOTE
Report Viewer has a dependency on Microsoft CLR Types for SQL Server 2014. The SQL Server System CLR Types package
contains the components implementing the geometry, geography, and hierarchy ID types in SQL Server 2014. This
component can be installed separately from the server to allow client applications to use these types outside of the server.

Web console
Client web browser for Silverlight-enabled dashboards: For backwards compatibility with Silverlight-
enabled dashboards, Internet Explorer 11 and Silverlight 5 is required.
NOTE
Operations Manager 2019 only includes the 64-bit version of the Operations console. The Web console does not
support running IE in Compatibility View, otherwise you will receive a blank page when attempting to access the
console. To turn off Compatibility View feature, please see How to use Compatibility View in Internet Explorer.
Client web browser for HTML5 web console:

Microsoft Edge version 40 and later
Google Chrome version 67 and later
Internet Information Services: IIS 7.5 and later versions with the IIS Management Console and the
following role services installed:
Static Content
Default Document
Directory Browsing
HTTP Errors
HTTP Logging
Request Monitor
Request Filtering
Static Content Compression
Web Server (IIS ) Support
IIS 6 Metabase Compatibility
ASP.NET (both the 3.5 and 4.5 or higher versions of ASP.NET are required.)
Windows Authentication
Selected website for web console: Requires a configured http or https binding.
NOTE
Installation of the web console requires that ISAPI and CGI Restrictions in IIS are enabled for ASP.NET 4. To enable this,
select the web server in IIS Manager, and then double-click ISAPI and CGI Restrictions. Select ASP.NET v4.0.30319, and
then click Allow.
Operations Manager reporting server

Remote Registry Service: Must be enabled and started.
Microsoft SQL Server Reporting Services: See SQL Server Requirements.
NOTE
System Center 2016 – Operations Manager and later supports SQL Server Reporting Services in native mode only;
do not use SharePoint integrated mode.
Client operating system

Windows 10 client operating system is supported for the Operations Manager 2019 Operations console.

NOTE
Operations Manager 2019 only includes the 64-bit version of the agent.

Windows Server 2012 R2 - Standard, Datacenter, Server Core
Windows Server 2012 – Standard, Datacenter, Server Core
Windows 10 - Enterprise, Pro
File system: %SYSTEMDRIVE% must be formatted with the NTFS file system.
Microsoft .NET Framework 3.5 or later.
NOTE
Windows PowerShell is required for local collection of IntelliTrace logs, and to run System Center Operations Manager
management packs that use PowerShell scripts. Microsoft .NET Framework 3.5 or later is required for local collection
of IntelliTrace logs and .NET Application Performance Monitoring.
Virtualization
Microsoft supports running all System Center 2019 – Operations Manager server features in any physical or
virtual environment that meets the minimum requirements that are stated in this document. There are some
restrictions on virtualization functionality that is applicable to Operations Manager. Specifically, Microsoft does not
support the use of the following virtualization functionality no matter what virtualization technology is used with
Operations Manager:
Virtual computers running any Operations Manager component must not make use of any functionality where
all activity on the virtual computer is not immediately committed to the virtual hard drive. This includes making
use of point-in-time snapshots, and writing changes to a temporary virtual hard drive.
Virtual computers running any Operations Manager component cannot be paused or placed into a ‘save state’
status and restarted. They can only be shut down and restarted just as would be done with a physical computer.
Virtual computers that are running Operations Manager components can be replicated to another virtualized
environment by using Azure Site Recovery. The virtualized environment referred here, can be either on on-
premises or Azure, and it would failover to this environment on account of any disaster.
If the Operations Manager databases are to be hosted on virtualized SQL Server(s), for performance reasons,
we recommend that you store the Operational database and data warehouse database on a directly attached
physical hard drive and not on a virtual hard disk.
System Center 2016 - Operations Manager and higher runs on virtual machines in Microsoft Azure just as it does
on physical computer systems. We recommend running Operations Manager on Microsoft Azure virtual machines
to monitor other virtual machines or resources hosted in Azure, or monitor instances and workloads hosted on-
premises. You can also run Operations Manager on-premises and monitor Microsoft Azure virtual machines or
other resources in Azure.
Supported coexistence
The following table lists the scenarios in which coexistence between Operations Manager 2019 and earlier
versions of Operations Manager is supported.
VERSION MANAGEMENT GROUP COEXISTENCE
Operations Manager 2016 RTM to the latest update rollup Yes
Operations Manager 1801 yes
Operations Manager 1807 yes
In-place upgrade
System Center 2019 - Operations Manager supports an in-place upgrade from the following versions:
System Center 2016
System Center 1801
System Center 1807
Active Directory and DNS

Operations Manager integrates with Active Directory for authentication, rights assignment, and authorization.
DNS is leveraged for name resolution of the supporting roles in the management group as well as computers,
network devices, and other monitored workloads such as web URLs.
Active Directory Domain Services
System Center Operations Manager relies on AD DS for a number of services, including definition of security
principles, rights assignment, authentication, and authorization. Operations Manager queries AD DS when
performing computer and service discovery and can use AD DS for storing and distributing agent configuration
information. For Operations Manager to function properly, AD DS and its supporting service, DNS, need to be
healthy and at certain minimum configuration levels. In addition, certain domain naming conventions must be
followed.
Domain space naming
An Operations Manager management group cannot be installed into a root Active Directory domain that has a flat
DNS namespace. However, you can install the management group into child domains of the root domain. For
example, you have a root domain that has a DNS name of "Woodgrove". Because this root domain has a flat DNS
namespace, you cannot install an Operations Manager management group into the Woodgrove domain. But, if the
Woodgrove domain has a child domain with a DNS name of "National", the fully qualified domain name of the
child domain would be national.woodgrove. For more information about configuring Windows for domains with
single-label DNS names, see Information about configuring Active Directory domains by using single-label DNS
names.
Domain functional level
Windows Server Active Directory can operate at different functional levels. These levels are distinguished by the
version of the Windows Server operating system that is permitted on the domain controllers present in the
domain. System Center Operations Manager does not have a domain functional level requirement.
Forest functional level
The forest functional level is similar to the domain functional level in that it sets a minimum domain controller
operating system level across the whole forest. After it is set, domain controllers with down-level operating
systems from lower functional levels cannot be introduced into the forest. Operations Manager does not have a
forest functional level requirement.
DNS
DNS must be installed and in a healthy state to support AD DS. Beyond the reliance of Operations Manager on
AD DS, there are no specific DNS requirements.
System requirements
This article describes general performance and scalability guidance for System Center - Operations Manager. It
recommends hardware configurations for a variety of workloads. Because System Center Operations Manager is
built to be flexible and scalable, the hardware requirements for specific scenarios may differ from the guidelines
that are presented here. A discussion of the factors that affect the performance of each Operations Manager
component is detailed in other sections of the planning guide so that they can be adapted to specific requirements.

server


management group

server

server

Upgrade sequence
If you are upgrading an installation of System Center 2012 R2 Operations Manager or System Center 2016 -
Operations Manager that is integrated with one or more System Center components, it is important that you
upgrade in the following order.
environment.
System Center 2016 - Operations Manager and higher, considering the minimum hardware requirements for
processor, RAM, and disk space. You should use the information here whether you are deploying one or multiple
Operations Manager deployment, refer to the Operations Manager 2012 Sizing Helper.
NOTE
OPERATIONS MANAGER

up to 2000 agents

network devices


Services server

components.
WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016

COMPONENT STANDARD, DATACENTER STANDARD, DATACENTER WINDOWS SERVER CORE 2016
Operations Manager yes yes yes

Management Server

Gateway Server
Operations Manager Web yes yes

Console
Operations Manager ACS yes yes

Collector
Operations Manager yes yes

Operations console

Operational, Data
Warehouse,
ACS database

Reporting server

The following versions of Windows client operating system are supported for the Operations Manager Operations
console.
WINDOWS 7 WINDOWS 8 WINDOWS 8.1 WINDOWS 10
yes yes yes yes

connecting to Operations Manager.
Windows Server 2019, Windows Server 2019 Server Core, Windows Server 2016, Windows Server 2016 Server
Core, Windows Server 2016 Nano Server, Windows Server 2012 R2, Windows Server 2012, Windows Server
2008 R2 Service Pack 1, Windows Server 2008 Service Pack 2, Windows 10, Windows 8 Enterprise, Windows 8
Pro, Windows Embedded POSReady 2009, Windows 7, Windows Embedded Standard 7 Service Pack 1.
Windows Server 2016, Windows Server 2016 Nano Server, Windows Server 2012 R2, Windows Server 2012,
Windows Server 2008 R2 Service Pack 1, Windows Server 2008 Service Pack 2, Windows 10, Windows 8
Enterprise, Windows 8 Pro, Windows Embedded POSReady 2009, Windows 7, Windows Embedded Standard 7
Service Pack 1.
Microsoft .NET Framework 3.5 or later
NOTE
management packs that use PowerShell scripts. Microsoft .NET Framework 3.5 or later is required for local collection of
IntelliTrace logs and .NET Application Performance Monitoring.

NET Framework 4 or .NET Framework 4.5 is required.
NOTE
Report Viewer has a dependency on Microsoft CLR Types for SQL Server 2014. The SQL Server System CLR Types
package contains the components implementing the geometry, geography, and hierarchy ID types in SQL Server
2014. This component can be installed separately from the server to allow client applications to use these types
outside of the server.

Web console
NOTE
The Web console does not support running IE in Compatibility View, otherwise you will receive a blank page when
attempting to access the console. To turn off Compatibility View feature, please see How to use Compatibility View in
Internet Explorer.

Microsoft Edge version 40 and higher
Google Chrome version 61 and higher
Firefox version 56 and higher
Internet Information Services: IIS 7.5 and later versions, with the IIS Management Console and the
Static Content
Default Document
Directory Browsing
HTTP Errors
HTTP Logging
Request Monitor
Request Filtering
The System Center 2012 R2 Operations Manager SharePoint Dashboard Viewer Web Part is supported on
SharePoint 2010 and SharePoint 2013. However, it is not supported on Office 365 SharePoint.
NOTE
then click Allow.

NOTE
System Center 2016 – Operations Manager and higher supports SQL Server Reporting Services in native mode only;
Virtualization
Microsoft supports running all System Center 2016 – Operations Manager and higher server features in any
physical or virtual environment that meets the minimum requirements that are stated in this document. There are
some restrictions on virtualization functionality that is applicable to Operations Manager. Specifically, Microsoft
does not support the use of the following virtualization functionality no matter what virtualization technology is
used with Operations Manager:
Operations Manager 2012 R2 Yes
Operations Manager 2012 R2 to the latest update rollup Yes
In-place upgrade
System Center 2016 Technical Preview 5 - Operations Manager
System Center 2012 R2 Operations Manager with Update Rollup 9
System Center Operations Manager supports an in-place upgrade from the following versions:
System Center 2012 R2 UR12 to the latest update rollup
System Center 2016 RTM to the latest update rollup

followed.
Domain space naming
names.
DNS
System requirements


server



management group

server

server

Upgrade sequence
environment.
NOTE
OPERATIONS MANAGER

up to 2000 agents

network devices


Services server

components.


Management Server

Gateway Server

Console

Collector

Operations console

Operational, Data
Warehouse,
ACS database

Reporting server

console.
yes yes yes yes

Service Pack 1.
NOTE

NOTE

Web console
NOTE
Internet Explorer.

Static Content
Default Document
Directory Browsing
HTTP Errors
HTTP Logging
Request Monitor
Request Filtering
NOTE
then click Allow.

NOTE
Virtualization
In-place upgrade

followed.
Domain space naming
names.
DNS
NOTE
you must install Operations Manager 1801 in order to upgrade to Operations Manager 1807. The system requirements
remain the same for 1801 and 1807 Operations Manager.
System requirements


server


management group

server

server

Upgrade sequence
environment.
NOTE
OPERATIONS MANAGER

up to 2000 agents

network devices


Services server

components.


Management Server

Gateway Server

Console

Collector

Operations console

Operational, Data
Warehouse,
ACS database

Reporting server

console.
yes yes yes yes

Service Pack 1.
NOTE

NOTE

Web console
NOTE
Internet Explorer.

Static Content
Default Document
Directory Browsing
HTTP Errors
HTTP Logging
Request Monitor
Request Filtering
NOTE
then click Allow.

NOTE
Virtualization
In-place upgrade

followed.
Domain space naming
names.
DNS
Next Steps
Plan installation
Supported UNIX and Linux operating system
versions
6 minutes to read
The following tables describe the required UNIX and Linux operating systems and package dependencies for
System Center 2019 - Operations Manager.
IBM AIX 7.1

REQUIRED PACKAGE DESCRIPTION MINIMUM VERSION
OS version Version of operating system 7100-01-06-1241
xlC.rte XL C/C++ Runtime 11.1.0.2
OpenSSL/openssl.base OpenSSL Libraries; Secure Network 1.0.0

Communications Protocol
IBM AIX 7.2

OpenSSL/openssl.base OpenSSL Libraries; Secure Network 1.0.0

Red Hat Enterprise Linux Server 7

glibc C Standard Libraries 2.17
Openssl OpenSSL Libraries; Secure Network 1.0.1e-fips

PAM Pluggable Authentication Modules 1.1.8-1
Red Hat Enterprise Linux Server 7 (Power)



PAM Pluggable Authentication Modules 1.1.8
Solaris 10 SPARC
SUNWlibC Sun Workshop Compilers Bundled libC 5.10, REV=2004.12.22
SUNWlibms Math & Microtasking Libraries (Usr) 5.10, REV=2004.11.23
SUNWlibmsr Math & Microtasking Libraries (Root) 5.10, REV=2004.11.23
SUNWcslr Core Solaris Libraries (Root) 11.10.0, REV=2005.01.21.15.53
SUNWcsl Core Solaris Libraries (Root) 11.10.0, REV=2005.01.21.15.53
SUNWopenssl-libraries SUNopenssl-libraries (Usr) 11.10.0, REV=2005.01.21.15.53
SUNWcsr Core Solaris (Root) 11.10.0, REV=2005.01.21.15.53
Release Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
Solaris 11 SPARC
SUNWcslr Core Solaris Libraries (Root) 11.11, REV=2009.11.11
SUNWcsl Core Solaris (Shared Libs) 11.11, REV=2009.11.11
SUNWcsr Core Solaris (Root) 11.11, REV=2009.11.11
SUNWopenssl-libraries OpenSSL Libraries (Usr) 11.11.0, REV=2010.05.25.01.00
Release Oracle Solaris 11 11/11 SPARC
Solaris UTF-8 Support

The Operations Manager agent requires Solaris UTF -8 code set conversion support under some circumstances.
Consult the Solaris documentation for details on installing UTF -8 code set conversion support. The Operations
Manager agent functions without UTF -8 support on Solaris, but unrecognized characters are translated to
question mark (?) characters.
glibc-2.19-17.72 C Standard shared library 2.19-17.72
PAM Pluggable Authentication Modules pam-1.1.8-11.57
OpenSSL OpenSSL Libraries; Secure Network 1.0

SUSE Linux Enterprise Server 12 (Power)




openSUSE Leap 15

Universal Linux (Debian package)

Debian 8, 9 and Ubuntu 16.04, 18.04 are supported
libc6 C Standard shared library 2.24-11

OpenSSL OpenSSL Libraries; Secure Network 1.0 or 1.1

PAM Pluggable Authentication Modules 1.1.8-3.1
Universal Linux (RPM package)

CentOS 6 and 7, Oracle Linux 6, 7 are supported
glibc C Standard shared library 2.5-12
OpenSSL OpenSSL Libraries; Secure Network 0.9.8 or 1.0

PAM Pluggable Authentication Modules 0.99.6.2-3.14
NOTE
Monitoring UNIX and Linux computers with System Center Operations Manager 2012 R2 management server is supported
when using the System Center 2016 - Operations Manager agent with the Operations Manager 2012 R2 UNIX and Linux
management packs. You cannot import the required Operations Manager 2016 management packs for the specific version
of UNIX/Linux and discover and deploy the Operations Manager 2016 agent from the Computer and Device
Management wizard in your 2012 R2 management group. This task must be performed manually following the command-
line based deployment.
IBM AIX 6.1

OpenSSL/openssl.base OpenSSL Libraries; Secure Network 0.9.8.1800

IBM AIX 7 (Power)

OpenSSL/openssl.base OpenSSL Libraries; Secure Network 0.9.8.1800

HP-UX 11i v3 IA64

HPUX11i-OE HP-UX Foundation Operating B.11.31.1109

Environment
OS-Core.MinimumRuntime.CORE- Specific IA development libraries B.11.31

SHLIBS
SysMgmtMin Minimum Software Deployment Tools B.11.31.1109
SysMgmtMin.openssl OpenSSL Libraries; Secure Network A.00.09.08q.003

PAM Pluggable Authentication Modules On HP-UX, PAM is part of the core

operating system components. There
are no other dependencies.

glibc C Standard Libraries 2.12-1.7
Openssl OpenSSL Libraries; Secure Network 1.0.0-4


glibc C Standard Libraries 2.12-1.7
Openssl OpenSSL Libraries; Secure Network 1.0.0-4



Red Hat Enterprise Linux Server 7 (Power)


PAM Pluggable Authentication Modules 1.1.8
Solaris 10 SPARC
SUNWlibms Math & Microtasking Libraries (Usr) 5.10, REV=2004.11.23
SUNWcsl Core Solaris Libraries (Root) 11.10.0, REV=2005.01.21.15.53
SUNWopenssl-libraries SUNopenssl-libraries (Usr) 11.10.0,REV=2005.01.21.15.53
Release Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
Solaris 10 x86
SUNWcsl Core Solaris (Shared Libs) 11.10.0, REV=2005.01.21.16.34

Release Oracle Solaris 10 9/10 s10x_u9wos_14a x86
Solaris 11 SPARC
Release Oracle Solaris 11 11/11 SPARC
Solaris 11 x86
Release Oracle Solaris 11 11/11 X86
Solaris UTF-8 Support

The Operations Manager agent requires Solaris UTF -8 code set conversion support under some circumstances.
Consult the Solaris documentation for details on installing UTF -8 code set conversion support. The Operations
Manager agent functions without UTF -8 support on Solaris, but unrecognized characters are translated to
question mark (?) characters.


Universal Linux (Debian package)

Debian, Ubuntu Server
libc6 C Standard shared library 2.3.6

PAM Pluggable Authentication Modules 0.79-3
Universal Linux (RPM package)

CentOS, Oracle Linux
glibc C Standard shared library 2.5-12

PAM Pluggable Authentication Modules 0.99.6.2-3.14

Planning a Management Group Design
16 minutes to read
Overview
A management group is identified by a single operational database, one or more management servers, and one or
more monitored agents and devices. Connecting management groups allows alerts and other monitoring data to
be viewed and edited from a single console. Tasks can also be initiated from a local management group to run on
the managed objects of a connected management group.
The simplest Operations Manager implementation is a single management group. Each additional group requires
at least its own operational database and management server. Each group must also be separately maintained with
its own configuration settings, management packs, and integration with other monitoring and ITSM solutions.
The distributed management group implementation will form the foundation of 99 percent of Operations
Manager deployments. It allows for the distribution of features and services across multiple servers to allow for
scalability and redundancy for some of those features. It can include all Operations Manager server roles and
supports the monitoring of devices across trust boundaries through the use of the gateway server.
The following diagram presents one possible option for the distributed management group topology.
NOTE
There is no direct communication between the Operations console and the databases. All communication is directed to a
specific management server over port TCP 5724, and then to the database servers using OLE DB on TCP 1433 or a user-
defined port specified by the SQL administrator during setup of the SQL Server database engine instance. However, there is
direct communication between an Application Diagnostics console (co-located with the Web console) and the SQL Server
hosting the operational and data warehouse databases.
A management group that you have deployed in your environment can integrate with Microsoft Operations
Management Suite (OMS ), and by utilizing Log Analytics, you can further correlate, visualize, and act on
performance, events, and alerts. This provides you with increased visibility by being able to perform custom
searches across the entire dataset in order to correlate data between systems and applications, hosted on-premise
or in the cloud.
Integration with Operations Manager extends to other products such as BMC Remedy, IBM, Netcool, or other
enterprise management solutions used by your organization. For more information about planning for
interoperability with these solutions, check out Integration with other management solutions.
Management group components

Management server
In Operations Manager 2007, the root management server (RMS ) was a specialized type of management server in
a management group, and was the first management server installed in a management group. The RMS was the
focal point for administering the management group configuration, administering and communicating with agents,
and communicating with the Operational database and other databases in the management group. The RMS also
served as the target for the Operations console and the preferred target for the Web consoles. In System Center
2012 R2 – Operations Manager, the root management server role was removed and all management servers are
now peers. This configuration continues to exist in System Center 2016 and later - Operations Manager.
The RMS is no longer a single point of failure as all management servers host the services previously hosted only
by the RMS. Roles are distributed to all the management servers. If one management server becomes unavailable,
its responsibilities are automatically redistributed. An RMS emulator role provides for backwards compatibility for
management packs targeting the RMS. If you do not have any management packs that previously targeted the
RMS, you will not need to make use of the RMS Emulator.
The management group can contain multiple management servers to provide additional capacity and continuous
availability. When two or more management servers are added to a management group, the management servers
automatically become part of the three default resource pools and work is spread across the members of the pool.
For custom defined resource pools, members are manually added. When a member of the resource pool fails,
other members in the resource pool will pick up that member’s workload. When a new management server is
added, the new management server automatically picks up some of the work from existing members in the
resource pool. Review Resource pool design considerations to learn more about how they function and
recommendations that influence your design plan.
If a management server is unavailable for any reason, by default agents that rely on it will automatically fail over to
another management server. When selecting the number and placement of management servers, this fail over
ability should be considered if high availability is a requirement.
Agents connect to a management server to communicate with all other Operations Manager components. Some
of the work performed by a management server is the process of taking the operational data sent by agents and
inserting it into the operational database and the data warehouse.
A typical management server will handle approximately 3,000 agents. Actual server performance varies according
to the volume of operational data collected; however, management servers typically can support 3,000 agents each,
even with a relatively high volume of operational data.
There is no limit on the maximum number of management servers per management group. However, it is best
practice to use as few management servers as possible after addressing scalability, high availability, and disaster
recovery constraints.
Management servers should have a good network connectivity to the Operations Manager database and data
warehouse because they frequently send large volumes of data to these stores. In general, these SQL Server
connections consume more bandwidth and are more sensitive to network latency. Therefore, all management
servers should be on the same local area network as the Operational database and the Data Warehouse database
and never deployed across a wide area network. There should be less than 10 milliseconds of latency between a
management server and SQL Server instance hosting the Operations Manager databases.
Gateway server
Operations Manager requires mutual authentication be performed between agents and management servers prior
to the exchange of information between them. To secure the authentication process between the two, the process is
encrypted. When the agent and the management server reside in the same Active Directory domain or in Active
Directory domains that have established trust relationships, they make use of Kerberos V5 authentication
mechanisms provided by Active Directory. When the agents and management servers do not lie within the same
trust boundary, other mechanisms must be used to satisfy the secure mutual authentication requirement.
Gateway servers are used when a firewall separates the agents from the management servers or when the agents
are in a separate, un-trusted domain. The gateway server acts as a proxy between the agents and the management
server. Without the gateway server, the agents could still perform certificate authentication with a management
server, but an X.509 certificate would need to be issued and installed on each agent using the MOMCertImport.exe
tool, and each would require access to the management server through the firewall. If the agents are in the same
domain as the gateway server or if they are in a trusted domain, they may use Kerberos authentication. In this case,
only the gateway server and the connected management servers will require certificates. This includes monitoring
of virtual machines running in Microsoft Azure Infrastructure as a Service (IaaS ), with Operations Manager (that is,
hybrid cloud monitoring) that are not joined to the same trusted realm as the roles supporting the Operations
Manager management group, or you have deployed Operations Manager in Azure IaaS (a virtual machine with
SQL Server hosting the operational databases and one or more virtual machines hosting the management server
role) and are monitoring un-trusted on-premise workloads.
The following presents an example Operations Manager deployment monitoring Azure IaaS resources.
The following is an example Operations Manager deployment hosted in Azure IaaS.
Typically gateway servers are not be used for managing bandwidth utilization because the overall volume of data
sent from agents to a management server is similar whether a gateway server is used or not. The intended
purpose of a gateway server is to reduce the effort required in managing certificates for agents in un-trusted
domains and to reduce the number of communication paths that must be allowed through firewalls.
Having more than 2,000 agents per gateway server can adversely affect the ability to recover in the event of a
sustained outage that prevents the gateway server from communicating with the management server. Multiple
gateway servers are recommended if more than 2,000 agents are required. The alternative, if gateway server
recovery time is a concern, is to test the system to make sure that the gateway server is able to quickly empty
its queue after a sustained outage between the gateway server and the management server. In addition, after
the incoming queue on the gateway server is filled, data in the queue is dropped according to its priority,
meaning that a sustained gateway server outage in this scenario could result in lost data.
When there are a large number of agents connected through gateway servers, consider using a dedicated
management server for all gateway servers. Having all gateway servers connect to a single management server
with no other agents connected to it can speed recovery time in the event of a sustained outage. The effective
load on the management server is the total number of agents reporting to it either directly or by way of
gateway servers.
To prevent the gateway server from initiating communication with a management server, including when
configured to failover between multiple management servers for high availability, the gateway Approval tool
includes the /ManagementServerInitiatesConnection command-line argument. This allows Operations
Manager to conform to a customer’s security policy when systems are deployed in a DMZ or other network
environment and communication can only be initiated from the intranet.
Web console server
The Web console provides an interface to the management group that is accessible via a Web browser. It does not
have the full functionality of the Operations console, however, and provides access to only the Monitoring and My
Workspace views. The Web console provides access to all the monitoring data and tasks that are actions that can
be run against monitored computers from the Operations console. Access to data in the Web console has the same
restrictions as access to content in the Operations console.
Reporting server
Reporting for System Center – Operations Manager is installed on SQL Server Reporting Services (that are
supported by the version of Operations Manager you are using), and the only valid configuration of Reporting
Services supported by Operations Manager Reporting is native mode.
NOTE
Installing System Center – Operations Manager Reporting Services integrates the security of the SQL Reporting Services
instance with the Operations Manager role-based security. Do not install any other Reporting Services applications in this
same instance of SQL Server.
The Operations Manager Report Server components can be installed on the same server that is running SQL
Server 2014 or 2016 Reporting Services or on a different computer. For optimum performance, especially in an
enterprise environment with high-volume, parallel report generation by users while interactive or scheduled
reports are processing concurrently, you need to scale-up to handle more concurrent users and larger report
execution loads. It is generally recommended that Operations Manager Reporting service is not co-located on the
same SQL Server hosting the data warehouse database and installed on a dedicated system.
Operational database
The operational database is a SQL Server database that holds all the operational data, configuration information,
and monitoring rules for a management group. The Operations Manager database is a single source of failure for
the management group, so it can be made highly available using supported clustering configurations.
To keep this database at a consistent size, the grooming settings in Operations Manager specify the length of time
that data may be retained in it. By default, this duration is seven (7) days.
Reporting Data Warehouse database
The Reporting data warehouse is a SQL Server database that collects and stores operational data for long-term
reporting. This data is written directly from rules that collect data to report and from data synchronization
processes in the operational database. Maintenance of the data warehouse, including aggregation, grooming, and
optimization, is performed automatically by Operations Manager.
The following table highlights the default data types and retention period after initial setup of the data warehouse
database.
DATASET AGGREGATION TYPE RETENTION PERIOD (IN DAYS)
Alert Raw 400

Client Monitoring Raw 30
Client Monitoring Daily 400
Events Raw 100
Performance Raw 10
Performance Hourly 400
Performance Daily 400
State Raw 180
State Hourly 400
State Daily 400
A data warehouse may serve multiple management groups. This allows a single report to incorporate data from all
the computers across the organization.
Like the Operations Manager database, the data warehouse database can be clustered for high availability. If it is
not clustered, it should be carefully monitored so that any issues can be quickly addressed.
ACS Collector
The ACS collector receives and processes events from ACS forwarders and then sends this data to the ACS
database. This processing includes disassembling the data so that it can be spread across several tables within the
ACS database, minimizing data redundancy, and applying filters so that unnecessary events are not added to the
ACS database.
ACS database
The ACS database is the central repository for events that are generated by an audit policy within an ACS
deployment. The ACS database can be located on the same computer as the ACS collector, but for best
performance, each should be installed on a dedicated server. By default, the data is retained for fourteen (14) days.
ACS Forwarder
The service that runs on ACS forwarders is included in the Operations Manager agent. By default, this service is
installed but not enabled when the Operations Manager agent is installed. You can enable this service for multiple
agent computers at once using the Enable Audit Collection task or using PowerShell. After you enable this service,
all security events are sent to the ACS collector in addition to the local Security log.
Design considerations
The following factors should be taken into consideration when deciding to implement a single or multiple
management groups:
Increased Capacity. Operations Manager has no built-in limits regarding the number of agents that a single
management group can support. Depending on the hardware that you use and the monitoring load (more
management packs deployed means a higher monitoring load) on the management group, you might need
multiple management groups in order to maintain acceptable performance.
Consolidated Views. When multiple management groups are used to monitor an environment, a mechanism is
needed to provide a consolidated view of the monitoring and alerting data from them. This can be
accomplished by deploying an additional management group (which might or might not have any monitoring
responsibilities) that has access to all the data in all other management groups. These management groups are
then said to be connected. The management group that is used to provide a consolidated view of the data is
called the Local management group, and the others that provide data to it are called Connected management
groups.
Security and Administrative. Partitioning management groups for security and administrative reasons is very
similar in concept to the delegation of administrative authority over Active Directory Organizational Units or
domains to different administrative groups. Your company might include multiple IT groups, each with its own
area of responsibility. The area might be a specific geographical area or business division. For example, in the
case of a holding company, it can be one of the subsidiary companies. Where this type of full delegation of
administrative authority from the centralized IT group exists, it might be useful to implement a management
group structure in each of the areas. Then they can be configured as Connected management groups to a Local
management group that resides in the centralized IT data center.
Installed Languages. All servers with an Operations Manager server role installed on them must be installed in
the same language. That is to say, you cannot install the management server by using the English version of
Operations Manager 2012 R2 and then deploy the Operations Console by using the Japanese version. If the
monitoring needs to span multiple languages, an additional management group will be needed for each
language of the operators.
Production and Pre-Production Functionality. In Operations Manager, it is a recommended practice to have a
production implementation that is used for monitoring your production applications and a pre-production
implementation that has minimal interaction with the production environment. The pre-production
management group is used for testing and tuning management pack functionality before it is migrated into the
production environment. In addition, some companies employ a staging environment for servers where newly
built servers are placed for a burn-in period prior to being placed into production. The pre-production
management group can be used to monitor the staging environment to ensure the health of servers prior to
production rollout.
Dedicated ACS Functionality. If your requirements include the need to collect Windows Audit Security log
events or UNIX/Linux security events, you will be implementing the Audit Collection Service (ACS ). It might be
beneficial to implement a management group that supports the ACS function exclusively if your company's
security requirements mandate that the ACS function be controlled and administered by an administrative
group other than the one that manages the rest of the production environment.
Disaster Recovery Functionality. In Operations Manager, all interactions with the Operations Manager database
are recorded in transaction logs prior to being committed to the database. Those transaction logs can be sent to
another server running Microsoft SQL Server and committed to a copy of the Operations Manager database
there. This feature is an option to provide redundancy of the Operations Manager operational database
between two SQL Servers in the same management group. When a controlled failover needs to be performed,
the management servers in the management group require a registry change in order to reference and
communicate with the secondary SQL Server. A failover management group can be deployed which matches
exact configuration of the primary management group (management packs, overrides, notification
subscriptions, security, etc.) and the agents are configured to report to both management groups. If the primary
management group in its entirety becomes unavailable for any reason, there is no downtime of the monitoring
environment. This solution ensures service continuity of the management group and zero loss of operational
monitoring.
Before you deploy System Center Operations Manager in a production environment, plan the design of your
management group. During the planning phase, understanding the IT service components (i.e. infrastructure and
application-level) and the number of systems and devices supporting them, how it will integrate and support your
incident and problem management processes, and how you will visualize the data for different incident escalation
support tiers, engineering, service consumers, and management.
Connected management groups

Many enterprises with servers in multiple geographical locations require central monitoring of those servers. The
Connected management group configuration, illustrated in the image below, is a set of workflow processes that are
designed to create a hierarchical systems management infrastructure.
This configuration can be used to achieve centralized monitoring. It is designed to support the viewing of alerts
and monitoring data, as well as to initiate tasks against a managed object of a connected management group.
By connecting Operations Manager management groups, centralized monitoring functionality can be maintained
while at the same time enabling:
Monitoring of a larger number of manage objects than is possible with a single management group.
Isolation of monitoring activity according to logical business units, such as “Marketing,” or physical locations,
such as Rome.
When you connect management groups, you are not deploying any new servers; rather, you are allowing the local
management group to have access to the alerts and discovery information that is in a connected management
group. In this way, you can view and interact with all the alerts and other monitoring data from multiple
management groups in a single Operations console. In addition, you can run tasks on the monitored computers of
the connected management groups. To learn how to connect management groups, see Connecting management
groups in Operations Manager.
Installed languages
Operations Manager management groups support only one installed language. If the overall IT environment that
you need to monitor has more than one installed language, a separate management group will be needed per
language.
SQL Server Design Considerations
32 minutes to read
System Center Operations Manager requires access to an instance of a server running Microsoft SQL Server to
support the operational, data warehouse, and ACS audit database. The operational and data warehouse databases
are required and created when you deploy the first management server in your management group, while the ACS
database is created when you deploy an ACS collector in your management group.
In a lab environment or small-scale deployment of Operations Manager, SQL Server can be co-located on the first
management server in the management group. In a medium to enterprise-scale distributed deployment, the SQL
Server instance should be located on a dedicated standalone server or in a SQL Server high-availability
configuration. In either case, SQL Server must already exist and is accessible before you start the installation of the
first management server or ACS collector.
SQL Server requirements

The following versions of SQL Server Enterprise & Standard Edition are supported for an existing installation of
System Center Operations Manager version 1807 to host Reporting Server, Operational, Data Warehouse, and
ACS database:
Before upgrading to SQL Server 2017, review the following article about the upgrade process - Upgrade
Operations Manager 1807 databases to SQL Server 2017.
The following versions of SQL Server Enterprise & Standard Edition are supported for a new or existing
installation of System Center Operations Manager version 1801 to host Reporting Server, Operational, Data
Warehouse, and ACS database:
The following versions of SQL Server Enterprise & Standard Edition are supported for a new or existing
installation of System Center 2016 - Operations Manager to host Reporting Server, Operational, Data Warehouse,
and ACS database:
NOTE
System Center Operations Manager databases must use the same version of SQL Server, the SQL Server collation setting
must be one of the following supported types as described in that section, and SQL Server Full Text Search is required for
both the operational and data warehouse databases. The Windows Server 2016 installation options (Server Core, Server with
Desktop Experience, and Nano Server) supported by Operations Manager database components, are based on what
installation options of Windows Server are supported by SQL Server.
NOTE
System Center Operations Manager Reporting cannot be installed in a side-by-side fashion with a previous version of the
Reporting role and must be installed in native mode only. (SharePoint integrated mode is not supported.)
Additional hardware and software considerations apply in your design planning:

We recommend that you run SQL Server on computers with the NTFS file format.
There must be at least 1024 MB of free disk space for the operational and data warehouse database. It is
enforced at the time of database creation, and it will likely grow significantly after setup.
.NET Framework 4 is required.
Reporting Server is not supported on Windows Server Core.
For more information, see Hardware and Software Requirements for Installing SQL Server 2014 or Hardware and
Software Requirements for Installing SQL Server 2016.
NOTE
During the initial installation of the operational database, only use Windows Authentication on the SQL Server that hosts the
Operations Manager operational database. Do not use Mixed Mode (Windows Authentication and SQL Server
Authentication) because using SQL Server Authentication mode during the initial installation of the operational database can
cause issues. Although enabling Mixed Mode security is possible on the SQL Server hosting the Operations Manager
operational database, it is not supported as all contact with the database is accomplished using Windows accounts only.
SQL Server collation setting

The following SQL Server and Windows collations are supported by System Center Operations Manager.
SQL Server collation
SQL_Latin1_General_CP1_CI_AS
Windows collation
Latin1_General_100_CI_AS
French_CI_AS
French_100_CI_AS
Cyrillic_General_CI_AS
Chinese_PRC_CI_AS
Chinese_Simplified_Pinyin_100_CI_AS
Chinese_Traditional_Stroke_Count_100_CI_AS
Japanese_CI_AS
Japanese_XJIS_100_CI_AS
Traditional_Spanish_CI_AS
Modern_Spanish_100_CI_AS
Latin1_General_CI_AS
Cyrillic_General_100_CI_AS
Korean_100_CI_AS
Czech_100_CI_AS
Hungarian_100_CI_AS
Polish_100_CI_AS
Finnish_Swedish_100_CI_AS
If your SQL Server instance is not configured with one of the supported collations listed earlier, performing a new
setup of Operations Manager setup will fail. However, an in-place upgrade will complete successfully.
Firewall configuration
Operations Manager depends on SQL Server to host its databases and a reporting platform to analyze and
present historical operational data. The management server, Operations, and Web console roles need to be able to
successfully communicate with SQL Server, and it is important to understand the communication path and ports
in order to configure your environment correctly.
If you are designing a distributed deployment that will require SQL Always On Availability Groups to provide
failover functionality for the Operations Manager databases, there are additional firewall configuration settings
that need to be included in your firewall security strategy.
The following table helps you identify the firewall ports required by SQL Server that will need to be allowed at a
minimum in order for server roles in your Operations Manager management group to successfully communicate.
SCENARIO PORT DIRECTION OPERATIONS MANAGER ROLE
SQL Server hosting TCP 1433 * Inbound management server and

Operations Manager Web console (for Application
databases Advisor and Application
Diagnostics)
SQL Server Browser service UDP 1434 Inbound management server
SQL Server Dedicated Admin TCP 1434 Inbound management server

Connection
Additional ports used by TCP 135 Inbound management server

SQL Server
- Microsoft remote
procedure calls (MS RPC)
- Windows Management
Instrumentation (WMI)
- Microsoft Distributed
Transaction Coordinator (MS
DTC)
SQL Server Always On Administrator configured Inbound management server

Availability Group Listener port
SQL Server Reporting TCP 80 (default)/443 (SSL) Inbound management server and
Services hosting Operations Operations console
Manager Reporting Server
* While TCP 1433 is the standard port for the default instance of the Database Engine, when you create a named
instance on a standalone SQL Server or have deployed a SQL Always On Availability Group, a custom port will be
defined and should be documented for reference so that you properly configure your firewalls and enter this
information during setup.
For a more detailed overview of the firewall requirements for SQL Server, see Configure the Windows Firewall to
Allow SQL Server Access.
Capacity and storage considerations

Operations Manager database
The Operations Manager database is a SQL Server database that contains all of the data needed by Operations
Manager for day-to-day monitoring. Sizing and configuration of the database server is critical to the overall
performance of the management group. The most critical resource used by the Operations Manager database is
the storage subsystem, but CPU and RAM are also significant.
Factors that influence the load on the Operations Manager database include:
Rate of operational data collection. Operational data consists of all the events, alerts, state changes, and
performance data collected by agents. Most of the resources that are used by the Operations Manager
database are used to write this data to disk as it comes into the system. The rate of operational data collected
tends to increase as additional management packs are imported and additional agents are added. The type of
computer that an agent is monitoring is also an important factor used when determining the overall rate of
operational data collection. For example, an agent that is monitoring a business-critical desktop computer can
be expected to collect less data than an agent monitoring a server that is running an instance of SQL Server
with a large number of databases.
Rate of instance space changes. Updating this data in the Operations Manager database is costly relative to
writing new operational data. In addition, when instance space data changes, the management servers make
additional queries to the Operations Manager database in order to compute configuration and group changes.
The rate of instance space changes increases as you import additional management packs into a management
group. Adding new agents to a management group also temporarily increases the rate of instance space
changes.
Number of Operations Consoles and other SDK connections running simultaneously. Each Operations console
reads data from the Operations Manager database. Querying this data consumes potentially large amounts of
storage I/O resources, CPU time, and RAM. Operations consoles that display large amounts of operational data
in the Events View, State View, Alerts View, and Performance Data View tend to cause the largest load on the
database.
The Operations Manager database is a single source of failure for the management group, so it can be made
highly available using supported failover configurations such as SQL Server Always On Availability Groups or
Failover Cluster Instances.
Operations Manager data warehouse database
System Center – Operations Manager inserts data into the Reporting data warehouse in near-real time, it is
important to have sufficient capacity on this server that supports writing all of the data that is being collected to
the Reporting data warehouse. As with the Operations Manager database, the most critical resource on the
Reporting data warehouse is the storage I/O subsystem. On most systems, loads on the Reporting data warehouse
are similar to the Operations Manager database, but they can vary. In addition, the workload put on the Reporting
data warehouse by reporting is different than the load put on the Operations Manager database by Operations
console usage.
Factors that influence the load on the Reporting data warehouse include:
Rate of operational data collection. To allow for more efficient reporting, the Reporting data warehouse
computes and stores aggregated data in addition to a limited amount of raw data. Doing this extra work means
that operational data collection to the Reporting data warehouse can be slightly more costly than to the
Operations Manager database. This additional cost is typically balanced by the reduced cost of processing
discovery data by the Reporting data warehouse versus the Operations Manager database.
Number of concurrent reporting users or scheduled report generation. Because reports frequently summarize
large volumes of data, each reporting user can add a significant load on the system. The number of reports run
simultaneously and the type of reports being run both affect overall capacity needs. Generally, reports that
query large date ranges or large numbers of objects require additional system resources.
Based on these factors, there are several recommended practices to consider when sizing the Reporting data
warehouse:
Choose an appropriate storage subsystem. Because the Reporting data warehouse is an integral part of the
overall data flow through the management group, choosing an appropriate storage subsystem for the
Reporting data warehouse is important. As with the Operations Manager database, RAID 0 + 1 is often the
best choice. In general, the storage subsystem for the Reporting data warehouse should be similar to the
storage subsystem for the Operations Manager database, and the guidance that applies to the Operations
Manager database also applies to the Reporting data warehouse.
Consider appropriate placement of data logs vs. transaction logs. As for the Operations Manager database,
separating SQL data and transaction logs are often an appropriate choice as you scale up the number of agents.
If both the Operations Manager database and Reporting data warehouse are located on the same server and
you want to separate data and transaction logs, you must put the transaction logs for the Operations Manager
database on a separate physical volume and disk spindles from the Reporting data warehouse to receive any
benefit. The data files for the Operations Manager database and Reporting data warehouse can share the same
physical volume as long as the volume provides adequate capacity and disk I/O performance does not
negatively impact monitoring and reporting functionality.
Consider placing the Reporting data warehouse on a separate server from the Operations Manager database.
Although smaller-scale deployments can often consolidate the Operations Manager database and Reporting
data warehouse on the same server, it is advantageous to separate them as you scale up the number of agents
and the volume of incoming operational data. When the Reporting data warehouse and Reporting Server are
on a separate server from the Operations Manager database, you experience better reporting performance.
The Operations Manager data warehouse database is a single source of failure for the management group, so it
can be made highly available using supported failover configurations such as SQL Server Always On Availability
Groups or Failover Cluster Instances.
SQL Server Always On

SQL Server Always On availability groups support failover environments for a discrete set of user databases
(availability databases). Each set of availability databases is hosted by an availability replica.
With System Center 2016 and later - Operations Manager, SQL Always On is preferred over failover clustering to
provide high availability for databases. All databases except the native mode Reporting Services installation, which
uses two databases to separate persistent data storage from temporary storage requirements, can be hosted in an
AlwaysOn Availability Group.
To set up an availability group you'll need to deploy a Windows Server Failover Clustering (WSFC ) cluster to host
the availability replica, and enable Always On on the cluster nodes. You can then add the Operations Manager SQL
Server database as an availability database.
Learn more about Always On prerequisites
Learn more about setting up a WSFC for Always On availability groups
Learn more about setting up an availability group
Multisubnet string
Operations Manager does not support the connection string key words (MultiSubnetFailover=True). Because an
availability group has a listener name (known as the network name or Client Access Point in the WSFC Cluster
Manager) depending on multiple IP addresses from different subnets, such as when you deploy in a cross-site
failover configuration, client-connection requests from management servers to the availability group listener will
hit a connection timeout.
The recommended approach to work around this limitation when you have deployed server nodes in the
availability group in a multi-subnet environment, is to do the following:
1. Set the network name of your availability group listener to only register a single active IP address in DNS
2. Configure the cluster to use a low TTL value for the registered DNS record
These settings allow, when fail over to a node in a different subnet, for quicker recovery and resolution of the
cluster name with the new IP address.
Run the following Powershell query on any one of the SQL nodes to modify its settings.
Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
If you are using Always On with a listener name, you should also make these configurations changes on the
listener.
Run the following Powershell query on the SQL node currently hosting the listener to modify its settings.
Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
When a clustered or an Always On SQL instance is used for high availability, you should enable the automatic
recovery feature on your management servers to avoid the Operations Manager Data Access service restart
anytime a failover between nodes occur. For information on how to configure this, see the following KB article The
System Center Management service stops responding after an instance of SQL Server goes offline.
Optimizing SQL Server

In general, previous deployment experience with customers shows that performance issues are typically not
caused by high resource utilization (that is, processor or memory) with SQL Server itself; rather it is directly
related to the configuration of the storage subsystem. Performance bottlenecks are commonly attributed to not
following recommended configuration guidance with the storage provisioned for the SQL Server database
instance. Such examples are:
Insufficient allocation of spindles for the LUNs to support the IO requirements of Operations Manager.
Hosting transaction logs and database files on the same volume. These two workloads have different IO and
latency characteristics.
Configuration of TempDB is incorrect with respect to placement, sizing, etc.
Disk partition misalignment of volumes hosting the database transaction logs, database files, and TempDB
Overlooking the basic SQL Server configuration such as using AUTOGROW for database and transaction log
files, MAXDOP setting for query parallelism, creating multiple TempDB data files per CPU core, etc.
Storage configuration is one of the critical components to a SQL Server deployment for Operations Manager.
Database servers tend to be heavily I/O bound due to rigorous database read and write activity and transaction
log processing. The I/O behavior pattern of Operations Manager is typically 80% writes and 20% reads. As a
result, improper configuration of I/O subsystems can lead to poor performance and operation of SQL Server
systems and becomes noticeable in Operations Manager.
It is important to test the SQL Server design by performing throughput testing of the IO subsystem prior to
deploying SQL Server. Make sure these tests are able to achieve your IO requirements with an acceptable latency.
Use the Diskspd Utility to evaluate the I/O capacity of the storage subsystem supporting SQL Server. The
following blog article, authored by a member of the File Server team in the product group, provides detailed
guidance and recommendations on how to go about performing stress testing using this tool with some
PowerShell code, and capturing the results using PerfMon. You can also refer to the Operations Manager Sizing
Helper for initial guidance.
NTFS allocation unit size
Volume alignment, commonly referred to as sector alignment, should be performed on the file system (NTFS )
whenever a volume is created on a RAID device. Failure to do so can lead to significant performance degradation
and are most commonly the result of partition misalignment with stripe unit boundaries. It can also lead to
hardware cache misalignment, resulting in inefficient utilization of the array cache. When formatting the partition
that will be used for SQL Server data files, it is recommended that you use a 64-KB allocation unit size (that is,
65,536 bytes) for data, logs, and tempdb. Be aware however, that using allocation unit sizes greater than 4 KB
results in the inability to use NTFS compression on the volume. While SQL Server does support read-only data on
compressed volumes, it is not recommended.
Reserve memory
Identifying the right amount of physical memory and processors to allocate to the Windows server for SQL Server
in support of System Center - Operations Manager is not an easy question to answer (not even for other
workloads outside of this product for that matter). While the sizing calculator provided by the product group,
which is based off of testing performed in a lab environment that may or may not align with the typical workload
and configuration in the real-world, provides guidance based on workload scale (that is, 500 systems, 1000
systems, etc.) the integrity of what's stated is often brought into question. It serves as an initial recommendation to
start with, however it's not and cannot be considered the final configuration.
By default, SQL Server can change its memory requirements dynamically based on available system resources.
The default setting for min server memory is 0, and the default setting for max server memory is 2147483647.
The minimum amount of memory you can specify for max server memory is 16 megabytes (MB ). A number of
performance and memory-related problems are because customer’s don’t set a value for Max. Server Memory and
they don’t do that because they don’t know what to set. A number of other factors influence the maximum amount
of memory you allocate to SQL to ensure the operating system has enough memory to support the other
processes running on that system, such as HBA card, management agents, anti-virus real-time scanning, etc.
Otherwise, the OS and SQL will page to disk and then disk I/O increases, further decreasing performance and
creating a "ripple" effect where it is noticeable in Operations Manager.
SQL Server allows you to configure the minimum and maximum amount of memory that should be reserved and
used by its process. Specify at least 4 GB of RAM as minimum amount. This should be done for every SQL node
hosting one of the Operations Manager databases (Operational, Data warehouse, ACS ).
First start by reserving 1 GB of RAM for the OS, 1 GB for each 4 GB of RAM installed from 4–16 GB, and then 1
GB for every 8 GB RAM installed above 16 GB RAM. Then monitor the Memory\Available MBytes performance
counter in Windows to determine if you can increase the memory available to SQL Server above the starting
value.
NOTE
This counter should remain above the 150-300 MB at a bare minimum. Windows signals the
LowMemoryResourceNotification at 96 MB so you want a buffer, but you should consider starting above 1 GB on larger
servers with 256 GB or higher RAM.
This approach has typically worked out well for servers that are dedicated to SQL Server. You can also get much
more technical with determining where to set 'max server memory' by working out the specific memory
requirements for the OS, other applications, the SQL Server thread stack, and other multipage allocators. Typically
this would be ((Total system memory) – (memory for thread stack) – (OS memory requirements ~ 2-4 GB ) –
(memory for other applications) – (memory for multipage allocations; SQLCLR, linked servers, etc.)), where the
memory for thread stack = ((max worker threads) (stack size)) and the stack size is 512 KB for x86 systems, 2 MB
for x64 systems and 4 MB for IA64 systems. The value for 'max worker threads' can be found in the
max_worker_count column of sys.dm_os_sys_info. However, the assumption with either of these methods is that
you want SQL Server to use everything that is available on the machine, unless you've made reservations in the
calculations for other applications.
As more customers move towards virtualizing SQL Server in their environment, this question is more relevant in
determining what is the minimum amount of memory that a SQL Server will need to run in a virtual machine.
Unfortunately there is no way to calculate what the ideal amount of memory for a given instance of SQL Server
might actually be since SQL Server is designed to cache data in the buffer pool, and it will typically use as much
memory as you can give it. One of the things to keep in mind when you are looking at reducing the memory
allocated to a SQL Server instance, is that you will eventually get to a point where the lower memory gets traded
off for higher disk I/O access.
If you need to figure out the ideal configuration for SQL Server memory in an environment that has been over
provisioned, the best way to try to go about doing it is to start with a baseline of the environment and the current
performance metrics. Counters to initially monitor include:
SQL Server:Buffer Manager\Page Life Expectancy
SQL Server:Buffer Manager\Page reads/sec
Physical Disk\Disk Reads/sec
Typically if the environment has excess memory for the buffer pool, the Page Life Expectancy value will continue to
increase by a value of one every second and it won't drop off under the workload because all of the data pages end
up being cached. At the same time, the number of SQL Server:Buffer Manager\Page reads/sec will be low after the
cache ramp up occurs, which will also correspond to a low value for Physical Disk\Disk Reads/sec.
Once you have your baseline for the environment, make a change to the sp_configure 'max server memory' option
to reduce the size of the buffer pool by 1GB and then monitor the impact to the performance counters after things
stabilize from the initial cache flushing that may typically occur when RECONFIGURE is run in the environment. If
the level of Page Life Expectancy remains acceptable for your environment (keeping in mind that a fixed target of
>= 300 is ridiculous for servers with large amounts of RAM installed), and the number of SQL Server:Buffer
Manager\Page reads/sec is within what the disk I/O subsystem can support without performance degradation,
repeat the process of reducing the sp_configure value for 'max server memory' by 1GB and continuing to monitor
the impact to the environment.
You can also refer to the guidance on MSDN for SQL 2014.
Optimize TempDB
The size and physical placement of the tempdb database can affect the performance of Operations Manager. For
example, if the size that is defined for tempdb is too small, part of the system-processing load may be taken up
with autogrowing tempdb to the size required to support the workload every time you restart the instance of SQL
Server. To achieve optimal tempdb performance, we recommend the following configuration for tempdb in a
production environment:
Set the recovery model of tempdb to SIMPLE. This model automatically reclaims log space to keep space
requirements small.
Preallocate space for all tempdb files by setting the file size to a value large enough to accommodate the typical
workload in the environment. It prevents tempdb from expanding too frequently, which can affect performance.
The tempdb database can be set to autogrow, but this should be used to increase disk space for unplanned
exceptions.
Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage
contention and yields improved scalability. However, do not create too many files as it can reduce performance
and increase management overhead. As a general guideline, create one data file for each logical processor on
the server (accounting for any affinity mask settings) and then adjust the number of files up or down as
necessary. As a general rule, if the number of logical processors is less than or equal to 8, use the same number
of data files as logical processors. If the number of logical processors is greater than 8, use eight data files and
then if contention continues, increase the number of data files by multiples of 4 (up to the number of logical
processors) until the contention is reduced to acceptable levels or make changes to the workload/code. If the
contention is not reduced, you may have to increase the number of data files more.
Make each data file the same size; allowing for optimal proportional-fill performance. The equal sizing of data
files is critical because the proportional fill algorithm is based on the size of the files. If data files are created
with unequal sizes, the proportional fill algorithm tries to use the largest file more for GAM allocations instead
of spreading the allocations between all the files, thereby defeating the purpose of creating multiple data files.
Put the tempdb database on a fast I/O subsystem using solid-state drives for the most optimal performance.
Use disk striping if there are many directly attached disks.
Put the tempdb database on disks that differ from those that are used by user databases.
To configure tempdb, you can run the following query or modify its properties in Management Studio.
USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH =
512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
Run the T-SQL query SELECT * from sys.sysprocesses to detect page allocation contention for the tempdb
database. In the system table output, the wait resource may show up as "2:1:1" (PFS Page) or "2:1:3" (Shared
Global Allocation Map Page). Depending on the degree of contention, this may also lead to SQL Server appearing
unresponsive for short periods. Another approach is to examine the Dynamic Management Views
[sys.dm_exec_request or sys.dm_os_waiting_tasks]. The results will show that these requests or tasks are waiting
for tempdb resources, and have similar values as highlighted earlier when you execute the sys.sysprocesses query.
If the previous recommendations do not significantly reduce the allocation contention and the contention is on
SGAM pages, implement trace flag -T1118 in the Startup parameters for SQL Server so that the trace flag remains
in effect even after SQL Server is recycled. Under this trace flag, SQL Server allocates full extents to each database
object, thereby eliminating the contention on SGAM pages. Note that this trace flag affects every database on the
instance of SQL Server.
Max degree of parallelism
The default configuration of SQL Server for small to medium size deployments of Operations Manager is
adequate for most needs. However, when the workload of the management group scales upwards towards an
enterprise class scenario (typically 2,000+ agent-managed systems and an advanced monitoring configuration,
which includes service-level monitoring with advanced synthetic transactions, network device monitoring, cross-
platform, and so forth) it is necessary to optimize the configuration of SQL Server described in this section of the
document. One configuration option that has not been discussed in previous guidance, is MAXDOP.
The Microsoft SQL Server max degree of parallelism (MAXDOP ) configuration option controls the number of
processors that are used for the execution of a query in a parallel plan. This option determines the computing and
thread resources that are used for the query plan operators that perform the work in parallel. Depending on
whether SQL Server is set up on a symmetric multiprocessing (SMP ) computer, a non-uniform memory access
(NUMA) computer, or hyperthreading-enabled processors, you have to configure the max degree of parallelism
option appropriately.
When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of
parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution.
By default, its value for this option is 0, which allows SQL Server to determine the maximum degree of parallelism.
The stored procedures and queries pre-defined in Operations Manager as it relates to the operational, data
warehouse, and even audit database do not include the MAXDOP option, as there is no way during installation to
dynamically query how many processors are presented to the operating system, nor does it attempt to hardcode
the value for this setting, which could have negative consequences when the query is executed.
NOTE
The max degree of parallelism configuration option does not limit the number of processors that SQL Server uses. To
configure the number of processors that SQL Server uses, use the affinity mask configuration option.
For servers that use more than eight processors, use the following configuration: MAXDOP=8
For servers that use eight or fewer processors, use the following configuration: MAXDOP=0 to N Note In this
configuration, N represents the number of processors.
For servers that have NUMA configured, MAXDOP should not exceed the number of CPUs that are assigned
to each NUMA node.
For servers that have hyperthreading enabled, the MAXDOP value should not exceed the number of physical
processors.
For servers that have NUMA configured and hyperthreading enabled, the MAXDOP value should not exceed
number of physical processors per NUMA node.
You can monitor the number of parallel workers by querying sys.dm_os_tasks.
In one customer deployment of Operations Manager 2012, which was monitoring multiple datacenter
infrastructure workloads across 5,000 Windows agent-managed systems, the SQL Server instance hosting the
operational database exhibited significant performance degradation. The hardware configuration of this server was
an HP Blade G6 with 24 core processors and 196 GB of RAM. The instance hosting the Operations Manager
database had a MAXMEM setting of 64 GB. After performing the suggested optimizations in this section,
performance improved. However, a query parallelism bottleneck still persisted. After testing different values, the
most optimal performance was found by setting MAXDOP=4.
Initial database sizing
Estimating the future growth of the Operations Manager databases, specifically the operational and data
warehouse databases, within the first several months after deployment is not a simple exercise. While the
Operations Manager Sizing Helper is reasonable in estimating potential growth based on the formula derived by
the product group from their testing in the lab, it does not take into account several factors, which can influence
growth in the near term versus long term.
The initial database size, as suggested by the Sizing Helper, should be allocated to a predicted size, to reduce
fragmentation and corresponding overhead, which can be specified at setup time for the Operational and Data
Warehouse databases. If during setup not enough storage space is available, the databases can be expanded later
by using SQL Management Studio and then reindexed thereafter to defragment and optimize accordingly. This
recommendation applies also to the ACS database.
Proactive monitoring of the growth of the operational and data warehouse database should be performed on a
daily or weekly cycle. This will be necessary to identify unexpected and significant growth spurts, and begin
troubleshooting in order to determine if it is caused by a bug in a management pack workflow (that is, discovery
rule, performance or event collection rule, or monitor or alert rule) or other symptom with a management pack
that was not identified during testing and quality assurance phase of the release management process.
Database autogrow
When the databases file size that has been reserved on disk becomes full, SQL Server can automatically increase
the size, by a percentage or by a fixed amount. Moreover, a maximum database size can be configured, to prevent
filling up all the space available on disk. By default, the Operations Manager database is not configured with
autogrow enabled; only the Data Warehouse and ACS databases are.
Only rely on autogrow as a contingency for unexpected growth. Autogrow introduces a performance penalty that
should be considered when dealing with a highly transactional database. Performance penalties include:
Fragmentation of the log file or database if you don’t provide an appropriate growth increment.
If you run a transaction that requires more log space than is available, and you have turned on the autogrow
option for the transaction log of that database, then the time it takes the transaction to complete will include the
time it takes the transaction log to grow by the configured amount.
If you run a large transaction that requires the log to grow, other transactions that require a write to the
transaction log will also have to wait until the grow operation completes.
If you combine the autogrow and autoshrink options, you might create unnecessary overhead. Make sure that the
thresholds that trigger the grow and shrink operations will not cause frequent up and down size changes. For
example, you may run a transaction that causes the transaction log to grow by 100 MB by the time it commits.
Some time after that the autoshrink starts and shrinks the transaction log by 100 MB. Then, you run the same
transaction and it causes the transaction log to grow by 100 MB again. In that example, you are creating
unnecessary overhead and potentially creating fragmentation of the log file, either of which can negatively affect
performance.
It is recommended to configure these two settings carefully. The particular configuration really depends on your
environment. In general, it is recommended to increase database size by a fixed amount in order to reduce disk
fragmentation. See, for example, the following figure, where the database is configured to grow by 1024 MB each
time autogrow is required.
Cluster failover policy
Windows Server Failover Clustering is a high availability platform that is constantly monitoring the network
connections and health of the nodes in a cluster. If a node is not reachable over the network, then recovery action
is taken to recover and bring applications and services online on another node in the cluster. The default settings
out of the box are optimized for failures where there is a complete loss of a server, which is considered a ‘hard’
failure. These would be unrecoverable failure scenarios such as the failure of non-redundant hardware or power. In
these situations, the server is lost and the goal is for Failover Clustering to quickly detect the loss of the server and
rapidly recover on another server in the cluster. To accomplish this fast recovery from hard failures, the default
settings for cluster health monitoring are fairly aggressive. However, they are fully configurable to allow flexibility
for a variety of scenarios.
These default settings deliver the best behavior for most customers, however as clusters are stretched from being
inches to possibly miles apart, the cluster may become exposed to additional and potentially unreliable networking
components between the nodes. Another factor is that the quality of commodity servers is constantly increasing,
coupled with augmented resiliency through redundant components (such as dual power supplies, NIC teaming,
and multi-path I/O ), the number of non-redundant hardware failures may potentially be fairly rare. Because hard
failures may be less frequent, some customers may wish to tune the cluster for transient failures, where the cluster
is more resilient to brief network failures between the nodes. By increasing the default failure thresholds, you can
decrease the sensitivity to brief network issues that last a short period of time.
It is important to understand that there is no right answer here, and the optimized setting may vary by your
specific business requirements and service level agreements.
Virtualizing SQL Server
In virtual environments, for performance reasons, it is recommended that you store the operational database and
data warehouse database on a direct attached storage, and not on a virtual disk. Always use the Operations
Manager Sizing Helper to estimate required IOPS, and stress test your data disks to verify. You can leverage the
SQLIO tool for this task. See also Operations Manager virtualization support for additional guidance on
virtualized Operations Manager environment.
Always On and recovery model
Although not strictly an optimization, an important consideration regarding Always On Availability Group is the
fact that, by design, this feature requires the databases to be set in the “Full” recovery model. Meaning, the
transaction logs are never discarded until either a full backup is done, or only the transaction log. For this reason, a
backup strategy is not an optional but a required part of the AlwaysOn design for Operations Manager databases.
Otherwise, with time, disks containing transaction logs will fill up.
A backup strategy must take into account the details of your environment. A typical backup schedule is given in the
following table.
BACKUP TYPE SCHEDULE
Transaction log only Every one hour
Full Weekly, Sunday at 3:00 AM
Optimizing SQL Server reporting services

The Reporting Services instance acts as a proxy for access to data in the Data Warehouse database. It generates
and displays reports based on templates stored inside the management packs.
Behind the scenes of Reporting Services, there is a SQL Server Database instance that hosts the ReportServer and
ReportServerTempDB databases. General recommendations regarding the performance tuning of this instance
apply.
Next steps
To understand how to configure hosting the Report data warehouse behind a firewall, see Connect Reporting Data
Warehouse Across a Firewall.
Resource pool design considerations
8 minutes to read
A Resource Pool is a logical grouping of management servers and/or gateway servers used to distribute work
among themselves and take over work from a failed member. In other words, they provide high availability and
scalability for workflows. When designing a management group, considerations must be made for monitoring of
network devices, Linux/UNIX systems, and other workloads that are designed to take advantage of a resource
pool.
Overview
Resource pools ensure the continuity of monitoring by providing multiple members, which are management
servers and/or gateway servers that can take over monitoring workflows if one of the members of the pool
becomes unavailable. You can create resource pools for specific purposes. For example, you might create a
resource pool of management servers in your primary data center to monitor network devices.
Resource pools apply a logic similar to clustering “majority node set”, where (< number of nodes as members of
the pool > /2) + 1. At a minimum, there must be three members in the pool to maintain quorum, which must be
more than 50% of the quorum voting members in a pool to maintain availability of the pool. If you only have two
members of the pool, and one is unavailable, you have lost quorum.
For every resource pool created in the Operations console, the Operations Manager database, which is referred to
as the default observer, is always given a vote, even if you have an even number of members in the pool to allow
quorum to be reached. This also applies to the three resource pools created by default when you first create the
management group, which is discussed later in this topic. For all resource pools created using the PowerShell
cmdlet NewSCOM -ResourcePool, it's set to disabled by default. Including the Operations Manager database as
the default observer reduces complexity of your management group by only requiring you to deploy two
management servers at a minimum to maintain high availability of your resource pools.
Another role supporting a resource pool are Observers. This is a management server or a Gateway server that
doesn't participate in loading workflows for the pool; however they participate in quorum decisions. This is never
used under normal circumstances, and therefore shouldn't be considered.
There are two types of membership, automatic and manual. When you create a resource pool, its membership is
set to manual and can't be reconfigured to automatic. When a System Center – Operations Manager management
group is created, three resource pools are created by default with automatic membership. The following table
describes these three resource pools.
RESOURCE POOL NAME DESCRIPTION
All Management Servers Resource Pool Performs workflows for group calculation, availability,
distributed monitor health rollup, and database grooming.
Notifications Resource Pool The Alert Subscription Service workflows are targeted to this
Resource Pool to support alert notifications.
AD Assignment Resource Pool The AD Integration workflows are targeted to this Resource
Pool to support automatic agent assignment to management
servers.
Because membership of the All Management Servers Resource Pool is automatic, any management server that is
commissioned is automatically made a member of this resource pool. In certain architectures and design
considerations, such as those incorporating geographically dispersed contingency operations, automatic
assignment to the All Management Servers Resource Pool may not be desired. In these situations, it's possible to
change the membership assignment from automatic to manual. As such, management servers must be added to
the All Management Servers Resource Pool through manual assignment.
NOTE
The membership of the All Management Servers Resource Pool is read-only. To change its membership from automatic to
manual, see Modifying Pool Membership.
With the introduction of resource pools, it is recommended that all members are connected by a low latency
network (less than 10 ms). Resource pools should not be deployed across multiple data centers or in a hybrid-
cloud environment like Microsoft Azure.
Resource Pool availability examples
The following examples demonstrate the concept of resource pool availability based on the following
configurations, only with management servers or only with Gateway servers.
Single management server
The default observer is enabled by default and provides no benefit since there are only two members and
quorum isn't reached.
There is no high availability, because the management server is a single point of failure.
Two management servers
The default observer is enabled by default.
There is high availability for the pool, because there are three voting members - two management servers and
the default observer.
If you disable the default observer, you'll lose high availability for the pool.
Three management servers
There is high availability for the pool, because there are four voting members - three management serves and
By default you can only have one management server unavailable to maintain quorum. If two management
servers are unavailable, you have exactly 50% of voting members and the resource pool no longer functions to
manage the monitoring workloads.
The default observer doesn't increase the number of management servers that can be down, therefore it
doesn't increase pool availability.
You can consider removing the default observer in this scenario.
Four management servers
There is high availability for the pool, because there are five voting members - four management servers and
By default you can only have two management server unavailable to maintain quorum. If three management
servers are down, you have less than 50% of voting members and the resource pool no longer functions to
The default observer in this scenario provides significant value, because it increases the number of
management servers that can be down. Without the default observer, you would only have four quorum
members, which only allows for one member to be unavailable.
Five management servers
There is high availability for the pool, because there are six voting members - five management servers and the
default observer.
By default you can only have two management servers unavailable to maintain quorum. If three management
servers are unavailable, this is exactly 50% of voting members, and the resource pool no longer functions to
The default observer doesn't increase the number of management servers that can be down, therefore it
doesn't increase pool availability.
You can consider removing the default observer in this scenario.
Once you reach three or more management servers in a resource pool, where you have an odd number of
members in the pool, you can consider removing the default observer as a member. If you reach five management
servers, there is the potential for the Operational database to experience significant load, which might generate
enough latency to affect resource pool calculations.
With the way the default observer plays a role, each management server in the pool queries its own local SDK
service, which allows it to query a table in the Operational database for the default observer. If the SDK service or
database is under a load, you'll experience latency that would otherwise not exist.
Single Gateway server
There is no high availability because the Gateway server is a single point of failure.
The default observer should not be used here because Gateway servers don't have a local SDK service and
therefore can't query the Operational database.
Two Gateway servers
There is no high availability because there are only two members of the pool and the default observer isn't a
participant because Gateway servers don't directly communicate with the Operational database. Three
Gateway servers are required to maintain pool quorum.
Three Gateway servers
There is high availability for the pool, because there are three voting members - three Gateway servers.
By default you can only have one Gateway server unavailable to maintain to maintain quorum. If two Gateway
servers are down, this is less than 50% of voting members, and the resource pool no longer functions to
The default observer should not be used here because Gateway servers don't have a local SDK service and
therefore can't query the Operational database.
Monitoring scenarios supporting resource pools

The following workflows are hosted by resource pools in Operations Manager:
Management of network devices
Management of UNIX/Linux agents
Monitoring web application URLs
NOTE
Windows agents don't report to resource pools.
Network monitoring in Operations Manager requires its own separate, dedicated resource pool. This is because
network monitoring workflows run on management servers (on the SNMP module) and not on agents. This
places a heavy load on the management servers once you include monitoring of network ports, especially if you
select most of the active ports available on the device. Therefore, for better performance, we recommend using
dedicated management servers in dedicated resource pools for network monitoring. Additionally, the
management servers that are members of this pool should be removed from the All Management Servers,
Notifications, and AD Assignment pools.
Linux/UNIX monitoring in Operations Manager can be assigned to a dedicated resource pool if necessary to
enable high-availability monitoring and agent management, but isn't required. Operations Manager uses
certificates to authenticate access to the computers it is managing. When the Discovery Wizard deploys an agent,
it retrieves the certificate from the agent, signs the certificate, deploys the certificate back to the agent, and then
restarts the agent. To support high availability, each management server in the resource pool must have all the
root certificates that are used to sign the certificates that are deployed to the agents on the UNIX and Linux
computers. Otherwise, if a management server becomes unavailable, the other management servers would not be
able to trust the certificates that were signed by the server that failed.
Next steps
To learn how to create and manage resource pools, see How to manage resource pools.
Integration with other enterprise management
products
2 minutes to read
Many customers have one or more monitoring platforms, where one provides consolidated operational data
across business infrastructure, data centers, complex networks, and IT domains in the enterprise. From this central
monitoring platform, they correlate this data and forward to service management solution for incident recording
and escalation, as well as to analyze and visualize the data presented through different types of dashboards.
System Center - Operations Manager is included in that service operations framework to forward alert or alert
and performance data, or is the primary monitoring platform extended to meet your business needs.
Interoperability between Operations Manager and other products is accomplished from many different methods
depending on the technical and business requirements. The following are common methods to interface with
Operations Manager:
System Center - Orchestrator with integration packs available from Microsoft, third parties, and the
community. Integration packs for Orchestrator contain additional activities that extend the functionality of
Orchestrator to communicate and exchange data with other third-party systems.
Connectors built on the Operations Manager Connector Framework (OMCF ). Connectors built on the OMCF,
which are developed from the Operations Manager SDK, provides methods and types that you can use to
initialize and manage a connector and to get or send operations data. Some examples of connectors used to
integrate with Operations Manager are other System Center products like Service Manager and Virtual
Machine Manager (VMM ), and third-party products such as Nagios or IBM Netcool. Connections to external
systems are commonly performed using a web service.
Querying the SQL operational or data warehouse databases to extract certain datasets for custom reports or
dashboards.
Other custom connectors are developed and implemented to support advanced scenarios such as alert
enrichment, including additional information before the alert is forwarded to the incident management system,
perform alert correlation, or provide advanced notification functionality with Operations Manager.
Operations Manager also integrates with Azure Monitor to forward collected events, alerts, and performance data
for further analysis and provides greater visibility for the enterprise.
When separated by a firewall

The ports and communication between Operations Manager and the other management products depends on the
method of integration used. If you are using System Center - Orchestrator, the Orchestrator runbook server
connects to the Operations Manager management server over TCP port 5724. It is a one-way directed
communication.
If you are using a connector provided by the vendor, review their documentation in order to understand what
ports and which direction the traffic flows.
Design considerations
Integration between Operations Manager and other monitoring and management products is commonly
configured between a single management server and the other management product. Or in other cases, between
multiple management servers or specifying the Operations Manager management group name. Support for
multiple, connected management groups are not supported, and each management group will need to install a
separate instance of the connector for each management group. This includes integration between System Center
Orchestrator, VMM, and Service Manager.
When planning for service continuity, it is important to evaluate and determine the risks, impact, and recovery
options for your Operations Manager deployment to support your service level targets.
If a management server is supporting integration (via a connector hosted directly on the management server or
from another System Center product such as VMM, Orchestrator or Service Manager), you need to plan for this
with manual or automatic recovery steps depending on the integration configuration and sequence of steps
required to return to normal functionality.
High Availability and Disaster Recovery
7 minutes to read
Various System Center – Operations Manager servers and features can potentially fail, impacting Operations
Manager functionality. The amount of data and functionality lost during a failure is different in each failure
scenario. It depends on the role of the failing feature, the length of time it takes to recover the failing feature.
High availability
High-availability needs are addressed by building redundancy into the management group for the Operations
Manager operational and data warehouse databases, the gateway and management servers, and specific
workloads. These workloads include network device monitoring, cross-platform monitoring, and management
group-specific workloads that were previously managed by the Root Management Server.
The multiple servers, single management group configuration can make use of SQL Server Always On for
providing high availability and service continuity of the Operations Manager databases. Management server fault-
tolerance is provided by having at least two management servers and by using the resource pools for monitoring
UNIX servers, Linux servers, and network devices. Agent-based Windows servers can be configured with a
primary and secondary management server to redirect agent communications should a management server fail.
The RMS Emulator can be moved to another management server as well should the management server hosting
the RMS Emulator become unavailable.
Operations console connections can be made highly available by configuring high availability for the Data Access
Services. This can be done by installing Microsoft Network Load Balancing (NLB ) or using a hardware-based load
balancers, or DNS alias. One or more management servers are added as members of the NLB pool and when
opening either the console, you reference the virtual name registered in DNS, of the load-balanced management
servers.
NOTE
A Network Load Balancer is not supported for the Operations Manager web console server.
Multiple gateway servers can be deployed across a trust boundary to provide redundant pathways for agents that
lie across that trust boundary. Just as agents can fail over between a primary management server and one or more
secondary management servers, they can also fail over between gateway servers. In addition, multiple gateway
servers can be used to distribute the workload of managing agentless-managed computers and managed network
devices.
In addition to providing redundancy through agent-gateway failover, gateway servers can be configured to fail
over between management servers in a management group, if multiple management servers are available.
While SQL Server Reporting Services supports a scale-out deployment model that allows you to run multiple
report server instances that share a single report server database, it is not supported with Operations Manager.
Operations Manager Reporting installs a custom security extension as part of the setup of the front-end
components, which cannot be replicated across the web farm.
Disaster recovery
Disaster recovery relates to measures taken to ensure that operations can be resumed if a catastrophic failure (for
example, loss of the entire data center that hosts the primary infrastructure). It is an important element that must
be considered in any deployment and the decisions that are made in planning for disaster recovery affect how
Operations Manager will be able to continue supporting proactive monitoring and reporting of the performance
and availability of your critical IT services. This section will focus on the recommended strategy of disaster
recovery and resiliency and what steps should be taken to ensure a smooth recovery.
While HA and DR solutions will provide protection from system failure or system loss, they should not be relied on
for protection from accidental, unintended, or malicious data loss or corruption. In these cases, back up copied or
lagged replication copies might have to be leveraged for restore operations. In many cases, a restore operation is
the most appropriate form of DR. One example of this could be a low -priority reporting database or analysis data.
In many cases, the cost to enable multisite DR at the system or application level far outweighs the value of the
data. In cases in which the near-term value of the data is low and the need to access the data can be delayed
without severe business impact if a failure or site DR excessive, consider using simple backup and restore
processes for DR if the cost savings warrant it.
Understanding the impact and tolerance for downtime will help drive the decisions that need to be understood in
order to properly design the architecture for Operations Manager and the level of complexity and cost required to
support disaster recovery. Additionally, consider the extent of monitoring data loss the IT organization can tolerate
without causing business consequences. This is best described in two terms: recovery time objective (RTO ) and
recovery point objective (RPO ).
The two most common disaster recovery design configurations for Operations Manager are:
Creating a duplicate management group deployed to your secondary data center that duplicates in scale and
configuration, the primary management group.
Deploying additional servers in a secondary data center to support the Operational and Data Warehouse
database, with management servers deployed in a cold-standby configuration, not participating in the
management group until recovery actions need to be performed.
Deploying a duplicate management group is an option when there is no tolerance for downtime; however, it is the
most complex option. Configuration between both needs to be consistent so that when you cut over, there is no
difference in what is monitored, alerted or reported, presented, and finally escalated. Integration with other
monitoring platforms or ITSM platforms such as System Center - Service Manager, Remedy or ServiceNow will
need to exist as well, and possibly configured in an active/passive state to avoid duplication of incidents,
configuration items, etc. Agents will be multihomed between both management groups, so there will be
duplication of data.
The following diagram is an example of this design scenario.
If immediate recovery is not necessary for your Operations Manager deployment and you want to avoid the
complexity of a duplicate management group, alternatively you can deploy additional management group
components in your secondary data center in order to retain functionality of your management group. At a
minimum, consider implementing a SQL Server 2014 or 2016 Always On Availability Group to provide recovery
of the Operational and Data Warehouse databases between two or more datacenters, where a two-node failover
cluster instance (FCI) is deployed in the primary data center, and a standalone SQL Server in the secondary
datacenter as part of a single Windows Server Failover Cluster (WSFC ). The secondary replica for the Always On
Availability Group would be on the non-FCI standalone instance as shown in the following diagram.
In this example, you would be required to deploy one or more Windows Servers with the same hardware
configuration and computer name, and reinstall the management server role using the /Recover parameter.
During this time, agents will queue the data collected (alerts, events, performance, etc.) until they can resume
communication with a management server in the management group. This approach avoids installing new
instances of SQL Server and restoring databases from your last known good backup. However, in this recovery
scenario there is likely going to be a longer delay in returning to an operable state given you will need to deploy
the other roles necessary to resume minimum monitoring functionality. If this approach isn't acceptable, you can
deploy management servers in your secondary data center for on-standby recovery. Remove them as members of
the three primary resources pools - All Management Servers Resource Pool, Notifications, and AD Assignment.
This also includes any custom resource pool, which may include management servers hosted in the primary data
center and need to continue to function as part of the recovery plan. The System Center Data Access, System
Center Configuration Management, and Microsoft Monitoring Agent services should be stopped and set to
manual or disable and only started in a disaster recovery scenario.
If a management server is supporting integration (via a connector hosted directly on the management server or
from another System Center product such as VMM, Orchestrator or Service Manager), this will need to be planned
for with manual or automatic recovery steps depending on the integration configuration and sequence of recovery
steps. This ensures any other dependency on the management server is captured and planned for when the
disaster recovery plan needs to be implemented.
If one site goes offline, the agent will fail over to the management server in another site, assuming that the agent’s
failover configuration allows this. Reconfigure the Windows agents to cache only management servers in your
primary data center that should manage them to prevent them from attempting to failover to a management
server in the secondary data center, which would only delay recovery and reporting. This can be accomplished if
you manually deploy the agent in an automated manner with a script (for example, VBScript or better yet,
PowerShell) to pre-configure during installation, or post deployment if you push the agent from the console, again
using a scripted method managed with your enterprise configuration management solution.
Operations Manager can be deployed on Azure virtual machines as an alternative disaster recovery option to
maintain continuity of the management group. It will be necessary to also deploy SQL Server on a virtual machine
in Azure and not in a hybrid configuration, as the latency between a management server and the SQL Server
hosting the Operations Manager databases will negatively impact performance of the management group.
Consider the monitoring scope, network topology, and network connectivity to Microsoft Azure (that is, site-to-site
VPN or ExpressRoute), integration points (that is, ITSM solutions, other System Center products, third-part add-
ons, etc.), console access, regulatory or relevant laws or policies, etc. in order to properly architect this scenario
within Azure IaaS or other public cloud providers.
Operations Manager agents
13 minutes to read
In System Center Operations Manager, an agent is a service that is installed on a computer that looks for
configuration data and proactively collects information for analysis and reporting, measures the health state of
monitored objects like a SQL database or logical disk, and execute tasks on demand by an operator or in
response to a condition. It allows Operations Manager to monitor Windows, Linux, and UNIX operating systems
and the components of an IT service installed on them, like a web site or an Active Directory domain controller.
Windows agent
On a monitored Windows computer, the Operations Manager agent is listed as the Microsoft Monitoring Agent
service. The Microsoft Monitoring Agent service collects event and performance data, executes tasks, and other
workflows defined in a management pack. Even when the service is unable to communicate with the
management server it reports to, the service continues to run and queues the collected data and events on the
disk of the monitored computer. When the connection is restored, the Microsoft Monitoring Agent service sends
collected data and events to the management server.
NOTE
The Microsoft Monitoring Agent service is sometimes referred to as the health service.
The Microsoft Monitoring Agent service also runs on management servers. On a management server, the service
runs monitoring workflows and manages credentials. To run workflows, the service initiates MonitoringHost.exe
processes using specified credentials. These processes monitor and collect event log data, performance counter
data, Windows Management Instrumentation (WMI) data, and run actions such as scripts.
Communication between agents and management servers
The Operations Manager agent sends alert and discovery data to its assigned primary management server, which
writes the data to the operational database. The agent also sends events, performance, and state data to the
primary management server for that agent, which writes the data to the operational and data warehouse
databases simultaneously.
The agent sends data according to the schedule parameters for each rule and monitor. For optimized collection
rules, data is only transmitted if a sample of a counter differs from the previous sample by a specified tolerance,
such as 10%. This helps reduce network traffic and the volume of data stored in the operational database.
Additionally, all agents send a packet of data, called a heartbeat, to the management server on a regular schedule,
by default every 60 seconds. The purpose of the heartbeat is to validate the availability of the agent and
communication between the agent and the management server. For more information on heartbeats, see How
For each agent, Operations Manager runs a health service watcher, which monitors the state of the remote Health
Service from the perspective of the management server. The agent communicates with a management server
over TCP port 5723.
Linux/UNIX agent
The architecture of the UNIX and Linux agent differs from a Windows agent significantly. The Windows agent has
a Health Service responsible for evaluating the health of the monitored computer. The UNIX and Linux Agent
does not run a health service, instead it passes information to the Health Service on a management server to be
evaluated. The management server runs all of the workflows to monitor operating system health defined in our
implementation of the UNIX and Linux management packs:
Disk
Processor
Memory
Network adapters
Operating System
Processes
Log files
The UNIX and Linux agents for Operations Manager consist of a CIM Object Manager (that is, CIM Server), and
a set of CIM Providers. The CIM Object Manager is the “server” component that implements the WS -
Management communication, authentication, authorization, and dispatch of requests to the providers. The
providers are the key to the CIM implementation in the agent, defining the CIM classes and properties,
interfacing with the kernel APIs to retrieve raw data, formatting the data (for example, calculating deltas and
averages), and servicing the requests dispatched from the CIM Object Manager. From System Center Operations
Manager 2007 R2 through System Center 2012 SP1, the CIM Object Manager used in the Operations Manager
UNIX and Linux agents is the OpenPegasus server. The providers used to collect and report monitoring data are
developed by Microsoft, and open-sourced at CodePlex.com.
This changed in System Center 2012 R2 Operations Manager, where UNIX and Linux agents are now based on a
fully consistent implementation of Open Management Infrastructure (OMI) as their CIM Object Manager. In the
case of the Operations Manager UNIX/Linux agents, OMI is replacing OpenPegasus. Like OpenPegasus, OMI is
an open-source, lightweight, and portable CIM Object Manager implementation – though it is lighter in weight
and more portable than OpenPegasus. This implementation continues to be applied in System Center 2016 -
Operations Manager and later.
Communication between the management server and the UNIX and Linux agent is split into two categories,
agent maintenance and health monitoring. The management server uses two protocols to communicate with the
UNIX or Linux computer:
Secure Shell (SSH) and Secure Shell File Transfer Protocol (SFTP )
Used for agent maintenance tasks such as installing, upgrading, and removing agents.
Web Services for Management (WS -Management)
Used for all monitoring operations and include the discovery of agents that were already installed.
Communication between the Operations Manager management server and UNIX and Linux agent uses WS -Man
over HTTPS and the WinRM interface. All agent maintenance tasks are performed over SSH on port 22. All
health monitoring is performed over WS -MAN on port 1270. The management server requests performance and
configuration data via WS -MAN before evaluating the data to provide health status. All actions, such as agent
maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined profiles according to their
requirement for an unprivileged or privileged account.
NOTE
All credentials referred to in this article pertain to accounts that have been established on the UNIX or Linux computer, not
to the Operations Manager accounts that are configured during the installation of Operations Manager. Contact your
system administrator for credentials and authentication information.
To support the new scalability improvements with the number of UNIX and Linux systems System Center 2016 -
Operations Manager and later can monitor per management server, the new Async Windows Management
Infrastructure (MI) APIs are available instead of WSMAN Sync APIs, which is in use by default. To enable this
change, you need to create the new registry key UseMIAPI to enable Operations Manager to use the new Async
MI APIs on management servers monitoring Linux/Unix systems.
1. Open the Registry Editor from an elevated command prompt.
2. Create registry key UseMIAPI under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup .
If you need to restore the original configuration using the WSMAN Sync APIs, you can delete the UseMIAPI
registry key.
Agent security
Authentication on UNIX/Linux computer
In Operations Manager, the system administrator is no longer required to provide the root password of the UNIX
or Linux computer to the management server. Now by elevation, an unprivileged account can assume the identity
of a privileged account on the UNIX or Linux computer. The elevation process is performed by the UNIX su
(superuser) and sudo programs that use the credentials that the management server supplies. For privileged
agent maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstallation, and agent
recovery), support for su, sudo elevation, and support for SSH key authentication (with or without passphrase) is
provided. For privileged WS -Management operations (such as viewing secure log files), support for sudo
elevation (without password) is added.
For detailed instructions for specifying credentials and configuring accounts, see How to Set Credentials for
Accessing UNIX and Linux Computers.
Authentication with gateway server
Gateway servers are used to enable agent-management of computers that are outside the Kerberos trust
boundary of a management group. Because the gateway server resides in a domain that is not trusted by the
domain that the management group is in, certificates must be used to establish each computer's identity, agent,
gateway server, and management server. This arrangement satisfies the requirement of Operations Manager for
mutual authentication.
This requires you to request certificates for each agent that will report to a gateway server and import those
certificates into the target computer using the MOMCertImport.exe tool, which is located on the installation
media SupportTools\ (amd64 or x86) directory. You need to have access to a certification authority (CA) which
can be a public CA such as VeriSign, or you can use Microsoft Certificate Services.
Agent deployment
System Center Operations Manager Agents may be installed by using one of the following three methods. Most
installations use a combination of these methods to install different sets of computers, as appropriate.
The discovery and installation of one or more agents from the Operations console. This is the most common
form of installation. A management server must be able to connect the computer with RPC, and either the
management server Action Account or other provided credentials must have administrative access to the
target computer.
Inclusion in the installation image. This is a manual installation to a base image that is used for the preparation
of other computers. In this case, Active Directory integration may be used to automatically assign the
computer to a management server upon the initial startup.
Manual installation. This method is used when the agent cannot be installed by one of the other methods—for
example, when remote procedure call (RPC ) is unavailable because of a firewall. The setup is manually run on
the agent or deployed through an existing software distribution tool.
Agents that are installed by using the Discovery Wizard can be managed from the Operations console, such as
updating agent versions, applying patches, and configuring the management server that the agent reports to.
When you install the agent using a manual method, updates to the agent must also be performed manually. You
will be able to use Active Directory integration to assign agents to management groups. For more information,
see Integrating Active Directory and Operations Manager.
Agent deployment to Windows system
Discovery of a Windows system requires that the TCP 135 (RPC ), RPC range, and TCP 445 (SMB ) ports remain
open and that the SMB service is enabled on the agent computer.
After a target device has been discovered, an agent can be deployed to it. Agent installation requires:
Opening RPC ports beginning with endpoint mapper TCP 135 and the Server Message Block (SMB ) port
TCP/UDP 445.
Enabling the File and Printer Sharing for Microsoft Networks and the Client for Microsoft Networks services.
(This ensures that the SMB port is active.)
If enabled, Windows Firewall Group Policy settings for Allow remote administration exception and Allow file
and printer sharing exception must be set to Allow unsolicited incoming messages from to the IP address and
subnets for the primary and secondary management servers for the agent.
An account that has local administrator rights on the target computer.
Windows Installer 3.1. To install, see article 893803 in the Microsoft Knowledge Base
http://go.microsoft.com/fwlink/?LinkId=86322 <verify if we need to continue calling this out>
Microsoft Core XML Services (MSXML ) 6 on the Operations Manager product installation media in the
\msxml sub directory. Push agent installation installs MSXML 6 on the target device if it is not already
installed. <verify if we need to continue calling this out>
Agent deployment to UNIX and Linux system
In System Center Operations Manager, the management server uses two protocols to communicate with the
Secure Shell (SSH) for installing, upgrading, and removing agents.
Web Services for Management (WS -Management) for all monitoring operations and include the discovery of
agents that were already installed.
The protocol that is used depends on the action or information that is requested on the management server. All
actions, such as agent maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined
profiles according to their requirement for an unprivileged or privileged account.
NOTE
All credentials referred to in this section pertain to accounts that have been established on the UNIX or Linux computer, not
to the Operations Manager accounts that are configured during the installation of Operations Manager. Contact your
system administrator for credentials and authentication information.
By elevation, an unprivileged account can assume the identity of a privileged account on the UNIX or Linux
computer. The elevation process is performed by the UNIX su (superuser) and sudo programs that use the
credentials that the management server supplies. For privileged agent maintenance operations that use SSH
(such as discovery, deployment, upgrades, uninstallation, and agent recovery), support for su, sudo elevation, and
SSH key authentication (with or without passphrase) is provided. For privileged WS -Management operations
(such as viewing secure log files), support for sudo elevation (without password) is supported.
Active Directory agent assignment

System Center Operations Manager allows you to take advantage of your investment in Active Directory Domain
Services (AD DS ) by enabling you to use it to assign agent-managed computers to management groups. This
feature is commonly used in conjunction with the agent deployed as part of a server deployment build process.
When the computer comes online for the first time, the Operations Manager agent queries Active Directory for its
primary and failover management server assignment and automatically starts monitoring the computer.
To assign computers to management groups by using AD DS:
The functional level of AD DS domains must be Windows 2008 native or higher
Agent-managed computers and all management servers must be in the same domain or in two-way trusted
domains.
NOTE
An agent that determines it is installed on a domain controller will not query Active Directory for configuration information.
This is for security reasons. Active Directory Integration is disabled by default on domain controllers because the agent runs
under the Local System account. The Local System account on a domain controller has Domain Administrator rights;
therefore, it detects all Management Server Service Connection Points that are registered in Active Directory, regardless of
the domain controller’s security group membership. As a result, the agent tries to connect to all management servers in all
management groups. The results can be unpredictable, thus presenting a security risk.
Agent assignment is accomplished by using a Service Connection Point (SCP ), which is an Active Directory object
for publishing information that client applications can use to bind to a service. This is created by a domain
administrator running the MOMADAdmin.exe command-line tool to create an AD DS container for an
Operations Manager management group in the domains of the computers it manages. The AD DS security group
that is specified when running MOMADAdmin.exe is granted Read and Delete Child permissions to the
container. The SCP contains connection information to the management server, including the server’s FQDN and
port number. Operations Manager agents can automatically discover management servers by querying for SCPs.
Inheritance is not disabled, and because an agent can read the integration information registered in AD, if you
force inheritance for the Everyone group to read all objects at the root level in Active Directory, this will severely
affect and essentially interrupt AD Integration functionality. If you explicitly force inheritance throughout the
entire directory by granting the Everyone group read permissions, you must block this inheritance at the top-level
AD Integration container, named OperationsManager, and all child objects. If you fail to do this, AD Integration
will not work as designed and you will not have reliable and consistent primary and failover assignment for
agents deployed. Additionally, if you happen to have more than one management group, all agents in both
management groups will be multi-homed as well.
This feature works well for controlling agent assignment in a distributed management group deployment, to
prevent agents from reporting to management servers that are dedicated to resource pools or management
servers in a secondary data center in a warm-standby configuration to prevent agent failover during normal
operation.
Configuration of agent assignment is managed by an Operations Manager administrator using the Agent
Assignment and Failover Wizard to assign computers to a primary management server and secondary
management server.
NOTE
Active Directory Integration is disabled for agents that were installed from the Operations console. By default, Active
Directory Integration is enabled for agents installed manually using MOMAgent.msi.
Next steps
To understand how to install the Windows agent from the Operations console, see Install Agent on
Windows Using the Discovery Wizard or to install the agent from the command line, see Install Windows
Agent Manually Using MOMAgent.msi.
To understand how to install the Linux and UNIX from the Operations console, see Install agent on UNIX
and Linux using the Discovery Wizard.
Review How to configure and use Active Directory Integration for agent assignment to learn how to create
the container in Active Directory, configure agent failover assignment, and manage the configuration.
Configuring a Firewall for Operations Manager
4 minutes to read
This section describes how to configure your firewall to allow communication between the different Operations
Manager features on your network.
Port assignments
The following table shows Operations Manager feature interaction across a firewall, including information about
the ports used for communication between the features, which direction to open the inbound port, and whether
the port number can be changed.
OPERATIONS PORT NUMBER AND OPERATIONS

MANAGER FEATURE A DIRECTION MANAGER FEATURE B CONFIGURABLE NOTE
Management server 1433/TCP ---> Operations Manager Yes (Setup) WMI Port 135
1434/UDP ---> database (DCOM/RPC) for the
135/TCP initial connection and
(DCOM/RPC) ---> then a dynamically
137/UDP ---> assigned port above
445/TCP ---> 1024. For further
49152-65535 ---> information, see
Special considerations
for Port 135
Ports
135,137,445,49152-
65535 are only
required to be open
during the initial
Management Server
installation to allow
the setup process to
validate the state of
the SQL services on
the target machine. 2
Management server 5723, 5724 ---> management server No Port 5724 must be
open to install this
feature and can be
closed after this
feature has been
installed.
Management server 161,162 <---> network device No All firewalls between

the management
server and the
network devices need
to allow SNMP (UDP)
and ICMP bi-
directionally.
Gateway server 5723 ---> management server No

Management server 1433/TCP ---> Reporting data No Ports

1434/UDP ---> warehouse 135,137,445,49152-
135/TCP 65535 are only
(DCOM/RPC) ---> required to be open
137/UDP ---> during the initial
445/TCP ---> Management Server
49152-65535 ---> installation to allow
the setup process to
validate the state of
the SQL services on
the target machine. 2
Reporting server 5723, 5724 ---> management server No Port 5724 must be
open to install this
feature and can be
closed after this
feature has been
installed.
Operations console 5724 ---> management server No
Operations console 443 ---> Management Pack No Supports

Catalog web service downloading
management packs
directly in the console
from the catalog.1
Connector framework 51905 ---> management server No

source
Web console server 5724 ---> management server No
Web console browser 80,443 ---> web console server Yes (IIS Admin) Default ports for
HTTP or SSL enabled.
Web console for 1433/TCP ---> Operations Manager Yes (Setup) 2

Application 1434 ---> database
Diagnostics
Web console for 1433/TCP ---> Reporting data Yes (Setup) 2

Application Advisor 1434 ---> warehouse
Connected 5724 ---> connected No

management server management server
(Local) (Connected)
Windows agent 5723 ---> management server Yes (Setup)

installed using
MOMAgent.msi
Windows agent 5723 ---> gateway server Yes (Setup)

installed using
MOMAgent.msi
Windows agent push 5723/TCP, 135/TCP, Communication is

installation, pending 137/UDP, 138/UDP, initiated from MS/GW
repair, pending 139/TCP, 445/TCP to an Active Directory
update *RPC/DCOM High domain controller and
ports (2008 OS and the target computer.
later) Ports 49152-
65535 TCP
UNIX/Linux agent TCP 1270 <--- management server No

discovery and or gateway server
monitoring of agent
UNIX/Linux agent for TCP 22 <--- management server Yes

installing, upgrading, or gateway server
and removing agent
using SSH
OMED Service TCP 8886 <--- management server Yes

or gateway server
Gateway server 5723 ---> management server Yes (Setup)
Agent (Audit 51909 ---> management server Yes (Registry)

Collection Services Audit Collection
forwarder) Services collector
Agentless Exception 51906 ---> management server Yes (Client

Monitoring data from Agentless Exception Monitoring Wizard)
client Monitoring file share
Customer Experience 51907 ---> management server Yes (Client

Improvement (Customer Experience Monitoring Wizard)
Program data from Improvement
client Program End) Point
Operations console 80 ---> SQL Reporting No The Operations

(reports) Services console uses Port 80
to connect to the SQL
Reporting Services
web site.
Reporting server 1433/TCP ---> Reporting data Yes 2

1434/UDP ---> warehouse
Management server 1433/TCP <--- Audit Collection Yes 2

(Audit Collection 1434/UDP <--- Services database
Services collector)
1 Additionally, the following URL

must be allowed by your firewall -
https://www.microsoft.com/mpdownload/ManagementPackCatalogWebService.asmx.
2 If SQL
Server is installed with a default instance, the port number is 1433. If SQL Server is installed with a
named instance, by default it is configured with a dynamic port. To identify the port, do the following:
1. In SQL Server Configuration Manager, in the console pane, expand SQL Server Network Configuration,
expand Protocols for , and then double-click TCP/IP.
2. In the TCP/IP Properties dialog box, on the IP Addresses tab, note the port value for IPAall.
If you plan on deploying the Operations Manager databases on a SQL Server configured with an Always On
Availability Group or migrate after installation, do the following to identify the port:
1. In Object Explorer, connect to a server instance that hosts any availability replica of the availability group
whose listener you want to view. Click the server name to expand the server tree.
2. Expand the Always On High Availability node and the Availability Groups node.
3. Expand the node of the availability group, and expand the Availability Groups Listeners node.
4. Right-click the listener that you want to view, and select the Properties command. This opens the Availability
Group Listener Properties dialog box.
How to implement Transport Layer Security 1.2
6 minutes to read
This topic describes how to enable Transport Layer Security (TLS ) protocol version 1.2 for a System Center
Operations Manager management groups.
Perform the following steps to enable TLS protocol version 1.2:
1. Install SQL Server 2012 Native Client 11.0 on all management servers and the Web console server.
2. Install .NET Framework 4.6 on all management servers, gateway servers, Web console server, and SQL Server
hosting the Operations Manager databases and Reporting server role.
3. Install the Required SQL Server update that supports TLS 1.2.
4. Install ODBC 11.0 or ODBC 13.0 on all management servers.
5. For System Center 2016 - Operations Manager, install Update Rollup 4 or later.
6. Configure Windows to only use TLS 1.2.
7. Configure Operations Manager to only use TLS 1.2.
Operations Manager generates SHA1 and SHA2 self-signed certificates. This is required to enable TLS 1.2. If CA-
signed certificates are used, make sure that the certificates are either SHA1 or SHA2.
NOTE
If your security policies restrict TLS 1.0 and 1.1, installing a new Operations Manager 2016 management server, gateway
server, Web console, and Reporting services role will fail because the setup media does not include the updates to support
TLS 1.2. The only way you can install these roles is by enabling TLS 1.0 on the system, apply Update Rollup 4, and then
enable TLS 1.2 on the system. This limitation does not apply to Operations Manager version 1801.
Configure Windows to only use TLS 1.2 protocol

Use one of the following methods to configure Windows to use only the TLS 1.2 protocol.
Method 1: Manually modify the registry
IMPORTANT
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you
modify it, back up the registry for restoration in case problems occur.
Use the following steps to enable/disable all SCHANNEL protocols system-wide. We recommend that you enable the TLS 1.2
protocol for incoming communications; and enable the TLS 1.2, TLS 1.1, and TLS 1.0 protocols for all outgoing
communications.
NOTE
Making these registry changes does not affect the use of Kerberos or NTLM protocols.
2. Start Registry Editor by right-clicking Start, type regedit in the Run textbox, and then click OK.
3. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Pro
tocols.
4. Create a subkey under Protocols for SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.
5. Create a Client and Server subkey under each protocol version subkey you created earlier. For example, the
sub-key for TLS 1.0 would be
HKLM\System\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client and
1.0\Server.
6. To disable each protocol, create the following DWORD values under Server and Client:
Enabled [Value = 0]
DisabledByDefault [Value = 1]
7. To enable the TLS 1.2 protocol, create the following DWORD values under
1.2\Client and
1.2\Server:
Enabled [Value = 1]
DisabledByDefault [Value = 0]
8. Close the Registry Editor.
Method 2: Automatically modify the registry
Run the following Windows PowerShell script in Administrator mode to automatically configure Windows to use
only the TLS 1.2 Protocol.
$ProtocolList = @("SSL 2.0","SSL 3.0","TLS 1.0", "TLS 1.1", "TLS 1.2")
$ProtocolSubKeyList = @("Client", "Server")
$DisabledByDefault = "DisabledByDefault"
$Enabled = "Enabled"
$registryPath = "HKLM:\\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\"
foreach($Protocol in $ProtocolList)
{
Write-Host " In 1st For loop"
foreach($key in $ProtocolSubKeyList)
{
$currentRegPath = $registryPath + $Protocol + "\" + $key
Write-Host " Current Registry Path $currentRegPath"
if(!(Test-Path $currentRegPath))
{
Write-Host "creating the registry"
New-Item -Path $currentRegPath -Force | out-Null
}
if($Protocol -eq "TLS 1.2")
{
Write-Host "Working for TLS 1.2"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "0" -PropertyType DWORD -
Force | Out-Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "1" -PropertyType DWORD -Force | Out-
Null
}
else
{
Write-Host "Working for other protocol"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "1" -PropertyType DWORD -
Force | Out-Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "0" -PropertyType DWORD -Force | Out-
Null
}
}
}
Exit 0
Configure Operations Manager to use only TLS 1.2

After completing the configuration of all prerequisites for Operations Manager, perform the following steps on all
management servers, the server hosting the Web console role, and on any Windows computer the agent is
installed on.
IMPORTANT
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before making
any modifications, back up the registry for restoration in case problems occur.
Manually modify the registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319.
4. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319.
6. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
7. Restart the system for the settings to take effect.
Automatically modify the registry

Run the following Windows PowerShell script in Administrator mode to automatically configure Operations
Manager to use only the TLS 1.2 Protocol.
# Tighten up the .NET Framework

$NetRegistryPath = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value "1" -PropertyType DWORD -Force | Out-
Null
$NetRegistryPath = "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value "1" -PropertyType DWORD -Force | Out-
Null
Additional settings
If this is being implemented for System Center 2016 - Operations Manager, after applying Update Rollup 4, be
sure to import the management packs that are included in this rollup located in the following directory: \Program
Files\Microsoft System Center 2016\Operations Manager\Server\Management Packs for Update
Rollups.
If you are monitoring a supported version of Linux server with Operations Manager, follow the instructions on the
appropriate website for your distro to configure TLS 1.2.
Audit Collection Services
For Audit Collection Services (ACS ), you must make additional changes in the registry on ACS Collector server.
ACS uses the DSN to make connections to the database. You must update DSN settings to make them functional
for TLS 1.2.
3. Locate the following ODBC subkey for OpsMgrAC:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\OpsMgrAC.
NOTE
The default name of DSN is OpsMgrAC.
4. Under ODBC Data Sources subkey, select the DSN name OpsMgrAC. This contains the name of ODBC
driver to be used for the database connection. If you have ODBC 11.0 installed, change this name to ODBC
Driver 11 for SQL Server, or if you have ODBC 13.0 installed, change this name to ODBC Driver 13 for
SQL Server.
5. Under the OpsMgrAC subkey, update the Driver for the ODBS version that is installed.
If ODBC 11.0 is installed, change the Driver entry to %WINDIR%\system32\msodbcsql11.dll.
If ODBC 13.0 is installed, change the Driver entry to %WINDIR%\system32\msodbcsql13.dll.
Alternatively, create and save the following .reg file in Notepad or another text editor. To run the saved .reg
file, double-click the file.
For ODBC 11.0, create the following ODBC 11.0.reg file:
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources]

"OpsMgrAC"="ODBC Driver 11 for SQL Server"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\OpsMgrAC]
"Driver"="%WINDIR%\\system32\\msodbcsql11.dll"
For ODBC 13.0, create the following ODBC 13.0.reg file:
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources]

"OpsMgrAC"="ODBC Driver 13 for SQL Server"
"Driver"="%WINDIR%\\system32\\msodbcsql13.dll"
Next steps
For a complete listing of ports used, the direction of the communication, and if the ports can be configured,
see Configuring a Firewall for Operations Manager.
For an overall review of how data between components in a management group is protected, see
Authentication and Data Encryption in Operations Manager.
Configuring antivirus exclusions for agent and
components
2 minutes to read
This article outlines antivirus exclusions as they pertain to System Center - Operations Manager. For earlier
versions of Operations Manager, see Recommendations for antivirus exclusions.
Exclusions by process executable

If exclusions are configured based on process executable, exclude the following processes:
Monitoringhost.exe
NOTE
You must be careful when you add exclusions that are based on executables. Incorrectly configured exclusions may prevent
some potentially dangerous programs from being detected. Therefore, we do not recommend relying on exclusions that are
based on any process executables for Operations Manager servers.
Exclusions by directories
The following directory-specific exclusions for Operations Manager includes real-time scans, scheduled scans, and
local scans. The directories that are listed here are default application directories so you may have to modify these
paths based on your specific environment. Only the following Operations Manager related directories should be
excluded.
NOTE
When a directory that is to be excluded has a directory name greater than 8 characters long, add both the short and long
directory names of the directory to the exclusion list. These names are required by some antivirus programs to traverse sub-
directories.
COMPONENT DIRECTORY EXCLUSION
SQL Server database server Exclude the directory containing the .ldf and .mdf files for all
Operations Manager databases,
Report server databases, and the master and tempdb
databases.
Management server C:\Program Files\Microsoft System Center 2016\Operations

Manager\Server\Health Service State for Operations Manager
2016
C:\Program Files\Microsoft System Center\Operations
Manager\Server\Health Service State for Operations Manager
1801
Gateway server C:\Program Files\System Center Operations

Manager\Gateway\Health Service State
COMPONENT DIRECTORY EXCLUSION
Agent C:\Program Files\Microsoft Monitoring Agent\Agent\Health

Service State
Exclusion of file type by extension

The following file name extension-specific exclusions for Operations Manager includes real-time scans, scheduled
scans, and local scans.
COMPONENT FILE TYPE EX TENSION EXCLUSION
SQL Server database server Exclude file type extension .ldf and .mdf.
These exclusions includes SQL Server database files for all
Operations Manager databases,
Report Server databases, and the system database files for
master and tempdb.
Management Servers Exclude file type extensions .edb, .chk, and .log.
Gateway Servers These exclusions includes the queue and log files used by
Agents Operations Manager.
Next steps
For a complete listing of ports used, the direction of the communication, and if the ports can be configured, see
Configuring a Firewall for Operations Manager.
Service, User, and Security Accounts
7 minutes to read
During the setup and daily operation of Operations Manager, you will be asked to provide credentials for several
accounts. This article provides information about each of these accounts, including the SDK and Config Service,
Agent Installation, Data Warehouse Write, and Data Reader accounts.
If you use domain accounts and your domain Group Policy object (GPO ) has the default password expiration
policy set as required, you will either have to change the passwords on the service accounts according to the
schedule, use system accounts, or configure the accounts so that the passwords never expire.
Action accounts
In System Center Operations Manager, management servers, gateway servers, and agents all execute a process
called MonitoringHost.exe. MonitoringHost.exe is used to accomplish monitoring activities such as executing a
monitor or running a task. Other example of actions MonitoringHost.exe performs include:
Monitoring and collecting Windows event log data.
Monitoring and collecting Windows performance counter data.
Monitoring and collecting Windows Management Instrumentation (WMI) data.
Running actions such as scripts or batches.
The account that a MonitoringHost.exe process runs as is called the action account. MonitoringHost.exe is the
process that runs these actions by using the credentials that are specified in the action account. A new instance of
MonitoringHost.exe is created for each account. The action account for the MonitoringHost.exe process running
on an agent is called the Agent Action Account. The action account used by the MonitoringHost.exe process on a
management server is called the Management Server Action account. The action account used by the
MonitoringHost.exe process on a gateway server is called the Gateway Server Action Account. On all
management servers in the management group, we recommend that you grant the account local administrative
rights unless least-privileged access is required by your organizations IT security policy.
Unless an action has been associated with a Run As profile, the credentials that are used to perform the action will
be those, you defined for the action account. For more information about Run As Accounts and Run As Profiles,
see the section Run As Accounts. When an agent runs actions as either the default action account and/or Run As
account(s), a new instance of MonitoringHost.exe is created for each account.
When you install Operations Manager, you have the option to specify a domain account or use LocalSystem. The
more secure approach is to specify a domain account, which allows you to select a user with the least privileges
necessary for your environment.
You can use a least-privileged account for the agent’s action account. On computers running Windows Server
2008 R2 or higher, the account must have the following minimum privileges:
Member of the local Users group
Member of the local Performance Monitor Users group
Allow log on locally (SetInteractiveLogonRight) permission (not applicable for Operations Manager 2019).
NOTE
The minimum privileges described above are the lowest privileges that Operations Manager supports for the action account.
Other Run As accounts can have lower privileges. The actual privileges required for the Action account and the Run As
accounts will depend upon which management packs are running on the computer and how they are configured. For more
information about which specific privileges are required, see the appropriate management pack guide.
The domain account that is specified for the action account can be granted either Log on as a Service
(SeServiceLogonRight) or Log on as Batch (SeBatchLogonRight) permission if your security policy does not allow
a service account to be granted an interactive log on session, such as when smart card authentication is required.
Modify the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health
Service:
The domain account that is specified for the action account is granted with Log on as a Service
(SeServiceLogonRight) permission. To change the logon type for health service, modify the registry value
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service:
Name: Worker Process Logon Type
Type: REG_DWORD
Values (for Operations Manager 2016 to 1807): Four (4) - Log on as batch, Two (2) - Allow log on locally and
Five (5) - Log on as Service. Default value is 2.
Values for Operations Manger 2019 and later: Four (4) - Log on as Batch, Two (2) - Allow log on locally, and
Five (5) - Log on as Service. Default value is 5.
You can centrally manage the setting using Group Policy by copying the ADMX file healthservice.admx from a
management server or agent-managed system located in the folder C:\Windows\PolicyDefinitions and
configuring the setting Monitoring Action Account Logon Type under the folder
Computer Configuration\Administrative Templates\System Center - Operations Manager . For more information
working with Group Policy ADMX files, see Managing Group Policy ADMX files.
System Center Configuration Service and System Center Data Access

Service account
The System Center Configuration service and System Center Data Access service account is used by the System
Center Data Access and System Center Management Configuration services to update information in the
Operational database. The credentials used for the action account will be assigned to the sdk_user role in the
Operational database.
The account should be either a Domain User or LocalSystem. The account used for the SDK and Config Service
account should be granted local administrative rights on all management servers in the management group. The
use of Local User account is not supported. For increased security, we recommended you use a domain user
account and it's a different account from the one used for the Management Server Action Account. LocalSystem
account is the highest privilege account on a Windows computer, even higher than local Administrator. When a
service runs under the context of LocalSystem, the service has full control of the computer’s local resources, and
the identity of the computer is leveraged when authenticating to and accessing remote resources. Using
LocalSystem account is a security risk because it doesn’t honor the principal of least privilege. Because of the
rights required on the SQL Server instance hosting the Operations Manager database, a domain account with
least privilege permissions is necessary to avoid any security risk if the management server in the management
group is compromised. The reasons why are:
LocalSystem has no password
It does not have its own profile
It has extensive privileges on the local computer
It presents the computer’s credentials to remote computers
NOTE
If the Operations Manager database is installed on a computer separate from the management server and LocalSystem is
selected for the Data Access and Configuration service account, the computer account for the management server computer
is assigned the sdk_user role on the Operations Manager database computer.
For more information, see about LocalSystem
Data Warehouse Write account

The Data Warehouse Write account is the account used to write data from the management server to the
Reporting data warehouse, and it reads data from the Operations Manager database. The following table
describes the roles and membership assigned to the domain user account during setup.
APPLICATION DATABASE/ROLE ROLE/ACCOUNT
Microsoft SQL Server OperationsManager db_datareader
Microsoft SQL Server OperationsManager dwsync_user
Microsoft SQL Server OperationsManagerDW OpsMgrWriter
Microsoft SQL Server OperationsManagerDW db_owner
Operations Manager User role Operations Manager Report Security

Administrators
Operations Manager Run As account Data Warehouse Action account
Operations Manager Run As account Data Warehouse Configuration

Synchronization Reader account
Data Reader account

The Data Reader account is used to deploy reports, define what user the SQL Server Reporting Services uses to
execute queries against the Reporting data warehouse, and define the SQL Reporting Services account to connect
to the management server. This domain user account is added to the Report Administrator User Profile. The
following table describes the roles and membership assigned to the account during setup.
Microsoft SQL Server Reporting Services Installation instance Report Server Execution account
Microsoft SQL Server OperationsManagerDW OpsMgrReader
Operations Manager User role Operations Manager Report Operators
Operations Manager User role Operations Manager Report Security

Administrators
Operations Manager Run As account Data Warehouse Report Deployment

account
Windows service SQL Server Reporting Services Logon account
Verify the account you plan to use for the Data Reader account is granted the Log on as Service (for 2019 and
later) or Log on as Service and Allow Log on Locally (for earlier release), right for each management server, and
the SQL Server hosting the Reporting Server role.
Agent Installation account

When performing discovery-based agent deployment, an account is required with Administrator privileges on the
computers targeted for agent installation. The management server action account is the default account for agent
installation. If the management server action account does not have administrator rights, the operator must
provide a user account and password with administrative rights on the target computers. This account is
encrypted before being used and then discarded.
Notification Action account

The Notification Action account is the account used for creating and sending notifications. These credentials must
have sufficient rights for the SMTP server, instant messaging server, or the SIP server that is used for notifications.
Run As Accounts and Profiles
7 minutes to read
Run As accounts define which credentials will be used for certain actions that are carried out by the Operations
Manager agent. These accounts are centrally managed through the Operations console and assigned to different
Run As profiles. If a Run As profile is not assigned to a particular action, it will be carried out under the Default
Action account. In a low -privilege environment, the default account may not have the required permissions for a
particular action, and a Run As profile can be used to provide this authority. Management packs may install Run
As profiles and Run As accounts to support required actions. If this is the case, their documentation should be
referenced for any required configuration.
Default Run As accounts

The following table lists the default Run As accounts that are created by Operations Manager during setup.
NAME DESCRIPTION CREDENTIALS
Domain\ManagementServerActionAcco This is the user account under which all Domain account specified as the
unt rules run by default on management Management Server Action account
servers. during setup.
Local System Action Account Built-in System account used as an Windows Local System account
action account.
APM Account Application Performance Monitoring Encrypted binary account

account used to provide keys for
encrypting secure information collected
from the application during monitoring.
Data Warehouse Action Account Used to authenticate with SQL Server Domain account specified during setup
hosting the OperationsManagerDW as the Data Warehouse Write account.
database.
Data Warehouse Report Deployment Used to authenticate between the Domain account specified during setup
Account management server and SQL Server as the Data Reader account.
hosting Operations Manager Reporting
Services.
Local System Windows Account Built-in SYSTEM account used by the Windows Local System account
agent action account.
Network Service Windows Account Built-in Network service account Windows NetworkService account
Default Run As profiles

The following table lists the Run As profiles that are created by Operations Manager during setup. Note that if the
Run As account is left blank for the particular profile, the Default Action account (either the Management Server
Action account or the Agent Action account, depending on the location of the action) will be used.
NAME DESCRIPTION RUN AS ACCOUNT
Active Directory Based Agent Account used by Active Directory-based Local System Windows Account
Assignment Account agent assignment module to publish
assignment settings to Active Directory.
Automatic Agent Management Account This account will be used to None

automatically diagnose agent failures.
Client Monitoring Action Account If specified, used by Operations None

Manager to run all client monitoring
modules. If not specified, Operations
Manager uses the default action
account.
Connected Management Group Account used by Operations Manager None

Account management pack to monitor
connection health to the connected
management groups.
Data Warehouse Account If specified, this account is used to run None

all Data Warehouse collection and
synchronization rules instead of the
default action account. If this account is
not overridden by the Data Warehouse
SQL Server Authentication account, this
account is used by collection and
synchronization rules to connect to the
Data Warehouse databases using
Windows integrated authentication.
Data Warehouse Report Deployment This account is used by Data Data Warehouse Report Deployment
Account Warehouse report auto-deployment Account
procedures to execute various report
deployment-related operations.
Data Warehouse SQL Server If specified, this login name and Data Warehouse SQL Server
Authentication Account password is used by collection and Authentication Account
synchronization rules to connect to the
Data Warehouse databases using SQL
Server authentication.
MPUpdate Action Account This account is used by the MPUpdate None

notifier.
Notification Account Windows account used by notification None

rules. Use this account's e-mail address
as the e-mail and instant message
'From' address.
Operational Database Account This account is used to read and write None
information to the Operations Manager
database.
NAME DESCRIPTION RUN AS ACCOUNT
Privileged Monitoring Account This profile is used for monitoring, None

which can only be done with a high
level of privilege to a system; for
example, monitoring that requires Local
System or Local Administrator
permissions. This profile defaults to
Local System unless specifically
overridden for a target system.
Reporting SDK SQL Server If specified, this login name and Reporting SDK SQL Server
Authentication Account password is used by SDK Service to Authentication Account
connect to the Data Warehouse
databases using SQL Server
authentication.
Reserved This profile is reserved and must not be None

used
Validate Alert Subscription Account Account used by the validate alert Local System Windows Account
subscription module that validates that
notification subscriptions are in scope.
This profile needs administrator rights.
SNMP Monitoring Account This account is used for SNMP None

monitoring.
SNMPv3 Monitoring Account This account is used for SNMPv3 None

monitoring.
UNIX/Linux Action Account THis account is used for low privilege None
UNIX and Linux access.
UNIX/Linux Agent Maintenance This account is used for privileged None

Account maintenance operations for UNIX and
Linux agents. Without this account
agent maintenance operations will not
work.
UNIX/Linux Privileged Account This account is used for accessing None

protected UNIX and Linux resources
and actions that require high privileges.
Without this account some rules,
diagnostics and recoveries will not
work.
Windows Cluster Action Account This profile is used for all discovery and None
monitoring of Windows Cluster
components. This profile defaults to
used action accounts unless specifically
populated by the user.
WS-Management Action Account This profile is used for WS-Management None

access.
Understanding distribution and targeting

Both Run As account distribution and Run As account targeting must be correctly configured for the Run As
profile to work properly.
When you configure a Run As profile, you select the Run As accounts you want to associate with the Run As
profile. After you create that association, you can specify the class, group, or object for which the Run As account is
to be used for running tasks, rules, monitors, and discoveries against.
Distribution is an attribute of a Run As account, and you can specify which computers will receive the Run As
account credentials. You can choose to distribute the Run As account credentials to every agent-managed
computer or only to selected computers.
Example of Run As account targeting: Physical computer ABC hosts two instances of Microsoft SQL Server,
instance X and instance Y. Each instance uses a different set of credentials for the sa account. You create a Run As
account with the sa credentials for instance X, and you create a different Run As account with the sa credentials for
instance Y. When you configure the SQL Server Run As profile, you associate both Run As account credentials—
for example, X and Y —with the profile and specify that the Run As account instance X credentials are to be used
for SQL Server instance X and that the Run As account Y credentials are to be used for SQL Server instance Y.
Then you must also configure each set of Run As account credentials to be distributed to physical computer ABC.
Example of Run As account distribution: SQL Server1 and SQL Server2 are two different physical computers. SQL
Server1 uses the UserName1 and Password1 set of credentials for the SQL sa account. SQL Server2 uses the
UserName2 and Password2 set of credentials for the SQL sa account. The SQL management pack has a single
SQL Run As profile that is used for all SQL Servers. You can then define one Run As account for UserName1 set
of credentials and another Run As account for the UserName2 set of credentials. Both of these Run As accounts
can be associated with the one SQL Server Run As profile and can be configured to be distributed to the
appropriate computers. That is, UserName1 is distributed to SQL Server1 and UserName2 is distributed to SQL
Server2. Account information sent between the management server and the designated computer is encrypted.
Run As account security

In System Center Operations Manager, Run As account credentials are distributed only to computers that you
specify (the more secure option). If Operations Manager automatically distributed the Runs As account according
to discovery, a security risk would be introduced into your environment as illustrated in the following example.
This is why an automatic distribution option was not included in Operations Manager.
For example, Operations Manager identifies a computer as hosting SQL Server 2016 based on the presence of a
registry key. It is possible to create that same registry key on a computer that is not actually running an instance of
SQL Server 2016. If Operations Manager were to automatically distribute the credentials to all agent managed
computers that have been identified as SQL Server 2016 computers, the credentials would be sent to the imposter
SQL Server and they would be available to anyone with administrator rights on that server.
When you create a Run As account using Operations Manager, you are prompted to choose whether the Run As
account should be treated in a Less secure or More secure fashion. “More secure” means that when you associate
the Run As account with a Run As profile, you have to provide the specific computer names that you want the Run
As credentials distributed to. By positively identifying the destination computers, you can prevent the spoofing
scenario that was described before. If you choose the less secure option, you will not have to provide any specific
computers and the credentials will be distributed to all agent-managed computers.
NOTE
The credentials you select for the Run As account must have at a minimum, logon locally rights; otherwise, the module will
fail.
Planning Security Credentials for Accessing Unix and
Linux Computers
7 minutes to read
This topic describes the credentials required to install, maintain, upgrade, and uninstall agents on a UNIX or Linux
computer.
In Operations Manager, the management server uses two protocols to communicate with the UNIX or Linux
computer:
Secure Shell (SSH) and Secure Shell File Transfer Protocol (SFTP )
Used for installing, upgrading, and removing agents.
actions, such as agent maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined
profiles according to their requirement for an unprivileged or privileged account.
In Operations Manager, the system administrator is no longer is required to provide the root password of the
UNIX or Linux computer to the management server. Now by elevation, an unprivileged account can assume the
identity of a privileged account on the UNIX or Linux computer. The elevation process is performed by the UNIX
su (superuser) and sudo programs that use the credentials that the management server supplies. For privileged
agent maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstallation, and agent
recovery), support for su, sudo elevation, and support for SSH key authentication (with or without passphrase) is
provided. For privileged WS -Management operations (such as viewing secure log files), support for sudo
elevation (without password) is added.
Credentials for installing agents

Operations Manager uses the Secure Shell (SSH) protocol to install an agent and Web Services for Management
(WS -Management) to discover previously installed agents. Installation requires a privileged account on the UNIX
or Linux computer. There are two ways to provide credentials to the targeted computer, as obtained by the
Computer and Device Management Wizard:
Specify a user name and password.
The SSH protocol uses the password to install an agent or the WS -Management protocol if the agent was
already installed by using a signed certificate.
Specify a user name and an SSH key. The key can include an optional passphrase.
If you are not using the credentials for a privileged account, you can provide additional credentials so that your
account becomes a privileged account through elevation of privilege on the UNIX or Linux computer.
The installation is not completed until the agent is verified. Agent verification is performed by the WS -
Management protocol that uses credentials maintained on the management server, separate from the privileged
account that is used to install the agent. You are required to provide a user name and password for agent
verification if you have done one of the following:
Provided a privileged account by using a key.
Provided an unprivileged account to be elevated by using sudo with a key.
Ran the wizard with the Discovery Type set to Discover only computers with the UNIX/Linux agent
installed.
Alternatively, you can install the agent, including its certificate, manually on the UNIX or Linux computer and then
discover that computer. This method is the most secure way to install agents. For more information, see Install the
Agent and Certificate on UNIX and Linux Computers Using the Command Line.
Credentials for monitoring operations and performing agent

maintenance
Operations Manager contains three predefined profiles to use in monitoring UNIX and Linux computers and
performing agent maintenance:
UNIX/Linux action account
This profile is an unprivileged account profile that is required for basic health and performance monitoring.
UNIX/Linux privileged account
This profile is a privileged account profile used for monitoring protected resources such as log files.
UNIX/Linux maintenance account
This profile is used for privileged maintenance operations, such as updating and removing agents.
In the UNIX and Linux management packs, all the rules, monitors, tasks, recoveries, and other management pack
elements are configured to use these profiles. Consequently, there is no requirement to define additional profiles
by using the Run As Profiles Wizard unless special circumstances dictate it. The profiles are not cumulative in the
scope. For example, the UNIX/Linux maintenance account profile cannot be used in place of the other profiles
simply because it is configured by using a privileged account.
In Operations Manager, a profile cannot function until it is associated with at least one Run As account. The
credentials for accessing the UNIX or Linux computers are configured in the Run As accounts. Because there are
no predefined Run As accounts for UNIX and Linux monitoring, you must create them.
To create a Run As account, you must run the UNIX/Linux Run As Account Wizard that is available when you
select UNIX/Linux Accounts in the Administration workspace. The wizard creates a Run As account based on
the choice of a Run As account type. There are two Run As account types:
Monitoring account
Use this account for ongoing health and performance monitoring in operations that communicate by using
WS -Management.
Agent maintenance account
Use this account for agent maintenance such as updating and uninstalling in operations that communicate
by using SSH.
These Run As account types can be configured for different levels of access according to the credentials that you
supply. Credentials can be unprivileged or privileged accounts or unprivileged accounts that will be elevated to
privileged accounts. The following table shows the relationships between profiles, Run As accounts, and levels of
access.
PROFILES RUN AS ACCOUNT TYPE ALLOWABLE ACCESS LEVELS
UNIX/Linux action account Monitoring account - Unprivileged

- Privileged
- Unprivileged, elevated to privileged
UNIX/Linux privileged account Monitoring account - Privileged

UNIX/Linux maintenance account Agent maintenance account - Privileged

Note that there are three profiles, but only two Run As Account types.
When you specify a Monitoring Run As Account Type, you must specify a user name and password for use by the
WS -Management protocol. When you specify an Agent Maintenance Run As Account Type, you must specify
how the credentials are supplied to the targeted computer by using the SSH protocol:
Specify a user name and a password.
Specify a user name and a key. You can include an optional passphrase.
After you created the Run As accounts, you must edit the UNIX and Linux profiles to associate them with the Run
As accounts you created. For detailed instructions, see How to Configure Run As Accounts and Profiles for UNIX
and Linux Access
Important security considerations

The Operations Manager Linux/UNIX agent uses the standard PAM (Pluggable Authentication Module)
mechanism on the Linux or UNIX computer to authenticate the user name and password specified in the Action
Profile and Privilege Profile. Any user name with a password that PAM authenticates can perform monitoring
functions, including running command lines and scripts that collect monitoring data. Such monitoring functions
are always performed in the context of that user name (unless sudo elevation is explicitly enabled for that user
name), so the Operations Manager agent provides no more capability than if the user name were to login to the
Linux/UNIX system.
However, the PAM authentication used by the Operations Manager agent does not require that the user name
have an interactive shell associated with it. If your Linux/UNIX account management practices include removing
the interactive shell as a way to pseudo-disable an account, such removal does not prevent the account from
being used to connect to the Operations Manager agent and perform monitoring functions. In these cases, you
should use additional PAM configuration to ensure that these pseudo-disabled accounts do not authenticate to
the Operations Manager agent.
Credentials for upgrading and uninstalling agents

The UNIX/Linux Agent Upgrade Wizard and the UNIX/Linux Agent Uninstall Wizard provide credentials
to their targeted computers. The wizards first prompt you to select the targeted computers to upgrade or
uninstall, followed by options on how to provide the credentials to the targeted computer:
Use existing associated Run As Accounts
Select this option to use the credentials associated with the UNIX/Linux action account profile and the
UNIX/Linux maintenance account profile.
The wizard alerts you if one or more of the selected computers do not have an associated Run As account
in the required profiles, in which case you must go back and clear those computers that do not have an
associated Run As account, or specify credentials.
Specify credentials
Select this option to specify Secure Shell (SSH) credentials by using a user name and password or a user
name and a key. You can optionally provide a passphrase with a key. If the credentials are not for a
privileged account, you can have them elevated to a privileged account on the target computered by using
the UNIX su or sudo elevation programs. The 'su' elevation requires a password. If you use sudo elevation,
you are prompted for a user name and password for agent verification by using an unprivileged account.
Authentication and Data Encryption in Operations
Manager
9 minutes to read
System Center Operations Manager consists of features such as the management server, gateway server,
Reporting server, Operational database, Reporting data warehouse, agent, web console, and Operations console.
This section explains how authentication is performed and identifies connection channels where the data is
encrypted.
Certificate-Based Authentication
When an Operations Manager agent and management server are separated by either an untrusted forest or
workgroup boundary, certificate-based authentication will need to be implemented. The following sections provide
information about these situations and specific procedures for obtaining and installing certificates from Windows-
based certification authorities.
Setting Up Communication Between Agents and Management Servers Within the Same Trust Boundary
An agent and the management server use Windows authentication to mutually authenticate with each other
before the management server accepts data from the agent. The Kerberos version 5 protocol is the default method
for providing authentication. In order for Kerberos-based mutual authentication to function, the agents and
management server must be installed in an Active Directory domain. If an agent and a management server are in
separate domains, full trust must exist between the domains. In this scenario, after mutual authentication has taken
place, the data channel between the agent and the management server is encrypted. No user intervention is
required for authentication and encryption to take place.
Setting Up Communication Between Agents and Management Servers Across Trust Boundaries
An agent (or agents) might be deployed into a domain (domain B ) separate from the management server (domain
A), and no two-way trust might exist between the domains. Because there is no trust between the two domains, the
agents in one domain cannot authenticate with the management server in the other domain using the Kerberos
protocol. Mutual authentication between the Operations Manager features within each domain still occurs. A
solution to this situation is to install a gateway server in the same domain where the agents reside, and then install
certificates on the gateway server and the management server to achieve mutual authentication and data
encryption. The use of the gateway server means you need only one certificate in domain B and only one port
through the firewall, as shown in the following illustration.
Setting Up Communication Across a Domain – Workgroup Boundary
In your environment, you may have one or two agents deployed to a workgroup inside your firewall. The agent in
the workgroup cannot authenticate with the management server in the domain using the Kerberos protocol. A
solution to this situation is to install certificates on both the computer hosting the agent and the management
server that the agent connects to, as shown in the following illustration.
NOTE
In this scenario, the agent must be manually installed.
Perform the following steps on both the computer hosting the agent and the management server using the same
certification authority (CA) for each:
1. Request certificates from the CA.
2. Approve the certificate requests on the CA.
3. Install the approved certificates in the computer certificate stores.
4. Use the MOMCertImport tool to configure Operations Manager.
NOTE
Certificates with the KEYSPEC other than 1 are not supported.
These are the same steps for installing certificates on a gateway server, except you do not install or run the
gateway approval tool
Confirming Certificate Installation
If you have properly installed the certificate, the following event is written into the Operations Manager event log.
TYPE SOURCE EVENT ID GENERAL
Information OpsMgr Connector 20053 The OpsMgr Connector has

loaded the specified
authentication certificate
successfully.
During the setup of a certificate, you run the MOMCertImport tool. When the MOMCertImport tool has finished,
the serial number of the certificate that you imported is written to the registry at the following subkey.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
Cau t i on
Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you
should back up any valued data on the computer.
Authentication and data encryption between management server,

Gateway server, and agents
Communication among these Operations Manager features begins with mutual authentication. If certificates are
present on both ends of the communications channel, then certificates will be used for mutual authentication;
otherwise, the Kerberos version 5 protocol is used. If any two features are separated across an untrusted domain,
mutual authentication must be performed using certificates. Normal communications, such as events, alerts, and
deployment of a management pack, occur over this channel. The previous illustration shows an example of an alert
being generated on one of the agents that is routed to the management server. From the agent to the gateway
server, the Kerberos security package is used to encrypt the data, because the gateway server and the agent are in
the same domain. The alert is decrypted by the gateway server and re-encrypted using certificates for the
management server. After the management server receives the alert, the management server decrypts the
message, re-encrypts it using the Kerberos protocol, and sends it to the management server where the
management server decrypts the alert. Some communication between the management server and the agent may
include credential information; for example, configuration data and tasks. The data channel between the agent and
the management server adds another layer of encryption in addition to the normal channel encryption. No user
intervention is required.
Management server and Operations console, Web console server, and

Reporting server
Authentication and data encryption between the management server and the Operations console, Web console
server, or Reporting server is accomplished by using Windows Communication Foundation (WCF ) technology.
The initial attempt at authentication is made by using the user's credentials. The Kerberos protocol is attempted
first. If the Kerberos protocol does not work, another attempt is made using NTLM. If authentication still fails, the
user is prompted to provide credentials. After authentication has taken place, the data stream is encrypted as a
function of either the Kerberos protocol or SSL, if NTLM is used.
In the case of a Reporting server and a management server, after authentication has occurred, a data connection is
established between the management server and SQL Server Reporting Server. This is accomplished by strictly
using the Kerberos protocol; therefore, the management server and Reporting Server must reside in trusted
domains. For more information about WCF, see the MSDN article What Is Windows Communication Foundation.
Management server and Reporting data warehouse

Two communication channels exist between a management server and the Reporting data warehouse:
The monitoring host process spawned by the health service (System Center Management service) in a
management server
The System Center Data Access services in the management server
Monitoring Host Process and Reporting Data Warehouse
By default, the monitoring host process spawned by the Health Service, which is responsible for writing collected
events and performance counters to the data warehouse, achieves Windows Integrated Authentication by running
as the Data Writer Account specified during Reporting Setup. The account credential is securely stored in a Run As
Account called Data Warehouse Action Account. This Run As Account is a member of a Run As Profile called Data
Warehouse Account (which is associated with the actual collection rules).
If the Reporting data warehouse and the management server are separated by a trust boundary (for example, each
resides in different domains with no trust), then Windows Integrated Authentication will not work. To work around
this situation, the monitoring host process can connect to the Reporting data warehouse using SQL Server
Authentication. To do this, create a new Run As Account (of Simple Account type) with the SQL account credential
and make it a member of the Run As Profile called Data Warehouse SQL Server Authentication Account, with the
management server as the target computer.
IMPORTANT
By default, the Run As Profile, Data Warehouse SQL Server Authentication Account was assigned a special account through
the use of the Run As Account of the same name. Never make any changes to the account that is associated with the Run As
Profile, Data Warehouse SQL Server Authentication Account. Instead, create your own account and your own Run As
Account and make the Run As Account a member of the Run As Profile, Data Warehouse SQL Server Authentication Account
when configuring SQL Server Authentication.
The following outlines the relationship of the various account credentials, Run As Accounts, and Run As Profiles
for both Windows Integrated Authentication and SQL Server Authentication.
Default: Windows Integrated Authentication
1. Run As Profile: Data Warehouse Account
Run As Account: Data Warehouse Action
Account credentials: Data Writer Account (specified during setup)
2. Run As Profile: Data Warehouse SQL Server Authentication Account
Run As Account: Data Warehouse SQL Server Authentication
Account credentials: Special account created by Operations Manager (do not change)
Optional: SQL Server Authentication
1. Run As Profile: Data Warehouse SQL Server Authentication Account
Run As Account: A Run As Account you specified during setup.
Account credentials: An account you specified during setup.
The System Center Data Access service and Reporting data warehouse
By default, the System Center Data Access service, which is responsible for reading data from the Reporting data
warehouse and making it available in the Report Parameter Area, achieves Windows Integrated Authentication by
running as the Data Access Service and Config Service account that was defined during setup of Operations
Manager.
If the Reporting data warehouse and the management server are separated by a trust boundary (for example, each
resides in different domains with no trust), then Windows Integrated Authentication would not work. To work
around this situation, the System Center Data Access service can connect to the Reporting data warehouse using
SQL Server Authentication. To do this, create a new Run As Account (of Simple Account type) with the SQL
account credential and make it a member of the Run As Profile called Reporting SDK SQL Server Authentication
Account with the management server as the target computer.
IMPORTANT
By default, the Run As Profile, Reporting SDK SQL Server Authentication Account was assigned a special account through the
use of the Run As Account of the same name. Never make any changes to the account that is associated with the Run As
Profile, Reporting SDK SQL Server Authentication Account. Instead, create your own account and your own Run As Account,
and make the Run As Account a member of the Run As Profile, Reporting SDK SQL Server Authentication Account when
configuring SQL Server Authentication.
The following outlines the relationship of the various account credentials, Run As Accounts, and Run As Profiles
for both Windows Integrated Authentication and SQL Server Authentication.
Default: Windows Integrated Authentication
1. Data Access Service and Config Service Account (defined during setup of Operations Manager)
Run As Profile: Reporting SDK SQL Server Authentication Account
Run As Account: Reporting SDK SQL Server Authentication Account
Account credentials: Special account created by Operations Manager (do not change)
2. Optional: SQL Server Authentication
Run As Profile: Data Warehouse SQL Server Authentication Account
Run As Account: A Run As Account you specified during setup.
Account credentials: An account you specified during setup.
Operations console and Reporting server

The Operations console connects to Reporting Server on port 80 using HTTP. Authentication is performed by
using Windows Authentication. Data can be encrypted by using the SSL channel.
Reporting server and Reporting data warehouse

Authentication between Reporting Server and the Reporting data warehouse is accomplished using Windows
Authentication. The account that was specified as the Data Reader Account during setup of Reporting becomes the
Execution Account on Reporting Server. If the password for the account should change, you will need to make the
same password change using the Reporting Services Configuration Manager in SQL Server. The data between the
Reporting Server and the Reporting data warehouse is not encrypted.
Data Encryption for Web console and Reporting
server Connections
3 minutes to read
You can configure the Operations Manager Web console and Reporting server to use Secure Sockets Layer (SSL )
connections to ensure that both incoming requests and outbound responses are encrypted prior to transmission.
Operations Manager can use Federal Information Processing Standard (FIPS ) compliant algorithms for secure
data encryption when accessing the Web console and when running reports in the Operations console from the
Reporting server.
Separate unique certificates will need to be requested and generated before you can proceed with configuring SSL
connections for either role.
Web console encryption

When you install the web console, you must specify a web site for use with the web console. The default port for
accessing the web console from a browser using Windows-based authentication is the same port as the web site
that is selected when the web console was installed. If the web site chosen has been configured to use SSL, then
you must also select Enable SSL.
You must also select an authentication mode for use with the web console. Use mixed authentication for intranet
scenarios and network authentication for extranet scenarios.
The web console uses two encryption algorithms:
SHA256
HMACSHA256
These algorithms may not be sufficient to meet compliance standards. For instance, they do not meet the Federal
Information Processing Standard (FIPS ). In order to meet a compliance standard, you need to map these names, in
the appropriate configuration files, to appropriate encryption algorithms.
Reporting server encryption

SQL Server Reporting Services Native mode uses the HTTP SSL (Secure Sockets Layer) service to establish
encrypted connections to a report server. If you have certificate (.cer) file installed in a local certificate store on the
report server computer, you can bind the certificate to a Reporting Services URL reservation to support report
server connections through an encrypted channel.
Because Internet Information Services (IIS ) also uses HTTP SSL, there are significant interoperability issues that
you must account for if you plan to run IIS and SQL Reporting Services on the same computer in support of
Operations Manager Reporting server. Be sure to review the Interoperability Issues with IIS section in the
Configure SSL Connections on a Native Mode Report Server for guidance on how to address these issues.
To configure SQL Server Reporting Services Native mode for SSL encryption before configuring Operations
Manager Reporting server to use SSL, please see Configure SSL Connections on a Native Mode Report Server.
FIPS Compliance
After you install these two roles, you need to manually edit several configuration files to enable this algorithm on
the IIS web server hosting the Web console, and the SQL Server report server.
Enabling FIPS compliance for System Center Operations Manager requires that the underlying infrastructure used
(Server OS, Active Directory etc.), also be FIPS compliant.
The following is a summarized list of steps required to configure FIPS for your Web console server.
Install the Microsoft.EnterpriseManagement.Cryptography.dll.
Edit several instances of the machine.config file.
Edit the WebHost\web.config file.
Edit the MonitoringView\web.config file.
You will need the Global Assembly Cache Tool, gacutil.exe. This utility is part of the Windows .NET Framework
SDK, which is a installation component included in the Windows Software Development Kit. For more information,
see Gacutil.exe (Global Assembly Cache Tool).
The following is a summarized list of steps required to configure FIPS for your Reporting server:
Change the configuration for the ReportServer and ReportManager Web.config file.
Certificates
You can configure the Operations Manager web console and report server to use Secure Sockets Layer (SSL )
connections to ensure that both incoming requests and outbound responses are encrypted prior to transmission.
Separate certificates will need to be requested and generated before you can proceed with configuring SSL
connections for either role. One unique certificate for the SQL server hosting reporting services and the other for
the server hosting the web console.
Next steps
To configure the Web console to use SSL encryption or support FIPS compliance, please review Configure
Authentication with the Web console
To configure the Reporting server to support FIPS compliance, please review Configure Authentication with
the Reporting server
Security Considerations for Microsoft Azure and
Office 365
3 minutes to read
Integration with Azure

The Azure monitoring pack runs on a specified agent and uses various Windows Azure APIs to remotely discover
and collect instrumentation information about a specified Windows Azure application. Secure communication and
authentication with Azure is performed by certificate authentication, which is required in order to successfully
monitor workloads hosted in Azure with Operations Manager.
If you don’t have a management certificate already, begin here by reviewing Certificates overview for Azure Cloud
Services.
For more information, see Introducing the Windows Azure Service Management API on the Windows Azure team
blog.
The Monitoring Pack for Windows Azure Applications creates three Run As profiles:
Windows Azure Run As Profile Blob
Windows Azure Run As Profile Password
Windows Azure Run As Profile Proxy
You must create Run As accounts for Windows Azure Run As Profile Blob and Windows Azure Run As Profile
Password. The account for Windows Azure Run As Profile Blob stores the certificate with the private key for the
Windows Azure application. The account for Windows Azure Run As Profile Password stores the password for the
private key.
Creating an account for Windows Azure Run As Profile Proxy is optional. The account for Windows Azure Run As
Profile Proxy stores credentials for access to the HTTP proxy server that is used to make API calls to Windows
Azure.
You must associate the Run As Account with an appropriate Run As profile. The Add Monitoring Wizard will
associate the Windows Azure Run As Profile Blob and Windows Azure Run As Profile Password profiles with the
accounts that you specify. If you create a Run As account for Windows Azure Run As Profile Proxy, you must
manually associate the Windows Azure Run As Profile Proxy profile with the account that you create.
Integration with Office 365

Office 365 management pack uses agentless monitoring approach. All monitoring workflows that communicate
with Office 365 Monitoring API are being executed on management servers only. An Office 365 user account with
Global Administrator permissions for the subscription is required for monitoring of an O365 subscription. It is
highly recommended to add a new dedicated user account to each Office 365 subscription you want to monitor. To
create a new user with Global Administrator permissions using Office 365 admin center:
1. Go to https://portal.office.com/UserManagement/ActiveUsers.aspx to open Office 365 admin center. Log in as
Subscription Global Administrator.
2. On Users and Groups tab: click Add button
3. Enter First name, Last name, Display name and User name and select a domain linked to the subscription. Note
that First and Last names are required for account with Global Administrator role.
4. On setting tab: select Global administrator role to be assigned to account. Specify alternate email address and
user location.
5. You are not required to assign Office 365 services licenses to the monitoring account
6. Specify an email address to receive a temporary password. Log out from Office 365 admin center and log in
again using new credentials received in the email.
7. Login to the Office 365 management portal using newly created credentials and set the password for the
account. Remember to use strong complex password because this account has Global administrator
permissions.
NOTE
Management Pack workflows are unable to obtain monitoring data, Connection State monitor sets Subscription
health to “Critical” state and generates “(401) Unauthorized” Alert until new Global Administrator account is used to
login to the Office 365 management portal at least once.
Configure Run As profiles

The Office 365 management pack creates two Run As Profiles:
Office 365 Subscription Password secure reference
Office 365 Subscription Password secure reference Run As Profile is used to store Office 365
subscription credentials and shouldn’t be edited manually
Office 365 Subscription Proxy secure reference

Office 365 Subscription Proxy secure reference Run As Profile should be configured manually. This profile is
used by all rules and monitors defined in this Management Pack. All Run As Accounts mapped to this profile
should have following permissions:
Be a member of “Operations Manager Operators” System Center Operations Manager user role.
Be able to establish an HTTPS connection from the Management Server to the Office 365 portal
endpoint. Please check firewall and proxy settings within your environment to ensure that
aforementioned connection is allowed.
Deploying System Center Operations Manager
4 minutes to read
All System Center Operations Manager individual management group deployments will either be an "all-in-one"
installation, where all features are loaded on a single server, or a distributed installation. Installations can then be
combined together to form an overall Operations Manager infrastructure that consists of multiple management
groups. These management groups can then relate to each other as your business needs require.
This section of the Deployment Guide describes an individual management group deployment, where you have
one management group, but the features of Operations Manager are either installed on a single server or
distributed over several servers.
Single Server Deployment of Operations Manager
Distributed Deployment of Operations Manager
For information about connecting management groups, see Connecting Management Groups in Operations
Manager.
Before you begin

Before you begin your deployment, you should read the release notes, and ensure that your server meets the
minimum system requirements for Operations Manager. For more information, see:
Release Notes for System Center Operations Manager 1807
Release Notes for System Center Operations Manager 1801
Release Notes for System Center 2016 - Operations Manager
System Requirements for System Center Operations Manager
Operations Manager Administrators role assignment
The System Center Operations Manager setup procedure automatically assigns the Administrators group on the
local computer to the Operations Manager Administrators role. You must be logged on with an account that has
local Administrator rights to run Setup on the first management server that you install; this ensures that you can
open the Operations console after Setup is completed. When you install additional management servers, you
must use a Domain account of which you are a member.
Required accounts
During setup, you are prompted for three accounts, the management server action account, the System
Center Configuration service and System Center Data Access service account, and the Data Warehouse
Write account. In Operations Manager, you can use the same account for the System Center Configuration
and System Center Data Access service services.
If you install Reporting, you are prompted for one additional account, the Data Reader account. For further
information regarding the specific privileges to be granted before running setup and what rights are assigned to
the accounts during setup, please review the Service, User, and Security accounts guidance.
NOTE
If you create a specific account for installation, this account must be a member of the sysadmin server role for Microsoft
SQL Server, but also have access to the master database.
NOTE
If you install multiple management servers, you are prompted for a management server action account and a System
Center Configuration service and System Center Data Access service account each time you add a management
server. You must provide the same accounts for each installation.
SQL Server requirements

System Center Operations Manager requires access to an instance of a server running Microsoft SQL Server.
This instance can be located on a separate computer from the management servers in a distributed installation or
on the first management server in the management group. In either case, the instance of Microsoft SQL Server
must already exist and be accessible before you start your first management server installation. The SQL Server
Collation setting must be a supported value, and SQL Full Text Search must be enabled. To review which versions
of SQL Server are supported for Operations Manager, see SQL Server requirements in the SQL Server Design
Considerations planning article.
During setup, you are prompted for the following:
The SQL Server database server name, Always On availability group name, or primary cluster name and
instance name. If you have installed SQL Server by using the default instance, you only have to specify the
SQL Server name.
You can accept the default values for or set:
SQL Server Port number. By default, 1433.
A new operational database (for first management server installation in the management group) or an
existing operational database (when installing additional management servers in an existing management
group).
The database name. By default, OperationsManager.
The starting database size. By default, 1000 MB.
The Data file and Log folder locations. By default, these are C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Data or C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Log as appropriate to the SQL Server defaults.
IMPORTANT
If TCP/IP is disabled on a remote server that is hosting the SQL Server database, Setup will not be able to connect to the
SQL Server database. To resolve this issue, enable TCP/IP on the remote server.
Ensure that SQL Server Reporting Services has been correctly installed and configured. For more information
about how to install and configure SQL Server Reporting Services, see SQL Server Installation (SQL Server
2014). For more information about how to install and configure SQL Server 2016 Reporting Services, see SQL
Server Installation (SQL Server 2016).
For additional information to help you properly plan your SQL Server configuration in support of Operations
Manager, see SQL Server Design Considerations.
Next steps
To deploy the Windows agent from the Operations console using the Discovery Wizard, review Install
Agent on Windows Using the Discovery Wizard
If you would like to manually install the Windows agent from the command line or automate the
deployment using a script or other automation solution, review Install Windows Agent Manually Using
MOMAgent.msi
If you would like to install the Nano Server agent from the command line or automate the deployment
using a script or other automation solution, review Install Agent on Nano Server
To deploy the agent to UNIX and Linux computers from the Operations console using the Discovery
Wizard, review Install Agent on UNIX and Linux Using the Discovery Wizard
Single server deployment of Operations Manager
2 minutes to read
The single server management group scenario combines all the management group roles that can coexist onto a
single server running as a member server in an Active Directory domain. This instance can be on dedicated
hardware or on a virtual computer. You can deploy the Operations console to computers other than the single
server, and access the web console with a browser.
You deploy Operations Manager in a single-server management group when you want to use it for evaluation,
testing, and management pack development, usually in a lab, development, or non-production environment.
Operations Manager services

The single server management group configuration supports the following services:
1. Monitoring and alerting
2. Reporting (available in the Operations console but not in the web console)
3. Audit collection
4. Agent-less exception management
5. Data (accessed by using the web console and the Operations console)
Operations Manager features

The single server management group configuration combines these features:
Audit Collection Services (ACS ) collector
ACS database
ACS forwarder
Operations console
Reporting data warehouse database
Reporting database
Reporting server
Web console server
Command Shell
Restrictions
The single server management group configuration is the easiest to deploy, but there are limitations to its
capabilities and therefore limitations to what it is commonly used for.
Gateway server
This configuration does not include the gateway server role. Because of this, all monitored devices must be in the
same Active Directory forest as the management server or you must use certificates on both the managed
computer and the management server to provide for mutual authentication.
High availability and redundancy
The single server, single management group resides on a single set of hardware or virtual machine. This
configuration supports only one instance of each server role and therefore does not support agent failover
between management servers.
Common uses
This configuration is most commonly used for evaluation, testing, and management pack development purposes,
usually in non-production or pre-production environments. Single-server management group configurations
generally lack the robustness and performance to support anything but the smallest production loads.
Ports used
In this configuration, you need to make sure that network ports are opened for communication between the agents
and the management server, between the Operations console and the management server, and between the Web
console and the management server. All other inter-service communication occurs on the management server
itself. The ports are as follows:
Operations console to management server: TCP 5724
Operations console to Reporting server: TCP 80
Web console to Web console server: TCP 51908 is the default port when you select Windows
Authentication. If you chose Forms Authentication, the port will be user-defined.
Agent to management server: TCP 5723
ACS forwarder to ACS collector: TCP 51909
Agentless management: occurs over remote procedure call (RPC ) dynamic port
Management server to UNIX\Linux computer: TCP 1270
Management server to UNIX\Linux computer for special discovery and troubleshooting: TCP 22
For a complete listing of ports used, the direction of the communication, and if the ports can be configured, see
Configuring a Firewall for Operations Manager.
Next steps
To deploy Operations Manager in a single server management group, see Walkthrough: Installing Operations
Manager on a Single Server.
Distributed deployment of Operations Manager
2 minutes to read
The distributed management group installation will form the foundation of 99 percent of Operations Manager
deployments. It allows for the distribution of features and services across multiple servers to allow for scalability.
It can include all Operations Manager server roles and supports the monitoring of devices across trust
boundaries through the use of the gateway server.
System Center - Operations Manager features

This configuration supports all System Center - Operations Manager features:
Monitoring and alerting, targeted for up to 15,000 agents
Monitoring across trust boundaries
Reporting
Audit collection
Agentless exception management
Agent failover between management servers
Gateway failover between management servers
Clustering high availability for database roles
Operations Manager server roles

This configuration supports all Operations Manager server roles:
Audit Collection Services (ACS ) collector
ACS database
ACS forwarder (on agent-managed devices)
Gateway server
Management server
Operations console
Operations Manager Reporting server
Web console server
This section of the Deployment Guide contains the following topics:
How to install an Operations Manager management server
How to install the Operations console
How to install an Audit Collection Services (ACS ) collector and database
How to install the Operations Manager Reporting server
How to deploy a gateway server
How to install an Operations Manager management
server
13 minutes to read
In System Center Operations Manager, the first feature you install is the management server. The setup procedure
creates the operational database and data warehouse database. The procedure described in this topic assumes that
you have already installed a supported version of Microsoft SQL Server. If you are hosting the Operations
Manager operational and data warehouse database on a SQL Always On Availability Group, be sure to use the
node planned for the initial Primary replica for initial installation of these databases.
You must ensure that your server meets the minimum system requirements for System Center Operations
Manager. For more information, see System Requirements for System Center - Operations Manager.
Once you have installed the first management server and created the management group, you can follow the steps
for installing an additional management server if you are planning to include additional management servers to
provide high availability and increased capacity for your monitoring workloads.
NOTE
If your security policies restrict TLS 1.0 and 1.1, installing a new Operations Manager 2016 management server role will fail
because the setup media does not include the updates to support TLS 1.2. The only way you can install this role is by
enabling TLS 1.0 on the system, apply Update Rollup 4, and then enable TLS 1.2 on the system. This limitation does not
apply to Operations Manager version 1801.
To install the first management server in the management group

2. On the Operations Manager installation media, run Setup.exe, and then click Install.
3. On the Getting Started, Select features to install page, select the Management server feature. You can
also select any of the additional features listed. For example, to also install the Operations console, select
Operations console. To read more about each feature and its requirements, click Expand all, or expand
the buttons next to each feature, and then click Next.
4. On the Getting Started, Select installation location page, accept the default value, type a new location
or browse to one, and then click Next.
IMPORTANT
You might receive a message that indicates that ASP.NET 4 is not registered with Internet Information Services (IIS).
To resolve this problem, open a Command Prompt window, select Run as administrator, and then run the following
command:
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -r
7. On the Configuration, Specify an installation option page, select Create the first Management
server in a new management group, type a name for your management group, and then click Next.
NOTE
After the management group name is set, it cannot be changed. The Management Group name cannot contain the
following characters:, ( ) ^ ~ : ; . ! ? " , ' ` @ # % \ / * + = $ | & [ ] <>{}, and it cannot have a leading or trailing space.
It is recommended that the Management Group name be unique within your organization if you plan to connect
several management groups together.
select I have read, understood and agree with the license terms, and then click Next.
server that will host the operational database.
If you installed SQL Server by using the default instance, you only have to type the server name.
If you changed the default SQL Server port, you must type the new port number in the SQL Server
port box.
If you are hosting the database on a SQL Server cluster, replace computer with the virtual network
name of the cluster.
If the database is part of a SQL Always On Availability Group, replace computer\<instance> with the
availability group listener and for SQL Server port, type the port number of the availability group
listener.
As you type the values for the SQL Server and instance names, you see a red circle with a white X in
it appear to the left of the Server name and instance name and SQL Server port boxes. The white
X indicates that the values have not yet been validated, and the black text indicates that you have not
entered any illegal characters. If you enter illegal characters, the text itself turns red.
You entered an instance of SQL Server or a SQL Server port value that is not valid or that
does not exist.
The instance of SQL Server that you specified does not have the required configuration or
features.
You can hover the cursor over the Server name and instance name text box to view additional
10. After you type the correct value for the SQL Server database server name, click the SQL Server port box
so that Setup will attempt to validate the values you typed for the SQL Server name and for the port
number.
11. In the Database name, Database size (MB ), Data file folder, and Log file folder boxes, we recommend
NOTE
IMPORTANT
<path> placeholder with the location of SQL Server.
mofcomp.exe <path>\Microsoft SQL Server\100\Shared\sqlmgmproviderxpsp2up.mof
NOTE
The SQL Server model database size must not be greater than 100 MB. If it is, you might encounter an error in Setup
regarding the inability to create a database on SQL due to user permissions. To resolve the issue, you must reduce
the size of the model database.
12. When the Configuration, Configure the data warehouse database page opens, in the Server name
and instance name box, type the server name and the name of the instance of SQL Server for the
database server that will host the data warehouse database.
port box.
If you are hosting the database on a SQL Server cluster, replace computer with the virtual network name
of the cluster.
listener.
13. Because this is the first management server installation, accept the default value of Create a new data
warehouse database.
14. In the Database name, Database size (MB ), Data file folder, and Log file folder boxes, we recommend
IMPORTANT
<path> placeholder with the location of SQL Server.
NOTE
15. On the Configuration, Configure Operations Manager accounts page, we recommend that you use the
Domain Account option for the Management server action account, the System Center
Configuration service and System Center Data Access service account, the Data Reader account,
and the Data Writer account. None of them should have domain administrator credentials. Click Next.
17. If Windows Update is not enabled on the computer, the Configuration, Microsoft Update page appears.
18. Review the options on the Configuration, Installation Summary page, and then click Install. Setup
continues.
19. When Setup is finished, the Setup is complete page appears. Click Close.
20. Open the Operations console.
21. In the Operations console, in the navigation pane, click the Administration button, and then expand
Device Management.
22. In Device Management, select Management Servers. In the results pane, you should see the
management server that you just installed with a green check mark in the Health State column.
To install additional management servers in the management group
Perform the following steps to add additional management servers in your management group.
3. On the Getting Started, Select features to install page, select the Management server feature. You can
also select any of the additional features listed. For example, to also install the Operations console, select
Operations console. To read more about each feature and its requirements, click Expand all, or expand
the buttons next to each feature, and then click Next.
4. On the Getting Started, Select installation location page, accept the default value, type a new location
or browse to one, and then click Next.
5. On the Configuration, Specify an installation option page, select Add a Management server to an
existing management group, and then click Next.
select I have read, understood and agree with the license terms, and then click Next.
server that will host the operational database.
port box.
If you are hosting the database on a SQL Server cluster, replace computer with the virtual network
name of the cluster.
listener.
As you type the values for the SQL Server and instance names, you see a red circle with a white X in
it appear to the left of the Server name and instance name and SQL Server port boxes. The white
X indicates that the values have not yet been validated, and the black text indicates that you have not
entered any illegal characters. If you enter illegal characters, the text itself turns red.
You entered an instance of SQL Server or a SQL Server port value that is not valid or that
does not exist.
The instance of SQL Server that you specified does not have the required configuration or
features.
You can hover the cursor over the Server name and instance name text box to view additional
8. After you type the correct value for the SQL Server database server name, click the SQL Server port box
so that Setup will attempt to validate the values you typed for the SQL Server name and for the port
number.
9. Select the database name from the Database name drop-down list, and then click Next.
10. On the Configuration, Configure Operations Manager accounts page, we recommend that you use the
Domain Account option for the Management server action account and the System Center
Configuration service and System Center Data Access service account. None of them should have
domain administrator credentials. Click Next.
IMPORTANT
You must provide the same credentials for the Management server action account and the System Center
Configuration Service and System Center Data Access service that you provided when you created the first
management server in your management group.
continues.
15. On a computer with the Operations console installed, sign on with an account that is a member of the
Operations Manager Administrators group and launch the Operations console.
16. In the Operations console, in the navigation pane, click the Administration button, and then expand
Device Management.
17. In Device Management, select Management Servers. In the results pane, you should see the
To install the first management server in the management group from

the Command Prompt
2. Open the Command Prompt window by using the Run as Administrator option.
NOTE
3. Change the path to where the Operations Manager setup.exe file is located, and run the following
command.
IMPORTANT
/UseLocalSystemActionAccount ) and Data Access service ( /UseLocalSystemDASAccount ). To specify a
domain\user name for these accounts, you must provide the following parameters instead.
setup.exe /silent /install /components:OMServer

/SqlServerInstance: <server\instance or Always On availability group listener>
/DWSqlServerInstance: <server\instance or Always On availability group listener>
/DWSqlInstancePort: <SQL instance port number>
To install additional management servers in the management group

from the Command Prompt
NOTE
command.
IMPORTANT
/UseLocalSystemActionAccount ) and Data Access service ( /UseLocalSystemDASAccount ). To specify a
domain\user name for these accounts, you must provide the following parameters instead.
setup.exe /silent /install /components:OMServer

/SqlServerInstance: <server\instance or Always On availability group listener>
/DataReaderUser: <domain\username>
/DataReaderPassword: <password>
Next steps
See Distributed Deployment of Operations Manager to understand the sequence and steps for installing the
Operations Manager server roles across multiple servers in your management group.
How to Install the Operations console
2 minutes to read
After you install System Center - Operations Manager, you can install the Operations console on other servers and
computers. For example, you might want to view monitoring data from your desktop computer.
You must ensure that the computer that will host the Operations console meets the minimum system
requirements. For more information, see System Requirements for System Center - Operations Manager
To install the Operations console

1. Log on to the computer that will host the Operations console with an account that has local administrative
credentials.
3. On the Getting Started, Select features to install page, select Operations console. To read more about
what each feature provides and its requirements, click Expand all, or expand the buttons next to each
feature, and then click Next.
4. On the Getting Started, Select installation location page, accept the default location, or type a new
location or browse to one, and then click Next.
5. On the Prerequisites page, review and address any warnings or errors that the Prerequisites checker
returns, and then click Verify Prerequisites Again.
6. If the Prerequisite checker returns no warnings or errors, the Prerequisites, Proceed with Setup page
appears. Click Next.
7. On the Configuration, Help improve System Center - Operations Manager page, select your options,
and then click Next.
continues.
10. When Setup is finished, the Setup is complete page appears. Click Close, and the Operations console
opens.
11. In the Operations console, on the Connect to Server page, type the name of the first management server
that you installed in the management group in the Server name box, and then click Connect.
IMPORTANT
If you are going to edit company knowledge on this computer, you also have to install the Microsoft Visual Studio 2010
Tools for Office Second Edition Runtime.
IMPORTANT
Company knowledge cannot be edited with the x64 version of Microsoft Word 2010. You must install the x86 version of
Microsoft Office 2010 or an earlier version to edit knowledge.
To install the Operations console from the Command Prompt

command.
setup.exe /silent /install /components:OMConsole /EnableErrorReporting:

[Never|Queued|Always]/SendCEIPReports:[0|1] /UseMicrosoftUpdate: [0|1]
Next steps
8 minutes to read
You can install the web console when you install System Center - Operations Manager, or you can install it
separately. You can install a stand-alone web console or install it on an existing management server that meets the
prerequisites. For information about the prerequisites, see System Requirements for System Center Operations
Manager.
IMPORTANT
If you install a stand-alone web console on a server, you will not be able to add the management server feature to this
server. If you want to install the management server and web console on the same server, you must either install both
features simultaneously, or install the management server before you install the web console.
When you install the web console, the following three components are installed:
Operations Manager web console
Application Diagnostics console
Application Advisor console
NOTE
If Application Diagnostics console is not installed, when viewing APM alerts, you will not be able to use the link embedded in
the alert description to launch the APM event details. To use this feature, install the web console within the management
group.
If you plan to use network load balancing with Application Diagnostics console and Application Advisor console,
be sure to use sticky sessions. This ensures that the same instance of the console is used for the entire session. For
more information about network load balancing, see Network Load Balancing. For more information about
sessions, see Support for Sessions.
NOTE
A Network Load Balancer is not supported for the Operations Manager web console server.
IMPORTANT
The web console operates with sensitive data, such as clear text user credentials, server names, IP addresses, and so on. If
these are exposed on the network, they can represent a significant security risk. If Internet Information Services (IIS) does not
have Secure Sockets Layer (SSL) configured, you are advised to configure it manually. For more information about security
see Data Encryption for Web console and Reporting server Connections
If the web console does not have sufficient access to the operational database or the data warehouse database, you
will receive a warning during the web console configuration step. You can proceed with Setup, but the web console
will not be configured correctly for .NET Application monitoring. To resolve this issue, you can have your database
administrator run the following SQL Server statement on both the operational database and data warehouse
database:
EXEC [apm].GrantRWPermissionsToComputer N'[LOGIN]'
The local and remote parameters are as follows:

For local installation, the LOGIN is: IIS APPPOOL\OperationsManagerAppMonitoring
For remote installation, the LOGIN is: Domain\MachineName$
NOTE
If you run Repair on the web console after installation, the settings that were selected during installation will be restored.
Any changes that you manually make to the web console configuration after the installation will be reset.
To install a stand-alone Web console
NOTE
If your security policies restrict TLS 1.0 and 1.1, installing a new Operations Manager 2016 Web console role will fail because
the setup media does not include the updates to support TLS 1.2. The only way you can install this role is by enabling TLS
1.0 on the system, apply Update Rollup 4, and then enable TLS 1.2 on the system. This limitation does not apply to
Operations Manager version 1801.
1. Log on to the computer that will host the web console with an account that has local administrative
credentials.
3. On the Getting Started, Select features to install page, select Web console. To read more about what
each feature provides and its requirements, click Expand all, or expand the buttons next to each feature,
4. On the Getting Started, Select installation location page, accept the default location, or type in a new
NOTE
returns, and then click Verify Prerequisites Again to recheck the system.
NOTE
Installation of the web console requires that ISAPI and CGI Restrictions in IIS be enabled for ASP.NET 4. To enable
this, select the web server in IIS Manager, and then double-click ISAPI and CGI Restrictions. Select ASP.NET
v4.0.30319, and then click Allow.
7. On the Configuration, Please read the license terms page, review the Microsoft Software License
Terms, select I have read, understood and agree with the license terms, and then click Next.
8. On the Configuration, Specify a management server page, enter the name of a management server
that only the web console uses, and then click Next.
9. On the Configuration, Specify a web site for use with the Web console page, select the Default Web
Site, or the name of an existing website. Select Enable SSL only if the website has been configured to use
Secure Sockets Layer (SSL ), and then click Next.
WARNING
Installing the web console on a computer that has SharePoint installed is not supported.
NOTE
If you install the management server on a server using a domain account for System Center Configuration service
and System Center Data Access service, and then install the web console on a different server and select Mixed
Authentication, you may need to register Service Principle Names and configure constraint delegations, as described
in Running the Web Console Server on a standalone server using Windows Authentication.
11. On the Diagnostic and Usage Data page, please review data collection terms and then click Next to
continue.
12. If Microsoft Update is not enabled on the computer, the Configuration, Microsoft Update page appears.
Select your option, and then click Next.
13. Review your selections on the Configuration, Installation Summary page, and then click Install. Setup
continues.
To install the Web console on an existing Management server
1. Log on to the computer that is hosting a management server with an account that has local administrative
credentials.
3. On the Getting Started, What do you want to do? page, click Add a feature.
4. On the Getting Started, Select features to install page, select Web console, and then click Next.
5. On the Prerequisites page, review and address any warnings or errors, and then click Verify
Prerequisites Again to recheck the system.
NOTE
Installation of the System Center - Operations Manager web console requires that ISAPI and CGI Restrictions in IIS
be enabled for ASP.NET 4. To enable this, select the web server in IIS Manager, and then double-click ISAPI and CGI
Restrictions. Select ASP.NET v4.0.30319, and then click Allow.
6. If the Prerequisite checker returns no warnings or errors, the Prerequisites, Proceed with Setup page
appears. Click Next.
7. On the Configuration, Please read the license terms page, review the Microsoft Software License
Terms, select I have read, understood and agree with the license terms, and then click Next.
8. On the Configuration, Specify a web site for use with the Web console page, select the Default Web
Site, or the name of an existing website. Select Enable SSL only if the website has been configured to use
Secure Sockets Layer (SSL ), and then click Next.
Select your option, and then click Next.
11. Review your selections on the Configuration, Installation Summary page, and click Install. Setup
continues.
12. On the Setup is complete page, click Close.
IMPORTANT
The Default website must have an http or https binding configured.
To install a Web console by using the Command Prompt window

1. Log on to the computer with an account that has local administrative credentials.
2. Open a Command Prompt window by using the Run as Administrator option.
command.
IMPORTANT
Use the /WebConsoleSSL parameter only if your website has Secure Sockets Layer (SSL) activated.
For a default web installation, specify Default Web Site for the /WebSiteName parameter.
NOTE
The /ManagementServer parameter is only required when you are installing the web console on a server that is not a
management server.
setup.exe /silent /install /components:OMWebConsole

/ManagementServer: <ManagementServerName>
To configure permissions inheritance for the Web console

The following steps are for configuring permission inheritance for the System Center - Operations Manager Web
console.
1. In Windows Explorer, navigate to the MonitoringView folder in the installation directory for the web
console (by default, C:\Program Files\System Center <version>\Operations
Manager\WebConsole\MonitoringView ), right-click the TempImages folder, and click Properties.
2. On the Security tab, click Advanced.
3. On the Permissions tab, click Change Permissions.
4. Select the Include inheritable permissions from this object's parent checkbox.
5. In Permission entries, click Administrators, and then click Remove. Repeat for the SYSTEM entry, and
then click OK.
6. Click OK to close Advanced Security Settings for TempImages, and then click OK to close
TempImages Properties.
All information and content at http://blogs.technet.com/b/momteam/archive/2008/01/31/running-the-web-
console-server-on-a-standalone-server-using-windows-authentication.aspx is provided by the owner or the users
of the website. Microsoft makes no warranties, express, implied or statutory, as to the information at this website.
Next steps
How to install an Audit Collection Services (ACS)
collector and database
4 minutes to read
Use the following procedures to install an Audit Collection Services (ACS ) collector and database and to start the
service for the ACS collector computer. Both procedures are performed on the computer that is designated as your
ACS collector.
The ACS database runs on a supported version of Microsoft SQL Server. The Audit Collection Services Collector
Setup wizard creates the ACS database on an existing installation of Microsoft SQL Server. To complete the
installation procedure, you must be a member of the local Administrators group on both the ACS collector and the
ACS database computers as well as a database administrator on the ACS database. As a best practice for security,
consider using Run As to perform this procedure.
To install an ACS collector and an ACS database

2. On the Operations Manager installation media, run Setup.exe, and then click Audit collection services.
For monitoring UNIX and Linux computers, click Audit collection services for UNIX/Linux.
The Audit Collection Services Collector Setup wizard opens.
3. On the Welcome page, click Next.
4. On the License Agreement page, read the licensing terms, click I accept the agreement, and then click
Next.
5. On the Database Installation Options page, click Create a new database, and then click Next.
6. On the Data Source page, in the Data source name box, type a name that you want to use as the Open
Database Connectivity (ODBC ) data source name for your ACS database. By default, this name is
OpsMgrAC. Click Next.
7. On the Database page, if the database is on a separate server than the ACS collector, click Remote
Database Server, and then type the computer name of the database server that will host the database for
this installation of ACS. Otherwise, click Database server running locally.
8. In the Database server instance name field, type the name of the server and the name of the SQL Server
instance, if not the default instance, for the database server that will host the ACS database. In the
Database name field, the default database name of OperationsManagerAC is automatically entered. You
can select the text and type in a different name or leave the default name. Click Next.
9. On the Database Authentication page, select one of the authentication methods. If the ACS collector and
the ACS database are members of the same domain, you can select Windows authentication, otherwise
select SQL authentication, and then click Next.
NOTE
If you select SQL authentication and click Next, the Database Credentials page displays. In the SQL login name
box, enter the name of the user account that has access to the SQL Server and the password for that account in the
SQL password box, and then click Next.
10. On the Database Creation Options page, click Use SQL Server's default data and log file directories
to use SQL Server's default folders. Otherwise, click Specify directories and enter the full path, including
drive letter, to the location you want for the ACS database and log file, for example C:\Program
Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data. Click Next.
11. On the Event Retention Schedule page, click Local hour of day to perform daily database
maintenance. Choose a time when the number of expected security events is low. During the database
maintenance period, database performance will be impacted. In the Number of days to retain events box
type the number of days ACS should keep events in the ACS database before the events are removed
during database grooming. The default value is 14 days. Click Next.
12. On the ACS Stored Timestamp Format page, choose Local or Universal Coordinated Time, formerly
known to as Greenwich Mean Time, and then click Next
13. The Summary page displays a list of actions that the installation program will perform to install ACS.
Review the list, and then click Next to begin the installation.
NOTE
If a SQL server login dialog box displays and the database authentication is set to Windows authentication, click
the correct database and verify that the Use Trusted Connection check box is checked. Otherwise click to remove
the check and enter the SQL login name and password. Click OK.
14. When the installation is complete, click Finish.
To deploy ACS reporting

1. Log on to the server that will be used to host ACS reporting as a user that is an administrator of the SSRS
instance.
2. Create a temporary folder, such as C:\acs.
3. On your installation media, go to \ReportModels\acs and copy the directory contents to the temporary
installation folder.
There are two folders (Models and Reports) and a file named UploadAuditReports.cmd.
4. On your installation media, go to \SupportTools and copy the file ReportingConfig.exe into the
temporary acs folder.
5. Open a Command Prompt window by using the Run as Administrator option, and then change directories
to the temporary acs folder.
6. Run the following command.
UploadAuditReports "<AuditDBServer\Instance>" "<Reporting Server URL>" "<path of the copied acs folder>"
For example:
UploadAuditReports "myAuditDbServer\Instance1" "http://myReportServer/ReportServer$instance1" "C:\acs"
This example creates a new data source called Db Audit, uploads the reporting models Audit.smdl and
Audit5.smdl, and uploads all reports in the acs\reports directory.
NOTE
The reporting server URL needs the reporting server virtual directory ( ReportingServer_<InstanceName> ) instead
of the reporting manager directory ( Reports_<InstanceName> ).
7. Open Internet Explorer and enter the following address to view the SQL Reporting Services Home page.
http://<yourReportingServerName>/Reports_<InstanceName>
8. Click Audit Reports in the body of the page and then click Show Details in the upper right part of the
page.
9. Click the Db Audit data source.
10. In the Connect Using section, select Windows Integrated Security and click Apply.
Next steps
How to install the Operations Manager Reporting
server
5 minutes to read
In this procedure, the Reporting server is installed on a stand-alone server that is hosting the SQL Server database
and SQL Server Reporting Services.
WARNING
Although SQL Server Reporting Services is installed on the stand-alone server, Operations Manager reports are not accessed
on this server; instead, they are accessed in the Reporting workspace in the Operations console.
You must ensure that your server meets the minimum system requirement for Operations Manager. For more
information, see System Requirements for System Center - Operations Manager.
NOTE
If your security policies restrict TLS 1.0 and 1.1, installing a new Operations Manager 2016 Reporting services role will fail
Installing Operations Manager reporting

No other applications that are using SQL Server Reporting Services can be installed on this instance of SQL
Server.
Ensure that SQL Server Reporting Services has been correctly installed and configured. For more information
about how to install and configure SQL Server Reporting Services, see SQL Server Installation.
NOTE
Before you continue with this procedure, ensure that the account you plan to use for the Data Warehouse Write account has
SQL Server logon rights and is an Administrator on the computers hosting both the operational database and the Reporting
data warehouse database. Otherwise, Setup fails, and all changes are rolled back, which might leave SQL Server Reporting
Services in an inoperable state.
To verify that Reporting Services is configured correctly

1. Verify that the ReportServer and ReportServerTempDB databases in SQL Server Management Studio
are located on the stand-alone server. Open SQL Server Management Studio, and then connect to the
default database instance. Open the Databases node and verify that the two Reporting Services databases
exist under this node.
2. Verify the correct configuration of SQL Server Reporting Services. Click Start, point to Programs, point to
the appropriate offering of Microsoft SQL Server, point to Configuration Tools, and then click Reporting
Services Configuration Manager. Connect to the instance on which you installed Reporting Services.
3. In the navigation pane, select the <servername>\SQLinstance . This displays the Report Server status in the
results pane. Ensure that the Report Server Status is Started.
4. In the navigation pane, select Scale-out Deployment, and then ensure that the Status column has the
value of Joined.
5. If Report Server is not started and the Scale out Deployment is not joined, check the configuration of
Service Account, Web Service URL, and Database.
6. Confirm that the SQL Server Reporting Services service is running. On the taskbar, click Start, point to
Administrative Tools, and then click Services.
7. In the Name column, find the SQL Server Reporting Services instance service and verify that its status
reads Started and that the Startup Type is Automatic.
8. In the Name column, find the SQL Server Agent service and verify that its status reads Started and that
its Startup Type is Automatic.
9. Verify that the Report Server website is functioning and available by browsing to
http://\<servername>/reportserver/_<$instance> . You should see a page with the
<servername>/ReportServer/_<$instance> and the text, Microsoft SQL Server Reporting Services Version
##.#.####.## where the # is the version number of your SQL Server installation.
10. Verify that the Report Manager website is configured correctly by opening Internet Explorer and browsing
to http://<servername>/reports/_<$instance> .
11. In the Report Manager website, click New Folder to create a new folder. Enter a name and description, and
then click OK. Ensure that the new, created folder is visible on the Report Manager website.
To install Operations Manager reporting
1. Log on to the computer with an account that has local administrative credentials.
3. On the Getting Started, Select features to install page, select the Reporting server feature. To read
more about each feature and its requirements, click Expand all, or expand the buttons next to each feature,
4. On the Getting Started, Select installation location page, accept the default value, or type a new
6. If the Prerequisites checker does not return any warnings or errors, continue to the Prerequisites, Proceed
with Setup page. Click Next.
7. On the Configuration, Specify a Management server page, enter the name of a management server
that is used by the Reporting features only. Then click Next.
8. On the Configuration, SQL Server instance for reporting services page, select the instance of SQL
Server that hosts SQL Server Reporting Services, and then click Next.
9. On the Configuration, Configure Operations Manager accounts page, enter the credentials for the
Data Reader account, and then click Next.
10. On the Configuration, Help improve System Center - Operations Manager page, select your options,
continues.
To install Operations Manager reporting from the Command Prompt
command.
NOTE
The /ManagementServer parameter is only required when you are installing reporting on a server that is not a
management server.
setup.exe /silent /install /components:OMReporting

/ManagementServer:<ManagementServerName>
/SRSInstance:<server\instance>
/DataReaderUser:<domain\username>
/DataReaderPassword:<password>
/SendODRReports:[0|1]
/UseMicrosoftUpdate:[0|1]
/AcceptEndUserLicenseAgreement:1
To confirm the health of Operations Manager reports

1. Open the Operations console, and select the Reporting workspace.
NOTE
After initial deployment, reports can require up to 30 minutes to appear.
2. Click Microsoft ODR Report Library, and then double-click any of the reports listed. The selected report
is then generated and displayed in a new window.
By default, you should see the following reports:
Alerts Per Day
Instance Space
Management Group
Management Packs
Most Common Alerts
3. Close the report window.
Next steps
Connecting to the Reporting Data Warehouse Across
a Firewall
2 minutes to read
This section describes how to configure your environment to support placing the Report data warehouse behind a
firewall for System Center Operations Manager.
In an environment where the Reporting data warehouse is separated from the management server and Reporting
server by a firewall, Windows Integrated Authentication cannot be used. You need to configure SQL Server
Authentication. The following sections explain how to enable SQL Server Authentication between the
management server, the Reporting server, and the Reporting data warehouse, as shown in the following
illustration:
Management Server and Reporting Data Warehouse

The following steps are necessary to enable SQL Server Authentication:
1. On the computer hosting the Reporting data warehouse, create a SQL Server Login in the proper role for
reader and writer. The credentials you supply for this account must be made a member of the following
roles in the data warehouse database on the computer running SQL Server: a. OpsMgrWriter
b. db_owner (only for the owning management group in the database)
2. On the computer hosting the management server, create a Run As Account (of type Simple) with the
credentials from the previous step.
3. Associate this Run As Account with the Run As Profile called Data Warehouse SQL Server Authentication
Account, targeting this Run As Profile to each management server. For more information, see [How to
Change the Run As Account Associated with a Run As Profile] in this guide.
If there is a firewall between the management server and the Reporting data warehouse, you will have to open
port 1433.
Reporting Server and Reporting Data Warehouse

If there is a firewall or trust boundary between the Reporting Server and the Reporting data warehouse, point-to-
point communications will need to be established.
The account that was specified as the Data Reader Account during setup of Reporting becomes the Execution
Account on Reporting Server, and it is this account that will be used to connect to the Reporting data warehouse.
Identify what port number the computer running SQL Server on the Reporting data warehouse is using and enter
this number into the dbo.MT_DataWarehouse table in the Operations Manager database. See the article, How to
Configure the Reporting Data Warehouse to Listen on a Specific TCP IP Port.
Reporting Server and Management Server Separated by a Firewall

A "Could not verify if current user is in sysadmin Role" error message might display when installing the Reporting
server role if the reporting server and the management server are separated by a firewall. This error message
might display even if the proper firewall ports have been opened. This error occurs after entering the computer
name for the management server and clicking Next. This error might also display because Reporting Setup was
unable to connect to the operational database. In this environment, determine what port number the SQL Server
instance is using and configure the Operations Manager database to use the port number. See the article, How to
Configure the Operations Manager Database to Listen on a Specific TCP IP Port.
Next steps
Review the list of reports installed with Operations Manager, to understand the different types of reports
that are available and their purpose.
How to Run, Save, and Export a Report walks you through how to preview your reports, save them with
specific report parameters to minimize repeated entry of information or to simplify the experience for your
report users, and how to export the report to different file formats.
Install a gateway server
7 minutes to read
Gateway servers are used to enable agent-management of computers that are outside the Kerberos trust
boundary of management groups, such as in a domain that is not trusted. The gateway server acts as a
concentration point for agent-to-management server communication. Agents in domains that are not trusted
communicate with the gateway server and the gateway server communicates with one or more management
servers. Because communication between the gateway server and the management servers occurs over only one
port (TCP 5723), that port is the only one that has to be opened on any intervening firewalls to enable
management of multiple agent-managed computers. Multiple gateway servers can be placed in a single domain so
that the agents can failover from one to the other if they lose communication with one of the gateway servers.
Similarly, a single gateway server can be configured to failover between management servers so that no single
point of failure exists in the communication chain.
Because the gateway server resides in a domain that is not trusted by the domain that the management group is
in, certificates must be used to establish each computer's identity, agent, gateway server, and management server.
This arrangement satisfies the requirement of Operations Manager for mutual authentication.
You must ensure that your server meets the minimum system requirements for System Center - Operations
Manager. For more information, see System Requirements for System Center Operations Manager.
NOTE
If your security policies restrict TLS 1.0 and 1.1, installing a new Operations Manager 2016 gateway server role will fail
How to deploy a gateway server

1. Request certificates for any computer in the agent, gateway server, management server chain.
2. Import those certificates into the target computers by using the MOMCertImport.exe tool.
3. Distribute the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe to the management server.
4. Run the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe tool to initiate communication
between the management server and the gateway
5. Install the gateway server.
Preparing for installation

Before you start
1. Deployment of gateway servers requires certificates. You need to have access to a certification authority
(CA). This can be a public CA such as VeriSign, or you can use Microsoft Certificate Services. This procedure
provides the steps to request, obtain, and import a certificate from Microsoft Certificate Services.
2. Reliable name resolution must exist between the agent-managed computers and the gateway server and
between the gateway server and the management servers. This name resolution is typically done through
DNS. However, if it is not possible to get proper name resolution through DNS, it might be necessary to
manually create entries in each computer's hosts file.
NOTE
The hosts file is located in the \Windows\system32\drivers\ directory, and it contains directions for configuration.
Obtaining computer certificates from Microsoft Certificate Services

For more information, see Active Directory Certificate Services
Distributing the Microsoft.EnterpriseManagement.GatewayApprovalTool
The Microsoft.EnterpriseManagement.GatewayApprovalTool.exe tool is needed only on the management server,
and it only has to be run once.
To c o p y M i c r o so ft .En t e r p r i se M a n a g e m e n t .G a t e w a y A p p r o v a l To o l .e x e t o m a n a g e m e n t se r v e r s
1. From a target management server, open the Operations Manager installation media \SupportTools\ (amd64
or x86) directory.
2. Copy the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe from the installation media to the
Operations Manager installation directory.
Registering the gateway with the management group
This procedure registers the gateway server with the management group, and when this is completed, the gateway
server appears in the Discovered Inventory view of the management group.
To r u n t h e g a t e w a y a p p r o v a l t o o l
1. On the management server that was targeted during the gateway server installation, log on with the
Operations Manager Administrator account.
2. Open a command prompt, and navigate to the Operations Manager installation directory or to the directory
that you copied the Microsoft.EnterpriseManagement.gatewayApprovalTool.exe to.
3. At the command prompt, run
Microsoft.EnterpriseManagement.gatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN>
/GatewayName=<GatewayFQDN> /Action=Create
NOTE
To prevent the gateway server from initiating communication with a management server, include the
/ManagementServerInitiatesConnection parameter on the command line.
4. If the approval is successful, you will see The approval of server <GatewayFQDN> completed successfully.
5. If you need to remove the gateway server from the management group, run the same command, but
substitute the /Action=Delete flag for the /Action=Create flag.
6. Open the Operations console to the Monitoring view. Select the Discovered Inventory view to see that the
gateway server is present.
Installing gateway server
This procedure installs the gateway server. The server that is to be the gateway server should be a member of the
same domain as the agent-managed computers that will be reporting to it.
TIP
An installation will fail when starting Windows Installer (for example, installing a gateway server by double-clicking
MOMGateway.msi) if the local security policy User Account Control: Run all administrators in Admin Approval Mode is
enabled.
To r u n O p e r a t i o n s M a n a g e r G a t e w a y W i n d o w s I n st a l l e r fr o m a C o m m a n d P r o m p t w i n d o w
1. On the Windows desktop, click Start, point to Programs, point to Accessories, right-click Command
Prompt, and then click Run as administrator.
2. In the Administrator: Command Prompt window, navigate to the local drive that hosts the Operations
Manager installation media.
3. Navigate to the directory where the .msi file is located, type the name of the .msi file, and then press ENTER.
To i n st a l l t h e g a t e w a y se r v e r
1. Log on to the gateway server with Administrator rights.

2. From the Operations Manager installation media, start Setup.exe.
3. In the Install area, click the Gateway management server link.
4. On the Welcome screen, click Next.
5. On the Destination Folder page, accept the default, or click Change to select a different installation
directory, and then click Next.
6. On the Management Group Configuration page, type the target management group name in the
Management Group Name field, type the target management server name in the Management Server
field, check that the Management Server Port field is 5723, and then click Next. This port can be changed
if you have enabled a different port for management server communication in the Operations console.
7. On the Gateway Action Account page, select the Local System account option, unless you have
specifically created a domain-based or local computer-based gateway Action account. Click Next.
8. On the Microsoft Update page, optionally indicate if you want to use Microsoft Update, and then click
Next.
9. On the Ready to Install page, click Install.
10. On the Completing page, click Finish.
To I n st a l l t h e g a t e w a y se r v e r fr o m t h e C o m m a n d P r o m p t
1. Log on to the gateway server with Administrator rights.

3. Run the following command, where path\Directory is the location of the Momgateway.msi, and path\Logs
is the location where you want to save the log file. Momgateway.msi can be found in the Operations
%WinDir%\System32\msiexec.exe /i path\Directory\MOMGateway.msi /qn /l*v C:\Logs\GatewayInstall.log

ADDLOCAL=MOMGateway
MANAGEMENT_GROUP="<ManagementGroupName>"
IS_ROOT_HEALTH_SERVER=0
ROOT_MANAGEMENT_SERVER_AD=<ParentMSFQDN>
ROOT_MANAGEMENT_SERVER_DNS=<ParentMSFQDN>
ACTIONS_USE_COMPUTER_ACCOUNT=0
ACTIONSDOMAIN=<DomainName>
ACTIONSUSER=<ActionAccountName>
ACTIONSPASSWORD=<Password>
ROOT_MANAGEMENT_SERVER_PORT=5723
[INSTALLDIR=<path\Directory>]
Importing certificates with the MOMCertImport.exe tool

Perform this operation on each gateway server, management server, and computer that will be agent-managed
and that is in a domain that is not trusted.
To i m p o r t c o m p u t e r c e r t i fi c a t e s b y u si n g M O M C e r t I m p o r t .e x e
1. Copy the MOMCertImport.exe tool from the installation media \SupportTools\ (amd64 or x86) directory to
the root of the target server or to the Operations Manager installation directory if the target server is a
management server.
2. As an administrator, open a Command Prompt window and change the directory to the directory where
MOMCertImport.exe is, and then run momcertimport.exe /SubjectName <certificate subject name> . This
makes the certificate usable by Operations Manager.
Configuring gateway servers for failover between management servers
Although gateway servers can communicate with any management server in the management group, this must be
configured. In this scenario, the secondary management servers are identified as targets for gateway server
failover.
Use the Set-SCOMParentManagementServer command in the Operations Manager shell, as shown in the
following example, to configure a gateway server to failover to multiple management servers. The commands can
be run from any Command Shell in the management group.
To c o n fi g u r e g a t e w a y se r v e r fa i l o v e r b e t w e e n m a n a g e m e n t se r v e r s
1. Log on to the management server with an account that is a member of the Administrators role for the
management group.
2. On the Windows desktop, click Start, point to Programs, point to System Center Operations Manager,
and then click Command Shell.
3. In Command Shell, run the following commands:
$GatewayServer = Get-SCOMGatewayManagementServer -Name "ComputerName.Contoso.com"
$FailoverServer = Get-SCOMManagementServer -Name
"ManagementServer.Contoso.com","ManagementServer2.Contoso.com" Set-
SCOMParentManagementServer -GatewayServer $GatewayServer -FailoverServer $FailoverServer
To chain multiple gateway servers

It is sometimes necessary to chain multiple gateways together in order to monitor across multiple untrusted
boundaries. This topic describes how to chain multiple gateways together.
NOTE
You should install one gateway at a time and verify that each newly installed gateway is configured correctly before adding
another gateway in the chain.
1. On the management server that was targeted during the gateway server installation, run the
Microsoft.EnterpriseManagement.GatewayApprovalTool.exe tool to initiate communication between the
management server and the gateway.
2. Open a command prompt, and navigate to the Operations Manager installation directory or, and then run the
following:
Microsoft.EnterpriseManagement.gatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN>
/GatewayName=<GatewayFQDN> /Action=Create
3. Install the gateway server on a new server.
4. Configure the certificates between gateways in the same way that you would configure certificates between a
gateway and a management server. The Health Service can only load and use a single certificate. Therefore, the
same certificate is used by the parent and child of the gateway in the chain.
Next steps
Upgrading System Center Operations Manager
9 minutes to read
This section of the Deployment Guide provides information about how to upgrade to System Center 2019 from an
older supported version. You can upgrade to Operations Manager 2019 from Operations Manager versions 2016,
1801 or 1807.
It is assumed in this guide that you are performing an upgrade from System Center 2016, 1801, or 1807. For
information about installing Operations Manager on a computer where no previous version of Operations
Manager exists, see Deploying System Center Operations Manager.
NOTE
If your Operations Manager management group is integrated with Microsoft Azure Log Analytics (Formerly referred to as
Microsoft Operations Management Suite (OMS)), its configuration will be retained and continue to function normally after
the upgrade is complete.
WARNING
If you are upgrading two or more System Center components, you should review the upgrade process for each component.
The order in which you perform component upgrades is important. Failure to follow the correct upgrade sequence might
result in component failure for which no recovery options exist. The following list are the affected System Center components
integrated with Operations Manager and the recommended upgrade sequence:
2. Service Manager - if you configured the connectors to import alert and configuration item data of objects discovered and
monitored from Operations Manager.
3. Data Protection Manager - if you have configured the central console to centrally manage your DPM environment.
5. Virtual Machine Manager - if you have configured integration with Operations Manager to monitor the health of your
VMM components, the virtual machines and virtual machine hosts.
Before you upgrade to System Center Operations Manager, you must first determine whether all servers in your
Operations Manager management group meet the minimum supported configurations. For more information, see
System Requirements: System Center Operations Manager.
There are several options for upgrade:
1. If you run upgrade on a single-server management group, you only need to run the upgrade one time since
all features are installed on a single server. The Operations Manager Upgrade wizard performs system
prerequisite checks and provides resolution steps for any issues. Installation will not continue until you
resolve all issues.
2. If you are upgrading a distributed management group, you must upgrade certain features before others.
For example, you upgrade the management servers first, followed by the gateways, operations consoles,
and then agents. Next, you can upgrade any remaining features, such as the web console, reporting and
Audit Collection Services (ACS ). You must also perform a number of pre-upgrade and post-upgrade tasks.
3. If you want to maintain your earlier version of Operations Manager (2016, 1801, 1807) Operations
Manager environment, you can install version 2019 in parallel, upgrade your agents and multi-home them
between both management groups.
Operations Manager 1801 and 1807 Yes
In-place upgrade
System Center 2016
System Center 1801
System Center 1807
High level overview of upgrade steps for a distributed management

group
The following steps outline the process for upgrading a distributed management group:
1. Accomplish Pre-Upgrade Tasks
2. Upgrade the initial management server and then additional management servers (each management server
must be upgraded)
3. Upgrade ACS (because the ACS server must be on same machine as a management server, we recommend
you perform this step along with the upgrade of the management server on which ACS resides.)
4. *Upgrade Gateway(s)
5. Upgrade Console
6. Push install to agent(s) / upgrade manually installed agents
7. Upgrade Web Console
8. Upgrade Reporting Server
9. Perform Post-Upgrade Tasks
*Steps 4 through 8 can be performed in parallel after all management servers have been upgraded.
High level overview of upgrading agents and running two

environments
The following upgrade path supports customers in an Operations Manager scenario with parallel environments,
sharing agents, so that the original System Center supported version environment is left intact. Agents that have
been upgraded to System Center 2019 Operations Manager on your upgrade path, are fully capable of working
with native Operations Manager 2016, 1801 and 1807 functionality.
Agents can be upgraded before the new Operations Manager management group is deployed and then configured
to multi-home between the original management group and the new management group using your existing
automation solution, or they can be upgraded after by discovering and performing a push-install from the new
Operations Manager management group. For further information, see How to Upgrade Agents in a Parallel
Deployment.
1. Retain the original System Center Operations Manager environment.
2. Set up a new System Center Operations Manager environment with management servers, gateway,
Operations Manager Database, Operations Manager Data Warehouse, Operations console, Web console,
and Reporting server.
3. Upgrade the System Center Operations Manager agents in your original management group to the same
version of the new management group using either one of the following options:
a. Push-Install option
b. Manual / Command-line option
Next steps
To understand the pre-upgrade tasks you should perform to complete the upgrade to your management
group, see Pre-Upgrade Tasks When Upgrading to System Center Operations Manager.
To understand the post-upgrade tasks you should perform to complete the upgrade to your management
group, see Post-Upgrade Tasks When Upgrading to System Center Operations Manager.
This section of the Deployment Guide provides information about how to upgrade to System Center 2016 -
Operations Manager or version 1801 from an older supported version.
It is assumed in this guide that you are performing an upgrade to System Center 2016 - Operations Manager or
version 1801. For information about installing Operations Manager on a computer where no previous version of
Operations Manager exists, see Deploying System Center Operations Manager.
NOTE
If your Operations Manager 2012 R2 or Operations Manager 2016 management group is integrated with Microsoft Azure
Log Analytics (Formerly referred to as Microsoft Operations Management Suite (OMS)), its configuration will be retained and
continue to function normally after the upgrade is complete.
WARNING
If you are upgrading two or more System Center components, you should review the upgrade process for each component.
The order in which you perform component upgrades is important. Failure to follow the correct upgrade sequence might
result in component failure for which no recovery options exist. The following list are the affected System Center components
integrated with Operations Manager and the recommended upgrade sequence:
2. Service Manager - if you configured the connectors to import alert and configuration item data of objects discovered and
monitored from Operations Manager.
3. Data Protection Manager - if you have configured the central console to centrally manage your DPM environment.
5. Virtual Machine Manager - if you have configured integration with Operations Manager to monitor the health of your
VMM components, the virtual machines and virtual machine hosts.
Before you upgrade to System Center Operations Manager, you must first determine whether all servers in your
Operations Manager management group meet the minimum supported configurations. For more information, see
System Requirements: System Center Operations Manager.
There are several options for upgrade:
1. If you run upgrade on a single-server management group, you only need to run upgrade one time since all
features are installed on a single server. The Operations Manager Upgrade wizard performs system
prerequisite checks and provides resolution steps for any issues. Installation will not continue until you
resolve all issues.
2. If you are upgrading a distributed management group, you must upgrade certain features before others.
For example, you upgrade the management servers first, followed by the gateways, operations consoles,
and then agents. Next, you can upgrade any remaining features, such as the web console, reporting and
Audit Collection Services (ACS ). You must also perform a number of pre-upgrade and post-upgrade tasks.
3. If you want to maintain your Operations Manager 2012 R2 or System Center 2016 - Operations Manager
environment, you can install version 1801 in parallel, upgrade your agents and multi-home them between
both management groups.
4. If you want to maintain your Operations Manager 2012 R2 environment you can install System Center
2016 - Operations Manager in parallel, upgrade your agents and multi-home them between both
management groups.
In-place upgrade
System Center Operations Manager 1801 supports an in-place upgrade from the following versions:
High level overview of upgrade steps for a distributed management

group
The following steps outline the process for upgrading a distributed management group:
1. Accomplish Pre-Upgrade Tasks
2. Upgrade the initial management server and then additional management servers (each management server
must be upgraded)
3. Upgrade ACS (because the ACS server must be on same machine as a management server, we recommend
you perform this step along with the upgrade of the management server on which ACS resides.)
4. *Upgrade Gateway(s)
5. Upgrade Console
6. Push install to agent(s) / upgrade manually installed agents
7. Upgrade Web Console
8. Upgrade Reporting Server
9. Perform Post-Upgrade Tasks
*Steps 4 through 8 can be performed in parallel after all management servers have been upgraded.
High level overview of upgrading agents and running two

environments
The following upgrade path supports customers in an Operations Manager scenario with parallel environments,
sharing agents, so that the original System Center 2012 R2 Operations Manager or Operations Manager 2016
environment is left intact. Agents that have been upgraded to System Center 2016 Operations Manager or version
1801 depending on your upgrade path, are fully capable of working with native System Center 2012 R2
Operations Manager or Operations Manager 2016 functionality.
Agents can be upgraded before the new Operations Manager management group is deployed and then configured
to multi-home between the original management group and the new management group using your existing
automation solution, or they can be upgraded after by discovering and performing a push-install from the new
Operations Manager management group. For more information, see How to Upgrade Agents in a Parallel
Deployment.
1. Retain the original System Center 2012 R2 Operations Manager or Operations Manager 2016
environment.
2. Set up a new System Center Operations Manager environment with management servers, gateway,
Operations Manager Database, Operations Manager Data Warehouse, Operations console, Web console,
and Reporting server.
3. Upgrade the System Center Operations Manager agents in your original management group to the same
version of the new management group using either one of the following options:
a. Push-Install option
b. Manual / Command-line option
Next steps
To understand the pre-upgrade tasks you should perform to complete the upgrade to your management
group, see Pre-Upgrade Tasks When Upgrading to System Center Operations Manager.
Pre-Upgrade tasks when upgrading to System
Center Operations Manager
5 minutes to read
Perform the following pre-upgrade tasks in the order presented before you begin the upgrade process to System
Center 2016 - Operations Manager or version 1801.
1. Review the Operations Manager Event Logs
2. Clean up the Database (ETL Table)
3. Configure agents to failover between multiple gateway servers so all agents reporting to a gateway have a
failover gateway assigned.
4. Remove Agents from Pending Management
5. Disable Notification Subscriptions
6. Disable any connectors
7. Stop the Microsoft Monitoring Agent, System Center Data Access Service, System Center Configuration
Management, and Microsoft Monitoring Agent services on all management servers except the one being
upgraded
8. Verify that the Operational Database Has More Than 50 Percent Free Space
9. Back up the Operations Manager Databases
10. Update the agent's health service cache size temporarily to prevent loss of data while Management, and
Gateway servers are upgraded.
11. Stop the application pool of Operations Manager and MonitoringViews in IIS server.
Review the Operations Manager event logs

Review the event logs for Operations Manager on the management servers to look for recurring warning or
critical events. Address them and save a copy of the event logs before you perform your upgrade.
Cleanup the database (ETL table)

As part of upgrade to System Center Operations Manager installation (setup) includes a script to cleanup ETL
tables, grooming the database. However, in cases where there are a large number of rows (greater than 100,000)
to cleanup, we recommend running the script before starting the upgrade to promote a faster upgrade and
prevent possible timeout of setup. Performing this pre-upgrade task in all circumstances ensures a more efficient
installation.
To cleanup ETL
To cleanup the ETL table, run the following script on the SQL Server hosting the Operations Manager database:
-- (c) Copyright 2004-2006 Microsoft Corporation, All Rights Reserved --
-- Proprietary and confidential to Microsoft Corporation --
-- File: CatchupETLGrooming.sql --
-- Contents: A bug in the ETL grooming code could have left the customer --
-- Database with a large amount of ETL rows to groom. This script will groom --
-- The ETL entries in a loop 100K rows at a time to avoid filling up the --
-- Transaction log --
---------------------------------------------------------------------------------
DECLARE @RowCount int = 1;
DECLARE @BatchSize int = 100000;
DECLARE @SubscriptionWatermark bigint = 0;
DECLARE @LastErr int;
-- Delete rows from the EntityTransactionLog. We delete the rows with TransactionLogId that aren't being
-- used anymore by the EntityChangeLog table and by the RelatedEntityChangeLog table.
SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();
WHILE(@RowCount > 0)
BEGIN
DELETE TOP(@BatchSize) ETL
FROM EntityTransactionLog ETL
WHERE NOT EXISTS (SELECT 1 FROM EntityChangeLog ECL WHERE ECL.EntityTransactionLogId =
ETL.EntityTransactionLogId) AND NOT EXISTS (SELECT 1 FROM RelatedEntityChangeLog RECL
WHERE RECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND ETL.EntityTransactionLogId < @SubscriptionWatermark;
SELECT @LastErr = @@ERROR, @RowCount = @@ROWCOUNT;
END
NOTE
Cleanup of ETL can require several hours to complete.
Remove Agents from pending management

Before you upgrade a management server, remove any agents that are in Pending Management.
1. Log on to the Operations console by using an account that is a member of the Operations Manager
Administrators role for the Operations Manager management group.
2. In the Administration pane, expand Device Management, and then click Pending Management.
3. Right-click each agent, and then click Approve or Reject.
Disable notification subscriptions

You must disable notification subscription before you upgrade the management group to ensure that notifications
are not sent during the upgrade process.
1. Log on to the Operations console account that is a member of the Operations Manager Administrators role
for the Operations Manager management group.
2. In the Operations console, select the Administration view.
3. In the navigation pane, expand Administration, expand the Notifications container, and then click
Subscriptions.
4. Select each subscription, and then click Disable in the Actions pane.
NOTE
Multiselect does not work when you are disabling subscriptions.
Disable connectors
Refer to the non-Microsoft connector documentation for any installed Connectors to determine the services used
for each Connector.
To stop a service for a Connector, perform the following steps:
1. On the Start menu, point to Administrative Tools, and then click Services.
2. In the Name column, right-click the Connector that you want to control, and then click Stop.
Verify the Operations Manager database has more than 50 percent

free
You must verify that the operational database has more than 50 percent of free space before you upgrade the
management group because the upgrade might fail if there is not enough space. Ensure that the transactions logs
are 50 percent of the total size of the operational database.
1. On the computer that hosts the operational database, open SQL Server Management Studio.
2. In the Object Explorer, expand Databases.
3. Right-click the Operations Manager database, select to Reports, Standard Reports, and then click Disk
Usage.
4. View the Disk Usage report to determine the percentage of free space.
If the database does not have 50 percent free, perform the following steps to increase it for the upgrade:
1. On the computer that hosts the operational database, open SQL Server Management Studio.
2. In the Connect to Server dialog box, in the Server Type list, select Database Engine.
3. In the Server Name list, select the server and instance for your operational database (for example,
computer\INSTANCE1).
4. In the Authentication list, select Windows Authentication, and then click Connect.
5. In the Object Explorer pane, expand Databases, right-click the Operations Manager database, and then
click Properties.
6. In the Database Properties dialog box, under Select a page, click Files.
7. In the results pane, increase the Initial Size value for the MOM_DATA database by 50 percent.
NOTE
This step is not required if free space already exceeds 50 percent.
8. Set the Initial Size value for the MOM_LOG transaction log to be 50 percent of the total size of the
database. For example, if the operational database size is 100 GB, the log file size should be 50 GB. Then
click OK.
Back up the Operations Manager databases

Obtain verified recent backups of the operational database and of the data warehouse database before you
upgrade the secondary management server. You should also create backups of databases for optional features,
such as the Reporting and the Audit Collection Services database before you upgrade them. For more
information, see Create a Full Database Backup (SQL Server).
Stop Operations Manager services on Management servers

Before upgrading the first management server in your management group, it is recommended to stop the
Operations Manager services - System Center Data Access, System Center Configuration, and Microsoft
Monitoring Agent on all other management servers to avoid any issues while the operational and data warehouse
databases are being updated.
Increase agent HealthService cache size

To ensure the agents can queue data during the upgrade, update the following registry setting on the agents
manually or automated with your configuration management or orchestration solution:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlsSet\Services\HealthService\Parameters\Management
Groups<ManagementGroupName>\maximumQueueSizeKb
The default decimal value of DWORD type is 15360 (15 MB ) and the recommended value to change it to is 76800
(75 MB ).
Once you have completed the upgrade of the management group, you can reset it back to the default value.
Next steps
To continue with the upgrade, review Upgrade overview.
How to upgrade a single server management group
3 minutes to read
When you upgrade a single server management group to System Center 2016 - Operations Manager or version
1801, all features that are installed on the server are upgraded. Before you begin the upgrade process, make sure
that your server meets the minimum supported configurations. For more information, see System Requirements
for System Center Operations Manager.
To upgrade a single server management group
1. Log on to the server with an account that is a member of the Operations Manager Administrators role for
your Operations Manager management group, a member of the SQL Server sysadmin fixed server role, and
a local administrator on the computer.
2. On the Operations Manager media, run Setup.exe, and then click Install.
NOTE
The Getting Started page displays information about what will be upgraded. Click Next to proceed with the
upgrade.
3. On the Getting Started, Please read the license terms page, read the Microsoft Software License Terms,
click I have read, understood, and agree with the license terms, and then click Next.
NOTE
returns, and then click Verify prerequisites again to recheck the system.
NOTE
Microsoft SQL Server Full Text Search must be enabled on the SQL Server hosting the OperationsManager and
OperationsManagerDW databases.
6. If the Prerequisites checker does not return any other errors or warnings that have to be addressed, click
Next.
7. On the Configuration, Configure Operations Manager accounts page, enter the domain account or
Local System credentials for the System Center Configuration and Data Access service accounts, and then
click Next.
IMPORTANT
If you receive a message about using the wrong version of SQL Server, or experience a problem with the SQL Server
Windows Management Instrumentation (WMI) provider, you can resolve this. Open a Command Prompt window by
using the Run as administrator option. Then run the following command, replace the <path> placeholder with the
location of Microsoft SQL Server:
8. When the Ready to Upgrade page appears, review the upgrade summary, and then click Upgrade.
To upgrade a single server management group from the Command Prompt
1. Log on to the server with an account that is a member of the Operations Manager Administrators role for
your Operations Manager management group, a member of the SQL Server sysadmin fixed server role, and
a local administrator on the computer.
2. Open an elevated Command Prompt by using the Run as Administrator option.
3. Change the path to where the Operations Manager Setup.exe file is located.
IMPORTANT
Use the /WebConsoleUseSSL parameter only if your website has Secure Sockets Layer (SSL) activated. For a default
web installation, specify Default Web Site for the /WebSiteName parameter.
IMPORTANT
The following commands assume that you specified the Local System for the Data Access service
(/UseLocalSystemDASAccount ). To specify a domain\user name for these accounts, you must provide the following
parameters instead: /DASAccountUser: <domain\username> /DASAccountPassword: <password>
4. Run the following command.
setup.exe /silent /install

/components:OMServer,OMConsole,OMWebConsole,OMReporting
/SqlServerInstance: <server\instance>
/SqlServerInstance: <SQL server instance port number>
/DWSqlServerInstance: <server\instance>
/DWSqlInstancePort: <SQL server instance port number>
/SRSInstance: <server\instance>
/SendODRReports: [0|1]
TIP
If you want to upgrade a specific component, you can add
/components: <component name1> [<, component name2>][ <, component name3>]
After you have upgraded your single-server management group, you can upgrade the agents.
Verifying the upgrade

To confirm the health of the management server
1. In the Operations console, in the navigation pane, click Administration.
2. Under Device Management, click Management Servers. In the results pane, you should see the
Next steps
How to upgrade a management server - upgrading a
distributed management group
3 minutes to read
When you upgrade a distributed management group to to System Center 2016 - Operations Manager or version
1801, you start by upgrading each of the management servers in your management group. There are a number of
pre-upgrade tasks that you must perform first. For more information, see Pre-Upgrade Tasks When Upgrading to
System Center Operations Manager.
IMPORTANT
Between the time that you upgrade the management servers and upgrade the agents, you might experience Application
Platform Monitoring (APM)-related event log entries on the agent-managed servers. These event log entries might occur on
agent-managed servers that are not APM-enabled. These event log entries will be resolved when you complete the upgrade
of the agents. You might have to restart the health service after the agent is upgraded in order to clear the events.
NOTE
Because the ACS Collector server must be on same machine as a management server, we recommend you perform the steps
described in How to Upgrade an ACS Collector along with the upgrade of the management server on which ACS resides.
IMPORTANT
When upgrading multiple management servers in a distributed management group, you must wait to start upgrade of
additional management servers until after setup on the first management server completes. Failing to do so can cause a SQL
update script that runs early in the set up process to run on multiple management servers and result in database issues. This
SQL update script only needs to run on the initial management server being upgraded.
NOTE
When upgrading multiple management servers in a distributed management group, sequence the upgrades in a manner that
best suits your business needs. Upgrade all management servers in the distributed management group as soon as possible
after the initial management server is upgraded to verify that your upgraded environment is healthy.
To upgrade a management server

1. Log on to the Operations Manager management server with an account that is a member of the Operations
Manager Administrators role for your Operations Manager management group, a member of the SQL
Server sysadmin fixed server role, and a local administrator on the computer.
2. From the Operations Manager media, run Setup.exe, and then click Install. The Getting Started page
displays information about which features will be upgraded.
3. On the Getting Started page, click Next to proceed with the upgrade.
click I have read, understood, and agree with the terms of the license agreement, and then click
Next.
5. On the Getting Started, Select installation location page, accept the default value, type in a new
location, or browse to one. Then click Next.
NOTE
returns, and then click Verify prerequisites again to recheck the system.
8. On the Configuration, Configure Operations Manager accounts page, enter the domain account
credentials for the System Center Configuration and Data Access Service account, and then click Next
9. Review the Configuration, Ready To Upgrade page, and then click Upgrade. The upgrade proceeds and
displays the upgrade progress.
10. When the upgrade is finished, the Upgrade complete page appears. Click Close.
NOTE
Upgrading a management server is just one phase of the distributed upgrade process. Upgrade is not completed
until you have upgraded all of the other features in your management group. The next step is to upgrade any
gateways. See How to Upgrade a Gateway Server for more information.
To upgrade a management server from the Command Prompt

1. Log on to the management server with an account that is a member of the Operations Manager
Administrators role for your Operations Manager management group, a member of the SQL Server
sysadmin fixed server role, and a local administrator on the computer.
3. Change the path to where the Operations Manager setup.exe file is located, and run the following command.
setup.exe /silent /upgrade

/AcceptEndUserLicenseAgreement:1
/DASAccountUser: <domain\username>
/DASAccountPassword: <password>
/DataReaderUser:<domain\user>
/DataReaderPassword:<password>
After you have upgraded all of the management servers in your management group, you should upgrade gateway
servers, and then upgrade any stand-alone Operations consoles.
Next steps
How to upgrade an ACS Collector
2 minutes to read
Perform this procedure to upgrade the Audit Collection Services (ACS ) Collector to System Center 2016 -
Operations Manager or version 1801 locally on the ACS Collector. During this procedure, the ACS database is also
upgraded without any additional steps.
WARNING
A computer that hosts an ACS Collector must also be an Operations Manager management server or gateway server.
Before you begin the upgrade process, make sure that your server meets the minimum supported configurations.
For more information, see System Requirements for System Center Operations Manager.
To upgrade an ACS Collector

1. Log on to the computer that hosts the ACS Collector with an Operations Manager Administrators role
account for your Operations Manager management group.
2. On the Operations Manager media, run Setup.exe.
3. In the Install section, click Audit Collection Services. The Audit Collection Services Setup wizard starts.
4. On the Welcome to the Audit Collection Services Collector Setup Wizard page, click Next.
5. On the Database Installation Options page, select Use an existing database, and then click Next.
6. On the Data Source page, type the name that you used as the Open Database Connectivity data source
name for your ACS database in the Data source name box. By default, this name is OpsMgrAC. Click
Next.
7. On the Database page, if the database is on a separate server than the ACS Collector, click Remote
Database Server, and then type the computer name of the database server that will host the database for
this installation of ACS. Otherwise, click Database server running locally, and then click Next.
8. On the Database Authentication page, select one authentication method. If the ACS Collector and the
ACS database are members of the same domain, you can select Windows authentication; otherwise,
select SQL authentication, and then click Next.
NOTE
If you select SQL authentication and click Next, the Database Credentials page appears. Enter the name of the
user account that has access to the SQL Server in the SQL login name box and the password for that account in the
SQL password password box, and then click Next.
9. The Summary page displays a list of actions that the installation program will perform to upgrade ACS.
Review the list, and then click Next to begin the installation.
NOTE
If a SQL Server Login dialog box appears and the database authentication is set to Windows Authentication,
select the correct database, and then verify that the Use Trusted Connection check box is selected. Otherwise, clear
it, enter the SQL Server login name and password, and then click OK.
10. When the upgrade is finished, click Finish.
Next steps
How to upgrade a gateway server
2 minutes to read
After you upgrade the management servers in your management group, you upgrade any gateway servers. The
procedure to upgrade a gateway server to System Center 2016 - Operations Manager or version 1801 is
performed locally on the gateway server. You can then verify whether the upgrade is successful. Before you begin
the upgrade process, make sure that your gateway server meets the minimum supported configurations. For more
information, see System Requirements for System Center Operations Manager.
To upgrade a gateway server

1. Log on to a computer that hosts the gateway server with an account that is a member of the Operations
Manager Administrators role for your Operations Manager management group.
2. On the Operations Manager media, run Setup.exe.
3. In the Optional Installations section, click Gateway management server.
5. On the Important Notice page, read the Microsoft Software License Terms, and then click I Agree.
6. On the The wizard is ready to begin gateway upgrade page, click Upgrade.
7. On the Completing Setup wizard page, click Finish.
To upgrade a gateway server from the Command Prompt

1. Log on to a computer that is hosting the gateway server with an account that is a member of the Operations
3. Change the directory to the Operations Manager installation media and change directory again to
gateway\AMD64, where the MOMGateway.msi file is located.
4. Run the following command where D:\ is the location for the upgrade log file.
msiexec /i MOMgateway.msi /qn /l*v D:\logs\GatewayUpgrade.log

AcceptEndUserLicenseAgreement=1
To verify the gateway server upgrade

2. Under Device Management, click Management Servers.
3. In the Management Servers pane, verify that the value listed in the Version column is 7.2.11469.0 for a
System Center 2016 - Operations Manager gateway server. For an Operations Manager version 1801
gateway server, the value listed in the version column is 8.0.13053.0.
Next steps
How to upgrade an Operations console
2 minutes to read
This procedure upgrades a stand-alone Operations console to System Center 2016 - Operations Manager or
version 1801. Perform this procedure locally on the computer that has a stand-alone Operations console installed.
You do not have to perform this procedure to upgrade Operations consoles that are installed locally on a
management server.
To upgrade a stand-alone Operations console

1. Log on to the computer that hosts the Operations console with an account that is a member of the
Operations Manager Administrators role in your Operations Manager management group.
2. On the Operations Manager source media, run Setup.exe, and then click Install.
NOTE
upgrade.
NOTE
5. On the Prerequisites page, review and address any warnings or errors that are returned by the
Prerequisites checker, and then click Verify Prerequisites Again to recheck the system.
7. On the Configuration, Ready To Upgrade page, click Upgrade.
8. When the upgrade is finished, the Upgrade complete page appears. Click Close.
To upgrade a stand-alone Operations console from the Command Prompt
1. Log on to the computer that hosts the Operations console with an account that is a member of the
Operations Manager Administrators role for your Operations Manager management group.
3. Change to the path to the Operations Manager source media, and run the following command.
Setup.exe /silent / upgrade /AcceptEndUserLicenseAgreement:1
To verify the Operations console upgrade

1. On the Windows desktop, click Start, and then click Run.
2. Type regedit, and then click OK. The Registry Editor starts.
Cau t i on
Incorrectly editing the registry can severely damage your system. Before you make changes to the registry,
you should back up any valued data that is on the computer.
3. Browse to the HKey_Local_Machine\Software\Microsoft\Microsoft Operations Manager\3.0\Setup
key. For System Center 2016 - Operations Manager, the value of the UIVersion entry is 7.2.11719.0. For
version 1801, the value of UIVersion is 8.0.13053.0.
Next steps
After you have upgraded all of the stand-alone operations consoles in your management group, you can
upgrade the agents. See How to Upgrade an Agent to System Center Operations Manager for more
information.
How to upgrade an Operations Manager agent
10 minutes to read
Use the following procedures to upgrade an agent running on Windows or Linux to System Center Operations
Manager 2019. You should first verify that the agents meet minimum supported configurations. For more
NOTE
If before the upgrade an agent was installed using the push install method, after upgrade the agent-managed computer is
put into a pending update state and can be upgraded through the Operations console. Otherwise the agent needs to be
upgraded manually.
When you upgrade an agent, the Operations Manager installer service runs and is not removed until after the
completion of the upgrade. If the agent upgrade fails, you might have to re-install the agent because the installer
service was not properly removed. If you attempt to upgrade the agent again and it fails, you should re-install the
agent after you have completed upgrading all features of Operations Manager.
NOTE
If you have Audit Collection Services (ACS) enabled for an agent prior to this upgrade, it is disabled as part of the agent
upgrade process. ACS must be re-enabled after upgrade completes.
If you are upgrading agents that are deployed to a computer that has other System Center 2012 R2 or 2016
Operations Manager features installed, you must do the following:
If the agent is installed on a computer that has System Center 2012 R2 or 2016 Operations Manager
Operations console or Web console installed, you must first uninstall the consoles before you upgrade the
agents. You can do this by uninstalling System Center 2012 R2 or 2016 Operations Manager in Programs and
Features. You can reinstall these consoles after upgrade is completed.
NOTE
If UAC is enabled, you must run the agent upgrade from an elevated command prompt.
NOTE
Information about upgraded agents might not appear in the Operations console for up to 60 minutes after performing the
upgrade.
Upgrading push-installed agents

Push-installed agents are agents that were installed by using the Computer and Device Management Wizard.
Use the following procedures to upgrade these agents.
To upgrade push-installed Windows agents by using the Operations console
1. Log on to the computer hosting the Operations Manager Operations console. Use an account that is a
member of the Operations Manager Administrators role for the Operations Manager management group.
2. In the Operations console, click Administration.
NOTE
When you run the Operations console on a computer that is not a management server, the Connect To Server
dialog box appears. In the Server name box, type the name of the management server to which you want to
connect.
3. In the Administration workspace, in the navigation pane under Device Management, click Pending
Management.
4. In the Pending Management pane, under Type: Agent Requires Update, right-click each agent-
managed computer listed, and then click Approve.
WARNING
You should not approve more than 200 agents at one time.
5. In the Update Agents dialog box, enter the administrator account credentials or use a selected
Management Server Action Account, and then click Update. The upgrade status is displayed in the Agent
Management Task Status dialog box.
6. When the upgrade is completed, click Close.
Upgrading manually installed agents

Manually-installed agents are agents that were installed manually, either from the Command Prompt, or by using
the MOMAgent.msi Setup Wizard. Use the following procedure to upgrade these agents.
To upgrade a manually installed Windows agent by using the Setup Wizard
1. Log on to the computer that hosts the agent with an Operations Manager Administrators role account for
your Operations Manager management group.
2. Run Setup.exe from the Operations Manager installation media.
3. On the first page of the Setup Wizard, click Local agent. When the Welcome to the Microsoft
Monitoring Agent Upgrade Wizard page opens, click Next.
4. In the Microsoft Monitoring Agent Setup dialog box, click Upgrade. The status page displays the
progress of the upgrade.
5. When the Completing the Microsoft Monitoring Agent Setup Wizard page appears, click Finish.
To upgrade a manually installed Windows agent from the Command Prompt
3. Run the following command, where D:\ is the location for the upgrade log file.
msiexec /i MOMAgent.msi /qn /l*v D:\logs\AgentUpgrade.log

Verifying Windows agent upgrade

To verify the Windows agent upgrade
1. In the Operations console, in the navigation pane, click the Administration button.
2. Under Device Management, click Agent Managed.
3. In the Agent Managed pane, verify that the value listed in the Version column is 10.19.10050.0.
NOTE
It can take up to one hour for the console to show the updated version of the agent.
Upgrading UNIX and Linux agents

To upgrade UNIX and Linux agents
In the Operations console, in the Administration pane, run the UNIX/Linux Upgrade Wizard.
Any existing Run As profiles and Run As accounts continue to have valid configurations. For information
about changes to Run As profiles and accounts for UNIX and Linux monitoring in Operations Manager, see
Accessing UNIX and Linux Computers in Operations Manager.
To manually upgrade UNIX and Linux agents
1. Log on to Linux/Unix machines and copy the agent (scx-<version>.universalr.<version>..sh) to the Linux
server. This should be done via SCP or FTP in binary mode..
2. Install the package with the following command.
sh ./scx-<version>.universalr.<version>.<arch>.sh –-upgrade --enable-opsmgr
3. Verify the package is installed with the following command.

rpm -q scx
4. Verify that the Microsoft SCX CIM Server is running with the following command.
scxadmin -status
To verify the UNIX or Linux agent upgrade from the console

2. Under Device Management, click UNIX/Linux Computers.
3. Verify that the value listed in the Agent Version column is 1.6.34.1-911.
NOTE
Use the following procedures to upgrade an agent running on Windows or Linux to System Center Operations
Manager 1801. You should first verify that the agents meet minimum supported configurations. For more
NOTE
If before the upgrade an agent was installed using the push install method, after upgrade the agent-managed computer is
put into a pending update state and can be upgraded through the Operations console. Otherwise the agent needs to be
upgraded manually.
When you upgrade an agent, the Operations Manager installer service runs and is not removed until after the
completion of the upgrade. If the agent upgrade fails, you might have to re-install the agent because the installer
service was not properly removed. If you attempt to upgrade the agent again and it fails, you should re-install the
agent after you have completed upgrading all features of Operations Manager.
NOTE
If you have Audit Collection Services (ACS) enabled for an agent prior to this upgrade, it is disabled as part of the agent
upgrade process. ACS must be re-enabled after upgrade completes.
If you are upgrading agents that are deployed to a computer that has other System Center 2012 R2 or 2016
Operations Manager features installed, you must do the following:
If the agent is installed on a computer that has System Center 2012 R2 or 2016 Operations Manager
Operations console or Web console installed, you must first uninstall the consoles before you upgrade the
agents. You can do this by uninstalling System Center 2012 R2 or 2016 Operations Manager in Programs and
Features. You can reinstall these consoles after upgrade is completed.
NOTE
If UAC is enabled, you must run the agent upgrade from an elevated command prompt.
NOTE
Information about upgraded agents might not appear in the Operations console for up to 60 minutes after performing the
upgrade.
Upgrading push-installed agents

Push-installed agents are agents that were installed by using the Computer and Device Management Wizard.
Use the following procedures to upgrade these agents.
To upgrade push-installed Windows agents by using the Operations console
NOTE
connect.
3. In the Administration workspace, in the navigation pane under Device Management, click Pending
Management.
4. In the Pending Management pane, under Type: Agent Requires Update, right-click each agent-
managed computer listed, and then click Approve.
WARNING
You should not approve more than 200 agents at one time.
5. In the Update Agents dialog box, enter the administrator account credentials or use a selected
Management Server Action Account, and then click Update. The upgrade status is displayed in the Agent
Management Task Status dialog box.
6. When the upgrade is completed, click Close.
Upgrading manually installed agents

Manually-installed agents are agents that were installed manually, either from the Command Prompt, or by using
the MOMAgent.msi Setup Wizard. Use the following procedure to upgrade these agents.
To upgrade a manually installed Windows agent by using the Setup Wizard
2. Run Setup.exe from the Operations Manager installation media.
3. On the first page of the Setup Wizard, click Local agent. When the Welcome to the Microsoft
Monitoring Agent Upgrade Wizard page opens, click Next.
4. In the Microsoft Monitoring Agent Setup dialog box, click Upgrade. The status page displays the
progress of the upgrade.
To upgrade a manually installed Windows agent from the Command Prompt
3. Run the following command, where D:\ is the location for the upgrade log file.
msiexec /i MOMAgent.msi /qn /l*v D:\logs\AgentUpgrade.log

Verifying Windows agent upgrade

To verify the Windows agent upgrade
2. Under Device Management, click Agent Managed.
3. In the Agent Managed pane, verify that the value listed in the Version column is 8.0.10918.0.
NOTE
Upgrading UNIX and Linux agents

To upgrade UNIX and Linux agents
In the Operations console, in the Administration pane, run the UNIX/Linux Upgrade Wizard.
Any existing Run As profiles and Run As accounts continue to have valid configurations. For information
about changes to Run As profiles and accounts for UNIX and Linux monitoring in Operations Manager, see
Accessing UNIX and Linux Computers in Operations Manager.
To manually upgrade UNIX and Linux agents
1. Log on to Linux/Unix machines and copy the agent (omsagent-<version>.universalr.<version>..sh) to the
Linux server. This should be done via SCP or FTP in binary mode..
2. Install the package with the following command.
sh ./omsagent-<version>.universalr.<version>.<arch>.sh –-upgrade
3. Verify the package is installed with the following command.

rpm -q omsagent
4. Verify that the Microsoft SCX CIM Server is running with the following command.
scxadmin -status
To verify the UNIX or Linux agent upgrade from the console

2. Under Device Management, click UNIX/Linux Computers.
3. Verify that the value listed in the Agent Version column is 1.4.1-45.
NOTE
Next steps
See Distributed Deployment of Operations Manager to understand the sequence and steps for installing
the Operations Manager server roles across multiple servers in your management group.
Review information in the Managing Discovery and Agents section to understand the options and steps for
installing agents and discovering objects to be monitored by Operations Manager.
How to upgrade agents in a parallel deployment
2 minutes to read
When you perform a side-by-side deployment of System Center 2016 - Operations Manager or System Center
Operations Manager 1801 from a previous version (also referred to as a parallel deployment) with your existing
Operations Manager management group, you can continue to proactively monitor your workloads and maintain
insight into the availability of your critical services.
The following coexistence scenarios are supported for the Operations Manager agent in a parallel deployment
scenario with System Center Operations Manager 1801.
System Center 2016 - Operations Manager RTM and higher
System Center Operations Manager 2012 R2 RTM and higher
Agents reporting to your Operations Manager 2012 R2 or 2016 management group can be upgraded to System
Center Operations Manager 1801 and are fully capable of communicating with both management groups until
you complete your migration and retire the old management group.
Agents reporting to your Operations Manager 2012 R2 management group can be upgraded to System Center
2016 - Operations Manager and are fully capable of communicating with both management groups until you
complete your migration and retire the Operations Manager 2012 R2 management group.
Upgrading agents
If you want to maintain your existing Operations Manager environment, you can install the latest release of
Operations Manager in parallel, and just upgrade your agents depending on what method you currently use today.
Such as:
The discovery and installation of one or more agents from the Operations console.
If you discover and install the existing agent-managed system from the new Operations Manager
management group, the agent will be upgraded and multi-homed to where it reports to both management
groups.
Inclusion in the installation image.
Your image will need to be updated to include the new version and configured to assign the agent to the
new Operations Manager management group.
Manual installation where setup is manually executed on the agent or deployed through an existing
software distribution tool.
Your deployment process will need to be updated to inlucde the new agent Windows installer package and
dependencies required. The logic defined to interrogate, install and configure, and verify the agent will need
to be updated accordingly.
Once you have completed all the post-upgrade steps and are comfortable with the state of your new Operations
Manager management group, you can reconfigure the agents to remove assignment from the existing Operations
Manager management group that you are preparing to retire. This can be accomplished by following the guidance
in the Operations Manager SDK to programatically remove the management group configuration from the agent.
Next steps
See Distributed Deployment of Operations Manager to understand the sequence and steps for installing
the Operations Manager server roles across multiple servers in your management group.
Review information in the Managing Discovery and Agents section to understand the options and steps for
installing agents and discovering objects to be monitored by Operations Manager.
How to upgrade a Web console
2 minutes to read
Before you begin the upgrade process, make sure that your server meets the minimum supported configurations
for System Center Operations Manager. This process is not applicable for version 1801. For more information, see
System Requirements for System Center Operations Manager.
NOTE
When you upgrade the web console, any customizations that were made to the web.config file after the web console was
installed will be reset. Make a backup copy before proceeding.
If you made changes after you set up your web console to either enable or disable Secure Sockets Layer (SSL ), the
SSL settings will be reset during upgrade. To resolve the issue, you must make changes to the registry key before
you upgrade the web console, as follows:
To set the registry to enable or disable SSL on the Web console server
1. Logon on to the web console with an account that has local administrator rights, and on the desktop, click
Start, and then click Run.
2. Type regedit, and then click OK. The Registry Editor starts.
Cau t i on
Incorrectly editing the registry can severely damage your system. Before you make changes to the registry,
you should back up any valued data that is on the computer.
3. Navigate to the HKey_Local_Machine\Software\Microsoft\System Center Operations
Manager\12\Setup\WebConsole\ key.
4. To enable SSL, set the following:
HTTP_GET_ENABLED=0
BINDING_CONFIGURATION=DefaultHttpsBinding
5. To disable SSL, set the following:
HTTP_GET_ENABLED=1
BINDING_CONFIGURATION=DefaultHttpBinding
To upgrade the Web console server
1. Log on to the computer that hosts the web console server with an Operations Manager Administrators role
NOTE
upgrade.
NOTE
7. When the Ready to Upgrade page appears, review the upgrade summary, and then click Upgrade.
To upgrade the Web console server from the Command Prompt
1. Log on to the computer that hosts the web console server with an Operations Manager Administrators role
2. Open a Command Prompt by using the Run as Administrator option.
3. Change the path to where the Operations Manager Setup.exe file is located, and run the following
command.
IMPORTANT
Use the /WebConsoleUseSSL parameter only if your website has Secure Sockets Layer (SSL) activated. For a default
web installation, specify Default Web Site for the /WebSiteName parameter.
setup.exe /silent /AcceptEndUserLicenseAgreement:1 /upgrade

/WebsiteName: "<WebSiteName>" [/WebConsoleUseSSL]
Next steps
How to upgrade a Reporting server
5 minutes to read
Use this procedure to upgrade a stand-alone Reporting server to System Center Operations Manager 2019. You
should not run upgrade on the Reporting server until after you have upgraded the management servers, gateways,
Operation consoles, and agents.
Before performing the upgrade

When you try to upgrade Reporting server to System Center Operations Manager 2019 Reporting server, the
upgrade fails for the following configuration:
Server A is configured as the System Center 2016 - Operations Manager management server.
Server B is configured with SQL Server hosting the System Center Operations Manager 2019 operational and
data warehouse database, and Operations Manager Reporting server or a standalone SQL Server hosting
Reporting server.
The prerequisites checker will report the following error: Management Server Upgraded Check - The
management server to which this component reports has not been upgraded.
To work around this issue, install the System Center 2016 or 1801 or 1807 - Operations Manager Operations
console on the server hosting the Reporting server role and then retry upgrading the Reporting server role to
version 2019. Once the upgrade is successfully completed, you can re-run setup and uninstall the upgraded
Operations console from the Reporting server.
To upgrade the Reporting server

1. Log on to the computer that hosts the Reporting server with an account that is a member of the Operations
Manager Administrators role for your Operations Manager management group and the SQL Server
sysadmin fixed server role.
NOTE
upgrade.
3. On the Getting Started, please read the license terms page, read the Microsoft Software License Terms,
NOTE
For System Center Operations Manager 2019, the default path is C:\Program Files\Microsoft System
7. On the Ready to Upgrade page, review the options, and then click Upgrade.
8. When upgrade is finished, the Upgrade complete page appears. Click Close.
To upgrade the Reporting server from the Command Prompt

command:
NOTE
If the Reporting server reports to an unsupported or inaccessible root management server, you must also pass the
following parameter: /ManagementServer: <ManagementServerName> .

Use this procedure to upgrade a stand-alone Reporting server to System Center 2016 - Operations Manager or
version 1801. You should not run upgrade on the Reporting server until after you have upgraded the management
servers, gateways, Operation consoles, and agents.
Before performing the upgrade

When you try to upgrade System Center 2016 - Operations Manager Reporting server to System Center
Operations Manager 1801 Reporting server, the upgrade fails for the following configuration:
Server B is configured with SQL Server hosting the System Center 2016 - Operations Manager operational and
data warehouse database, and Operations Manager Reporting server or a standalone SQL Server hosting
Reporting server.
The prerequisites checker will report the following error: Management Server Upgraded Check - The
management server to which this component reports has not been upgraded.
To work around this issue, install the System Center 2016 - Operations Manager Operations console on the server
hosting the Reporting server role and then retry upgrading the Reporting server role to version 1801. Once the
upgrade is successfully completed, you can re-run setup and uninstall the upgraded Operations console from the
Reporting server.
To upgrade the Reporting server

Manager Administrators role for your Operations Manager management group and the SQL Server
sysadmin fixed server role.
NOTE
upgrade.
NOTE
7. On the Ready to Upgrade page, review the options, and then click Upgrade.
8. When upgrade is finished, the Upgrade complete page appears. Click Close.
To upgrade the Reporting server from the Command Prompt

command:
NOTE
If the Reporting server reports to an unsupported or inaccessible root management server, you must also pass the
following parameter: /ManagementServer: <ManagementServerName> .
Next steps
How to upgrade Operations Manager 1807
databases to SQL Server 2017
4 minutes to read
Use the steps in this article to perform an in-place upgrade of the databases supporting Operations Manager
version 1807 to SQL Server 2017. Before proceeding, you should back up any custom authored reports, favorites,
and schedules, which are stored in the report server database.
NOTE
Upgrading to SQL Server 2017 uninstalls SQL Reporting Services, as this is now a separately-installed feature.
Before performing these upgrade steps, review the SQL Server 2017 upgrade information.
Stop the Operations Manager services.

On all the management servers in the management group, stop the Operations Manager services:
System Center Data Access
Microsoft Monitoring Agent
System Center Management Configuration
Back up the Reporting server database

1. On the SQL Server hosting the Reporting server databases, create a full backup of the ReportServer and
ReportServerTempDB database. For more information, see Create a Full Database Backup (SQL Server).
2. On the current Operations Manager reporting server, back up the SSRS encryption key. For more
information, see SSRS Encryption Keys - Back Up and Restore Encryption Keys.
3. Back up the report server configuration files. Files to back up include:
Web.config
Uninstall Operations Manager reporting server

1. On the Operations Manager reporting server, uninstall the Operations Manager reporting server
component as follows:
a. Open Control Panel, and then click Programs and Features.
b. In Programs and Features, select System Center Operations Manager, and then click Uninstall.
c. In the Operations Manager Setup wizard, click Remove a feature.
d. In the Select features to remove page, select Reporting server, and then click Uninstall. Click Close
when the wizard finishes.
2. Perform the upgrade to SQL Server 2017 following the steps described in SQL 2017 dcoumentation.
Install SQL Server 2017 Reporting services

To download SQL Server 2017 Reporting services, go to the Microsoft Download Center.
After a successful setup, select Configure Report Server to launch the Reporting Services Configuration
Manager. This is necessary to configure Reporting Services to:
1. Configure the report server database and select the existing report server database that already contains
the content you want to use.
2. Restore the symmetric key that is used to encrypt stored connection strings and credentials.
3. Create and configure the Web Service and Web Portal URLs.
4. Run regedit from an elevated Command Prompt and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\SSRS\MSSQLServer\CurrentVersion. Note the value for the key CurrentVersion.
5. Create a registry REG_SZ value named Version under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SSRS\Setup\ with REG_SZ value
noted in the previous step.
6. Reboot the server in order for the changes to take effect.
Verify the installation of SQL Report server

After reinstalling the Operations Manager reporting server component, perform the following steps to confirm
SQL Reporting Services is working correctly.
1. Run the Reporting Services Configuration tool and connect to the report server instance you installed. The
Web Service URL page includes a link to the Report Server Web service. Click the link to verify you can
access the server.
2. Open a browser and type the report server URL in the address bar. The address consists of the server name
and the virtual directory name that you specified for the report server during setup. By default, the report
server virtual directory is named ReportServer. You can use the following URL to verify report server
installation: http://<computer name>/ReportServer<_instance name> . The URL will be different if you installed
the report server as a named instance.
3. To verify that the web portal is installed and running, open a browser and type the Web Portal URL in the
address bar. The address consists of the server name and the virtual directory name that you specified for
the web portal during setup or in the Web Portal URL page in the Reporting Services Configuration tool. By
default, the web portal virtual directory is Reports. You can use the following URL to verify the web portal
installation: http://<computer name>/Reports<_instance name> .
Install Operations Manager Reporting server

After the upgrade is complete, perform the following steps to install Operations Manager Reporting server.
Optional - Enable CLR strict security

To enable CLR strict security on the Operations Manager databases, run the following SQL script on each
Operations Manager database (by default, CLR strict security will be OFF after upgrading to SQL Server 2017).
-- Do this only for SQL server version 2017 and more

IF( convert(int, SERVERPROPERTY('ProductMajorVersion')) > 13 )
BEGIN
DECLARE @Hash1 BINARY(64), @ClrName1 NVARCHAR(4000);
set @Hash1 = HASHBYTES(N'SHA2_512',
0x4d5a90000300000004000000ffff0000b800000000000000400000000000000000000000000000000000000000000000000000000000
000000000000800000000e1fba0e00b409cd21b8014ccd21546869732070726f6772616d2063616e6e6f742062652072756e20696e2044
000000000000800000000e1fba0e00b409cd21b8014ccd21546869732070726f6772616d2063616e6e6f742062652072756e20696e2044
4f53206d6f64652e0d0d0a2400000000000000504500004c010300cdef7c440000000000000000e0000e210b010800000c000000080000
000000005e2b000000200000004000000000ec560020000000020000040000000000000004000000000000000080000000020000f2f100
00030000040000100000100000000010000010000000000000100000000000000000000000042b00005700000000400000100500000000
0000000000000000000000000000006000000c0000008c2a00001c00000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000200000080000000000000000000000082000004800000000000000000000002e74657874000000
640b000000200000000c000000020000000000000000000000000000200000602e72737263000000100500000040000000060000000e00
00000000000000000000000000400000402e72656c6f6300000c0000000060000000020000001400000000000000000000000000004000
004200000000000000000000000000000000402b0000000000004800000002000500082100008409000009000000000000000000000000
000000502000008000000000000000000000000000000000000000000000000000000000000000000000000c506f2ef337d14f0bc66e27
fa02006623253f6655697a25078f76132dfd4cf9ec02d54581a9310a12538c2a82f19f230bbe2ac6017a095a82147a15f65488b5b38c96
12cfc2c228f748d5519b4981a836189698e99b7f54961091fbb404afb93ab9d8110f22652ab16e7ff50f9dfb4236d78f61e93555018ba8
5d95c28cb5452a02281000000a0000002a00133003001e00000001000011000214fe0116fe010b072d0500160a2b0b02031e281200000a
0a2b00062a000042534a4201000100000000000c00000076322e302e35303732370000000005006c0000001c020000237e000088020000
3c03000023537472696e677300000000c40500000800000023555300cc050000100000002347554944000000dc050000a803000023426c
6f620000000000000002000001471502000900000000fa0133001600000100000014000000020000000200000002000000120000000e00
000001000000010000000300000000000a00010000000000060084007d000600c900aa000600d700aa000600fd00eb0006001601eb0006
003101eb0006005001eb0006006d01eb0006008401eb0006009f01eb000600b801eb000600d101eb000600ee01eb0006001a0207023b00
2e02000006005d023d0206007d023d020a00df02c4020e00210302030e00270302030000000001000000000001000100010110002b0046
00050001000100d0200000000081188b000a000100dc2000000000960091000e00010000000100f40200000200fa0211008b0014001900
8b00190021008b00140029008b00140031008b00140039008b00140041008b00140049008b00140051008b00140059008b00140061008b
00140069008b00140071008b001e0081008b00240089008b000a0009008b000a0091008b000a009900340336022e003b00ac022e000b00
43022e0013006d022e0023006d022e002b006d022e00330073022e0053004a032e004300e4022e004b0025032e006b0075032e007b0087
032e005b0065032e0073007e0340008b00cb003e020480000006000000f50f00000100000029009b020000020000000000000000000000
01007400000000000200000000000000000000000100b8020000000002000000000000000000000001007d00000000000000003c4d6f64
756c653e004d6963726f736f66742e4d6f6d2e446174614163636573732e53716c2e646c6c00526567756c617245787072657373696f6e
4576616c7561746f72004d6963726f736f66742e456e74657270726973654d616e6167656d656e742e446174614163636573732e53716c
006d73636f726c69620053797374656d004f626a656374002e63746f72004d617463686573526567756c617245787072657373696f6e00
53797374656d2e52756e74696d652e496e7465726f705365727669636573004775696441747472696275746500436f6d56697369626c65
4174747269627574650053797374656d2e5265666c656374696f6e00417373656d626c7943756c74757265417474726962757465004173
73656d626c7954726164656d61726b41747472696275746500417373656d626c79436f6e66696775726174696f6e417474726962757465
00417373656d626c794465736372697074696f6e41747472696275746500417373656d626c795469746c65417474726962757465004173
73656d626c79436f7079726967687441747472696275746500417373656d626c7950726f6475637441747472696275746500417373656d
626c79436f6d70616e7941747472696275746500417373656d626c7946696c6556657273696f6e41747472696275746500417373656d62
6c7956657273696f6e4174747269627574650053797374656d2e446961676e6f73746963730044656275676761626c6541747472696275
746500446562756767696e674d6f6465730053797374656d2e52756e74696d652e436f6d70696c6572536572766963657300436f6d7069
6c6174696f6e52656c61786174696f6e734174747269627574650052756e74696d65436f6d7061746962696c6974794174747269627574
65004d6963726f736f66742e4d6f6d2e446174614163636573732e53716c0053797374656d2e44617461004d6963726f736f66742e5371
6c5365727665722e5365727665720053716c46756e6374696f6e41747472696275746500696e707574007061747465726e005379737465
6d2e546578742e526567756c617245787072657373696f6e730052656765780052656765784f7074696f6e730049734d61746368000003
200000000000a79e22af2016204a81c804d4f9bce8010008b77a5c561934e08903200001050002020e0e042001010e0420010102052001
01113d042001010880a000240000048000009400000006020000002400005253413100040000010001004ddb14fd25fa54ef1fe05516d6
9c0bb19c86956e2d5245e728300417e6a018daac56b61ee215e4c096dba942368bb4aa76956042bb3efb709cda847d7396839f57a40b90
829fe5f347a5d2e2c198367cbc1092aa9762ae9776e59fed16703887329ffeb6d6cbf44853c496a22bc79bb3ce00f29760995dafa6aa97
779983e0b48169010005005455794d6963726f736f66742e53716c5365727665722e5365727665722e446174614163636573734b696e64
2c2053797374656d2e446174612c2056657273696f6e3d322e302e302e302c2043756c747572653d6e65757472616c2c205075626c6963
4b6579546f6b656e3d623737613563353631393334653038390a446174614163636573730000000054020f497344657465726d696e6973
7469630154020949735072656369736501540e044e616d651b666e5f4d617463686573526567756c617245787072657373696f6e54557f
4d6963726f736f66742e53716c5365727665722e5365727665722e53797374656d446174614163636573734b696e642c2053797374656d
2e446174612c2056657273696f6e3d322e302e302e302c2043756c747572653d6e65757472616c2c205075626c69634b6579546f6b656e
3d623737613563353631393334653038391053797374656d4461746141636365737300000000070003020e0e1151040702020229010024
33333532323533352d393332652d346130342d623965302d30616330383630353137663300000501000000003801003353716c436c7220
66756e6374696f6e616c697479207573656420627920746865206461746120616363657373206c617965722e0000370100324d6963726f
736f66742e456e74657270726973654d616e6167656d656e742e53716c2e446174614163636573734c6179657200004001003b436f7079
72696768742032303035204d6963726f736f667420436f72706f726174696f6e2e2020416c6c207269676874732072657365727665642e
00002401001f4d6963726f736f6674204f7065726174696f6e73204d616e6167657220763300001a0100154d6963726f736f667420436f
72706f726174696f6e00000f01000a362e302e343038352e3000000801000701000000000801000800000000001e010001005402165772
61704e6f6e457863657074696f6e5468726f777301000000000000cdef7c44000000000200000059000000a82a0000a80c000052534453
165649e3ed4a514990cc3fb2ca36648a01000000643a5c6d6f6d76332e6d61696e5c7461726765745c64656275675c693338365c4d6963
726f736f66742e4d6f6d2e446174614163636573732e53716c2e706462000000002c2b000000000000000000004e2b0000002000000000
000000000000000000000000000000000000402b00000000000000000000000000000000000000005f436f72446c6c4d61696e006d7363
6f7265652e646c6c0000000000ff250020ec56000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000001001000000018000080000000000000000000000000000001000100000030
00008000000000000000000000000000000100000000004800000058400000b80400000000000000000000b80434000000560053005f00
560045005200530049004f004e005f0049004e0046004f0000000000bd04effe00000100000006000000f50f000006000000f50f3f0000
00000000000400000002000000000000000000000000000000440000000100560061007200460069006c00650049006e0066006f000000
00002400040000005400720061006e0073006c006100740069006f006e00000000000000b00418040000010053007400720069006e0067
00460069006c00650049006e0066006f000000f4030000010030003000300030003000340062003000000080003400010043006f006d00
00460069006c00650049006e0066006f000000f4030000010030003000300030003000340062003000000080003400010043006f006d00
6d0065006e00740073000000530071006c0043006c0072002000660075006e006300740069006f006e0061006c00690074007900200075
00730065006400200062007900200074006800650020006400610074006100200061006300630065007300730020006c00610079006500
72002e0000004c001600010043006f006d00700061006e0079004e0061006d006500000000004d006900630072006f0073006f00660074
00200043006f00720070006f0072006100740069006f006e000000900033000100460069006c0065004400650073006300720069007000
740069006f006e00000000004d006900630072006f0073006f00660074002e0045006e00740065007200700072006900730065004d0061
006e006100670065006d0065006e0074002e00530071006c002e0044006100740061004100630063006500730073004c00610079006500
72000000000038000b000100460069006c006500560065007200730069006f006e000000000036002e0030002e0034003000380035002e
0030000000000064002100010049006e007400650072006e0061006c004e0061006d00650000004d006900630072006f0073006f006600
74002e004d006f006d002e0044006100740061004100630063006500730073002e00530071006c002e0064006c006c00000000009c003c
0001004c006500670061006c0043006f007000790072006900670068007400000043006f00700079007200690067006800740020003200
30003000350020004d006900630072006f0073006f0066007400200043006f00720070006f0072006100740069006f006e002e00200020
0041006c006c0020007200690067006800740073002000720065007300650072007600650064002e0000006c00210001004f0072006900
670069006e0061006c00460069006c0065006e0061006d00650000004d006900630072006f0073006f00660074002e004d006f006d002e
0044006100740061004100630063006500730073002e00530071006c002e0064006c006c0000000000600020000100500072006f006400
7500630074004e0061006d006500000000004d006900630072006f0073006f006600740020004f007000650072006100740069006f006e
00730020004d0061006e00610067006500720020007600330000003c000b000100500072006f0064007500630074005600650072007300
69006f006e00000036002e0030002e0034003000380035002e0030000000000040000b00010041007300730065006d0062006c00790020
00560065007200730069006f006e00000036002e0030002e0034003000380035002e003000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000002000000c000000603b000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000);
set @ClrName1 = CONVERT(NVARCHAR(4000), 'Microsoft.EnterpriseManagement.Sql.DataAccessLayer');
-- Drop trusted assembly if exists

IF EXISTS (select * from sys.trusted_assemblies where description = @ClrName1)
BEGIN
EXEC SYS.sp_drop_trusted_assembly @Hash1
END
--Add to trusted assembly

EXEC SYS.SP_ADD_TRUSTED_ASSEMBLY @Hash1, @ClrName1
END
GO
-- Do this only for SQL server version 2017 and more

IF( convert(int, SERVERPROPERTY('ProductMajorVersion')) > 13 )
BEGIN
DECLARE @Hash BINARY(64), @ClrName NVARCHAR(4000);
set @Hash = HASHBYTES(N'SHA2_512',
0x4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000
000000000000800000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E2044
4F53206D6F64652E0D0D0A2400000000000000504500004C0103006182CF4B0000000000000000E00002210B0108000016000000080000
00000000BE3400000020000000400000000040000020000000020000040000000000000004000000000000000080000000020000000000
00030040850000100000100000000010000010000000000000100000000000000000000000683400005300000000400000600400000000
0000000000000000000000000000006000000C000000B83300001C00000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000200000080000000000000000000000082000004800000000000000000000002E74657874000000
C4140000002000000016000000020000000000000000000000000000200000602E72737263000000600400000040000000060000001800
00000000000000000000000000400000402E72656C6F6300000C0000000060000000020000001E00000000000000000000000000004000
004200000000000000000000000000000000A0340000000000004800000002000500DC250000DC0D000001000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000360002731000000A7D010000
042A0000133002002D00000001000011000F01281100000A16FE010A062D03002B1A027B010000040F01281200000A6F1300000A1F2C6F
1400000A262A5200027B01000004037B010000046F1500000A262A0000133004004C00000002000011007E1600000A0A027B010000042C
13027B010000046F1700000A16FE0216FE012B01170C082D1A027B0100000416027B010000046F1700000A17596F1800000A0A06731900
000A0B2B00072A133003002900000001000011000314FE0116FE010A062D0B7201000070731A00000A7A02036F1B00000A731C00000A7D
010000042A000000133002002A00000001000011000314FE0116FE010A062D0B7205000070731A00000A7A03027B010000046F1D00000A
6F1E00000A002A1E02281F00000A2A5602281F00000A000002732100000A7D02000004002A133002002F00000001000011022808000006
0000032C0E036F2200000A16FE0216FE012B01170A062D0F00027B02000004036F2300000A0000002A001B300300760000000300001100
7E1600000A0A00027B020000046F2400000A0D2B1C1203282500000A0B00067209000070076F1D00000A282600000A0A00120328270000
0A130411042DD7DE0F1203FE160300001B6F2800000A00DC0006282900000A16FE01130411042D09007E1600000A0C2B0B0006176F2A00
000A0C2B00082A000001100000020014002D41000F0000000013300200140000000100001100027B020000046F2B00000A16FE010A2B00
062A133001000B000000040000110073080000060A2B00062A00133004008100000005000011000F00281200000A0A0F00281100000A2D
10066F2C00000A282900000A16FE012B0116130411042D08280C0000060D2B4E06178D2100000113051105161F2C9D1105176F2D00000A
0B160C2B1600070807089A6F2C00000A6F2E00000AA2000817580C08078E69FE04130411042DDE07280100002B000773090000060D2B00
092A00000013300100110000000600001100027B020000046F2B00000A0A2B00062A0000001B300300560000000700001100160A00027B
020000046F2400000A0D2B1F1203282500000A0B0007031B283100000A0A0616FE01130411042D022B0E001203282700000A130411042D
D4DE0F1203FE160300001B6F2800000A00DC00060C2B00082A000001100000020010003040000F000000001B3002005200000007000011
00170A00037B020000046F2400000A0D2B1B1203282500000A0B000207280F0000060A06130411042D022B0E001203282700000A130411
042DD8DE0F1203FE160300001B6F2800000A00DC00060C2B00082A000001100000020010002C3C000F0000000013300200170000000800
001100020328130000060A066F0B00000616FE010B2B00072A001B300200670000000900001100027B0200000473090000060A00037B02
0000046F2400000A0D2B261203282500000A0B0006076F0F000006130411042D0F00067B02000004076F3200000A000000120328270000
0A130411042DCDDE0F1203FE160300001B6F2800000A00DC00060C2B00082A000110000002001A003751000F000000001B300200640000
00090000110073080000060A00037B020000046F2400000A0D2B291203282500000A0B0002076F0F00000616FE01130411042D0F00067B
02000004076F3200000A0000001203282700000A130411042DCADE0F1203FE160300001B6F2800000A00DC00060C2B00082A0110000002
0014003A4E000F0000000013300400410000000A000011000314FE0116FE010C082D0B7201000070731A00000A7A036F1B00000A0A0617
8D210000010D09161F2C9D09176F2D00000A0B027B02000004076F2300000A002A000000133002002500000001000011000314FE0116FE
010A062D0B7205000070731A00000A7A03026F1D00000A6F1E00000A002A00000042534A4201000100000000000C00000076322E302E35
303732370000000005006C00000014050000237E000080050000A805000023537472696E677300000000280B0000100000002355530038
0B0000100000002347554944000000480B00009402000023426C6F6200000000000000020000015717A2090908000000FA013300160000
01000000250000000300000002000000150000000F0000000300000032000000110000000A000000010000000200000002000000030000
0001000000020000000100000000000A0001000000000006009C0095000A00CA00AF000A00F000DB0006000601FA000A002C01DB000600
5B01510106006D0151010600A10186010600B001860106006902570206008002570206009D0257020600BC0257020600D50257020600EE
02570206000903570206002403570206005C033D0306007003570206009C0389035300B00300000600DF03BF030600FF03BF0306001D04
95000A003304AF000A005404AF0006006C0495000600840495000A00A504AF000600CB0486012300E20400000600170595000600480595
0006004D05950006006E0595000A007905AF0006008C059500000000000100000000000100010001201000450051000500010001000120
100088005100050002000800010014010A000100A8012F00502000000000860027010E0001006020000000008600360112000100992000
0000008600410118000200B02000000000860047011E000300082100000000E601680123000300402100000000E6017A01290004007621
00000000861880010E0005007E2100000000861880010E0005009421000000008618800136000500D02100000000C600BE013F00060064
2200000000E609C701430006008422000000009608D201470006009C22000000009600DB014C0006002C23000000008600E10153000700
4C23000000008600E70157000700C023000000008600EB015C0008003024000000008600F4015C0009005424000000009600FD0162000A
00D824000000009600030262000C00582500000000E601680123000E00A82500000000E6017A0129000F00000001001902000001001F02
000001002502000001002702000001002902000001003102000001003302000001003B02000001004202000001004A0200000200500200
0001004A020000020050020000010025020000010027020200090003000D00030009005100800174005900800174006100800174006900
80017400710080017400790080017400810080017400890080017400910080017900990080017400A10080017E00B10080018400B90080
010E00C10080010E00C90080018900210080010E002900C701430029005B043F0021006504F10021006504F700210065040101D9007304
07012100790453002100BE010A01290080017400E1008001740031009A043F002100800174000900BE013F0039007A017400090080010E
00E900800189000C0080010E001400C10453000C00D9044F010C00ED0459011C00FB046801D90007056D011C000E054300010123050E00
D9002B057401D900390579010C00C1045300D90043053F00D90060058F01D90066053F00190174059901210180010E00D9009D05DA010C
00A405F5012E001B002B022E006B0073022E000B0012022E0013002B022E00230031022E002B0012022E00330040022E003B002B022E00
4B002B022E005B0061022E0063006A0243007B008F00630003011701C0018301B101E0018301B10100028301B10120028301B101FD0010
017E018A01A501D601E301EF01FB0109020300010000000D026B00000014026F0002000B00030002000C00050043014901620104800000
01000000B30EF0680000000000005100000002000000000000000000000001008C00000000000200000000000000000000000100A30000
0000005F00A10100000000003C4D6F64756C653E004D6963726F736F66742E456E74657270726973654D616E6167656D656E742E53716C
2E55736572446566696E656444617461547970652E646C6C00436F6E636174656E617465004D6963726F736F66742E456E746572707269
73654D616E6167656D656E742E53716C2E55736572446566696E6564446174615479706500536574006D73636F726C6962005379737465
6D004F626A6563740053797374656D2E44617461004D6963726F736F66742E53716C5365727665722E536572766572004942696E617279
53657269616C697A650053797374656D2E446174612E53716C547970657300494E756C6C61626C650053797374656D2E54657874005374
72696E674275696C64657200696E7465726D656469617465526573756C7400496E69740053716C537472696E6700416363756D756C6174
65004D65726765005465726D696E6174650053797374656D2E494F0042696E61727952656164657200526561640042696E617279577269
746572005772697465002E63746F720053797374656D2E436F6C6C656374696F6E732E47656E65726963004C6973746031006D656D6265
72730049436F6C6C656374696F6E603100546F537472696E67006765745F49734E756C6C006765745F4E756C6C00506172736500436F75
6E740048617300496E636C7564657300496E436F6D6D6F6E00556E696F6E00496E746572736563740049734E756C6C004E756C6C007661
6C7565006F7468657200720077006F626A65637473007300656C656D656E740073756273657400616E6F74686572006669727374007365
636F6E640053797374656D2E5265666C656374696F6E00417373656D626C795469746C6541747472696275746500417373656D626C7944
65736372697074696F6E41747472696275746500417373656D626C79436F6E66696775726174696F6E4174747269627574650041737365
6D626C79436F6D70616E7941747472696275746500417373656D626C7950726F6475637441747472696275746500417373656D626C7943
6F7079726967687441747472696275746500417373656D626C7954726164656D61726B41747472696275746500417373656D626C794375
6C747572654174747269627574650053797374656D2E52756E74696D652E496E7465726F70536572766963657300436F6D56697369626C
6541747472696275746500417373656D626C7956657273696F6E4174747269627574650053797374656D2E446961676E6F737469637300
44656275676761626C6541747472696275746500446562756767696E674D6F6465730053797374656D2E52756E74696D652E436F6D7069
6C6572536572766963657300436F6D70696C6174696F6E52656C61786174696F6E734174747269627574650052756E74696D65436F6D70
61746962696C6974794174747269627574650053657269616C697A61626C654174747269627574650053716C55736572446566696E6564
41676772656761746541747472696275746500466F726D6174006765745F56616C756500417070656E6400537472696E6700456D707479
006765745F4C656E67746800417267756D656E744E756C6C457863657074696F6E0052656164537472696E670053716C55736572446566
696E656454797065417474726962757465006765745F436F756E740049456E756D657261626C6560310041646452616E676500456E756D
657261746F7200476574456E756D657261746F72006765745F43757272656E7400436F6E636174004D6F76654E6578740049446973706F
7361626C6500446973706F73650049734E756C6C4F72456D70747900537562737472696E67005472696D004368617200537472696E6753
706C69744F7074696F6E730053706C697400546F4C6F77657200417272617900536F72740053716C4D6574686F64417474726962757465
00537472696E67436F6D70617269736F6E00457175616C730041646400000372000003770000032C0000000000988CD7764C980A49A3DB
04E0EFC50A160008B77A5C561934E0890306121103200001052001011115052001011208042000111505200101121905200101121D0606
151221010E08200101151225010E0320000E03200002040000120C060001120C111503200008042001020E05200102120C080002120C12
0C120C03280002040800120C042001010E042001010205200101115504200101080520010111696101000200000004005402124973496E
76617269616E74546F4E756C6C73015402174973496E76617269616E74546F4475706C696361746573005402124973496E76617269616E
74546F4F726465720054080B4D61784279746553697A65401F000005200112110E0520011211030307010205200112111C02060E052002
0E08080607030E1115022B010002000000020054080B4D61784279746553697A65401F000054020D4973427974654F7264657265640105
151221010E05151225010E0920010115127901130008200015117D0113000515117D010E04200013000600030E0E0E0E040001020E0420
010E080B07050E0E0E15117D010E02040701120C0920021D0E1D0311808907100101011D1E00030A010E0B07060E1D0E08120C021D0324
0100020054020F497344657465726D696E6973746963015402094973507265636973650103070108080003020E0E1180950B0705020E02
15117D010E02050702120C020520010113000D0705120C0E120C15117D010E020807040E1D0E021D031801001355736572446566696E65
64446174615479706500000501000000000E0100094D6963726F736F667400002001001B436F7079726967687420C2A9204D6963726F73
6F6674203230313000000801000701000000000801000800000000001E01000100540216577261704E6F6E457863657074696F6E546872
6F7773010000000000006182CF4B000000000200000091000000D4330000D415000052534453E34F9E44F81FB94E95CF281C5235867A01
000000443A5C50726F6A656374735C55736572446566696E656444617461547970655C55736572446566696E656444617461547970655C
6F626A5C44656275675C4D6963726F736F66742E456E74657270726973654D616E6167656D656E742E53716C2E55736572446566696E65
6444617461547970652E70646200000000903400000000000000000000AE34000000200000000000000000000000000000000000000000
0000A034000000000000000000000000000000005F436F72446C6C4D61696E006D73636F7265652E646C6C0000000000FF250020400000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
00100000001800008000000000000000000000000000000100010000003000008000000000000000000000000000000100000000004800
000058400000080400000000000000000000080434000000560053005F00560045005200530049004F004E005F0049004E0046004F0000
000000BD04EFFE0000010000000100F068B30E00000100F068B30E3F000000000000000400000002000000000000000000000000000000
440000000100560061007200460069006C00650049006E0066006F00000000002400040000005400720061006E0073006C006100740069
006F006E00000000000000B00468030000010053007400720069006E006700460069006C00650049006E0066006F000000440300000100
30003000300030003000340062003000000034000A00010043006F006D00700061006E0079004E0061006D006500000000004D00690063
0072006F0073006F00660074000000500014000100460069006C0065004400650073006300720069007000740069006F006E0000000000
550073006500720044006500660069006E006500640044006100740061005400790070006500000040000F000100460069006C00650056
0065007200730069006F006E000000000031002E0030002E0033003700360033002E00320036003800360034000000000098003B000100
49006E007400650072006E0061006C004E0061006D00650000004D006900630072006F0073006F00660074002E0045006E007400650072
00700072006900730065004D0061006E006100670065006D0065006E0074002E00530071006C002E005500730065007200440065006600
69006E0065006400440061007400610054007900700065002E0064006C006C00000000005C001B0001004C006500670061006C0043006F
007000790072006900670068007400000043006F0070007900720069006700680074002000A90020004D006900630072006F0073006F00
660074002000320030003100300000000000A0003B0001004F0072006900670069006E0061006C00460069006C0065006E0061006D0065
0000004D006900630072006F0073006F00660074002E0045006E00740065007200700072006900730065004D0061006E00610067006500
6D0065006E0074002E00530071006C002E00550073006500720044006500660069006E0065006400440061007400610054007900700065
002E0064006C006C0000000000480014000100500072006F0064007500630074004E0061006D0065000000000055007300650072004400
6500660069006E006500640044006100740061005400790070006500000044000F000100500072006F0064007500630074005600650072
00730069006F006E00000031002E0030002E0033003700360033002E00320036003800360034000000000048000F000100410073007300
65006D0062006C0079002000560065007200730069006F006E00000031002E0030002E0033003700360033002E00320036003800360034
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000003000000C000000C034000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000);
set @ClrName = CONVERT(NVARCHAR(4000), 'Microsoft.EnterpriseManagement.Sql.UserDefinedDataType');
-- Drop trusted assembly if exists

IF EXISTS (select * from sys.trusted_assemblies where description = @ClrName)
BEGIN
EXEC SYS.sp_drop_trusted_assembly @Hash
END
END
--Add to trusted assembly

EXEC SYS.SP_ADD_TRUSTED_ASSEMBLY @Hash, @ClrName
END
GO
Verify the installation of Operations Manager Reporting server

When reinstalling the Operations Manager reporting server component on the server, perform the following steps
to confirm Reporting server is working correctly.
1. Verify that you can successfully run a report from the Operations console.
2. Ensure that the health state of all Management servers is Healthy.
How to upgrade to Operations Manager version
1807
4 minutes to read
This article describes how to perform a successful upgrade of System Center Operations Manager version 1801 to
1807. For more information about this upgrade and what issues are addressed, see KB4133779.
Requirements
This update is available from Microsoft Update in the following languages:
Chinese Simplified (CHS )
Chinese Traditional (CHT)
Czech (CSY )
Dutch (NLD )
English (ENU )
French (FRA)
German (DEU )
Hungarian (HUN )
Italian (ITA)
Japanese (JPN )
Korean (KOR )
Polish (POL )
Portuguese (Brazil) (PTB )
Portuguese (Portugal) (PTG )
Russian (RUS )
Spanish (ESN )
Swedish (SWE )
Turkish (TUR )
Some components are multilanguage, and the updates for these components are not localized.
You must run this update as an administrator on the systems hosting the Operations Manager components and
have System Administrator rights on the SQL Server instance hosting the Operations Manager databases and
Reporting server role.
If you don't want to restart the computer after you apply the Operations console update, close the Operations
console before you apply the update for the role.
If User Account Control is enabled, run the .msp update files from an elevated command prompt.
Supported installation order

Install the update package in the following order:
1. Management group features:
a. Management server or servers
b. Audit Collection Services
c. Web console server role computers
d. Gateway server or servers
e. Operations console role computers
f. Reporting server
2. Apply SQL scripts.
3. Manually import the management packs.
4. Apply the Agent update to manually installed agents or approve for upgrade from the Pending
Management view in the Operations console for agents discovered and installed from the console.
5. Apply the Nano Agent update to manually installed agent or approve the upgrade from the Pending view in
the Operations console for agents discovered and installed from the console.
6. Update Unix/Linux management packs and agents.
How to obtain Microsoft System Center Operations Manager 1807

Update
Update packages for Operations Manager are available from Microsoft Update or by manual download.
Microsoft Update
To obtain and install an update package from Microsoft Update, follow these steps on a computer that has an
Operations Manager component installed:
1. Select Start, and then select Control Panel.
2. In Control Panel, double-click Windows Update.
3. In the Windows Update window, select Check Online for updates from Microsoft Update.
4. Select Important updates are available.
5. Select the update rollup package, and then select OK.
6. Select Install updates to install the update package.
If your computer is running Windows Server 2016 or later, follow these steps:
1. Select Start, and then select Settings.
2. In Settings, select Updates & Security.
3. On the Windows Update tab, select Check Online for updates from Microsoft Update.
4. Select Important updates are available.
5. Select the update rollup package, and then select OK.
6. Select Install updates to install the update package.
Manual download
Go to the following websites to manually download the update packages from the Microsoft Update Catalog:
Download the Operations Manager update package now.
Update Operations Manager features

To download the update rollup package and extract the files that are contained in the update rollup package, follow
these steps:
1. Download the update packages that Microsoft Update provides for each computer. Microsoft Update
provides the appropriate updates according to the components that are installed on each computer. Or
download from the Microsoft Update Catalog. Apply the appropriate MSP files on each computer.
NOTE
Windows Installer patch (.MSP file) files are included in the update package. Apply all patch packages that relate to a
specific computer. For example, if the Web console and Operations console role is installed on a management server,
apply the .MSP files on the management server. Apply one patch package to a server for each specific feature that is
installed on the server.
2. Execute the following SQL database SQL scripts located in the following location:
%SystemDrive%\Program Files\Microsoft System Center\Operations Manager\Server\SQL Script for Update
Rollups
Execute the following script on the SQL Server instance hosting the OperationsManagerDB
database:
Update_rollup_mom_db.sql
Execute the following script on the SQL Server instance hosting the DataWarehouse database:
UR_Datawarehouse.sql
3. Import the following management packs:
MANAGEMENT PACK VERSION
Microsoft.SystemCenter.Advisor.Internal.mpb 7.3.13261.0
Microsoft.SystemCenter.HtmlDashboard.Library.CHS.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.CHT.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.CSY.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.DEU.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.ESN.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.FRA.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.HUN.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.ITA.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.JPN.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.KOR.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.mp 7.3.13261.0
Microsoft.SystemCenter.HtmlDashboard.Library.NLD.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.PLK.mp 7.3.13246.0
MANAGEMENT PACK VERSION
Microsoft.SystemCenter.HtmlDashboard.Library.PTB.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.PTG.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.RUS.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.SVE.mp 7.3.13246.0
Microsoft.SystemCenter.HtmlDashboard.Library.TRK.mp 7.3.13246.0
Microsoft.SystemCenter.Internal.mp 7.0.8438.7
Microsoft.SystemCenter.Internal.UI.Tasks.mp 7.3.13261.0
Microsoft.Unix.ConsoleLibrary.mp 7.7.1135.0
For information about how to import a management pack from a disk, see How to import, export, and
remove an Operations Manager management pack.
NOTE
Management packs are included in the Server component updates in the following location:
%SystemDrive%\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for
Update Rollups
Update Nano Agent

To manually install the updates to Nano Agent, download the KB3209591-8.0.10913.0-NanoAgent.cab file. You
can install this update on a Nano Agent system by using the following PowerShell script:
.\UpdateNanoServerScomAgentOnline.ps1 -NanoServerFQDN <FQDN of target Nano Server> -BinaryFolder <Path where

the update .cab is already expanded OR path to one or more Nano-agent update .cab files> -IsCabExpanded <$true
if BinaryFolder path is to an expanded .cab, $false if it is for a packed .cab file(s)> -RemoveBackup <$true
to remove the previous binaries from the agent machine>
NOTE
The UpdateNanoServerScomAgentOnline.ps1 file is available in the following location:
%SystemDrive%\Program Files\Microsoft System Center\Operations
Manager\Server\AgentManagement\Nano\NanoServer
Update UNIX and Linux management packs

To install the updated monitoring packs and agents for UNIX and Linux operating systems, perform the following
steps.
1. Apply System Center Operations Manager version 1807 Update to your System Center version 1801
Operations Manager management group.
2. Download the Microsoft System Center 1801 MP for UNIX and Linux.msi installer package file -
System Center Management Pack for UNIX and Linux Operating Systems.
3. Install the management pack update package to extract the management pack files.
4. Import the updated management pack for each version of Linux or UNIX that you are monitoring in your
environment.
5. Upgrade each agent to the latest version by using either the Update-SCXAgent Windows PowerShell
cmdlet or the UNIX/Linux Agent Upgrade Wizard from the Device Management node under the
Administration workspace in the Operations console.
How to upgrade from the evaluation version of
Operations Manager
2 minutes to read
The System Center Operations Manager evaluation version expires 180 days after you install it.
To upgrade from an evaluation version of Operations Manager to a licensed version, you must obtain a valid
product key from Microsoft. For information about Operations Manager licensing, see System Center Licensing.
NOTE
To check whether Operations Manager is licensed, in the Operations console, click Help, and then click About. In the
Product version field, it will show the version (Retail) after the version information. If it shows (Eval), then your installation
is an evaluation version.
To upgrade from the evaluation version of System Center Operations

Manager 1801
Before proceeding, you need to be a member of the Operations Manager administrators role.
1. In the Operations console, click Help and then click About.
2. Click Activate and on the Enter Product Key window in the Product key box, enter a valid product key
including the dashes. Press Continue to save your changes.
3. On the Please read this license agreement, review the Microsoft Software License Terms, select I have read,
understood and agree with the license terms, and then click Accept.
After the change is applied, the Operations console title bar will no longer show how many days are remaining for
evaluation period as well as in the About window.
Upgrade after the evaluation period
If you did not activate your license for the management group before the evaluation period expires, which is 180
days, after the evaluation period has expired you will receive a notification when you open the Operations console
or launch the Operations Manager command shell.
You perform the following steps to upgrade from the evaluation period using PowerShell directly on a
management server or from a remote computer that has the Operations Manager Command Shell installed.
Before proceeding, you need to be a member of the Operations Manager administrators role to ensure this
completes successfully.
1. Open the Operations Manager Command Shell.
2. Run the
Set-SCOMLicense -ManagementServer <Server name or IP address> -ProductId <your licensekey> -Credential
<PSCredential>
command. If you do not include the -Credential parameter, after you enter the command, an authentication
dialog box appears prompting you to enter credentials.
3. The cmdlet asks for confirmation. Enter Y to allow it to complete the action. If the command is successful, it
returns a message indicating it was licensed successfully.
4. Restart the System Center Data Access Service service on all management servers in the management group in
order for the setting to take effect.
To upgrade from the evaluation version of System Center 2016 -
Operations Manager
Before proceeding, you need to be a member of the Operations Manager administrators role, member of the
computer's local Administrators group on the management server, and granted temporary membership of the
sysadmin fixed server role on the SQL Server instance hosting the Operations Manager operational database to
ensure this completes successfully.
NOTE
Note To use the Set-SCOMLicense cmdlet, you must use elevated permissions (Run as Administrator).
1. Open PowerShell as an administrator.

2. Load the OperationsManager module (import-module operationsmanager).
3. Connect to your management group (New -SCOMManagementGroupConnection).
4. Run the Set-SCOMLicense -ProductId <yourlicensekey> command.
5. Restart the System Center Data Access Service service on all management servers in the management group in
order for the setting to take effect.
6. To check whether the changes were made, run the following command:
Get-SCOMManagementGroup | ft skuforlicense, version, timeofexpiration –a
For more information about Set-SCOMLicense, type the following in the Operations Manager Command Shell:
get-help Set-SCOMLicense
For current information about your license, you can use the Get-SCOMLicense cmdlet. For more information, type
the following in the Operations Manager Command Shell:
get-help Get-SCOMLicense
Post-Upgrade tasks when upgrading to System
Center Operations Manager
2 minutes to read
After you have completed the upgrade process to System Center 2016 - Operations Manager or version 1801,
you must perform a number of post-upgrade tasks.
Post-upgrade tasks
Perform the following tasks when you have completed the upgrade process.
1. Re-enable the Notification Subscriptions
2. Restart or re-enable the Connector Services (if needed)
3. Re-enable Audit Collection Services (ACS ) on agents that were upgraded
4. Reset agent HealthService Cache size
5. Verify the upgrade was successful
Re -enable the notification subscriptions
After the upgrade has finished, use the following procedure to re-enable subscriptions.
To re-enable the subscriptions
1. Open the Operations console with an account that is a member of the Operations Manager
NOTE
dialog box appears. In the Server name text box, type the name of the Operations Manager management server
to which you want to connect.
3. In the Administration pane, under Notifications, click Subscriptions.

4. n the Actions pane, click Enable for each subscription listed that was enabled prior to performing the
upgrade.
Restart or re -enable the connector services
Refer to third-party documentation for any installed connectors to determine if the connectors are supported
for System Center Operations Manager. If you stopped a connector for any reason during upgrade, restart the
service.
To restart a connector service
1. Open the Services MMC snap-in. Click Start, and then type services.msc in the Start Search box.
2. In the Name column, right-click the connector that you want to restart, and then click Start.
Re -Enable Audit Collection Services
If you had Audit Collection Services (ACS ) enabled for an agent prior to upgrade, it was disabled as part of the
agent upgrade process. Re-enable ACS as appropriate.
Reset agent HealthService cache size
Restore the default setting for the agent HealthService cache size by updating the following registry setting on
the agents manually or automated with your configuration management or orchestration solution:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlsSet\Services\HealthService\Parameters\Management
Groups<ManagementGroupName>\maximumQueueSizeKb
The default decimal value of DWORD type is 15360 (15 MB ).
Verify that the upgrade was successful
Perform the following tasks to verify that the upgrade was successful.
Check the health state of the management and gateway servers, and agents in the Health Service Watcher
state view. In the Administration workspace of the Operations console, ensure that the management and
gateway servers, and agents are healthy. In the Monitoring workspace, check if there are any alerts related
to the management group health.
Review the event logs of all the management servers for new errors. Sort alerts by the last-modified column
to review the new alerts.
Monitor CPU and memory utilization, and disk I/O on your database servers to ensure that they are
functioning normally.
If the Reporting feature is installed, click Reporting, and then run a generic performance report to ensure
that Reporting is functioning correctly.
Next steps
Quick reference to Operations Manager tasks
4 minutes to read
The following table gives a quick reference for where to perform common tasks and links to relevant information.
TO PERFORM THIS TASK DO THIS
Check for problems in a management group - Check the Management Group Health view in the
Operations Manager folder in the Monitoring workspace
- See the State and Alerts summary on the Monitoring
Overview page
- Check Active Alerts in the Monitoring workspace
- Check Task Status in the Monitoring workspace
Start monitoring a computer On the Administration Overview page, click Configure

computers and devices to manage. For more information,
see Operations Manager agents.
Start monitoring a network device On the Administration overview page, click Configure
computers and devices to manage. For more information,
see Monitor network devices.
Create or modify a resource pool In the Administration workspace, click Resource Pools. For
more information, see How to Create a Resource Pool and
Managing Resource Pools for UNIX and Linux Computers.
- Create a group Click Groups in the Authoring workspace

- View available groups
- View group members For instructions, see Creating and Managing Groups
- View state of a group
- View diagram of a group
- Modify a group
Create a view In the Monitoring workspace or My Workspace, at the

bottom of the navigation pane, click New View. For more
information, see Using Views in Operations Manager.
Customize the settings of a view for your own use In the Monitoring workspace, right-click a view in the
navigation pane, and then click Personalize view. For more
information, see How to Personalize a View in Operations
Manager.
Change the interval for heartbeats. In the Administration workspace, click Settings, and then
under Agent, click Heartbeat. For more information, see How
Change the number of missed heartbeats allowed In the Administration workspace, click Settings, and then
under Server, click Heartbeat. For more information, see
How Heartbeats Work in Operations Manager.
Change a setting for a rule, monitor, or alert. Make changes to rules, monitors, or alerts by creating an
override. Select a rule, monitor, or alert, and then access the
overrides options by right-clicking, or clicking Overrides on
the toolbar, or clicking Overrides in the Tasks pane. For more
information, see How to Override a Rule or Monitor and
Creating a Management Pack for Overrides.
Change how frequently records are removed from the In the Administration workspace, click Settings, right-click
operational database. Database Grooming, and then click Properties. For more
information, see How to Configure Grooming Settings for the
Operations Manager Database.
Give a user permissions to view Operations Manager In the Administration workspace, click User Roles, and then
information or perform tasks. right-click a specific role and click Properties. For more
information, see Implementing User Roles
Display a dashboard view on a SharePoint site. You must deploy the Operations Manager Web Part to a
SharePoint site, configure the Web Part to connect to a web
console, and add the Web Part to a SharePoint page. For more
information, see Using SharePoint to View Operations
Manager Data.
Receive notifications of an alert in email, instant message, or Right-click an alert, point to Notification subscription, and
text message. then click Create. For more information, see Subscribing to
Alert Notifications.
Investigate a gray agent. In the Monitoring workspace, in the Operations

Manager\Agent Details\Agent Health State view, in the
Agent State from Health Service Watcher section, click the
gray agent, and then in the Tasks pane, click Show Gray
Agent Connectivity Data. For more information, see Not
Monitored and Gray Agents.
Stop monitoring a computer temporarily. In the Monitoring workspace, click Windows Computers,
right-click the computer you want to stop monitoring, and
click Maintenance Mode. For more information, see How to
Suspend Monitoring Temporarily by Using Maintenance
Mode.
Monitor health of management group In the Monitoring workspace, navigate to Operations

Manager\Management Group Health to see important
health status information for components and agents in the
management group. For more information, see Monitor health
of the management group.
Migrate the Operations Manager databases If you need to upgrade your SQL Server or move to a server
on new hardware, perform the steps described in the following
articles to move the operational or data warehouse database
- How to move the Operational database
- How to move the Reporting DW database.
Configure data retention of Operations Manager databases To maintain data for a set period of time and maintain optimal
performance, you can configure data retention in the
Operations Manager and data warehouse database. Perform
the steps described in the following articles
- How to configure grooming for the Operational database
- How to configure grooming for the Reporting DW database.
How and when to clear the cache Understand how and when to clear the cache when
troubleshooting console or agent issues by performing the
steps described in
- How and when to clear the cache
Configure communication from Operations Manager to SQL If you need to move the Operations Manager databases to a
Server different SQL Server, reconfigure the SQL Server instance, or
implement SQL Always On, perform the steps described in
How to configure Operations Manager to communicate with
SQL Server.
Integrate with Azure Monitor Integration with Azure Monitor logs provides an analytics
platform that compliments the Data Warehouse to deliver
improved analytics, query performance across large data
volumes, correlate log data from Azure resources, and longer
retention of monitoring data.
Next steps
To learn more about what to manage, how to manage, or how to support an Operations Manager management
group, see the Operations Guide for System Center - Operations Manager
Operations Manager Monitoring Scenarios
2 minutes to read
System Center Operations Manager supports a variety of methods to actively monitor different services and the
components and devices that support them. This article summarizes each scenario supported with a link to the
detailed supporting documentation describing how to plan and configure monitoring each scenario.
Operations Manager monitoring scenarios topics

Agentless monitoring
Monitoring across untrusted boundaries
Client monitoring using Agentless Exception Monitoring
Monitoring failover clusters
Monitoring networks
Monitoring Service Level Objectives
Monitoring .NET applications
Monitoring Java applications
Monitoring UNIX and Linux computers
Monitoring Linux log files
Connecting Operations Manager with other management systems
Monitoring Operations Manager from a second management group
Integrating with Active Directory
Integration with Azure Log Analytics
Install Agent on Windows Using the Discovery
Wizard
6 minutes to read
You can use the Operations console to search your environment for manageable objects and then deploy an
agent to any object that you want to monitor. The process of searching your environment is called discovery. One
of the advantages of using discovery is that it lists all manageable objects, including any that you might not be
aware of.
The Discovery Wizard does not show computers that the management group is already monitoring. If you are
doing a phased rollout of your management group, you can run the wizard to add new computers to the group.
Also, after your initial deployment, you can use the Discovery Wizard to add newly installed computers to be
managed.
When agents are pushed out to computers, System Center Operations Manager sends credentials that have local
administrator rights for that computer; this is required to install the agent.
If the Discovery Wizard is not right for your needs (for example, if you have a set list of computers to which you
want to deploy agents), you have the option of manually installing agents on systems to be managed. Agents can
also be embedded in the host image of the monitored computer.
Use the following procedure to discover computers running Windows and deploy the Operations Manager agent
to the discovered computers from the Operations console. For a list of the supported operating system versions,
see Microsoft Monitoring Agent Operating System requirements.
NOTE
For information about port requirements for agents, see Agent and Agentless Monitoring in the Deployment Guide.
To install an agent on a computer running Windows by using the

Discovery Wizard
1. Log on to the Operations console with an account that is a member of the Operations Manager
Administrators role.
2. Click Administration.
3. At the bottom of the navigation pane, click Discovery Wizard.
4. In the Computer and Device Management Wizard, on the Discovery Type page, click Windows
computers.
5. On the Auto or Advanced? page, do the following:
a. Select either Automatic computer discovery or Advanced discovery. If you select Automatic
computer discovery, click Next, and then go to step 7. If you select Advanced discovery,
continue with the following steps.
NOTE
Automatic computer discovery scans for Windows-based computers in the domain. Advanced discovery
allows you to specify criteria for the computers that the wizard will return, such as computer names starting
with NY.
b. In the Computer and Device Classes list, select Servers and Clients, Servers Only, or Clients
Only.
c. In the Management Server list, click the management server or gateway server to discover the
computers.
d. If you selected Servers and Clients, you can select the Verify discovered computers can be
contacted check box. This is likely to increase the success rate of agent deployment, but discovery
can take longer.
NOTE
If the Active Directory catalog does not contain the NetBIOS names for computers in a domain, select
Verify discovered computers can be contacted. Otherwise, the Browse, or Type In option fails to find
computers. This affects computers in the same domain as the management server, in another domain with a
full trust relationship, and in untrusted domains by using a gateway server.
e. Click Next.
NOTE
The wizard can return approximately 4000 computers if Verify discovered computers can be contacted
is selected, and it can return 10,000 computers if this option is not selected. Automatic computer discovery
verifies that discovered computers can be contacted. A computer that is already managed by the
management group is not returned.
6. On the Discovery Method page, you can locate the computers that you want to manage by either
scanning or browsing Active Directory Domain Services or typing the computer names.
If you want to scan, do the following:
a. If it is not already selected, select Scan Active Directory and then click Configure.
b. In the Find Computers dialog box, type the criteria that you want to use for discovering computers,
and then click OK.
c. In the Domain list, click the domain of the computers that you want to discover.
If you want to browse Active Directory Domain Services or type the computer names, do the following:
a. Select Browse for, or type-in computer names, click Browse, specify the names of the computers
that you want to manage, and then click OK.
b. In the Browse for, or type-in computer names box, type the computer names, separated by a
semi-colon, comma, or a new line. You can use NetBIOS computer names or fully qualified domain
names (FQDN ).
7. Click Next, and on the Administrator Account page, do one of the following:
a. Select Use selected Management Server Action Account if it is not already selected.
b. Select Other user account, type the User name and Password, and then select the Domain from
the list. If the user name is not a domain account, select This is a local computer account, not a
domain account.
IMPORTANT
The account must have administrative privileges on the targeted computers. If This is a local computer
account, not a domain account is selected, the management server action account will be used to
perform discovery.
8. Click Discover to display the Discovery Progress page. The time it takes discovery to finish depends on
many factors, such as the criteria specified and the configuration of the IT environment. If a large number
(100 or more) of computers are being discovered or agents are being installed, the Operations console will
not be usable during discovery and agent installation.
NOTE
Computers that are already managed by the management group will not be returned by the wizard.
9. On the Select Objects to Manage page, do the following:

a. Select the computers that you want to be agent-managed computers.
b. In the Management Mode list, click Agent and then click Next.
NOTE
The discovery results show virtual nodes of clusters. Do not select any virtual nodes to be managed.
10. On the Summary page, do the following:

1. Leave the Agent installation directory set to the default of %ProgramFiles%\Microsoft
Monitoring Agent or type an installation path.
IMPORTANT
If a different Agent installation directory is specified, the root of the path must exist on the targeted
computer or the agent installation fails. Subdirectories, such as \Agent, are created if they do not exist.
2. Leave Agent Action Account set to the default, Local System, or select Other and type the User
name, Password, and Domain. The Agent Action Account is the default account that the agent will
use to perform actions.
3. Leave Install APM set to the default if you intend to monitor a .NET web-based application on the
targeted computer. Otherwise, deselect the option.
4. Click Finish.
a. Leave the Agent installation directory set to the default of %ProgramFiles%\Microsoft
IMPORTANT
b. Leave Agent Action Account set to the default, Local System, or select Other and type the User
c. Click Finish.
11. In the Agent Management Task Status dialog box, the Status for each selected computer changes from
Queued to Success; the computers are ready to be managed.
NOTE
If the task fails for a computer, click the targeted computer. The reason for the failure is displayed in the Task
Output text box.
12. Click Close.
Next steps
MOMAgent.msi.
To learn how to upgrade the agent on Windows computers from a previous version, see How to upgrade
an agent to System Center Operations Manager.
To understand how to manage the configuration settings of a Windows agent and options available, review
Configuring Windows Agents.
Review Uninstall Agent from Windows-based Computers to understand what options and steps need to
be performed to properly uninstall the agent from your Windows computers.
Install agent on UNIX and Linux using the Discovery
Wizard
3 minutes to read
Use the Computer and Device Management Wizard to discover and install agents on UNIX and Linux
computers. For a list of the supported operating system versions, see Supported Operating Systems and
Versions.
Before you run the wizard, gather the following information:
The host name, IP address, or range of IP addresses of the UNIX or Linux computers that you want to
discover.
At a minimum, you will need a low -privileged account established on the UNIX or Linux computer to
discover it. To install an agent, you will need privileged access. For more information, see Planning Security
Credentials for UNIX and Linux Computers.
If defined, the name of the resource pool created to monitor UNIX or Linux computers. Resource pools can
contain management servers or gateways for monitoring UNIX or Linux computers. For more
information, see Resource Pool Design Considerations.
To discover and install an agent on a UNIX or Linux computer

4. On the Discovery Type page, click Unix/Linux computers.
5. On the Discovery Criteria page, do the following:
a. Click Add to define a discovery scope. In the Discovery Criteria dialog box, do the following:
a. For the Discovery scope, click the ellipsis button … to specify the host name, IP address, or
range of IP addresses of the UNIX- or Linux-based computers to be discovered.
b. For the Discovery type select Discover all computers or Discover only computers with the
UNIX/Linux agent installed.
If you choose to discover only computers with the agent installed, the only credential that you will
need to provide is for the agent verification. This can be a low -privileged account on the UNIX or
Linux computer.
IMPORTANT
Discovering only computers with the agent installed requires that the agent is currently installed and
configured with a signed certificate.
c. To specify the credentials for installing an agent, click Set credentials. For detailed instructions,
see “Credentials for Installing Agents” in Setting Credentials for Accessing UNIX and Linux
Computers.
Alternatively, to use default credentials, check the box Use Run As Credentials. If this option is
selected, a default Run As account must be defined in the UNIX/Linux Action Account and
UNIX/Linux Agent Maintenance Account Run As profiles. The default account is one that is
associated with All Managed Objects.
d. Click Save.
b. Select a resource pool to monitor the UNIX or Linux computer.
6. Click Discover to display the Discovery Progress page. The time it takes to finish discovery depends on
many factors, such as the criteria specified and the configuration of the environment. If a large number
(100 or more) of computers are being discovered or agents are being installed, the Operations console will
not be usable during discovery and agent installation.
7. On the Computer Selection page, on the Manageable computers tab, select the computers that you
want to be managed. The Additional results tab lists any errors and computers that are already being
managed.
8. Click Manage.
9. On the Computer Management page, after the deployment process is completed, click Done.
You must have, at a minimum, a UNIX/Linux Action Account profile configured with a Monitoring Run As
Account to monitor the UNIX or Linux computer. For more information, see How to Configure Run As Accounts
and Profiles for UNIX and Linux Access.
NOTE
Solaris Zones are supported on Solaris 10 or newer versions. In monitoring a computer with Zones, each Zone is treated
like a separate computer. You must install the agent on each computer that you want to monitor. Install the agent on the
global zone first, because sparse zones share files with the global zone. If you try to install on a sparse zone first, the
installation fails. For more information about troubleshooting, see Operating System Issues.
Next steps
For more information on how to install the agent and understand the steps for signing the agent
certificate, see Install Agent and Certificate on UNIX and Linux Computers Using the Command Line
To learn how to configure object discovery rules and disable discovery of a specific object, see Applying
Overrides to Object Discoveries.
To understand how to perform agent maintenance on UNIX and Linux computers, see Upgrading and
Uninstalling Agents on UNIX and Linux Computers.
Review Manually Uninstalling Agents from UNIX and Linux Computers to understand what options and
steps need to be performed to properly uninstall the agent from your UNIX and Linux computers.
Install Windows Agent Manually Using
MOMAgent.msi
8 minutes to read
You can use MOMAgent.msi to deploy System Center Operations Manager agents from the command line or by
using the Setup Wizard. Deploying agents from the command line is also referred to as a manual install. For a
list of the supported operating system versions, see Microsoft Monitoring Agent Operating System
requirements.
Before you use either method to manually deploy the agent, ensure the following conditions are met:
The account that is used to run MOMAgent.msi must have administrative privileges on the computer on
which you are installing agent.
Each agent that is installed with the Setup Wizard or from the command line must be approved by a
management group. For more information, see Process Manual Agent Installations.
If an agent is manually deployed to a domain controller and the Active Directory management pack is
later deployed, errors might occur during deployment of the management pack. The Active Directory
helper object is used by the Active Directory management pack on Windows domain controllers. The
Active Directory Management Pack helper object is normally installed automatically when the agent is
deployed using the Discovery Wizard. To prevent errors from occurring or recover from errors already
occurring, you need to manually install the Windows installer package OomADs.msi on the affected
domain controller. The file can be located on the domain controller in the %ProgramFiles%\Microsoft
Monitoring Agent\Agent\HelperObjects folder.
A management group (or single management server) must be configured to accept agents installed with
MOMAgent.msi or they will be automatically rejected and therefore not display in the Operations console.
For more information, see Process Manual Agent Installations. If the management group or server is
configured to accept manually installed agents after the agents have been manually installed, the agents
will display in the console after approximately one hour.
NOTE
For information about port requirements for agents, see Communication Between Agents and Management Servers.
MOMAgent.msi can be found in the Operations Manager installation media and in the following folder on a
System Center - Operations Manager management server %ProgramFiles%\Microsoft System Center
2016\Operations Manager\Server\AgentManagement<platform>. For a version 1801 or higher management
server, the agent installation files can be found in the following folder - %ProgramFiles%\Microsoft System
Center\Operations Manager\Server\AgentManagement<platform>.
IMPORTANT
The Application Performance Monitoring (APM) feature in System Center 2016 Operations Manager and version 1801
agent causes a crash with IIS Application Pools that are running under the .NET Framework 2.0 runtime. By default when
the agent is installed on a Windows computer, the APM components are installed by default. To avoid issues and prevent
installation of the APM components on target Windows servers when you deploy the agent, add the NOAPM=true
parameter
To deploy the Operations Manager agent with the Agent Setup
Wizard
1. Use local administrator privileges to log on to the computer where you want to install the agent.
2. On the Operations Manager installation media, double-click Setup.exe.
3. In Optional Installations, click Local agent.
5. On the Important Notice page, review the Microsoft software license terms and then click I Agree.
6. On the Destination Folder page, leave the installation folder set to the default, or click Change and type
a path, and then click Next.
7. On the Agent Setup Options page, you can choose whether you want to connect the agent to
Operations Manager. When you connect the agent to Operations Manager, you can manually choose
the management group that this agent will participate with in monitoring. If you do not select this option,
the agent can still collect Application Performance Monitoring data locally. You can change your selection
in the Monitoring Agent item in Control Panel.
8. On the Management Group Configuration page, do the following:
a. Type the name of the management group in the Management Group Name field and the (which
server?) server name in the Management Server field.
NOTE
To use a gateway server, enter the gateway server name in the Management Server text box.
b. Type a value for Management Server Port, or leave the default of 5723.
c. Click Next.
9. On the Agent Action Account page, leave it set to the default of Local System, or select Domain or
Local Computer Account; type the User Account, Password, and Domain or local computer; and
then click Next.
10. On the Ready to Install page, review the settings and then click Install to display the Installing
Microsoft Monitoring Agent page.
To deploy the Operations Manager agent from the command line

1. Log on to the computer where you want to install the agent by using an account with local administrator
privileges.
2. Open a command prompt as an administrator.
3. Run the following command:
%WinDir%\System32\msiexec.exe /i path\Directory\MOMAgent.msi /qn USE_SETTINGS_FROM_AD={0|1}
USE_MANUALLY_SPECIFIED_SETTINGS={0|1} MANAGEMENT_GROUP=MGname MANAGEMENT_SERVER_DNS=MSname
MANAGEMENT_SERVER_AD_NAME =MSname SECURE_PORT=PortNumber ACTIONS_USE_COMPUTER_ACCOUNT={0|1}
ACTIONSUSER=UserName ACTIONSDOMAIN=DomainName ACTIONSPASSWORD=Password AcceptEndUserLicenseAgreement=1
NOTE
Ensure you use the correct 32-bit or 64-bit version of MOMAgent.msi for the computer you are installing the
agent on.
where:
PARAMETER VALUE
USE_SETTINGS_FROM_AD={0|1} Indicates whether the management group settings

properties will be set on the command line. Use 0 if you
want to set the properties at the command line. Use 1 to
use the management group settings from Active
Directory.
USE_MANUALLY_SPECIFIED_SETTINGS=={0|1} If USE_SETTINGS_FROM_AD=1, then

USE_MANUALLY_SPECIFIED_SETTINGS must equal 0.
MANAGEMENT_GROUP=MGname Specifies the management group that will manage the

computer.
MANAGEMENT_SERVER_DNS=MSname Specifies the fully qualified domain name for the

management server. To use a gateway server, enter the
gateway server FQDN as MANAGEMENT_SERVER_DNS.
MANAGEMENT_SERVER_AD_NAME=ADname Use this parameter if the computer's DNS and Active

Directory names differ to set to the fully qualified Active
Directory Domain Services name.
SECURE_PORT=PortNumber Sets the health service port number.
ENABLE_ERROR_REPORTING={0|1} Optional parameter. Use this parameter with "1" to opt in

to error report forwarding to Microsoft. If you do not
include this parameter, the agent installation defaults to
"0", which opts out of error report forwarding.
QUEUE_ERROR_REPORTS={0|1} Optional parameter. Use this parameter with "1" to queue

error reports or with "0" to send reports immediately. If
you do not include this parameter, the agent installation
defaults to "0".
INSTALLDIR=path Optional parameter. Use this parameter if you want to

install the agent to a folder other than the default
installation path. Note that \Agent will be appended to
this value.
ACTIONS_USE_COMPUTER_ACCOUNT={0|1} Indicates whether to use a specified user account (0) or

the Local System account (1).
PARAMETER VALUE
ACTIONSUSER=UserName Sets the Agent Action account to UserName. This

parameter is required if you specified
ACTIONS_USE_COMPUTER_ACCOUNT=0.
ACTIONSDOMAIN= DomainName Sets the domain for the Agent Action account identified
with the ACTIONSUSER parameter.
ACTIONSPASSWORD= Password The password for the user identified with the
ACTIONSUSER parameter.
NOAPM=1 Optional parameter. Installs the Operations Manager

agent without .NET Application Performance Monitoring.
If you are using AVIcode 5.7, NOAPM=1 leaves the
AVIcode agent in place. If you are using AVIcode 5.7 and
install the Operations Manager agent by using
momagent.msi without NOAPM=1, the AVIcode agent
will not work correctly and an alert will be generated.
AcceptEndUserLicenseAgreement=1 Used to specify that you accept the End User License
Agreement (EULA). This parameter is required when you
use /qn to perform a fully silent installation of the agent.
Examples of installing the agent from the command line

The following examples show different ways in which you can install the MOMAgent.msi Windows Installer
package manually from the command line. You can perform new installations of agents, upgrade agents from
previous releases of Operations Manager, uninstall the agent, or change the configuration of an agent (such as
the management group or management server associated with the agent).
Agent installation using a specific Action Account
The following example shows a fresh installation of an agent and uses a specific Action Account.
msiexec.exe /i path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentinstall.log USE_SETTINGS_FROM_AD=0

MANAGEMENT_GROUP=<MG_Name> MANAGEMENT_SERVER_DNS=<MSDNSName> MANAGEMENT_SERVER_AD_NAME=<MSDNSName>
ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER=<AccountUser> ACTIONSDOMAIN=<AccountDomain> ACTIONSPASSWORD=
<AccountPassword> USE_MANUALLY_SPECIFIED_SETTINGS=1 AcceptEndUserLicenseAgreement=1
Agent installation using the Local System account

The following example shows a fresh installation of an agent and uses the Local System for the Action Account.
msiexec.exe /i path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentinstall.log USE_SETTINGS_FROM_AD=0

MANAGEMENT_GROUP=<MG_Name> MANAGEMENT_SERVER_DNS=<MSDNSName> MANAGEMENT_SERVER_AD_NAME=<MSDNSName>
ACTIONS_USE_COMPUTER_ACCOUNT=1 USE_MANUALLY_SPECIFIED_SETTINGS=1 AcceptEndUserLicenseAgreement=1
Agent installation with Active Directory integration and using a specific Action Account
The following example installs an agent by using Active Directory and a specific Action Account.
msiexec /i path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentInstall.log USE_SETTINGS_FROM_AD=1
USE_MANUALLY_SPECIFIED_SETTINGS=0 ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER=<AccountUser> ACTIONSDOMAIN=
<AccountDomain> ACTIONSPASSWORD=<AccountPassword> AcceptEndUserLicenseAgreement=1
Agent installation with Active Directory integration and using the Local System account
The following example installs an agent by using Active Directory and the Local system account for the Action
Account.
msiexec /i path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentInstall.log USE_SETTINGS_FROM_AD=1

ACTIONS_USE_COMPUTER_ACCOUNT=1 USE_MANUALLY_SPECIFIED_SETTINGS=0 AcceptEndUserLicenseAgreement=1
Agent upgrade from a previous release of Operations Manager

The following example upgrades an agent.
msiexec /i path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentUpgrade.log AcceptEndUserLicenseAgreement=1
Uninstall the agent

The following example uninstalls an agent.
msiexec /x path\Directory\MOMAgent.msi /qn /l*v %temp%\OMAgentUninstall.log
Deploy the agent with APM disabled using PowerShell

The following example shows how you install the Windows agent from PowerShell with the Application
Performance Monitoring (APM ) component disbled.
Install-SCOMAgent -DNSHostName "ComputerA.contoso.net" -PrimaryManagementServer $PrimaryMS -NoAPM
Repair the agent and disable APM using PowerShell

The following example shows how you repair the Windows agent from PowerShell and disable the Application
Performance Monitoring (APM ) component.
Get-SCOMAgent -DNSHostName "ComputerA.contoso.net" | Repair-SCOMAgent -NoAPM
Next steps
Agent on Windows Using the Discovery Wizard.
If you would like to install the Nano Server agent using the Discovery Wizard, from the command line or
automate the deployment using a script or other automation solution, review Install Agent on Nano
Server.
To learn how to upgrade the agent on Windows computers from a previous version, see How to upgrade
an agent to System Center Operations Manager.
To understand how to manage the configuration settings of a Windows agent and options available,
review Configuring Windows Agents.
Review Uninstall Agent from Windows-based Computers to understand what options and steps need to
be performed to properly uninstall the agent from your Windows computers.
Install agent on Nano Server
8 minutes to read
Windows Server 2016 Nano Server is a new installation option introduced in Windows Server 2016. Nano
Server is optimized for private cloud and datacenter operations. With System Center 2016 - Operations Manager
you can now monitor Nano Server by installing the Operations Manager agent.
Nano Server monitoring capabilities

With the release of Nano Server you can monitor the basic operations of the Server by using the Windows Server
Operating System Management Pack. You can also monitor a Nano Server running the following workloads:
Windows Failover Cluster
Domain Name System (DNS ) server
Internet Information Services (IIS )
You can download these management packs for Nano Server from the Microsoft Download Center.
Monitoring a Nano Server installation is similar to monitoring any other installation of Windows Server, however,
there are some key differences in how you install the agent on a Nano Server.
You will need to follow the steps listed below to start monitoring a Nano Server.
1. Deploy the Operations Manager agent from the Operations console using the Discovery Wizard or
Manually install the Operations Manager agent on a Nano server.
2. Validate that the Operations Manager agent has been successfully installed
3. Process Manual Agent Installations if you installed the agent manually on Nano Server.
4. Verify that you are monitoring your Nano Server.
There are several limitations in this release of the Nano Server agent. The following operations are not supported
in this release:
Installing the Operations Manager Agent via an MSI package.
Monitoring a Nano Server that is not in the same domain as the Operations Manager Management
Server.
Monitoring a Nano Server with a Management Pack written in VBScript or JScript.
Monitoring .Net applications running on a Nano Server.
Process Monitoring on the Nano Server.
ICMP monitoring on the Nano Server.
OLE DB monitoring on the Nano Server.
Integrating the Nano Server with Active Directory.
Updating the Operations Manager agent on a Nano Server by applying updates.
Using network discovery rules to discover devices that support ICMP.
Monitoring specific URL's on a Nano Server.
Collecting data from the Application Log of a Nano Server.
Putting a Nano Server into maintenance mode.
Manually install the Operations Manager agent on a Nano server

1. Follow the instructions for manually installing Nano Server on either a physical computer or a virtual
machine. See Getting Started with Nano Server for complete instructions.
NOTE
The Nano Server must be in the same domain as the Operations Manager Management Server.
2. Add the Microsoft-OneCore-ReverseForwarders package as described in the Getting Started with Nano
Server topic.
3. Join the Nano Server to the same domain as the Operations Manager Management Server. There are two
methods available for installing the Operations Manager agent on Nano Servers, Discovery Wizard from
the Operations console or PowerShell script. The process of installing the agent using the Discovery
Wizard is consistent with the steps described in the following document Discover and install agent on
Windows.
Use the following procedure to install the agent with a PowerShell script.
1. Copy the NanoServer directory from the System Center Operations Manager setup directory to the Nano
Server.
2. Open a PowerShell command window on the Nano Server from a computer running in the same domain
as the Nano Server.
3. Set the file path on the Nano Server to NanoAgent\NanoServer
4. Run the following script:
.\InstallNanoServerScomAgentOnline.ps1 -ManagementServerFQDN <Management Server Name FQDN> -

ManagementGroupName <Management Group Name> -NanoServerFQDN <FQDN of target Nano Server> -BinaryFolder
..\
NOTE
If the installation is successful you will see "Installation successful" in the Installlog.txt file which the installer will add
to the NanoAgent\NanoServer directory on the Nano Server. You should not see any errors in that file.
5. Run the following command on the Nano Server:
Net Start HealthService
Troubleshooting agent installation

If you encounter any difficulties with setting up the Operations Manager Agent on a Nano Server you can follow
the checklist below for possible solutions.
ERROR MESSAGE POSSIBLE REASON RESOLUTION
There was an error opening the firewall Insufficient permissions for setting the Make sure the account the script is
port Remote Event Log Management running under has sufficient
firewall rule. permissions to set the firewall rule.
Agent directory already present in If you ran the installation script already Run the uninstallation script as
Nano Server. Please uninstall the agent and it did not complete, the Agent suggested by the error message.
using the uninstallation script and then directory might have been created
try again. already.
Setting up and importing the registry Insufficient permissions to edit the Make sure the account the script is
failed. registry. running under has sufficient
permissions to edit the registry and run
the installation script again.
Failed to install performance counters. Insufficient permissions to edit the Make sure the account the script is
registry. running under has sufficient
the installation script again.
Validate that the Operations Manager agent has been successfully installed
1. Open the Services console on a computer joined to the same domain as the Nano Server by running the
running the services.msc command.
2. Connect to the Nano Server in the Action panel by specifying the Fully Qualified Domain Name (FQDN )
of the Nano Server.
3. Verify that the Status of the Microsoft Monitoring Agent Service is "Running".
Start Monitoring your Nano Server

NOTE
The following procedure is only required for a PowerShell-based agent installation.
1. Open the Pending Management section of the Administration pane in the Operations Manager console.
2. Approve the Nano Server for management.
Verify that you are monitoring your Nano Server
1. Open the Agent Managed list in the Device Management section of the Operations Manager Console
Administration pane.
2. Verify that the Health State is shown as Healthy.
Remove the Operations Manager Agent from your Nano Server

1. Open a PowerShell window as an administrator on the Nano Server.
2. Change to the \NanoAgent\NanoServer folder.
3. Run the following script:
.\UnInstallNanoServerScomAgentOnline.ps1 -ManagementServerFQDN <Management Server Name FQDN> -

ManagementGroupName <Management Group Name> -NanoServerFQDN <FQDN of target Nano Server>
NOTE
You can validate that the Operations Manager agent has been removed by checking that the uninstalllog.txt file in
the \NanoAgent\NanoServer folder does not contain any errors and that you see the message "Successfully un-
installed the agent from Nano Server" in the log file.
Troubleshooting agent uninstall

If you encounter any difficulties with removing the Operations Manager Agent on a Nano Server you can follow
the checklist below for possible solutions.
ERROR MESSAGE POSSIBLE REASON RESOLUTION
HealthService was not found on the If the installation did not complete the Make sure the HealthService is not
Nano Server. Assuming previous HealthService might not have been being used and run the uninstall script
uninstall didn't complete. setup. Another process could also be again.
using the HealthService.
Unable to delete HealthService on The HealthService may be busy or Make sure the HealthService is not in
Nano Server. another process is using the use and run the uninstall script again.
HealthService.
Unable to kill the MonitoringHost(s) on The Operations Manager agent runs in Make sure the MonitoringHost process
the Nano Server. the MonitoringHost process. If that is not running, and run the uninstall
process is active the Uninstallation script again.
script will not be able to terminate it.
Unable to uninstall the performance Insufficient permissions to edit the Make sure the account the script is
counters. registry. running under has sufficient
the uninstall script again.
Unable to remove registry changes Insufficient permissions to edit the Make sure the account the script is
done by the Operations Manager registry. running under has sufficient
agent on Nano Server. permissions to edit the registry and run
the Uninstallation script again.
Unable to delete the agent directory. Insufficient permissions to access the Make sure the account the script is
NanoAgent directory. running under has sufficient
permissions to access the NanoAgent
directory and run the uninstall script
again.
Unable to locate agent folder on the Either the NanoAgent directory has Make sure the account the script is
Nano Server. been moved, or the account has running under has sufficient
insufficient permissions to access the permissions to access the NanoAgent
NanoAgent directory. directory and that the NanoAgent
directory is present and run the
uninstall script again.
Unable to remove the agent directory. A process may be using the Operations Make sure there are no processes
Try restarting the Nano Server and Manager agent. attached to the Operations Manager
then re-running this script. agent and run the uninstall script again.
Installing updates to the Nano agent

The Nano agent can be updated by one of the following methods:
1. Push updates from a management server.
Updates are offered and installed automatically from Microsoft Update to an Operations Manager
management server. With Operations Manager 2016, the management server updates will also include the
updated files for Nano agent.
After the management server is upgraded, the Nano agents will be placed in a pending management state,
as described in the process manual agent installations topic. After approving updates, the agents will
receive and apply the update. Alternatively, you can trigger repair from the Operations console on any
Nano agent. This will cause the update to be pushed and installed on the Nano agent from the
management server.
2. Manually install update
Updates to the Nano agent are available for download by following the instructions in the KB article and
applying the update manually. You can install these downloaded updates on a Nano agent machine using
the following Powershell script.
.\UpdateNanoServerScomAgentOnline.ps1 -NanoServerFQDN <FQDN of target Nano Server> -BinaryFolder

<<Path where the update .cab is already expanded OR path to one or more Nano-agent update .cab files> -
IsCabExpanded <$true if BinaryFolder path is to an expanded .cab, $false if it is for a packed .cab
file(s)> -RemoveBackup <$true to remove the previous binaries from the agent machine>
For System Center 2016 - Operations Manager RTM, you can download the Nano Agent cab file from the
Microsoft Download Center.
Uninstalling updates from the Nano Agent
Directly uninstalling the most recent update from the Nano agent is not supported. Instead, you should uninstall
the agent completely and reinstall the agent with the desired set of updates.
Next steps
After manually installing the Operations Manager agent on Windows and Nano Server, you need to Process
Manual Agent Installations
Configuring Windows agents
3 minutes to read
In System Center – Operations Manager, when you install an agent on a computer, an Microsoft Monitoring
Agent application is added to Control Panel. You can use the application to change the account that the agent will
use when performing actions requested by the management server, to remove a management group from an
agent configuration, and to configure the Active Directory integration setting for the agent. To perform these
tasks, you must have local Administrator permissions on the computer.
NOTE
If you want to automate the process of adding or removing management groups from an agent, you can use the
Operations Manager cmdlets or the Agent API from the Operations Manager Agent Configuration Library, allowing you to
write scripts that can automate the agent configuration process.
NOTE
When you save changes in the Microsoft Monitoring Agent application, the Microsoft Monitoring Agent service will be
stopped and restarted.
Configuring an agent to report to multiple management groups

Use the following procedure to make an Operations Manager agent a member of multiple management groups,
also referred to as multihoming. For example, an agent can be configured to report Active Directory data to the
Directory Services Management Group and Exchange data to the Messaging Management Group. An agent can
be a member of up to four management groups.
You do not need to use the same deployment method for all of the management groups.
NOTE
It might take one day or longer for the discovered instances of the agent to be made part of the new management group.
They will be added after the next discovery interval.
Do one of the following:

On the agent-managed computer, in Control Panel, double-click Microsoft Monitoring Agent. In
Microsoft Monitoring Agent, on the Operations Manager tab, click Add, enter the information for the
new management group, and then click OK.
Run the Discovery Wizard from the Operations Manager Operations console that is connected to the
new management group, select the desired computers, and deploy the agent to them. For more
information, see Install agent on Windows using the Discovery Wizard. (The menu item in the Operations
console named Discovery Wizard opens the Computer and Device Management wizard.)
Run the MOMAgent.msi Windows installer package on the desired computers, and modify the installation
by adding a new management group. For more information, see Install Windows Agent Manually Using
MOMAgent.msi.
Changing the account configuration for an agent
You can use the following procedure to change the account that the agent will use when performing actions
requested by the management server.
1. On the agent-managed computer, in Control Panel, double-click Microsoft Monitoring Agent.
2. On the Operations Manager tab, select a management group and then click Edit.
3. In the Agent Action Account section, edit the account information and then click OK.
Removing a management group from an agent

You can use the following procedure to remove a management group from the agent configuration.
2. On the Operations Manager tab, select a management group and then click Remove.
3. Click OK.
NOTE
You can remove all management groups while leaving the agent installed. This is useful in situations such as when you want
to prepare a computer for imaging and want an image with the agent installed but without assignment to a specific
management group.
Changing the Active Directory Integration setting for an agent

You can use the following procedure to change the Active Directory integration setting for an agent.
2. On the Operations Manager tab, clear or select Automatically update management group assignments
from AD DS. If you select this option, on agent startup, the agent will query Active Directory for a list of
management groups to which it has been assigned. Those management groups, if any, will be added to the list.
If you clear this option, all management groups assigned to the agent in Active Directory will be removed from
the list.
3. Click OK.
Next steps
MOMAgent.msi.
Review Uninstall Agent from Windows-based Computers to understand what options and steps need to be
performed to properly uninstall the agent from your Windows computers.
How to Configure Agent Failover to Multiple
Gateway Servers
2 minutes to read
If you have deployed multiple gateway servers in a domain that does not have a trust relationship established with
the domain that the rest of the management group is in, you can configure agents to utilize those gateway servers
as necessary. To do this, you must use the Operations Manager Shell to configure an agent to fail over to multiple
gateway servers. The commands can be run from any command shell in the management group.
IMPORTANT
When changing the primary management server of an agent, allow the agent to connect to its new primary management
server before making changes to its failover server. Allowing the agent to get current topology information from the new
primary management server prevents the agent from losing communication with all management servers.
To configure agent failover to multiple gateway servers

1. Log on to the computer with an account that is a member of the Administrators group.
2. Click Start, click All Programs, click Microsoft System Center 2012, click Operations Manager, and
then click Operations Manager Shell.
3. In Operations Manager Shell, run the following command:
$primaryMS = Get-SCOMManagementServer -Name "<name of primary server>"

$failoverMS = Get-SCOMManagementServer -Name "<name of 1st failover>","<name of 2nd failover>",...,"
<name of nth failover>"
$agent = Get-SCOMAgent -Name "<name of agent>"
Set-SCOMParentManagementServer -Agent $agent -PrimaryServer $primaryMS

Set-SCOMParentManagementServer -Agent $agent -FailoverServer $failoverMS
For help with the Set-SCOMParentManagementServer command, type the following in the command shell
window:
Get-help Set-SCOMParentManagementServer -full
Next steps
Install agent on UNIX and Linux computers from the
command line
16 minutes to read
Your environment may require that you manually install the agent. Use the following procedures to manually
install agents to UNIX and Linux computers for monitoring in System Center Operations Manager version 2019.
The agent packages can be found in the following folder on a management server - %ProgramFiles%\Microsoft
System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Import the
required management packs for the specific version of UNIX/Linux you need to monitor. The management packs
are available in the Operations Manager installation media, in the \ManagementPacks folder or you can
download the latest version from the Download Center.
install agents to UNIX and Linux computers for monitoring in System Center Operations Manager version 1801
and higher. The agent packages can be found in the following folder on a management server -
%ProgramFiles%\Microsoft System Center\Operations
Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Import the required management packs for
the specific version of UNIX/Linux you need to monitor. The management packs are available in the Operations
Manager installation media, in the \ManagementPacks folder or you can download the latest version from the
Download Center.
install agents to UNIX and Linux computers for monitoring in System Center Operations Manager version 1801
and higher. The agent packages can be found in the following folder on a management server -
%ProgramFiles%\Microsoft System Center\Operations
Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Import the required management packs for
the specific version of UNIX/Linux you need to monitor. The management packs are available in the Operations
Manager installation media, in the \ManagementPacks folder or you can download the latest version from the
Download Center.
install agents to UNIX and Linux computers for monitoring in System Center 2016 - Operations Manager. The
agent packages can be found in the following folder on a management server - %ProgramFiles%\Microsoft
System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Import the
required management packs for the specific version of UNIX/Linux you need to monitor. The management packs
are available in the Operations Manager installation media, in the \ManagementPacks folder or you can
download the latest version from the Download Center.
Install Operations Manager 2019 agent on UNIX and Linux computers

The following procedures show how to manually install agents to UNIX and Linux computers for monitoring in
System Center Operations Manager version 2019.
To install the agent on Red Hat Enterprise Linux and SUSE Linux
Enterprise Server
1. Transfer the Red Hat Enterprise agent to the Linux server:
scx-<version>.rhel.<version>.<arch>.sh
or for SUSE Linux Enterprise Server:
scx-<version>.sles.<version>.<arch>.sh
2. To install the Red Hat Enterprise package, type:

sh ./scx-<version>.rhel.<version>.<arch>.sh --install --enable-opsmgr
or for SUSE Linux Enterprise package, type:

sh ./scx-<version>.sles.<version>.<arch>.sh --install --enable-opsmgr
3. To verify that the package is installed, type:

rpm -q scx
4. To verify that the Microsoft SCX CIM Server is running, type:

scxadmin -status
To install the agent on RPM based Universal Linux Servers (Oracle and
Centos)
1. Transfer the agent ( scx-<version>.universalr.<version>.<arch>.sh ) to the Linux server. This should be done
via SCP or FTP in binary mode.
2. To install the package, type:
sh ./scx-<version>.universalr.<version>.<arch>.sh --install --enable-opsmgr

rpm -q scx

scxadmin -status
To install the agent on DPKG-based Universal Linux Servers (Debian

and Ubuntu)
1. Transfer the agent ( scx-<version>.universald.<version>.<arch>.sh ) to the Linux server. This should be done
sh ./scx-<version>.universald.<version>.<arch>.sh --install --enable-opsmgr

dpkg -l scx

scxadmin -status
To install the agent on Solaris

1. Transfer the agent ( scx-<version>.solaris.<version>.sparc.sh ) to the Solaris server .
sh ./scx-<version>.solaris.<version>.sparc.sh –install --enable-opsmgr

pkginfo –l scx

svcs omiserver
To install the agent on AIX

1. Transfer the agent ( scx-<version>.aix.<version>.<arch>.sh ) to the AIX server.
sh ./scx-<version>.aix.<version>.<arch>.sh --install --enable-opsmgr

lslpp -l “scx*"

scxadmin -status
Signing agent certificates

When you manually deploy an agent, you perform the first two steps that are typically handled by the Discovery
Wizard, deployment and certificate signing. Then, you use the Discovery Wizard to add the computer to the
management group.
If there are existing certificates on the system, they are reused during agent installation. New certificates are not
created. Certificates are not automatically deleted when you uninstall an agent. You must manually delete the
certificates that are listed in the folder /etc/opt/microsoft/scx/ssl for UNIX and
/etc/opt/microsoft/scx/scom/certs folder for Linux. To regenerate the certificates at install, you must remove this
folder before agent installation.
You must have already manually installed an agent before you start this procedure. You will need a root or
elevated account to perform the procedure.
To install certificates for UNIX and Linux support

1. On the computer that is running the UNIX or Linux operating system, locate the file
/etc/opt/microsoft/scx/ssl/scx-host-<hostname>.pem and securely copy or transfer it to any location on the
computer that is hosting Operations Manager.
2. On the computer that is hosting Operations Manager, on the Windows desktop, click Start, and then click
Run.
3. In the Run dialog box, type cmd, and then press Enter.
4. Change directories to the location where you copied the pem file.
5. Type the command scxcertconfig -sign scx-host-<hostname>.pem scx_new.pem , and then press Enter. This
command will self-sign your certificate ( scx-host-<hostname>.pem ) and then save the new certificate (
scx-host-<hostname>_new.pem ).
NOTE
Ensure that the location where Operations Manager is installed is in your path statement, or use the fully qualified
path of the scxcertconfig.exe file.
6. Securely copy or transfer the scx_new.pem file into the /etc/opt/microsoft/scx/ssl folder on the computer
that is hosting the UNIX or Linux operating system. This replaces the original scx-host-<hostname>.pem file.
7. Restart the agent by typing scxadmin –restart .
Discovering computers after manual deployment

After you have manually deployed agents to UNIX and Linux computers, they still need to be discovered by
Operations Manager by using the Discovery Wizard. For the Discovery type, select Discover only computers
with the UNIX/Linux agent installed. For more information see Install Agent on UNIX and Linux Using the
Discovery Wizard.
Install Operations Manager 1801/1807 agent on UNIX and Linux

computers
Enterprise Server
omsagent-<version>.rhel.<version>.<arch>.sh

omsagent-<version>.sles.<version>.<arch>.sh

sh ./omsagent-<version>.rhel.<version>.<arch>.sh --install --enable-opsmgr

sh ./omsagent-<version>.sles.<version>.<arch>.sh --install --enable-opsmgr

rpm -q omsagent

scxadmin -status
Centos)
1. Transfer the agent ( omsagent-<version>.universalr.<version>.<arch>.sh ) to the Linux server. This should be
done via SCP or FTP in binary mode.
sh ./omsagent-<version>.universalr.<version>.<arch>.sh --install --enable-opsmgr

rpm -q omsagent

scxadmin -status

and Ubuntu)
1. Transfer the agent ( omsagent-<version>.universald.<version>.<arch>.sh ) to the Linux server. This should be
sh ./omsagent-<version>.universald.<version>.<arch>.sh --install --enable-opsmgr

dpkg -l omsagent

scxadmin -status

1. Transfer the agent ( scx-<version>.solaris.<version>.<arch>.sh ) to the Solaris server .
sh ./scx-<version>.solaris.<version>.<arch>.sh –install --enable-opsmgr

pkginfo –l scx

svcs omiserver
To install the agent on HP-UX

1. Transfer the agent ( scx-<version>.hpux.<version>.<arch>.sh ) to the HP server .
sh .scx-<version>.hpux.<version>.<arch>.sh --install --enable-opsmgr

swlist scx

scxadmin -status"

lslpp -l “scx*"

scxadmin -status

management group.
/etc/opt/microsoft/omsagent/scom/certs folder for Linux. To regenerate the certificates at install, you must remove
this folder before agent installation.

Run.
NOTE
that is hosting the UNIX or Linux operating system. This replaces the original scx-host-<hostname>.pem
file.

Discovery Wizard.
Install Operations Manager 1801/1807 agent on UNIX and Linux

computers
Enterprise Server
omsagent-<version>.rhel.<version>.<arch>.sh

omsagent-<version>.sles.<version>.<arch>.sh

sh ./omsagent-<version>.rhel.<version>.<arch>.sh --install --enable-opsmgr

sh ./omsagent-<version>.sles.<version>.<arch>.sh --install --enable-opsmgr

rpm -q omsagent

scxadmin -status
Centos)
1. Transfer the agent ( omsagent-<version>.universalr.<version>.<arch>.sh ) to the Linux server. This should be
sh ./omsagent-<version>.universalr.<version>.<arch>.sh --install --enable-opsmgr

rpm -q omsagent

scxadmin -status
and Ubuntu)
1. Transfer the agent ( omsagent-<version>.universald.<version>.<arch>.sh ) to the Linux server. This should be
sh ./omsagent-<version>.universald.<version>.<arch>.sh --install --enable-opsmgr

dpkg -l omsagent

scxadmin -status

sh ./scx-<version>.solaris.<version>.<arch>.sh –install --enable-opsmgr

pkginfo –l scx

svcs omiserver

sh .scx-<version>.hpux.<version>.<arch>.sh --install --enable-opsmgr

swlist scx

scxadmin -status"


lslpp -l “scx*"
scxadmin -status

management group.
/etc/opt/microsoft/omsagent/scom/certs folder for Linux. To regenerate the certificates at install, you must remove
this folder before agent installation.

Run.
NOTE
file.

Discovery Wizard.
Install Operations Manager agent on UNIX and Linux computers

Enterprise Server
scx-<version>.rhel.<version>.<arch>.sh

scx-<version>.sles.<version>.<arch>.sh

sh ./scx-<version>.rhel.<version>.<arch>.sh --install

sh ./scx-<version>.sles.<version>.<arch>.sh --install

rpm -q scx

scxadmin -status
Centos)
1. Transfer the agent ( scx-<version>.universalr.<version>.<arch>.sh ) to the Linux server. This should be done
sh ./scx-<version>.universalr.<version>.<arch>.sh --install

rpm -q scx

scxadmin -status

and Ubuntu)
1. Transfer the agent ( scx-<version>.universald.<version>.<arch>.sh ) to the Linux server. This should be done
sh ./scx-<version>.universald.<version>.<arch>.sh --install

dpkg -l scx

scxadmin -status

sh ./scx-<version>.solaris.<version>.<arch>.sh –install

pkginfo –l scx

svcs omiserver

sh .scx-<version>.hpux.<version>.<arch>.sh --install

swlist scx

ps –ef|grep omi
Look for the following process in the list:

omiserver

sh ./scx-<version>.aix.<version>.<arch>.sh --install

lslpp -l “scx*"

ps –ef|grep omi
Look for the following process in the list:

omiserver
management group.
certificates that are listed in the /etc/opt/microsoft/scx/ssl folder. To regenerate the certificates at install, you
must remove this folder before agent installation.

Run.
NOTE
file.

Discovery Wizard.
Next steps
Overrides to Object Discoveries
Uninstalling Agents on UNIX and Linux Computers
Install agent and certificate on Linux computers using
the command line
4 minutes to read
This article provides details of the latest version of the Linux agent for System Center Operations Manager 1801
and the process for installing it.
This version of the Linux agent supports Fluentd, an open source data collector for Linux that collects data from a
variety of sources. The existing OMI based monitoring for currently supported Linux workloads will continue to
work without change.
What's new in version 1801

1. A new converter plugin is included that enables customers to use third party plugins for Operations Manager
log file monitoring.
2. Added support to Server Authentication.
3. Added support to additional Linux distros.
Supported platforms
The Linux distributions in the following table are supported in this release.
LINUX OPERATING SYSTEM VERSION SUPPORTED
Red Hat Enterprise Linux Server 5 (x86/x64)

6 (x86/x64)
7 (x86/x64)
Cent OS 5 (x86/x64)
6 (x86/x64)
7 (x64)
Ubuntu 12.04 LTS (x86/x64)

14.04 LTS (x86/x64)
16.04 LTS (x86/x64)
Debian 6 (x86/x64)
7 (x86/x64)
8 (x86/x64)
Oracle Linux 5 (x86/x64)

6 (x86/x64)
7 (x64)
SUSE Linux Enterprise Server 11 (x86/x64)

12 (x64)
<Upgrade from existing Operations Manager/OMS agents is not currently supported>.
Supported deployment configurations

Operations Manager supports the following agent reporting configurations in the management group.
1. Linux servers reporting directly to a management server
2. Linux server reporting to a Gateway server
3. Linux servers reporting to a chained Gateway server
Agent installation
You can choose to install the latest version of the Linux agent for Operations Manager using automatic discovery
or manual installation. Automatic discovery hasn't changed since the previous version, and you can follow the
same procedure at Discover and install agent on UNIX and Linux.
Use the following procedures to manually install agents to UNIX and Linux computers. The agent packages can be
found in the the following folder on a management server - %ProgramFiles%\Microsoft System
Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits after you import the
required management packs for the specific version of UNIX/Linux you need to monitor. The management pack
are available in the Operations Manager installation media, in the \ManagementPacks directory.
Manual installation
The agent is provided as a self-extracting, installable shell script bundle. This bundle contains both Debian and
RPM packages for each of the agent components and can be installed directly or extracted to retrieve the individual
packages. Separate bundles are available for x64 and x86 architectures.
This will require the following steps:
1. Install the agent and register Operations Manager as your workspace
2. Open TCP port on management server or gateway server
3. Configure a server authentication certificate
4. Discover the Linux server using the Discovery Wizard
The following sections describe the steps required to manually install the Linux agent.
Install agent
1. The agent install bundles will be located in %Program Files%\Microsoft System Center\Operations
Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Transfer the appropriate bundle
(x86 or x64) to the Linux computer, using scp/sftp.
2. Install the bundle with the following command. The enable-opsmgr parameter ensures that port 1270 is
open for the management server to communicate with the agent.
sudo sh ./omsagent-1.4.0-45.universald.1.x64.sh --install --enable-opsmgr
3. Run the omsadmin.sh command supplying scom for your workspace id. This command must be run as root
(with sudo elevation). This script will generate a certificate at
/etc/opt/microsoft/omsagent/scom/certs/scom -cert.pem which will need to be signed by the
Management Server in a later step.
/opt/microsoft/omsagent/bin/omsadmin.sh -w scom
4. Create a configuration file called omsadmin.conf in /etc/opt/microsoft/omsagent/scom/conf/ with the
following contents. Fill in the name of the machine and use 8886 for the port of the OMED service.
WORKSPACE_ID=scom SCOM_ENDPOINT=https://<FQDN_OF_OM_MACHINE>:
<PORT_OF_OMED_SERVICE>
Configure TCP port for OMED service
Operations Manager requires that TCP port 8886 be used to establish inbound communication between the Linux
agent and the management server or gateway server to enable data collection.
Configure certificates
In the previous version of the Linux agent, the management server accessed each Linux computer with a server
authentication certificate. With the new agent, Fluentd acts as the client accessing the management server, so the
certificate requires client authentication. You need to obtain a new certificate to work with the new agent.
Operations Manager will use the new certificate for Fluentd communications and the old certificate for other
communications.
1. Locate/etc/opt/omi/ssl/omi-host-<hostname>.pem and
/etc/opt/microsoft/omsagent/scom/certs/scom -cert.pem on the Linux computer and copy them to
any location on the management server.
2. Open a command prompt on the management server and run the following command to sign your
certificate.
scxcertconfig -sign omi-host-<hostname>.pem omi_new.pem and scxcertconfig -sign scom-cert.pem scom-
cert_new.pem
3. Copy the file - omi_new.pem to /etc/opt/omi/ssl/ and scom -cert_new.pem to
/etc/opt/microsoft/omsagent/scom/certs/ on the Linux computer. Remove the old certificate files and
rename the new certificate files to replace them.
Restart the agent
1. Restart the agent with the following command.
scxadmin –restart
Discovery
Operations Manager using the Discovery Wizard. For the Discovery type, select Discover only computers with
the UNIX/Linux agent installed. For more information see Install Agent on UNIX and Linux using the
Discovery Wizard.
Next steps
Review Manually Uninstalling Agents from UNIX and Linux Computers to understand what options and steps
need to be performed to properly uninstall the agent from your UNIX and Linux computers.
Managing certificates for UNIX and Linux computers
2 minutes to read
With System Center Operations Manager, you can deploy agents to UNIX or Linux computers. Kerberos
authentication is not possible. Therefore, certificates are used between the management server and the UNIX or
Linux computers. In this scenario, the certificates are self-signed by the management server. (Although it is possible
to use third-party certificates, they are not needed.)
There are two methods you can use to deploy agents. You can use the Discovery Wizard or you can manually
install an agent. Of these two methods, manually installing an agent is the more secure option. When you use the
Discovery Wizard to push agents to UNIX or Linux computers, you trust that the computer that you are deploying
to is really the computer that you think it is. When you use the Discovery Wizard to deploy agents, it involves
greater risk than when you deploy to computers on the public network or in a perimeter network.
When you use the Discovery Wizard to deploy an agent, the Discovery Wizard performs the following functions:
Deployment - The Discovery Wizard copies the agent package to the UNIX or Linux computer and then
starts the installation process.
Certificate Signing - Operations Manager retrieves the certificate from the agent, signs the certificate,
deploys the certificate back to the agent, and then restarts the agent.
Discovery - The Discovery Wizard discovers the computer and tests to see that the certificate is valid. If the
Discovery Wizard verifies that the computer can be discovered and that the certificate is valid, the Discovery
Wizard adds the newly discovered computer to the Operations Manager database.
Wizard: deployment and certificate signing. Then, you use the Discovery Wizard to add the computer to the
Operations Manager database.
certificates that are listed in the /etc/opt/microsoft/scx/ssl folder. To regenerate the certificates during instalation,
you must remove this folder before agent installation.
For instructions on how to manually deploy an agent, see Install Agent and Certificate on UNIX and Linux
Computers Using the Command Line, and then use the following procedure to install the certificates.
UNIX and Linux firewall considerations

If you have a firewall on your UNIX or Linux computer, you must open port 1270 (inbound). This port number is
not configurable. If you are deploying agents in a low security environment and you use the Discovery Wizard to
deploy and sign the certificates, you must open the SSH port. The SSH port number is configurable. By default,
SSH uses inbound TCP port 22. For more information about firewall configuration for Operations Manager, see
Configuring a Firewall for Operations Manager
Next steps
For more information on how to install the agent and understand the steps for signing the agent certificate,
see Install Agent and Certificate on UNIX and Linux Computers Using the Command Line.
How to repair the Windows agent
2 minutes to read
Use the one of the following procedures to repair the installation of the Windows agent on agent-managed
computers.
With Operation Manager 1807 and later, you can reconfigure the Application Performance Monitoring (APM )
component for the agent from the Operations console.
To repair the installation of the agent by using the Operations console

1. Sign in to the Operations console with an account that is a member of the Operations Manager
3. In the Administration pane, navigate to Device Management\Agent Managed.
4. In the Agent Managed pane, select one or more computers you want to repair the agent on, right-click
them and then select Repair.
5. In the Repair Agents dialog box, either leave Use selected Management Server Action Account
selected or do the following:
1. Select Other user account.
2. Type the User name and Password, and type or select the Domain from the list. Select This is a
local computer account, not a domain account if the account is a local computer account.
IMPORTANT
The account must have administrative rights on the computer for the repair to succeed.
3. Deselect the option Install or keep APM if you no longer intend to monitor a .NET web-based
application or require the component installed on the targeted computer. Otherwise, leave the option
selected.
4. Click Repair.
e. Select Other user account.
f. Type the User name and Password, and type or select the Domain from the list. Select This is a
IMPORTANT
The account must have administrative rights on the computer for the repair to succeed.
c. Click Repair.
NOTE
If the task fails for a computer, click the targeted computer. The reason for the failure is displayed in the Task Output
text box.
7. Click Close.
To repair the agent by using the MOMAgent.msi setup wizard

1. Sign in to a managed computer with an account that is a member of the Administrators security group for
the computer.
2. In Control Panel, click Programs and Features.
3. In Programs and Features, click Change for Microsoft Monitoring Agent setup.
4. In the Agent Setup Wizard, click Next.
5. In the Program Maintenance page, select Repair, and then click Next.
6. On the Ready to Repair the Program page, click Install.
7. On the Completing the Microsoft Monitoring Agent Setup Wizard page, click Finish.
8. Check the Application Event Log to confirm it completed successfully or for errors if the repair failed by
searching at events from source MsiInstaller.
To repair the agent by using MOMAgent.msi from the command line

1. Sign in to a managed computer with an account that is a member of the administrators security group for
the computer.
2. Open a command prompt.
3. Type the following, for example, at the prompt:
%WinDir%\System32\msiexec.exe /fomus \MOMAgent.msi./qb
4. Check the Application Event Log to confirm it completed successfully or for errors if the repair failed by
searching at events from source MsiInstaller.
Next steps
Process manual agent installations
3 minutes to read
Manual installation of an agent refers to the process of running MOMAgent.msi locally on a computer that is to
host a System Center Operations Manager agent. When it is installed, the agent attempts to join the specified
management group by contacting a specified management server. You can use security settings at both the
management group and the management server level to configure how requests from manually installed agents
are processed.
The following three options are available to process manually installed agents.
OPTION ACTION
Reject new manual agent installations Designates that all requests from a manually installed agent
will be denied by Operations Manager. This is the most secure
setting and is selected by default.
Review new manual agent installations in pending Designates that all requests from a manually installed agent
management view will be directed to Pending Management before being allowed
to join the management group. An administrator must review
the request and manually approve the agents' request.
Auto-approve new manually installed agents This option is available only if Review new manual agent
installations in pending management view has been
selected. This setting causes Operations Manager to
automatically allow any manually installed agent to join the
management group. This is the least secure option.
IMPORTANT
A management group or management server must be configured to accept agents that are installed with MOMAgent.msi
or they will be automatically rejected and therefore not displayed in the Operations console. If a management group is
configured to accept manually installed agents, the agents will display in the console approximately one hour after they are
installed.
The following procedures show you how to configure settings for manual agent installations.
To configure manual agent installation settings for a management

group
3. In the Administration workspace, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: Server, right-click Security, and then click Properties.
5. In the Global Management Server Settings - Security dialog box, on the General tab, do one of the
following:
To maintain a higher level of security, click Reject new manual agent installations, and then click
OK.
To configure for manual agent installation, click Review new manual agent installations in
pending management view, and then click OK.
Optionally, select Auto-approve new manually installed agents.
To override the manual agent installation setting for a single

management server
3. In the Administration workspace, expand Administration, expand Device Management, and then click
Management Servers.
4. In the results pane, right-click the management server that you want to view the properties of, and then
click Properties.
5. In the Management Server Properties dialog box, click the Security tab.
6. On the Security tab, do the following:
To maintain a higher level of security, select Reject new manual agent installations, and then click
OK.
To configure for manual agent installation, click Review new manual agent installations in
pending management view, and then click OK.
Optionally, select Auto-approve new manually installed agents.
7. Click OK.
To approve a pending agent installation when automatic approval is

not configured
2. Click Pending Management.
3. In the Pending Management pane, select computers in Type: Manual Agent Install.
4. Right-click the computers, and then click Approve.
5. In the Manual Agent Install dialog box, click Approve. The computers now appear in the Agent
Managed node and are ready to be managed.
NOTE
Rejected agents remain in Pending Management until the agent is uninstalled for the management group.
Next steps
MOMAgent.msi.
Applying overrides to object discoveries
2 minutes to read
System Center Operations Manager monitors computers and devices that it has discovered, and it also discovers
applications and features that it discovers on monitored computers. There may be situations where you want to
limit discovery. For example, you might want only some instances of SQL Server to be discovered and monitored,
or you want to remove a computer that has already been discovered.
The precise steps to limit or restrict discovery depend on the object, application, or feature that you want to
exclude from discovery. However, the general procedure is the same: identify the discovery that you want to limit
and create an override to disable the discovery.
The override to disable the discovery can apply to:
All objects in the class that the discovery applies to. If you use this selection for your override, you disable
the discovery completely.
A group. Group membership can be defined explicitly or dynamically. When you create a group, you save it
to an unsealed management pack. However, an element in an unsealed management pack, such as an
override, cannot reference an element in a different unsealed management pack, such as a group. If you are
going to use a group to limit the application of an override, you must either save the group to the same
unsealed management pack as the override, or you must seal the management pack that contains the
group. For more information, see Creating and Managing Groups.
One or more specific objects in the class that the discovery applies to. Using this method, you can select
from discovered objects.
All objects of another class. Using this method, you specify a class of objects to apply the override to.
Choosing how to apply the override to disable the discovery depends on your situation. The simplest situation is
when you want to disable discovery for a specific object or for all objects in a class. When you want to disable the
discovery for any object that meets certain criteria, you must use a group that contains those objects or create a
group that will identify those objects.
For example, you want to disable discovery of logical disks on management servers. You can configure an
override to disable the discovery of Windows Server 2008 logical disks and apply it to the Operations Manager
Management Servers group which is created automatically when you install Operations Manager. If, instead, you
want to disable discovery of logical disks on computers in a specific organizational unit, there is no built-in group
that satisfies that definition and so you would need to create a group that identifies those computers.
After an object has been already discovered, if you want to delete the object and not let it be discovered again,
disable the discovery for that object and then run the Remove-SCOMDisabledClassInstance cmdlet in
Operations Manager Shell. For help with this cmdlet, open Operations Manager Shell, and then type Get-Help
Remove-SCOMDisabledClassInstance.
Next steps
To learn how to create a custom writeable management pack to store your overrides, see How to Create a
Management Pack for Overrides.
Before making changes to the monitoring settings defined in an Operations Manager management pack,
review How to Override a Rule or Monitor to understand how to configure the change.
To understand the differences between classes and groups in Operations Manage and how workflows
apply to each, review Using Classes and Groups for Overrides in Operations Manager.
Upgrading and uninstalling agents on UNIX and
Linux computers
2 minutes to read
This topic describes how to upgrade and uninstall agents on UNIX and Linux computers, using the UNIX/Linux
Agent Upgrade Wizard and the UNIX/Linux Agent Uninstall Wizard. These wizards are similar in how you
select the target computers and provide credentials. Both wizards require privileged credentials on the UNIX or
Linux computers to complete their tasks, for more information see Planning Security Credentials for Accessing
Unix and Linux Computers.
Upgrading agents
You must run the UNIX/Linux Agent Upgrade Wizard to upgrade agents from earlier versions, or when
updates are issued by Microsoft, for of Operations Manager.
To upgrade an agent
1. In the Operations Console click Administration.
2. Click UNIX/Linux Computers in the Device Management node.
3. In the Actions pane, click Upgrade Agent to start the UNIX/Linux Agent Upgrade Wizard.
4. In the Select Upgrade Targets page, all applicable computers that have the installed agent will be
selected by default for upgrade. Unselect any targets you do not want to upgrade.
5. On the Credentials page, select one of the credentials options.
If you select the option to use existing credentials and are alerted that one or more of the selected target
computers does not have a Run As account assigned with the required profiles, you must do one of the
following:
Provide specified credentials with the Provide upgrade credentials option.
Click Show Computers (in the alert text) for a list of the computers that do not have the required
credentials specified in Run As Accounts. Then click Previous to unselect them and try again.
For detailed instructions on how to set credentials, see How to Set Credentials for Accessing UNIX and
Linux Computers.
6. Click Upgrade.
Uninstalling agents
You can uninstall an agent from the targeted computer by using the UNIX/Linux Agent Uninstall Wizard. For
information on manually uninstalling agents, see Manually Uninstalling Agents from UNIX and Linux
Computers.
To uninstall an agent
1. In the Operations Console click Administration.
2. Click UNIX/Linux Computers in the Device Management node.
3. In the Actions pane, click Uninstall Agent to start the UNIX/Linux Agent Uninstall Wizard.
4. In the Select Uninstall Targets page, all applicable computers that have the installed agent will be
selected by default for uninstallation. Unselect any targets you do not want to uninstall.
5. On the Credentials page, select one of the credentials options.
If you select the option to use existing credentials and are alerted that one or more of the selected target
computers does not have a Run As account assigned, you must do one of the following:
Provide specified credentials with the Provide uninstall credentials option.
Click Show Computers (in the alert text) for a list of the computers does not have the required
credentials specified in Run As Accounts. Then click Previous to unselect them and try again.
For detailed instructions on how to set credentials, see How to Set Credentials for Accessing UNIX and
Linux Computers.
6. Click Uninstall.
Next steps
certificate, see Install Agent and Certificate on UNIX and Linux Computers Using the Command Line.
To understand how to approve agents manually installed, review Process Manual Agent Installations.
Manually uninstalling agents from UNIX and Linux
computers
2 minutes to read
There are three ways to uninstall the UNIX and Linux management packs and agents.
1. Delete selected UNIX or Linux system management packs from the Operations Manager Operations
Console.
2. Delete an agent from Operations Manager, and uninstall the agent from the monitored computer. It will be
uninstalled first from the UNIX or Linux computer.
3. Delete the agent from Operations Manager without uninstalling it on the UNIX or Linux host.
Use the following procedures to uninstall agents.
To delete an agent with the UNIX Linux Agent Uninstall Wizard

1. For more information, see Upgrading and Uninstalling Agents on UNIX and Linux Computers.
After the UNIX or Linux computer has been deleted from the list of monitored computers, you must log on to the
monitored computer and manually uninstall the agent. Use the following procedures to manually uninstall agents
from UNIX and Linux computers.
To uninstall the agent from Red Hat enterprise Linux and SUSE Linux enterprise servers
1. Log on as the root user, and uninstall the agent by typing
rpm -e scx
2. To verify that the package is uninstalled, type
rpm -q scx
To uninstall the agent from RPM based Universal Linux servers (Oracle and Centos)
rpm -e scx
rpm -q scx
To uninstall the agent from DEB based Universal Linux servers (Debian and Ubuntu)
dpkg -P scx
dpkg -l scx
To uninstall the agent from Solaris computers
pkgrm MSFTscx
pkginfo -I MSFTscx
To uninstall the agent from HP-UX
swremove scx
swlist scx
To uninstall the agent from IBM AIX
installp -u scx
lslpp -L scx.rte
Next steps
certificate, see Install Agent and Certificate on UNIX and Linux Computers Using the Command Line.
Uninstall Agent from Windows-based Computers
2 minutes to read
Use one of the following procedures to uninstall an System Center Operations Manager agent from an agent-
managed computer.
Uninstall the agent by using the Operations console

1. Log on to the computer with an account that is a member of the Operations Manager Administrators role.
3. In the Administration workspace, click Agent Managed.
4. In the Agent Managed pane, right-click the computers for which you want to uninstall the agent, and
then select Uninstall.
5. In the Uninstall Agents dialog box, either leave Use selected Management Server Action Account
selected or do the following:
a. Select Other user account.
b. Type the User name and Password, and type or select the Domain from the list. Select This is a
IMPORTANT
The account must have administrative rights on the computer or the uninstall will fail.
c. Click Uninstall.
Queued to Success.
NOTE
If the task fails for a computer, click the computer and read the reason for the failure in the Task Output text box.
7. Click Close.
Uninstall the agent by using the MOMAgent.msi agent setup wizard

1. Log on to a managed computer with an account that is a member of the administrators security group for
the computer.
2. In Control Panel, click Uninstall a program.
3. In Programs and Features, click Microsoft Monitoring Agent, click Remove, and then click Yes.
NOTE
The Agent Setup Wizard can also be run by double-clicking MOMAgent.msi, which is available on the Operations
Uninstall the agent by using MOMAgent.msi from the command line

1. Log on to the managed computer with an account that is a member of the administrators security group
for the computer.
2. Open a command prompt.
3. At the prompt, for example, type the following:
%WinDir%\System32\msiexec.exe /x <path>\MOMAgent.msi /qb
Uninstall the agent from a cluster

1. Using either the Operations console method or the command line method, uninstall the agent from each
node of the cluster.
3. In the Administration workspace, click Agentless Managed.
4. In the Agentless Managed pane, locate all virtual instances for the cluster, right-click, and then select
Delete.
Next steps
If you would like to install the Nano Server agent using the Discovery Wizard, from the command line or
automate the deployment using a script or other automation solution, review Install Agent on Nano
Server.
MOMAgent.msi.
How to configure and use Active Directory
Integration for agent assignment
9 minutes to read
System Center Operations Manager allows you to take advantage of your investment in Active Directory Domain
Services (AD DS ) by enabling you to use it to assign agent-managed computers to management groups. This
topic will help you create and manage the configuration of the container in Active Directory, and agent assignment
of management servers agents should report to.
Create an Active Directory Domain Services Container for a

management group
You can use the following command-line syntax and procedure to create an Active Directory Domain Service (AD
DS ) container for a System Center - Operations Manager management group. MOMADAdmin.exe is provided for
this purpose and is installed with the Operations Manager management server. MOMADAdmin.exe must be run
by an administrator of the specified domain.
Command line syntax:
<path>\MOMADAdmin.exe <ManagementGroupName> <MOMAdminSecurityGroup> <RunAsAccount> <Domain>
IMPORTANT
You must put a value inside quotation marks if the value contains a space.
ManagementGroupName is the name of the management group for which an AD container is being
created.
MOMAdminSecurityGroup is a domain security group, domain\security_group format, which is a
member of the Operations Managers Administrators security role for the management group.
RunAsAccount: This is the domain account which will be used by the management server to read, write,
and delete objects in AD. Use the format domain\username.
Domain is the name of the domain in which the management group container will be created.
MOMADAdmin.exe can be run across domains only if a two-way trust exists between them.
For Active Directory integration to work, the security group must be either a global security group (if Active
Directory integration needs to function in multiple domains with two-way trusts) or a local domain group (if Active
Directory integration is only used in one domain)
To add a security group to the Operations Manager Administrators group, use the following procedure.
1. In Operations console, select Administration.
2. In the Administration workspace, select User Roles under Security.
3. In User Roles, select Operations Manager Administrators and click the Properties action or right click
Operations Manager Administrators and select Properties.
4. Click Add to open the Select Group dialog box.
5. Select the desired security group, and then click OK to close the dialog box.
6. Click OK to close User Role Properties.
NOTE
We recommend one security group, which might contain several groups, be used for the Operations Manager
Administrators role. That way, groups and members of groups can be added and removed from groups without a domain
administrator needing to perform manual steps to assign them Read and Delete Child permissions to the Management
Group container.
Use the following procedure to create the AD DS container.

1. Open a command prompt as an administrator.
2. At the prompt, for example, type the following:
"C:\Program Files\Microsoft System Center 2016\Operations Manager\Server\MOMADAdmin.exe" "Message Ops"
MessageDom\MessageOMAdmins MessageDom\MessageADIntAcct MessageDom**
NOTE
3. The preceding command-line example will:

a. Run the MOMADAdmin.exe utility from the command line.
b. Create the "Message Ops" Management Group AD DS container in the AD DS schema root of the
MessageDom domain. To create the same Management Group AD DS container in additional
domains, run MOMADAdmin.exe for each domain.
c. Add the MessageDom\MessageADIntAcct domain user account to the
MessageDom\MessageOMAdmins AD DS security group and assign the security AD DS group
the rights necessary to manage the AD DS container.
How to Use Active Directory Domain Services to assign computers to

management servers
The Operations Manager Agent Assignment and Failover Wizard creates an agent assignment rule that uses
Active Directory Domain Services (AD DS ) to assign computers to a management group and assign the
computers' primary management server and secondary management servers. Use the following procedures to
start and use the wizard.
IMPORTANT
The Active Directory Domain Services container for the management group must be created prior to running the Agent
Assignment and Failover Wizard.
The Agent Assignment and Failover Wizard does not deploy the agent. You must manually deploy the agent to the
computers using MOMAgent.msi.
Changing the agent assignment rule can result in computers no longer being assigned to, and therefore monitored
by, the management group. The state of these computers will change to critical, because the computers no longer
send heartbeats to the management group. These computers can be deleted from the management group and, if
the computer is not assigned to other management groups, the Operations Manager agent can be uninstalled.
To start the Operations Manager Agent Assignment and Failover Wizard
3. In the Administration workspace, click Management Servers.
4. In the Management Servers pane, right-click the management server or gateway server to be Primary
Management Server for the computers returned by the rules you will create in the following procedure,
and then click Properties.
NOTE
Gateway servers work like management servers in this context.
5. In the Management Server Properties dialog box, click the Auto Agent Assignment tab, and then click
Add to start the Agent Assignment and Failover Wizard.
6. In the Agent Assignment and Failover Wizard, on the Introduction page, click Next.
NOTE
The Introduction page does not appear if the wizard has been run and Do not show this page again was selected.
7. On the Domain page, do the following:
NOTE
To assign computers from multiple domains to a management group, run the Agent Assignment and Failover
Wizard for each domain.
Select the domain of the computers from the Domain name drop-down list. The management
server and all computers in the AD Agent Assignment resource pool must be able to resolve the
domain name.
IMPORTANT
The management server and the computers that you want to manage must be in two-way trusted domains.
Set Select Run As Profile to the Run As profile associated with the Run As account provided when
MOMADAdmin.exe was run for the domain. The default account used to perform agent assignment
is the default action account specified during Setup, also referred to as the Active Directory Based
Agent Assignment Account. This account represents credentials used when connecting to the
specified domain's Active Directory and modifying Active Directory objects, and should match the
account specified when running MOMAdmin.exe. If this was not the account used to run
MOMADAdmin.exe, select Use a different account to perform agent assignment in the
specified domain, and then select or create the account from the Select Run As Profile drop-
down list. The Active Directory Based Agent Assignment Account profile must be configured to
use an Operations Manager administrator account which is distributed to all servers in the AD Agent
Assignment resource pool.
NOTE
For more information about Run As profiles and Run As accounts, see Managing Run As Accounts and
Profiles.
8. On the Inclusion Criteria page, either type the LDAP query for assigning computers to this management
server in the text box and then click Next, or click Configure. If you click Configure, do the following:
a. In the Find Computers dialog box, type the desired criteria for assigning computers to this
management server or type in your specific LDAP query.
The following LDAP query only returns computers running the Windows Server operating system,
and it excludes domain controllers.
(&(objectCategory=computer)(operatingsystem=*server*))
This example LDAP query only returns computers running the Windows Server operating system. It
excludes domain controllers and servers hosting the Operations Manager or Service Manager
management server role.
(&(objectCategory=computer)(operatingsystem=*server*)(!
(userAccountControl:1.2.840.113556.1.4.803:=8192)(!(servicePrincipalName=*MSOMHSvc*))))
For more information about LDAP queries, see Creating a Query Filter and Active Directory: LDAP
Syntax Filters.
b. Click OK, and then click Next.
9. On the Exclusion Criteria page, type the FQDN of computers that you explicitly want to prevent from
being managed by this management server, and then click Next.
IMPORTANT
You must separate the computer FQDNs that you type with a semicolon, colon, or a new line (CTRL+ENTER).
10. On the Agent Failover page, either select Automatically manage failover and click Create or select
Manually configure failover. If you select Manually configure failover, do the following:
a. Clear the check boxes of the management servers to which you do not want the agents to failover.
b. Click Create.
NOTE
With the Manually configure failover option, you must run the wizard again if you subsequently add a
management server to the management group and want the agents to failover to the new management
server.
11. In the Management Server Properties dialog box, click OK.

Note that it can take up to one hour for the agent assignment setting to propagate in AD DS.
When complete, the following rule is created in the management group and targets the AD Assignment
Resource Pool class.
This rule includes the agent assignment configuration information that you specified in the Agent Assignment
and Failover Wizard, such as the LDAP query.
To confirm if the management group successfully published its information in Active Directory, search for Event ID
11470 from source Health Service Modules in the Operations Manager event log on the management server the
agent assignment rule was defined on. In the description it should state that it successfully added all the computers
that were the added to the agent assignment rule.
In Active Directory, under the OperationsManager<ManagementGroupName> container, you should see the
service connection point (SCP ) objects created similar to the following example.
The rule also creates two security groups with the name of the management server NetBIOS name, the first one
with the suffix “_PrimarySG<random number>” and the second one “_SecondarySG<random number>”. In this
example, there are two management servers deployed in the management group and the primary security group
ComputerB_Primary_SG_24901 membership includes computers which matched the include rule defined in
your agent assignment rule and the security group ComputerA_Secondary_SG_38838 membership includes the
primary group ComputerB_Primary_SG-29401 security group containing the machine account of agents that
would failover to this secondary management server in the event the primary management server is
unresponsive. The SCP name is the management server NetBIOS name with the suffix “_SCP”.
NOTE
In this example, it is only showing objects from a single management group and not other management groups that may
exist and also configured with AD integration.
Manual agent deployment with Active Directory Integration Setting

Below is an example of the command line to manually install the Windows agent with Active Directory Integration
enabled.
%WinDir%\System32\msiexec.exe /i path\Directory\MOMAgent.msi /qn USE_SETTINGS_FROM_AD=1
USE_MANUALLY_SPECIFIED_SETTINGS=0 ACTIONS_USE_COMPUTER_ACCOUNT=1 AcceptEndUserLicenseAgreement=1
Changing the Active Directory Integration Setting for an agent

You can use the following procedure to change the Active Directory integration setting for an agent.
2. On the Operations Manager tab, clear or select Automatically update management group
assignments from AD DS. If you select this option, on agent startup, the agent will query Active Directory
for a list of management groups to which it has been assigned. Those management groups, if any, will be
added to the list. If you clear this option, all management groups assigned to the agent in Active Directory
will be removed from the list.
3. Click OK.
Next steps
To understand how to install the Windows agent from the Operations console, see Install Agent on Windows
Using the Discovery Wizard or to install the agent from the command line, see Install Windows Agent Manually
Using MOMAgent.msi.
What is in an Operations Manager management
pack?
8 minutes to read
Management packs typically contain monitoring settings for applications and services. After a management pack
is imported into a management group, System Center - Operations Manager immediately begins monitoring
objects based on default configurations and thresholds that are defined in the management pack.
Each management pack can contain any or all of the following parts:
Monitors, which direct an agent to track the state of various parts of a managed component.
Rules, which direct an agent to collect performance and discovery data, send alerts and events, and more.
Tasks, which define activities that can be executed by either the agent or the console.
Knowledge, which provides textual advice to help operators diagnose and fix problems.
Views, which offer customized user interfaces for monitoring and managing this component.
Reports, which define specialized ways to report on information about this managed component.
Object discoveries, which identify objects to be monitored.
Run As profiles, which allow you to run different rules, tasks, monitors, or discoveries under different
accounts on different computers.
Parts of a management pack

Every management pack defines a model of the component that it manages. This model is expressed as one or
more classes, each representing something that can be monitored and managed. When a management pack's
information is sent to an agent, the agent relies on specific discovery rules in the management pack to find the
actual instances of the classes this pack defines.
To reduce network utilization and storage requirements on the agent, only the parts of the management pack that
are required by the agent to perform monitoring are downloaded to the agent for local storage. For example, the
sections of the management packs which define rules and monitors are downloaded, while the sections for
knowledge and reports are not.
Monitors
Each management pack defines one or more classes that can be managed, and then specifies a group of monitors
for instances of the classes. These monitors keep track of the state of each class instance, making it easier to avoid
problems before they occur.
Each monitor reflects the state of some aspect of a class instance, and changes as the state of the class instance
changes. For example, a monitor that tracks disk utilization might be in one of three states: green, if the disk is less
than 75 percent full; yellow, if it is between 75 and 90 percent full; and red, if the disk is more than 90 percent full.
A monitor that tracks the availability of an application might have only two states: green, if the application is
running; and red, if it is not. The author of each management pack defines the monitors it contains, how many
states each monitor has, and what aspect of the managed class this monitor tracks.
Rules
In Operations Manager, a rule defines the events and performance data to collect from computers, and what to do
with the information after it is collected. A simple way to think about rules is as an if/then statement. For example,
a management pack for an application might contain rules such as the following:
If a message indicating that the application is shutting down appears in the event log, send an alert.
If a logon attempt fails, collect the event that indicates this failure.
As these examples show, rules can send alerts, events, or performance data. Rules can also run scripts, such as
allowing a rule to attempt to restart a failed application.
Views and dashboards
The Operations Manager Operations console provides standard views such as State, Alerts, and Performance. The
console also includes dashboards to consolidate and visualize the operational data for specific services or
applications for increased insight and visibility. In addition, you can create a personalized view in the Operations
console.
Knowledge
Knowledge is content, embedded in rules and monitors, that contains information from the management pack
author about the causes of an alert and suggestions on how to fix the issue that caused an alert to be raised.
Knowledge appears as text in the console, and its goal is to help an operator diagnose and fix problems. The text
can include links to tasks, allowing the author of this knowledge to walk an operator through the recovery process.
For example, the operator might first be instructed to run task A, and then based on the result of this task, run
either task B or task C. Knowledge can also contain links to performance views and to reports, giving the operator
direct access to information needed to solve a problem.
Knowledge is referred to as product knowledge or company knowledge. Product knowledge is added to the
management pack by the management pack author. Administrators can add their own knowledge to rules and
monitors to expand the troubleshooting information and provide company-specific information for operators,
which is known as company knowledge. For more information on adding company knowledge to a management
pack, see How to Add Knowledge to a Management Pack.
Tasks
A task is a script or other executable code that runs either on the management server or on the server, client, or
other device that is being managed. Tasks can potentially perform any kind of activity, including restarting a failed
application and deleting files. Like other aspects of a management pack, each task is associated with a particular
managed class. For example, running chkdsk makes sense only on a disk drive while a task that restarts Microsoft
Exchange Server is meaningful only on a computer that is running Exchange Server. If necessary, an operator can
also run the same task simultaneously on multiple managed systems. Monitors can have two special kinds of tasks
associated with them: diagnostic tasks that try to discover the cause of a problem, and recovery tasks that try to fix
the problem. These tasks can be run automatically when the monitor enters an error state, providing an automated
way to solve problems. They can also be run manually, because automated recovery isn't always the preferred
approach.
Reports
Just as a management pack can contain views customized for the objects that management pack targets, it can
also contain custom reports. For example, a management pack might include a customized definition of one of
Operations Manager's built-in reports, specifying the exact objects that the report should target.
Object discoveries
Object discoveries are used to find the specific objects on a network that need to be monitored. Management
packs define the type of objects that the management pack monitors. The object discoveries can use the registry,
WMI, scripts, OLE DB, LDAP, or even custom managed code to find objects on a network. If an object discovery
finds objects on your network that you do not want to monitor, you can limit the scope of object discoveries by
using overrides.
Run As profiles
A management pack can include one or more Run As profiles. Run As profiles and Run As accounts are used to
select users with the privileges needed for running rules, tasks, and monitors.
Management pack authors can create a Run As profile and associate the profile with one or more rules, monitors,
tasks, or discoveries. The named Run As profile is imported along with the management pack into Operations
Manager. The Operations Manager administrator then creates a named Run As account and specifies users and
groups. The administrator adds the Run As account to the Run As profile and specifies the target computers that
the account should run on. The Run As account provides the credentials for running the rules, monitors, tasks, and
discoveries that are associated with the Run As profile to which the Run As account belongs.
Sealed and unsealed management packs

Management packs are either sealed or unsealed. A sealed management pack is a binary file that cannot be edited.
An unsealed management pack is an XML file that can be edited. Sealed management packs should have an .mp
extension, while unsealed management packs should have an .xml extension.
In general, management packs obtained from an application or hardware device vendor are sealed.
Although you cannot change the settings in a sealed management pack, you can still customize the applied
settings of a management pack after it is imported by using overrides or by creating additional settings such as
rules, monitors, and tasks that supersede the management pack's default settings. All customizations that you
create are saved to a separate management pack file.
Management pack libraries and dependencies

Certain management packs are referred to as libraries, because they provide a foundation of classes on which
other management packs depend. A management pack that you download from the Operations Manager Catalog
might include a library management pack. Several library management packs are imported as part of the
Operations Manager installation process. For a list of management packs imported during the installation of
Operations Manager, see Management Packs Installed with Operations Manager.
A dependency exists when a management pack references other management packs. You must import all
referenced management packs before you can import the management pack that depends on those management
packs. Management packs include a management pack guide that should document the dependencies of the
management pack. In addition, if you attempt to import a management pack and the management packs that it is
dependent on are not present, the Import Management Packs dialog box will display a message that the
management pack will fail to import and a list of the missing management packs. After you import a management
pack, you can view its dependencies in the Operations console.
To view the dependencies for a management pack
1. In the Operations console, in the Administration workspace, click Management Packs.
2. Right-click the desired management pack, and then click Properties.
3. In the Properties dialog box for the management pack, click the Dependencies tab.
The Dependencies tab lists any management packs that the selected management pack depends on and
any management packs that depend on the selected management pack.
Next steps
Management Pack for Overrides
To understand the basic concepts for managing the monitoring configuration of an application or service
defined in a management pack, see Management Pack Lifecycle
See How to import, export and remove a management pack to perform common administrative tasks with
management packs in your management group.
If you want to create your own custom knowledge for specific alerts generated by rules or monitors from a
sealed management pack, review How to Add Knowledge to a Management Pack
Management packs installed with Operations
Manager
2 minutes to read
When you install Operations Manager, a component of System Center, a number of management packs are
installed as well. The following table describes the purposes of those management packs.
PURPOSE ASSOCIATED MANAGEMENT PACKS
Core monitoring functionality - System Center Core Library

- System Center Core Monitoring
- System Center Core Monitoring Agent Management
- System Center Internal Library
- Microsoft System Center Operations Manager Library
- Operations Manager Internal Library
- Performance Library
- Process Monitoring Library
- Health Internal Library
- Health Library
- Default Management Pack
- Baselining Tasks Library
- System Center Operations Manager Infrastructure
Monitoring
- Instance Group Library
- Process Monitoring Library
- System Center Hardware Library
- System Library
- System Software Library
- Windows Cluster Library
- Windows Core Library
- Windows Service Library
- System Center Operations Manager Data Access Service
Monitoring
- System Center Rule Templates
- System Center Task Templates
- System Center UI Executed Tasks
- System Center Workflow Foundation Library
- System Virtualization Library
- WS-Management Library
Client monitoring, agentless exception monitoring (AEM), and - Client Monitoring Internal Library
Customer Experience Improvement Program (CEIP) - Client Monitoring Library
- Client Monitoring Overrides Management Pack
- Client Monitoring Views Library
PURPOSE ASSOCIATED MANAGEMENT PACKS
Application monitoring - Distributed Application Designer Library

- Microsoft System Center Application Monitoring 360
Template Library
- Operations Manager APM Infrastructure
- Operations Manager APM Infrastructure Monitoring
- Operations Manager APM Library
- Operations Manager APM Library Resources (enu)
- Operations Manager APM Reports Library
- Operations Manager APM Wcf Library
- Operations Manager APM Web
- Operations Manager Application Monitoring Library
- Web Application Availability Monitoring Library
- Web Application Availability Monitoring Solutions Base
Library
- Web Application Availability Monitoring Solutions Library
- Web Application Monitoring Library
- System Application Log Library
- Synthetic Transactions Library
- Microsoft.SystemCenter.DataProviders.Library
Network monitoring - SNMP Library

- Network Device Library
- Network Discovery Internal
- Network Management - Core Monitoring
- Network Management Library
- Network Management Reports
- Network Management Templates
UNIX and Linux monitoring - UNIX/Linux Core Library

- UNIX/Linux Core Console Library
- UNIX View Library
- UNIX Log File Template Library
- Image Library (UNIX/Linux)
Enabling views and consoles - Image Library (System Center)

- Image Library (System)
- Image Library (UNIX/Linux)
- Image Library (Windows)
- Microsoft SystemCenter OperationsManager Summary
Dashboard
- Microsoft SystemCenter Visualization Network Dashboard
- Microsoft System Center Visualization Network Library
- Microsoft.SystemCenter.Visualization.Configuration.Library
- Microsoft.SystemCenter.Visualization.Internal
- Microsoft.SystemCenter.Visualization.Library
- System Center Core Monitoring Views
Notifications - Notifications Internal Library

- Notifications Library
Reporting - Data Warehouse Internal Library

- Date Warehouse Library
- Microsoft Data Warehouse Reports
- Microsoft Generic Report Library
- Microsoft ODR Report Library
- Microsoft Service Level Report Library
- Microsoft.SystemCenter.Reports.Deployment
Audit collection services (ACS) - Microsoft Audit Collection Services

The following unsealed management packs are included in Operations Manager:
Client Monitoring Overrides Management Pack
Default Management Pack
Microsoft SystemCenter Virtualization Network Management Pack
Network Discovery Internal Management Pack
Do not save any settings, views, or overrides to these management packs. You should create your own local pack,
which is an unsealed management pack in which to store your customizations. As a best practice, you should
create a separate local pack for each sealed management pack you customize.
Next steps
See How to import, export and remove a management pack to perform common administrative tasks with
management packs in your management group.
Management Pack Lifecycle
10 minutes to read
System Center - Operations Manager uses management packs contain monitoring settings for applications and
services. Ideally, a management pack tells you everything you want to know about the application or technology
that you are monitoring and nothing that you do not want to know. Management packs are designed to provide a
useful monitoring experience for most environments, however you will want to test, tune, and tailor each
management pack to provide optimal results for your organization's needs.
The management pack lifecycle, described in the following table, is the recommended approach to using
management packs. The sections following the table provide details for each stage.
STAGE DESCRIPTION
Review and evaluate management packs in a pre-production Before you deploy a management pack in your production
environment environment, you should familiarize yourself with the contents
of the management pack and guide, and import the
management pack in a pre-production or test environment.
You can also view the management pack in a virtual machine
environment.
Tune the management pack settings and save in a Use overrides to tune the settings of a management pack-
customized management pack such as monitors, rules, object discoveries, and attributes-to
better meet your organization's needs. You should save
overrides to a management pack that you create.
Deploy management packs into a production environment Export the management pack with overrides that is associated
with the management pack that you are going to deploy, and
import management packs in your production environment.
Maintain management pack After deployment, a management pack might need additional
tuning, such as in following circumstances:
- Environmental changes, such as new hardware or new

operating system
- Adding a new application to the production environment
- Upgrading a version of an application
- When a new or updated version of the management pack is
available
- Policy changes, which result in more or less monitoring
based on business needs
Review and evaluate

Each management pack should be accompanied by a management pack guide that is installed to the same folder
as the management pack. A management pack guide contains instructions for installing and configuring the
management pack, and information about the management pack, such as objects that the management pack
discovers and how health rolls up. You can use this information to help you customize the management pack for
your purposes. You should always review the management pack guide before you import the management pack.
A tool for reviewing the contents of a sealed management pack is the MPViewer, which can display the following
contents of a management pack: rules, monitors, views, tasks, console tasks, and reports. MPViewer will also
display the knowledge associated with the particular management pack item. You can install and use MPViewer
on any computer on which the Operations Manager Operations console is installed.
When you have a new management pack, you should import it to a pre-production environment. In Operations
Manager, it is a best practice to have a production implementation that is used for monitoring your production
applications and a pre-production implementation that has minimal interaction with the production environment.
The pre-production management group is used for testing and tuning management pack functionality before the
management pack is deployed in the production environment.
To accurately measure the data that a management pack gathers, you need to expose the agent to the demands of
your production environment. The hardware of the management server in the pre-production environment
should reflect the hardware that is in use in your production environment. Your pre-production management
group should have the same management packs imported to the management server as the production
management group. To test interoperability, your pre-production environment should also include the same types
of server roles that are in your production environment, just on a smaller scale.
You can assign an Operations Manager agent to more than one management group, which is called multihoming.
If you multihome a representative subset of agents in your production environment and your pre-production
environment, the pre-production environment should give you much of the information you need to correctly
tune the management pack. For more information on multihoming agents, see Configuring Windows Agents.
Tune and customize

You can use overrides to refine the settings of a monitoring object in Operations Manager, including monitors,
rules, object discoveries, and attributes. You should create a management pack in which to save customizations
that you make.
To effectively tune the monitoring configuration of your IT services, which may involve one or more management
packs depending on the complexity of that service, you should involve the service owner or subject matter
experts, a representative from the service desk, a representative from the operations team members who monitor
the alerts and events and take action when something requires attention, and the engineering team responsible
for the Operations Manager infrastructure. Depending on the service that is monitored by the management
pack(s), you might also include representation from the networking and security teams. Those responsible for the
Operations Manager infrastructure might not have the knowledge and experience with the service to effectively
tune the management pack(s) without expert input.
Start by reviewing the most common alerts in an effort to improve monitoring accuracy by focusing on high-
volume alerts. Identify the following and prioritize based on impact:
Number and percentage of alerts caused by existing/known problems
Number and percentage of repeated or duplicate alerts. May indicate additional tuning is necessary or there is
a potential issue to investigate further.
Number and percentage of alerts indicating performance or availability issues
Ratio of alerts to tickets generated
Alerts whose resolution state has been set to a state indicating the workflow is generating a high volume of
alerts and is determined through investigation to be faulty by operations or tier-2 support
Leverage the following reports to determine if additional tuning is required:
Most Common Alerts Report
Alerts Report
Data Volume by Management Pack
The following reports are important to validate we are efficiently monitoring the service in its entirety, and there
isn’t:
Configuration churn due to discovery rules running too frequently or there is a property/attribute being
collected that changes frequently
Performance data being collected too frequently or doesn’t need to be collected because the organization will
not use it in a report, view, or dashboard
Event data being collected which adds no value and is only enabled for troubleshooting (short period of time)
Health State flip flopping due to misconfiguration, bug, or other symptom
Alert rule with high repeat count
At a minimum, each workflow should be evaluated according to the following criteria:
Measurable and identifiable occurrence. Anything not aligning with that category is disabled.
When the alert occurs, do we know how to resolve it?
Exceptions (warnings) that provide a proactive notice of potential service impact are exposed to the
NOC/Service Desk, besides any Incident (error) that indicates disruption of service.
Is discovery running too frequent?
Do we need to collect this performance data? Is it useful?
Is the alert understandable, relevant, and up to date?
Should the monitor auto-resolve if the symptom/problem corrects itself?
What to Tune
Discovery frequency
Monitor thresholds
Targets
Intervals for script-based rules/monitors and performance collection rules
Parameters
Tips
Review any new alerts reported for servers monitored with the new management pack. You can use the
Alerts and Most Common Alerts reports to help you discover your most common alerts. When you first
install a management pack, it tends to discover a multitude of previously unknown issues. Monitor the
alerts to determine potential areas of concern
Override the monitor or rule as applicable for all objects of a particular class, a group, or a specific object.
Disable the monitor or rule if the issue is not severe enough to warrant an alert and you do not need to be
made aware of the specific situation being monitored.
Change the threshold of the monitor that is generating the alert if you want the underlying condition to be
monitored, but the alert is being generated before the condition is actually a problem for your particular
environment.
When you set overrides for a management pack, save them to a management pack that is named
ManagementPack_Override, where ManagementPack is the name of the sealed management pack to
which the overrides apply.
Deploy
When you are satisfied with the performance and results of the management pack in the pre-production
environment, you can deploy the management pack and its customizations in the production environment. The
management pack in which you saved the customizations must be exported so that you can import it to other
computers. For more information, see How to Import, Export, and Remove Management Packs. The management
pack that contains the overrides that you set is dependent on the original management pack and can be imported
only to management groups that have the original management pack installed.
Maintain
After a management pack has been deployed, you should periodically evaluate its performance and results in the
production environment to ensure that it continues to meet business needs. The following list describes common
events that might require changes to a management pack:
Environmental changes, such as new hardware or a new operating system
When you are testing new hardware or a new operating system that you plan to add to your production
environment, you should include existing management packs in your test plan to identify any additional
tuning that might be necessary. For a new operating system, you might need to import new management
packs specific to that operating system.
Adding a new application to the production environment
A new application might require a new management pack or adjustments to existing management packs.
Upgrading a version of an application
When organizations upgrade application versions, they usually either upgrade in stages, during which both
versions of the application will exist in the network, or upgrade all installations of the application at one
time. After testing the management packs with the new version and making any necessary adjustments,
you should use the same approach for deploying the management packs that you use for deploying the
upgrades. If both versions of the application will be in use at one time, you should install management
packs appropriate for each version. If all installations of the application will be upgraded at one time,
remove the management pack for the old version of the application and install the management pack for
the new version.
When a new or updated version of the management pack is available
You should use the pre-production environment to review and tune new or updated versions of a
management pack.
Policy changes
Ongoing changes in your business or organization might require adjustments to management packs to
accomplish more monitoring or less monitoring.
Best Practices for change control

The following are some best practices to follow when managing Operations Manager management packs:
Maintain an archive of management pack versions to enable you to roll back changes when necessary. An
efficient method for maintaining the archive is by using version control software, such as Microsoft Team
Foundation Server or SharePoint Server. Another method is to use a file share on the network with
individual folders for each management pack version.
When you set overrides for a management pack, save them to a management pack that is named
ManagementPack_Override, where ManagementPack is the name of the sealed management pack to
which the overrides apply. For example, overrides to the management pack
Microsoft.SQLServer.2012.Monitoring.mp would be saved to
Microsoft.SQLServer.2012.Monitoring_Overrides.xml. For more information, see Creating a Management
Pack for Overrides.
When a management pack is updated, update the corresponding _Overrides.xml file with the new version
number. You must use an XML editor to update the version number of the _Overrides.xml file. If you make
changes to an _Overrides.xml file but do not change the version attribute, you can import the file but the
settings in the file will not be applied.
Document the overrides that you make to management packs. When you set an override, add an
explanation of the action you are taking and the reason for it to the description field by clicking Edit in the
Details pane of the Override Properties dialog box. You may also want to maintain a spreadsheet or other
form to document changes that you make to management packs.
Next steps
To understand what an Operations Manager management pack is and how it helps you proactively monitor
your services and applications, see What is in an Operations Manager Management Pack.
See How to Import, Export, and Remove an Operations Manager Management Pack to perform common
administrative tasks with management packs in your management group.
Management pack templates
2 minutes to read
Management Pack Templates provide Monitoring wizards that let you create complete monitoring scenarios with
minimal input. The wizard creates the required monitors, rules, and even targets to implement the particular
scenario. There is no requirement for you to understand the management pack elements that are created. You can
modify the configuration of the wizard itself if you want to change the way that monitoring is being performed.
Conceptual view of a monitoring wizards
If a management pack template is available for your particular monitoring requirement, using the template most
likely is your best strategy. In many cases, you could create the individual rules and monitors yourself, but this
exercise is significantly more complex than using an available template. In addition, some templates perform
actions that you cannot perform in any other way in the Operations console.
The following table lists the management pack templates that are part of the standard Operations Manager
installation. You can install other management packs that might provide additional templates. Each of these
templates is covered in detail in subsequent sections of this guide.
TEMPLATE DESCRIPTION
.NET Application Performance Monitoring Template Monitor .NET applications to get details about application
performance and reliability.
OLE DB Data Source Template Monitor a database accessible with OLE DB.
Process Monitoring Template Discover and monitor instances of a particular Windows

process.
TCP Port Template Monitor the availability of an application that is listening on a

specific port.
UNIX or Linux Log File Monitor a UNIX or Linux log file for a specific entry.
UNIX or Linux Process Monitor a UNIX or Linux process.
Web Application Availability Monitoring Template Monitor the availability of one or more web application URLs
and run these monitoring tests from internal locations.
Web Application Transaction Monitoring Template Monitor the availability, operation, and performance of a web
application.
Windows Service Template Discover and monitor instances of a particular Windows

service.
See also
Creating Management Pack Templates
Watcher Nodes
Create management pack templates
2 minutes to read
Use the following procedure to create and modify management pack templates.
To create a management pack template

1. Start the Operations console with an account that has Author credentials in the management group.
2. Open the Authoring workspace.
3. In the Authoring navigation pane, right-click the Management Pack Templates node, and then click Add
Monitoring Wizard.
4. Select the management pack template that you want to create, and then click Next.
5. Follow the instructions for the template that you selected. You can use the links in the table above to access this
content.
To edit an existing management pack template
3. In the Authoring navigation pane, expand the Management Pack Templates node.
4. Right-click the template to edit and then select Properties.
To view the elements created by the management pack template
3. In the Authoring navigation pane, expand the Management Pack Templates node.
4. Right-click the template to view, select View Management Pack Objects , and then select the kind of element
that you want to view.
See also
Management Pack Templates
41 minutes to read
The .NET Application Performance Monitoring (APM ) template in System Center – Operations Manager lets
you monitor Internet Information Services (IIS )-hosted .NET applications from server- and client-side perspectives
to get details about application performance and reliability that can help you pinpoint root causes of incidents. (For
System Center 2012 SP1 only: You can also monitor Windows Services.) When you specify settings, the types of
events to collect, the performance goals to measure, and servers to monitor, .NET Application Performance
Monitoring reveals how applications are running. You can see how frequently a problem is occurring, how a server
was performing when a problem occurred, and the chain of events related to the slow request or method that is
raising exceptions. This information is required to partner with software developers and database administrators to
help ensure that applications perform correctly and reliably for your customers.
This template lets you monitor applications and web services that are hosted in Internet Information Services (IIS )
7.0. You can select one or more applications or services discovered by the IIS 7.0 management pack and configure
monitoring of performance and exception events. You must have the Windows Server 2008 Internet Information
Services (IIS ) 7.0 management pack installed to monitor applications and web services.
For System Center 2012 SP1, you can use the template to monitor applications and web services that are hosted
in Internet Information Services (IIS ) 8.0. You can select one or more applications or services discovered by the IIS
8.0 management pack and configure monitoring of performance and exception events. You must have the
Windows Server 2012 Internet Information Services (IIS ) 8.0 management pack installed to monitor applications
and web services.
For more information, see Before You Begin Monitoring .NET Applications
Scenarios
Monitoring Performed by the .NET Application Performance Monitoring Template
Viewing Monitoring Data
Wizard Options
Server-Side Configuration
Advanced Settings for Server-Side Monitoring
Server-Side Customization
Server-Side Modifying Settings
Transaction Properties: Add ASP.NET Web Page
Transaction Properties: Add ASP.NET Web Service
Transaction Properties: Add ASP.NET MVC Page
Transaction Properties: Add WCF Method
Transaction Properties: Add Function
Client-Side Configuration
Advanced Settings for Client-Side Monitoring
Enable Client-Side Monitoring
Client-Side Modifying Settings
Summary
Creating and Modifying .NET Application Performance Monitoring Templates
Viewing .NET Application Performance Monitoring Monitors and Collected Data
Scenarios
Use the .NET Application Performance Monitoring template in scenarios where you have to monitor web-
based applications. These scenarios include the following monitoring processes:
Server-side monitoring: single- or multi-tier web applications

You might have applications that must be running at all times. Use the .NET Application Performance
Monitoring template to ensure that your applications are reliable, have no exceptions, and meet service level
agreements (SLAs), in short, that they perform correctly on the computers where they are installed.
Client-side monitoring: browser performance and reliability

You want to ensure that your customers are having quality web experiences. By creating or editing existing
templates, you can extend your server-side monitoring by adding client-side monitoring that measures the
browser experience of your customers.
Monitoring performed by the .NET application performance monitoring

template
By default, the .NET Application Performance Monitoring template configures the following monitoring. You
can be enable, disable, and modify monitors in the Advanced Configuration page of the .NET Application
Performance Monitoring template.
MONITOR DESCRIPTION DEFAULT VALUES
Percentage of exception events per monitored requests Enabled, Threshold=15%, Interval=5 minutes
Percentage of performance events per monitored requests Enabled, Threshold=20%, Interval=5 minutes
Average Request Time Enabled, Threshold=10,000 ms, Interval=5 minutes
Viewing monitoring data

All data collected by the .NET Application Performance Monitoring template appears in the .NET
Monitoring folder in the Application Monitoring folder in the Monitoring navigation pane. For each of the
application groups that you create by using the .NET Application Performance Monitoring template, the
template creates a folder under .NET Monitoring. The Application Monitoring folder contains the default
views and subfolders that provide health state, Performance views, and alerts related to the application
components in the application group. By using the top-level Application Group State view, you can see the health
of the individual components and the monitoring configurations that have been enabled. The state of each object
matches the state of the targeted object that has the worst health state so that you see the worst state of the
monitors that are running. If one or more of the components are shown with an error while at least one other
component is healthy, it could indicate a problem with that particular component, such as a credential issue. If all of
the components are unhealthy, it could indicate a problem with the infrastructure, such as network connectivity
issues.
Application monitoring folders
To view the state of the individual monitors, open the Health Explorer for each component. Drill down to the
unhealthy monitors to see what is making your application unhealthy. For more information, see Monitoring .NET
Applications
Wizard options
When you run the .NET Application Performance Monitoring template, you have to provide values for options
as listed in the following tables. Each table represents a single page in the wizard.
General properties
The following options are available on the General Properties page of the wizard.
OPTION DESCRIPTION
Name Enter the friendly name used for the template and application
group that you are creating. This name is displayed in the
Operations console and used for the folder under the .NET
Monitoring folder.
Note: After you have given the template a name and saved
the template, this name cannot be edited without deleting
and re-creating the template instance.
Description Describe the application group. (Optional)
Select destination management pack Select the management pack to store the views and
configuration created by the template. Use the same name for
your new management pack as the application group so you
can easily pair the two names. You can use an existing
management pack or create a new management pack. For
more information about management packs, see Selecting a
Management Pack File.
What to monitor
The following options are available on the What to Monitor page of the wizard.
OPTION DESCRIPTION
Application components, Add Search for and add or remove the application components to
monitor. When you click Add , the Object Search page opens,
which lets you select whether you want to monitor Web
Applications and Services. For System Center 2012 SP1 only:
You can monitor Windows Services.
Note: For System Center 2012 SP1 only: Before you begin
monitoring Windows Services, you need to configure Windows
Services using the Windows Service template. Once you do
this, the.NET Application Performance Monitoring template
can discover the Windows Services that are running. For more
information, see Authoring the Windows Service Template.
Environment Select the environment in which you want to monitor your

application: None , Production , Staging , Test ,
Development , or use New to create a new tag. Typically,
you want to pair the environment tag with the server group
that you are monitoring. The tag is appended to the
application group name and component names, letting you
differentiate the event data in Application Diagnostics and
Application Advisor. From a monitoring perspective, the
environment tag lets you separate the same application into
multiple virtual applications.
Note: After you have selected an environment tag and saved
the template, the tag cannot be edited without deleting and
re-creating the template instance.
OPTION DESCRIPTION
Targeted group Select specific servers to limit monitoring to this specific set of
servers. This is optional. Targeted group scoping only becomes
necessary when you have the same application running in
multiple environments, such as production and staging, and
you intend to run the template multiple times, one for each
environment. In this scenario, group which machines belong
to production and which belong to the staging environment,
and then use the targeted groups to restrict where the
configuration is propagated. You can also use groups to apply
configuration to a subset of your servers. Otherwise, it is not
necessary to specify targeted group scoping if you just want
to monitor all instances of a given application.
Object search
The following options are available on the Object Search page of the wizard.
OPTION DESCRIPTION
OPTION DESCRIPTION
Search for Select Web Applications and Services. For System Center 2012
SP1 only: You can also select Windows Services.
Note: For System Center 2012 SP1, before you begin
monitoring Windows Services, you need to configure Windows
Services using the Windows Service template. Once you do
this, the.NET Application Performance Monitoring template
can discover the Windows Services that are running. For more
information, see Authoring the Windows Service Template
Filter by part of name (optional) Enter part of the name of Web Application and Services that
you want to select. For System Center 2012 SP1 only: You can
also enter part of the name of a Windows Service that you
want to select.
Available items Displays the Windows Web Application and Services that are
available for monitoring. For System Center 2012 SP1 only:
Also displays the Windows Services that are available for
monitoring.
Selected objects Displays the application components that you have selected
to monitor.
Server-side configuration
The following options are available on the Server-Side Configuration page of the wizard.
OPTION DESCRIPTION
Turn on performance event alerts Turn performance event alert reporting for the application
group on or off within the Operations console for server-side
monitoring. Performance events are still logged to the
Application Diagnostics console. You have the option whether
to raise alerts after an Application Performance Monitoring
event is generated.
Turn on exception event alerts Turn the exception event alert notification for the application
monitoring. Exception events are still logged to the
event is generated.
Performance event threshold (ms) Set the threshold in milliseconds (ms) that a user transaction
must exceed before it raises a performance event.
Advanced Settings Set advanced configurations, including sensitivity (restricting

the collection of fast functions), namespaces (that define
where you want to collect data from custom applications),
methods (specific functions where you want to start
monitoring), custom exception handlers (that define critical
exceptions), and customize the configuration of the monitors
that affect the component health state.
Enable additional configuration options for server-side and Specify additional options in the wizard to customize
client-side monitoring monitoring for individual application components and client-
side monitoring.
Advanced settings for server-side monitoring

The following options are available on the Advanced Settings for server-side monitoring page of the wizard.
OPTION DESCRIPTION
event is generated.
event is generated.
Performance event threshold (ms) Set the threshold in milliseconds (ms) that a request must be
processed in before it causes a performance event.
OPTION DESCRIPTION
Sensitivity threshold (ms) Specify to filter out fast-running methods to reduce overall
"noise" by reducing the size of the call stack by gathering less
data for each event. For more information, see Authoring
Strategies for .NET Application Monitoring
Set Namespaces Specify namespaces and classes where to start measuring for
performance events and performance threshold violations,
and define which namespaces should be treated by default as
entry points. For more information, see How to Add, Enable,
and Disable Namespaces
Set Methods Specify how deep in the call stack to drill down to collect more
detailed information, such as parameters and variables, for
specific methods. For more information, see How to Add, Edit,
and Remove Methods
Security alerts Turn alerting of exceptions on or off that are classified as

security alerts for the application group, with errors such as
"Access Denied" or "Login Failed".Security events are logged to
the Application Diagnostics console. You have the option to
choose whether to raise alerts after an Application
Performance Monitoring event is generated.
Connectivity alerts Turn alerting of exceptions on or off that are classified as

connectivity alerts for the application group, with errors such
as "Connection timed out".Connectivity events are logged to
Application failure alerts Turn alerting of exceptions on or off that are classified as
application, or code, failures for the application group. By
default, this option is turned off to reduce the "noise" of alerts
raised due to code failures that typically only development
teams can resolve. For more information, see Authoring
Strategies for .NET Application MonitoringException events are
logged to the Application Diagnostics console. You have the
option to choose whether to raise alerts after an Application
Critical exceptions only Specify whether the exception is considered relevant by the
Application Performance Monitoring agent and whether an
event is created. An event is created if the exception raised is
one of those in the list of critical exception handlers. For more
information, see Using Exception Handlers to Define Critical
Exceptions
All exceptions Specify whether all exceptions are considered relevant by the
Application Performance Monitoring agent and events are
created when exceptions are detected in monitored
namespaces and classes.
Exception Tracking Select to add namespace or classes where you track exception
parameters or variables, and collect additional information
about each exception that a namespace or class raised. For
more information, see How to Add, Edit, and Remove
Exception Tracking
OPTION DESCRIPTION
Critical Exceptions Select to add items to the Exception handlers list. Define
exception handlers that catch critical exceptions that an
application raised. For more information, see Using Exception
Handlers to Define Critical Exceptions
Monitors: Exception Events/sec exceeds Monitor that watches the .NET App/% Exception Events/sec
performance counter.
Monitors: Performance Events/sec exceeds Monitor that watches the .NET Apps/% Performance
Events/sec performance counter.
Monitors: Average Request Time exceeds Monitor that watches the .NET Apps/Average Request Time
Server-side customization
For System Center 2012 SP1, the following options are available on the Server-Side Customization page of the
wizard.
OPTION DESCRIPTION
Component Select the component you want to customize for monitoring

individual application components.
Customize Modify the settings for the selected application component.

This opens the Modifying Settings page. The settings on this
page are the same as those on the Advanced Settings for
Server-Side Monitoring page, except you can create
individual transaction monitoring for ASP.NET webpages,
ASP.NET web services, or individual functions in an assembly.
These are described in the Transaction Properties: Add
ASP.NET Web Page sections that follow.
Note: The buttons for namespaces, exception tracking, and
critical exceptions are unavailable because these can only be
set at the application-group level, not at the component level.
For System Center 2012 SP1 only: you can customize these
settings if you are configuring monitoring for Windows
Services.
Modifying Settings page Customize settings for the application component and/or
specify monitoring for a specific webpage, web method, or
function within the application component.
Server-side modifying settings

The following options are available on the Server-Side Modifying Settings page of the wizard.
OPTION DESCRIPTION
event is generated.
event is generated.
OPTION DESCRIPTION
Performance event threshold (ms) Set the threshold in milliseconds (ms) that a request must be
process in before it causes a performance event.
Set Methods Specify how deep in the call stack to drill down to collect more
detailed information, such as parameters and variables, for
specific methods. For more information, see How to Add, Edit,
and Remove Methods
Security alerts Turn on or off alerting of exceptions classified as security

alerts for the application component, with errors such as
"Access Denied" or "Login Failed".Security events are logged to
Connectivity alerts Turn on or off alerting of exceptions classified as connectivity

errors for the application component, such as "Connection
Timed Out".Connectivity events are logged to the Application
Diagnostics console. You have the option to choose whether
event is generated.
Application failure alerts Turn on or off alerting of exceptions classified as application,

or code, failures for the application component. By default, this
option is turned off to reduce the "noise" of alerts raised due
to code failures that typically only development teams can
resolve. For more information, see Authoring Strategies for
.NET Application MonitoringException events are logged to
Critical exceptions only Specify whether the exception is considered relevant by the
Application Performance Monitoring agent and whether an
event is created. An event is created if the exception raised is
one of those in the list of critical exception handlers. For more
information, see Using Exception Handlers to Define Critical
Exceptions
All exceptions Specify whether all exceptions are considered relevant by the
Application Performance Monitoring agent and events are
created when exceptions are detected in monitored
namespaces and classes.
Monitors: Exception Events/sec exceeds Monitor that watches the .NET App/% Exception Events/sec
Monitors: Performance Events/sec exceeds Monitor that watches the .NET Apps/% Performance
Monitors: Average Request Time exceeds Monitor that watches the .NET Apps/Average Request Time
OPTION DESCRIPTION
Transactions: Add Add transactions for ASP.NET web pages, ASP.NET Web
services, and functions. See the following tables.
NOTE
The buttons for namespaces, exception tracking, and critical exceptions are unavailable because these can only be set at the
application-group level, not at the component level. For System Center 2012 SP1 only: You can customize these settings if
you are configuring monitoring for Windows services.
Application types and server-side transactions you can monitor

For each application type there are several transaction types you can choose to monitor. The following options are
available:
TRANSACTION TYPES FOR SYSTEM CENTER TRANSACTION TYPES FOR SYSTEM CENTER
APPLICATION TYPE 2012 2012 SP1
ASP.NET Web application - ASP.NET webpage - ASP.NET webpage

- ASP.NET web service - ASP.NET MVC page
- Function - ASP.NET web service
- WCF method
- Function
ASP.NET Web service - ASP.NET webpage - ASP.NET webpage

- ASP.NET web service - ASP.NET MVC page
- Function - ASP.NET web service
- WCF method
- Function
WCF service Not available - ASP.NET webpage

- ASP.NET MVC page
- ASP.NET web service
- WCF method
- Function
Windows service Not available - WCF method

- Function
Transaction properties: add ASP.NET web page

The following options are available on the Transaction Properties page for ASP.NET Web Page page of the
wizard.
OPTION DESCRIPTION
Transaction name Enter the friendly name for the transaction as it will be
displayed on the Monitoring tab, performance counters, and
elsewhere.
ASP.NET page Enter the path to the page that you are configuring these
monitoring settings for.
Note: The application component continues to monitor the
page specified in the transaction by using the performance
threshold that is set for the application component. This
threshold is used as a second measure on the same page in
the application component. If you set this threshold higher
than the application component threshold, you get a single
event, but you might get two performance alerts for the
transaction when the threshold is breached—one from the
application component and one from the transaction,
depending on your alerting settings. Transactions are typically
used to monitor the individual page more aggressively than
the parent application, at a lower threshold, or to monitor a
page where alerting has been disabled on the parent.
OPTION DESCRIPTION
data for each event. An event is still generated if the threshold
is surpassed. For more information, see Authoring Strategies
for .NET Application Monitoring
Collect alerts by event type: Connectivity Turn on or off alerting of events, classified as connectivity
alerts with errors such as "Connection Timed
Out".Connectivity events are logged to the Application
event is generated.
Collect alerts by event type: Application failure Turn on or off alerting of events classified as application, or
code, failures. Turning this off reduces the "noise" of many
alerts raised due to code failures. Because these alerts are
raised from code failures, developers usually resolve these
issues. For more information, see Authoring Strategies for
Collect alerts by event type: Security Turn on or off alerting of events classified as security alerts,
with errors such as "Access Denied" or "Login Failed". Security
events are logged to the Application Diagnostics console. You
have the option to choose whether to raise alerts after an
Application Performance Monitoring event is generated.
Collect alerts by event type: Performance Turn on or off alerting of events classified as performance
alerts. Performance events are logged to the Application
event is generated.
Monitors: % Exception Events/sec Monitor that watches the .NET App/% Exception Events/sec
Monitors: % Performance Events/sec Monitor that watches the .NET Apps/% Performance
Monitors: Average Request Time Monitor that watches the .NET Apps/Average Request Time
Transaction properties: add ASP.NET web service

The following options are available on the Transaction Properties page for the ASP.NET Web Service page of
the wizard.
OPTION DESCRIPTION
so on.
Web service file Enter the path to the file for which you are configuring these
monitoring settings.
Method name Enter the URI of the web method that you want to monitor.
OPTION DESCRIPTION
the parent application, at a lower threshold, or to monitor a
Collect alerts by event type: Connectivity Turn on or off alerting of events classified as connectivity
alerts, with errors, such as "Connection Timed
event is generated.
code, failures. Turning this option off reduces the "noise" of
many alerts raised due to code failures. Because these alerts
are raised from code failures, developers usually resolve these
Collect alerts by event type: Security Turn on or off alerting of events classified as security alerts,
with errors such as "Access Denied" or "Login Failed".Security
alerts.Performance events are logged to the Application
event is generated.
Transaction properties: add ASP.NET MVC page
For System Center 2012 SP1 the following options are available on the Transaction Properties for the ASP.MVC
page of the wizard.
OPTION DESCRIPTION
so on.
MVC controller Enter the name of the MVC controller for which you are
configuring these monitoring settings.
MVC action Specify the name of the MVC action for which you are
configuring these monitoring settings.
OPTION DESCRIPTION
the parent application, at a lower threshold or to monitor a
page where monitoring has been disabled on the parent.
alerts, with errors such as "Connection Timed
event is generated.
Collect alerts by event type: Security Turn on or off alerting of events classified as security alerts
event is generated.
Transaction properties: add WCF method
The following options are available on the Transaction Properties for the Add WCF method settings page of
the wizard.
OPTION DESCRIPTION
so on.
Class name Enter the name of the class for which you are configuring
these monitoring settings. The class name is in the format:
Namespace.Class. For example: wcfservice.myclass.
Method name Specify the name of the method that is expected to be in the
class for which you are configuring these monitoring settings.
OPTION DESCRIPTION
event is generated.
event is generated.
Transaction properties: add function
The following options are available on the Transaction Properties for the Add Function page of the wizard.
OPTION DESCRIPTION
so on.
Function name Enter the name of the function for which you are configuring
these monitoring settings. The function name is in the format:
Namespace.Class.Method. For example:
System.Web.UI.Page.ProcessRequest.
Function module Specify the name of the assembly, such as System.Web.dll,

that defines the function for which you are configuring these
monitoring settings.
OPTION DESCRIPTION
event is generated.
event is generated.
Client-side configuration
The following options are available on the Client-Side Configuration page of the wizard.
OPTION DESCRIPTION
Turn on performance event alerts Turn performance event alert reporting on or off within the
Operations console for server-side monitoring. Performance
events are still logged to the Application Diagnostics console.
You have the option whether to raise alerts after an
Turn on exception event alerts Turn exception event alert reporting on or off within the
Operations Manager console for server-side monitoring.
Exception events are still logged to the Application Diagnostics
console. You have the option whether to raise alerts after an
Page load threshold (ms) Set the threshold in milliseconds (ms) that a page load must
exceed before it causes a performance event. You have the
option whether to raise alerts after an Application
Performance Monitoring event is generated. The event is only
turned into an alert if you have selected Turn on
performance event alerts.
IP address filter: IP Address Specify the IP addresses that you want to exclude from
monitoring. For more information, see How to Configure IP
Address Exclusion Filters for Client-Side Monitoring
OPTION DESCRIPTION
IP address filter: Netmask The part of the filter IP address and user IP address that have
to be compared for equality.
IP address filter: Comparison Type Specify to exclude IP addresses that match the IP addresses in
the subnet ( IP is in subnet ), or to exclude the user IP
addresses that do not match the IP addresses in the subnet (
IP is not in subnet ).
IP address filter: Use IPv6 Add the IPv6 filter if the IPv6 protocol is enabled on the web
server.
Advanced Settings Specify settings, such as performance and event monitoring

thresholds, exception event monitoring, Critical Exceptions,
and monitors.
Advanced settings for Client-side monitoring

The following options are available on the Advance Settings for Client-Side Monitoring page of the wizard.
OPTION DESCRIPTION
OPTION DESCRIPTION
Turn on exception event alerts Turn exception event alert notification on or off within the
Operations console for server-side monitoring. Exception
exceed before it causes a performance event. You have the
option whether to raise alerts after an Application
Ajax and WCF threshold (ms) Set the threshold in milliseconds (ms) that an Ajax or Windows
Communications Foundation (WCF) call initiated from the
page must exceed before it causes a performance event. The
event is only turned to an alert if you have selected Turn on
Monitor % of incoming requests. Specify a sample size of incoming requests, defined as a

percentage of the total number of incoming requests that you
want to monitor. For more information, see Authoring
IP address: IP Address Specify the IP addresses that you want to exclude from
IP address: Netmask Specify the part of the filter IP address and user IP address
that have to be compared for equality.
IP address: Comparison Type Specify to exclude IP addresses that match the IP addresses in
addresses that do not match the IP addresses in the subnet (
IP is not in subnet ).
IP address: Use IPV6 Specify to add the IPv6 filter if the IPv6 protocol is enabled on
the web server.
Monitors: Exception Events\sec exceeds Monitor that watches the .NET CSM Apps/% Exceptions
Monitors: Performance Events\sec exceeds Monitor that watches the .NET CSM Apps/% Performance
Monitors: Average Request Time exceeds Monitor that watches the .NET CSM Apps/Average Page Load
Response Time performance counter.
Data Items Select the type of client-side data that you want to collect. For
more information, see Working with Sensitive Data for .NET
Applications
Load balancer settings Select the type of load balancer that you are using with your
application. You can also add your own load balancer, if it is
not included in the list. For more information, see Client-Side
Monitoring with Targeted Groups and Load Balancers
OPTION DESCRIPTION
Enable client-side monitoring
The following options are available on the Enable Client-Side Monitoring page of the wizard.
OPTION DESCRIPTION
Component Select the component you want to customize for monitoring

individual application components. Only the components of
the ASP.NET Web application type are displayed. Web Services
and WCF Services do not serve HTML pages to browsers, so
you cannot enable client-side monitoring for them. For
System Center 2012 SP1 only: .NET applications hosted in
Windows Services do not serve HTML pages to browsers, so
you cannot enable client-side monitoring for them.
OPTION DESCRIPTION
Customize Modify the settings for the selected application component.

This opens the Modifying Settings page. The settings on this
page are similar to those on the Advanced Settings for
Client-Side Monitoring page. On the Modifying Settings
page, you can specify the pages to be excluded from
monitoring.
Client-side modifying settings

The following options are available on the Client-Side Modifying Settings page of the wizard.
OPTION DESCRIPTION
OPTION DESCRIPTION
Turn on exception event alerts Turn exception event alert reporting on or off within the
Operations console for server-side monitoring. Exception
exceed before it causes a performance event alert. You have
the option whether to raise alerts after an Application
Ajax and WCF threshold (ms) Sets the threshold in milliseconds that an Ajax or Windows
Communications Foundation (WCF) call initiated from the
page must exceed before it causes a performance event. The
event is only turned into an alert if you have selected Turn on
Monitor % of incoming requests. Specify a sample size of incoming requests, defined as a

percentage of the total number of incoming requests that you
want to monitor. For more information, see Authoring
IP address: IP Address Enter the IP addresses that you want to exclude from
IP address: Netmask Specify the part of the filter IP address and user IP address
that have to be compared for equality.
IP address: Comparison Type Specify to exclude IP addresses that match the IP addresses in
addresses that do not match the IP addresses in the subnet IP
is not in subnet ).
IP address: Use IPV6 Specify to add the IPv6 filter if the IPv6 protocol is enabled on
the web server.
Monitors: Exception Events\sec exceeds Monitor that watches the .NET CSM Apps/% Exceptions
Monitors: Performance Events\sec exceeds Monitor that watches the .NET CSM Apps/% Performance
OPTION DESCRIPTION
Monitors: Average Request Time exceeds Monitor that watches the .NET CSM Apps/Average Page Load
Response Time performance counter.
Data collection Select the type of client-side data you want to collect. For
more information, see Working with Sensitive Data for .NET
Applications
Load balancer settings Select the type of load balancer that you are using with your
application. You can also add your own load balancer, if it is
not included in the list. For more information, see Client-Side
Monitoring with Targeted Groups and Load Balancers.
Excluded pages: Add Specify to add the pages to exclude from monitoring. You
typically exclude pages that are considered unimportant for
given metrics or that did not pass the compatibility check.
Transactions: Add Specify transactions to add for ASP.NET web pages.
Summary
The Summary page of the wizard lists the settings you have configured for the .NET Application Performance
Monitoring template. If you want to change any of these settings, click Previous or the template page until you
reach the page with the settings that you want to change.
Creating and modifying .NET application performance monitoring

templates
For the procedure to run the .NET Application Performance Monitoring wizard, see How to Configure Monitoring
for .NET Applications.
To modify an existing .NET application performance monitoring template
1. Open the Operations console with a user account that has Author credentials in the management group.
2. Click the Authoring workspace.
3. In the Authoring navigation pane, expand Management Pack Templates , and then select .NET
Application Performance Monitoring.
4. In the .NET Application Performance Monitoring pane, locate the template to change.
5. Right-click the application group that you want to modify, and then select Properties.
6. Using the tabs to navigate the pages of settings, make the desired changes, such as adding customized
monitoring for a specific application component or configuring and enabling client-side monitoring, and then
click OK.
Viewing .NET application performance monitoring monitors and

collected data
After you configure monitoring for an application, these three views will help you get started with the monitoring
experience.
To view all .NET application performance monitoring monitored applications
2. Click the Monitoring workspace.
3. In the Monitoring navigation pane, expand Application Monitoring , expand .NET Monitoring , and then
click Monitored Applications.
To view the state of each monitor
4. In the Monitored Applications view, right-click an object. Select Open , and then click Health Explorer.
5. Expand the Availability and Performance nodes to view the individual monitors.
To view the performance collected for an application component
4. In the Monitored Applications pane, right-click an object. Select Open , and then click Performance View.
5. In the Legend pane, select the counters that you want to view.
6. Use options in the Actions pane to modify the Performance view.
See also
Before You Begin Monitoring .NET Applications
How to Configure Monitoring for .NET Applications
How to Start Monitoring a New Application
Authoring Strategies for .NET Application Monitoring
Using exception handlers to define critical exceptions
3 minutes to read
Exception handlers are application functions that "catch" exceptions that the applications throw to report errors
and perform some error handling. By default, .NET Application Performance Monitoring defines critical exceptions
as exceptions handled by specific exception handlers provided by the .NET framework. These handlers catch top-
level ASP.NET exceptions, and web service exceptions that the monitored application failed to catch and handle
internally. By adding exception handlers, you are adding to what application monitoring's definition of what a
critical exception is. In effect, any exceptions handled by these functions will be considered critical exceptions. The
advantage to doing this is that you maintain the benefit of streamlined reporting of critical exceptions only, but
you have the additional benefit of reporting functions that are of interest to you. It is common to add any
customer error handlers defined for web applications to the list of critical exception handlers so that you can be
alerted when a user is sent to your error handler page in the web application.
WARNING
Exception handlers are set on the process level. If you enable an exception handler for an application that is running in the
process and then disable it for a different application running in that process, there will be a configuration conflict and
application monitoring will be disabled. To resolve this, you must make the exception handling the same for all applications in
the same process.
Default exception handlers

The default list of exception handlers includes:
Web.HttpApplication.RecordError
Web.UI.Page.HandleError
Web.Services.Protocols.WebServiceHandler.WriteException
AppDomain.OnUnhandledExceptionEvent
Windows.Forms.Application.ThreadContext.OnThreadException
AppDomain.OnUnhandledExceptionEvent
Runtime.Remoting.Messaging.ReturnMessage..ctor
Windows.Forms.DataGridView.OnDataError
For System Center 2012 SP1 these resources are included:
Office.Server.Data.SqlSession.LogException
Office.Excel.Server.CalculationServer.Proxy.ExcelServerProxy.ProcessSoapException
Office.Excel.Server.CalculationServer.Proxy.ExcelServerProxy.ProcessWebException
SharePoint.Portal.WebControls.BusinessDataWebPart.ConstructErrorMessage
SharePoint.Diagnostics.ULS.SendEventTag
SharePoint.ApplicationRuntime.SPRequestModule.IsWebPartOnExceptionStack
SharePoint.Utilities.SqlSession.LogException
Office.Web.Environment.Sharepoint.Diagnostics.ULS.SendExceptionTag
SharePoint.Diagnostics.ULS.SendExceptionTag
Office.Server.Diagnostics.ULS.SendExceptionTag
Workflow.Runtime.WorkflowExecutor.IsIrrecoverableException
ServiceModel.DiagnosticUtility.IsFatal
Web.Mvc.ControllerActionInvoker.InvokeExceptionFilters
Add an exception handler

To add an exception handler
1. To open the .NET Application Performance Monitoring template, in the Operations Manager console, in the
navigation pane, click the Authoring button, click Management Pack Templates, and then click .NET
2. Right-click the application group you want to modify, and then select Properties.
3. On the Server-Side Defaults tab, click Advanced Settings.
4. On the Advanced settings page, click Critical Exceptions to open the Exception handlers list page.
This is where you can add exception handlers.
5. To add an exception handler, click Add and type the method you want to add to the exception handlers list.
If you want this exception handler to effect monitoring, make sure the Enable monitoring checkbox is
selected. Click OK.
IMPORTANT
Adding handlers that are defined in the .NET Framework as part of mscorlib as Critical Exceptions will not produce
any effect.
NOTE
The method name is case sensitive and should be specified in the following format:
Namespace.ClassName.MethodName
Edit an exception handler

To edit an exception handler
1. Open the .NET Application Performance Monitoring template. In the Operations Manager console, in the
2. Right-click the application group you want to modify and select Properties.
4. On the Advanced settings page, click Critical Exceptions. This opens the Exception handlers list page
where you can edit exception handlers.
5. To edit an exception handler, click Edit, select the exception handler you want to change, and then modify it.
Click OK.
NOTE
The method name is case sensitive. Additionally, the method name should be specified in the following format:
Namespace.ClassName.MethodName
Remove an exception handler
To remove an exception handler
1. Open the .NET Application Performance Monitoring template. In the Operations Manager console, in the
2. Right-click the application group you want to modify and select Properties.
4. On the Advanced settings page, click Critical Exceptions. This opens the Exception handlers list page
where you can remove exception handlers.
5. To remove an exception handler, select the exception handler you want to remove, click Remove, and then click
OK.
Authoring strategies for .NET application
monitoring
7 minutes to read
Here are some scenarios and settings to change during authoring that can help you receive the monitoring
experience and data that is most helpful for you.
Monitoring a new application

Accepting all defaults can be a good way to start monitoring an application for which the administrator has
little or no knowledge. Then, after monitoring with all defaults for some time, the administrator can begin
adjusting settings based on the monitoring alerts, Application Diagnostics data, and Application Advisor
reports. For more information, see How to Start Monitoring a New Application and Application Monitoring
Using the Default Settings
Limit monitoring to a specific set of servers

Defining a targeted group allows you to limit monitoring to a specific set of servers. In the .NET Application
Performance Monitoring wizard, targeted group for server-side monitoring is on the What to Monitor page.
Targeted group for client-side monitoring is on the Enable Client-Side Monitoring page. If you are using a
targeted group for client-side monitoring and use a load balancer, see Client-Side Monitoring with Targeted
Groups and Load Balancers
For large application deployments, you typically do not need to monitor all instances of the application. A
representative sample is enough to get the data you need. Using only a representative sample will keep the
amount of data collected and stored lower.
Reduce the "Noise"

Increasing the sensitivity threshold allows you to filter out fast-running methods, which reduce overall "noise",
or how deep the call stack is going to go, making it easier for you to determine where the problem is. It also
reduces network bandwidth usage.
The sensitivity setting is used to determine if a function call should be included in the call stack. Any function
that executes and returns faster than the sensitivity level is dropped, keeping small fast-running functions
from hiding the actual problem. Remember that using sensitivity only reduces the number of functions shown
in the call stack for specific events, but an event will still be generated if the overall threshold is surpassed.
You can adjust the sensitivity threshold for server-side and client-side monitoring independently.
To change the sensitivity threshold for server-side monitoring
1. To open properties for the application group that you want to reconfigure, in the Operations Manager
console, in the navigation pane, click the Authoring button, expand Management Pack Templates,
click .NET Application Performance Monitoring, right-click the application group that you want to
configure, and then select Properties.
NOTE
If you are currently authoring a new .NET Application Performance Monitoring template, to change the
sensitivity threshold for server-side monitoring, go to the Server-Side Configuration page and click
Advanced Settings Change the Sensitivity threshold and click OK.
2. To change the sensitivity threshold for server-side monitoring, on the Properties page, click the
Server-Side Monitoring tab, and then click the Advanced Settings button.
3. Change the Sensitivity threshold and click OK.
To change the sensitivity threshold for client-side monitoring
console, in the navigation pane, click the Authoring button, expand Management Pack Templates ,
click .NET Application Performance Monitoring , right-click the application group that you want to
want to configure, and then select Properties.
NOTE
If you are currently authoring a new .NET Application Performance Monitoring template, to change the
sensitivity threshold for client-side monitoring, go to the Client-Side Configuration page and click Advanced
Settings. Change the Sensitivity threshold and click OK.
2. To change the sensitivity threshold for client-side monitoring, on the Properties page, click the Client-
Side Monitoring tab, and then click the Advanced Settings button.
3. Change the Sensitivity threshold and click OK.
It is also possible for high sensitivity to hide problems. In the situation where you have a function that calls
another function, if the callee's response time increases even slightly, it might cause issues for the application.
For example, if you have a data processing function that calls a lookup function 1,000 times and the lookup's
processing time increases by 1 ms, you will increase the response time for your top-level function by a full
second. This might be masked by the high sensitivity. When you find this kind of situation, you can add the
callee as a method and set a custom sensitivity for it to ensure it is always measured according to the lower
sensitivity threshold.
Application failure alerts are application, or code, failures that are detected within the application. You can
choose not to receive application failure alerts, which will potentially occur often if an application has
problems because these kinds of alerts usually require code modifications to address. Turning this off reduces
the "noise" of many alerts raised that cannot be directly resolved by the operations team.
You can turn off application failure alerts for server-side and client-side monitoring independently.
To turn off alerts for application failures for server-side monitoring
NOTE
If you are currently authoring a new .NET Application Performance Monitoring template, to turn off alerts for
application failures for server-side monitoring, go to the Server-Side Configuration page and click Advanced
Settings. Clear the Application failure alerts checkbox and click OK.
2. To turn off application failure alerts for server-side monitoring, on the Properties page, click the
Server-Side Defaults tab, and then click the Advanced Settings button.
3. On the Advanced settings page and clear the Application failure alerts checkbox.
4. Click OK.
To turn off alerts for application failures for client-side monitoring
NOTE
If you are currently authoring a new .NET Application Performance Monitoring template, to turn off alerts for
application failures for client-side monitoring, go to the Client-Side Configuration page and click Customize.
On the Modifying Settings page, in the Transactions section, click Add. On the Transaction Properties
page, clear the Application failure checkbox and click OK.
2. To turn off application failure alerts for client-side monitoring, on the Properties page, click the Client-
Side Monitoring tab, and then click the Advanced Settings button.
3. In the Transactions section, click Add.
4. On the Transaction Properties page, clear the Application failure
5. Click OK.
Only receive critical exceptions

By default, .NET Application Performance Monitoring defines critical exceptions as exceptions handled by
specific exception handlers provided by the .NET framework. These handlers catch top-level ASP.NET
exceptions and web service exceptions that the monitored application failed to catch and handle internally. By
adding exception handlers, you are adding to what application monitoring's definition of what a critical
exception is. In effect, any exceptions handled by these functions will be considered critical exceptions. The
advantage to using exception handlers is that you maintain the benefit of streamlined reporting of critical
exceptions only, but you have the additional benefit of reporting functions that are of interest to you. For more
information and a list of default exception handlers, see Using Exception Handlers to Define Critical
Exceptions.
Improve client-side monitoring performance

You might also want to adjust the sampling rate to control the performance impact of the monitoring on your
application with client-side monitoring. Reducing the sampling rate reduces the application monitoring traffic
and helps conserve server resources. If you have even a low -traffic site, instrumenting and collecting data
from every user who connects will result in a large amount of non-actionable data to sift through. Taking a
random sample will give you the insight you need into the application performance from the client perspective
without flooding you with a large amount of data to process and store.
To change the sampling rate for client-side monitoring
1. To open client-side properties for the application group that you want to reconfigure, in the Operations
Manager console, in the navigation pane, click the Authoring button, expand Management Pack
Templates , click .NET Application Performance Monitoring , right-click the application group that
you want to want to reconfigure, and then select Properties.
On the Properties page, click the Client-Side Defaults tab, and then click the Advanced Settings
button.
NOTE
Because you can change the sampling rate for both the application group and each application component,
changes to the application group settings will not automatically be applied to the component settings when the
component settings have been previously customized.
2. In the Sampling section, use the drop-down menu to select the percentage of incoming requests that
you want to monitor. For example, if you select 50%, you will monitor 50 percent of the incoming
requests. Select 25% and you will monitor 25 percent of the incoming requests, and so on. To get
helpful information, you do not have to monitor all of the incoming requests.
3. When you have set the sampling rate, click OK.
See also
Application monitoring using the default settings
2 minutes to read
Accepting all defaults can be a good way to start monitoring an application for which the administrator has little or
no knowledge. Then, after monitoring with all defaults for some time, the administrator can begin adjusting
settings based on the monitoring alerts, Application Diagnostics data, and Application Advisor reports.
Using default settings for server-side monitoring

You still need to select the application you want to monitor and the target management pack, but then you can
start monitoring with "all defaults". With all default settings Application Performance Monitoring will monitor only
server-side, and all thresholds for all pages will be the same. To see the default values, you can go through the
wizard without changing anything.
Using default settings for client-side monitoring

The defaults are enough to get this started and to allow you to test it out from localhost connections. It is scoped to
monitor localhost by default.
You can certainly accept the default settings for client-side monitoring, but it is important to run the compatibility
check task to validate if the application can be monitored and if any of the pages should be excluded from
monitoring. Therefore, simply applying of client-side monitoring defaults might be risky. For more information
about running the compatibility check task, see Before You Begin Monitoring .NET Applications
In general, client-side threshold settings should be higher than server-side threshold settings. This is because the
client-side monitoring contains the server time, too. For instance, when a client-side event is divided into various
parts, some of the time is spent on the server, but the client also monitors the time spent on the network and the
time spent in the browser.
IP Address Filters and Load balancers Also, IP filters by default will enable client-side monitoring for localhost
only. Additionally, load balancer settings need to be set correctly for client-side monitoring. If the IP header is not
set, all client-side monitoring traffic will appear to be coming from a single IP address. All IP - and subnet- based
reports in Application Advisor will be invalid if the default settings are used with a load balancer.
There is no default for the load balancers. The load balancer setting is one you can opt to change, whereas you
must change the client IP filters because if you do not update those settings you will not get any data at all.
IP Address Filters You can use client IP filters to choose the networks that you want to monitor. By applying
filters, administrators can limit the scope of the monitored computers. By default, only localhost IP addresses are
monitored. If the IP filter list is empty, all IP addresses are monitored. Any IP addresses that fit the filter definitions
are excluded from client-side monitoring. For more information, see How to Configure IP Address Exclusion Filters
for Client-Side Monitoring
See also
Authoring Strategies for .NET Application Monitoring
OLE DB data source template
10 minutes to read
OLE DB (Object Linking and Embedding Database) is a Microsoft technology for accessing a variety of data
sources by using a common method to connect to different databases such as Microsoft SQL Server.
The OLE DB Data Source template lets you monitor the availability and performance of any database that can be
accessed with OLE DB. One or more watcher nodes connect to the database to verify its availability and test its
performance. The watcher nodes can test the connection to the database or measure the time taken to perform a
particular query.
The database can reside on any computer whether it has an agent for Operations Manager installed or not, but it
must be accessible from the watcher nodes. Each watcher node must have an Operations Manager agent installed.
Scenarios
Use the OLE DB Data Source template in scenarios where applications rely on a database. You can either define a
single watcher node to ensure that the database is accessible and responds to requests, or you can define each
application server as a watcher node. The monitors that the template creates attempt to connect to the database
from each location at the defined interval, and verify that each watcher node can connect successfully. In addition
to validating the health of the database itself, any network connections and other required features between the
watcher node and the database are also validated. You can use any number of watcher nodes, but it is typically
most useful to select a sample that represents different environment or network segments.
Monitoring performed by OLE DB data source template

Depending on your selections in the OLE DB Data Source Template wizard, the monitoring performed by the
created monitors and rules can include any of the following settings.
TYPE DESCRIPTION ENABLED?
Monitors Success of the database connection or Enabled by default.

query
Time to connect to database Enabled if specified in wizard.
Time to complete query Enabled if specified in the wizard and

the query is provided.
Time to fetch results of query Enabled if specified in the wizard and

the query is provided.
Collection Rules Collection of time to connect to the Enabled by default.

database
Collection of time to complete the Always enabled if the query is provided.

query
Collection of time to fetch results of Always enabled if the query is provided.

query
All data collected by the OLE DB Data Source template is available in the OLE DB Data Source State view
located in the Synthetic Transaction folder. In this view, an object represents each of the watcher nodes. The state
of each object represents the worst state of the set of database monitors that are running on that node. If one or
more of the nodes is shown with an error while at least one other node is healthy, it could indicate a problem with
that particular node accessing the database, a network issue. If all of the nodes are unhealthy, it could indicate a
problem with the database itself.
You can view the state of the individual database monitors by opening the Operations Manager Health Explorer for
each object. You can view performance data by opening the Performance view for each of these objects.
Wizard options
When you run the OLE DB Data Source template, you have to provide values for options in the following tables.
Each table represents a single page in the wizard.
General properties
The following options are available on the General Options page of the wizard.
OPTION DESCRIPTION
Name The name used for the monitoring wizard. This name is
displayed in the Operations console in the OLE DB Data
Source State view.
Description Optional description of the monitor.
Management Pack Management pack to store the classes, monitors, and rules
that the template created. For more information about
management packs, see Selecting a Management Pack File.
Connection String
The following options are available on the Connection String page of the wizard.
OPTION DESCRIPTION
Connection string The connection string to connect to the database. A

connection string contains the properties required to locate
and connect to the database. It contains such information as
the server that is hosting the database, the database name,
and the type of authentication to perform. You can type a
connection string or build a connection string in a dialog box
by clicking Build.For more detailed information about
connection strings, see Connection String Syntax.
Query to execute Optional query after the connection to the database has been
made. If no query is provided, the monitor only attempts to
connect to the database.
Query time-out If a query is provided, this option specifies the maximum

number of seconds that the query can take before it times
out. You must set the Query Time-out value.
Query Performance
The following options are available on the Query Performance page of the wizard.
OPTION DESCRIPTION
Connection time in milliseconds If selected, the values Error Threshold and Warning
Threshold provide the number of milliseconds for the
connection when the monitor enters that state and an alert is
generated. If not selected, the connection time is not
monitored.
Query time in milliseconds If selected, the values Error Threshold and Warning
Threshold define the number of milliseconds the query can
run before the monitor enters that state and generates an
alert. If not selected, the time to run the query is not
monitored. If a query is not provided, this option is not
available.
Fetch time in milliseconds If selected, the values Error Threshold and Warning
Threshold define the number of milliseconds to retrieve the
results of the query before the monitor enters that state and
generates an alert. If not selected, the time to retrieve the
results of the query is not monitored. If a query is not
provided, this option is not available.
Watcher Nodes
The following options are available on the Watcher Nodes page of the wizard.
OPTION DESCRIPTION
Select one or more agent-managed computers Specify one or more agent-managed computers to run the
monitor. For more information, see Watcher Nodes.
Run this query every The frequency to attempt the connection to the database and
run the query, if specified.
Security considerations
The OLE DB Data Source template creates two Run As profiles. The name for each of these profiles starts with
the name that you provided in the template and is followed by "Simple Authentication Profile" and "Synthetic
Transaction Profile". If no Run As account is added to either of these profiles, the Default Action Account for each
watcher node is used to connect the database and run the query. If the Default Action Account does not have
access to the database that is being monitored, the connection fails. You can specify either integrated security or
simple authentication by creating a Run As account and adding it to the appropriate Run As profile that the OLE
DB Data Source template created.
When you run the OLE DB Data Source template, it creates two Run As profiles. The name for each starts with
the Name that you provided when you ran the template. The OLE DB Synthetic Transaction Profile is used
when you want to use integrated security for the database connection. The OLE DB Simple Authentication
Profile is used when you want to use simple authentication for the database connection.
Integrated security
Integrated security lets you connect to the database by using credentials stored in Active Directory Domain
Services. To connect the watcher nodes to the database by using integrated security, create a Run As account with
Windows as the Account type and the credentials for the appropriate user account. Then add this Run As profile
to the OLE DB Synthetic Transaction Profile.
Simple authentication
Simple authentication lets you connect to the database by using a simple name and password. For a SQL Server
database, this simple authentication could be used for SQL Server authentication. To have the watcher nodes
connect to the database by using simple authentication, create a Run As account with Simple Authentication as
the Account type and the credentials for the appropriate user account. Then add this Run As profile to the OLE
DB Simple Authentication Profile. When you specify the connection string for the template, select the Use
Simple Authentication RunAs Profile created for this OLE DB data source transaction check box. This adds
variables to the connection string for the user name and password that you specified in the Run As account.
Creating and modifying OLE DB data source templates

To run the OLE DB Data Source wizard
3. In the Authoring navigation pane, right-click Management Pack Templates , and then select Add
Monitoring Wizard.
4. On the Select Monitoring Type page, select OLE DB Data Source , and then click Next.
5. On the General Properties page, in the Name and Description boxes, type a name and an optional
description.
6. Select a management pack in which to save the monitor, or click New to create a new management pack.
For more information, see Selecting a Management Pack File.
7. Click Next.
8. In the Connection string box, type a connection string for the database, or click the Build button to be
prompted for the required information.
9. If you want the monitor to run a query, select Query to execute , and then type a query.
10. If you want to set a time-out for the query, type the number of seconds in the Query time-out box.
11. Click Test to perform a test connection by using the connection string and query that you just provided.
NOTE
The test is performed on the workstation that you are using to run the template. If this workstation cannot access
the database, this test fails. When the template is completed, the query is run from the watcher nodes that you
specify.
12. Click Next when you have validated your connection string and query.
13. Select the measurements that you want to monitor and set an error and warning threshold for each. Click
Next.
14. Select one or more Watcher Nodes to run the monitor.
15. Specify the frequency to run the monitor in the Run this query box. Click Next.
16. Review the summary of the monitor, and then click Create.
17. If a Run As account with credentials that have access to the database does not exist, create an appropriate
Run As account in the Administration workspace. For more information, see How to Create a Run As
Account.
NOTE
To create and modify a Run As account, you must have administrative credentials for the management group.
18. If the database uses integrated security, add the Run As account to the Synthetic Transaction Action
Profile for the template. If the database uses simple authentication, add the Run As account to the Simple
Authentication Profile for the template.
NOTE
To create and modify a Run As profile, you must have administrative credentials for the management group.
To modify an existing OLE DB Data Source template

1. Open the Operations console with a user account that has Author credentials.
3. In the Authoring navigation pane, expand Management Pack Templates , and then select OLE DB Data
Source.
4. In the OLE DB Data Source pane, locate the monitor to change.
5. Right-click the monitor, and then select Properties.
6. Enter the changes that you want, and then click OK.
Viewing OLE DB data source monitors and collected data

To view all OLE DB Data Source monitors
2. Open the Monitoring workspace.
3. In the Monitoring navigation pane, select Synthetic Transaction , and then click OLE DB Data Source
State.
1. In the OLE DB Data Source State pane, right-click an object. Select Open , and then click Health Explorer.
To view the performance collected for a monitor
1. In the OLE DB Data Source State pane, right-click an object. Select Open , and then click Performance.
See also
Watcher Nodes
Process Monitoring template
11 minutes to read
The Process Monitoring template lets you monitor whether a particular process is running on a computer. By using
this template, you can implement two different basic scenarios: You might require the process to be running for a
particular application and want to be warned if it is not running, or you might have to be alerted if you discover
that an unwanted process is running. In addition to monitoring whether the application is running, you can collect
performance data for the processor and memory usage of the process.
Scenarios
Use the Process Monitoring template in different scenarios where you have to monitor a running process on an
agent-managed Windows-based computer. Your application can monitor the following processes.
Critical process
A process that must be running at all times. Use the Process Monitoring template to ensure that this process is
running on the computers where it is installed, and use the Process Monitoring template to measure its
performance.
Unwanted process
A process that should not be running. This process might be a known rogue process that can cause damage, or it
might be a process that is automatically started when an error in the application occurs. The Process Monitoring
template can monitor for this process and send an alert if it is found to be running.
Long running process

A process that runs for short periods at a time. If the process is running for an excessive length of time, it might
indicate a problem. The Process Monitoring template can monitor for the length of time that this process runs
and send an alert if the running time exceeds a particular duration.
Monitoring performed by Process Monitoring Template

Depending on your selections in the Process Monitoring wizard, the monitoring performed by the created
monitors and rules can include any of the following settings.
TYPE DESCRIPTION WHEN ENABLED
Monitors Count of wanted processes running Enabled if you select Processes you
want on the Process to Monitor page
and Number of processes on the
Running Processes page.
Time that a wanted process has been Enabled if you select Processes you
running want on the Process to Monitor page
and Duration on the Running
Processes page.
Unwanted process running Enabled if Monitoring Scenario is for

unwanted processes.
Processor utilization of process Enabled if you select Processes you

want on the Process to Monitor page,
and you enable CPU alert on the
Performance Data page.
Memory usage of process Enabled if you select Processes you

and you enable memory alert on the
Collection Rules Collection of processor utilization of Enabled if you select Processes you
process want on the Process to Monitor page,
and you enable CPU alert on the
Collection of memory usage of process. Enabled if you select Processes you

and you enable memory alert on the

All data collected by the Process Monitoring template is available in the Process State view located in the
Windows Service and Process Monitoring folder. In this view, an object is listed for each agent in the group
that you selected. Even if an agent does not monitor a process, it is listed, and the monitor reflects the state for the
process that is not running.
You can view the state of the individual process monitors by opening the Operations Manager Health Explorer for
the process object. You can view performance data by opening the Performance view for the process object.
The same process objects that are listed in the Process State view are included in the Health Explorer for the
computer that hosts the process. The health state of the process monitors rolls up to the health of the computer.
Wizard options
When you run the Process Monitoring template, you have to provide values for the options in the following
tables. Each table represents a single page in the wizard.
General properties
OPTION DESCRIPTION
Name The name used for the process. This name is displayed in the
Operations console for the wizard. It does not have to be the
same name as the process.
Description Optional description of the process.

OPTION DESCRIPTION
Management Pack Management pack to store the class and monitors that the
template creates. If you create any additional monitors or
rules that are using the service as a target class, they have to
be stored in the same management pack.
For more information about management packs, see Selecting
a Management Pack File.
Process to Monitor
The following options are available on the Process to Monitor page of the wizard.
OPTION DESCRIPTION
Monitoring Scenario The kind of monitoring that is to be performed. Select

Monitor whether and how a process is running to monitor
for a wanted process and set the monitor to a critical state
when the process is not running. Select Monitor only
whether a process is running to monitor for an unwanted
process and set the monitor to a critical state when the
process is running.
Process name The full name of the process. This is the name of the process
as it appears in Task Manager. It should not include the path
to the actual executable file. You can either type the name or
click the ellipse ( … ) button to locate the file name.
Targeted group The process is monitored on all computers that are included in
the specified group.
Running Processes
The following options are available on the Running Processes page of the wizard.
OPTION DESCRIPTION
Generate an alert of the number of processes is below the If selected, the monitor is set to a critical state, and an alert is
minimum value or above the maximum value for longer than created if the number of instances of the specified process is
the specified duration less than the specified minimum or greater than the specified
maximum for a longer period than the specified duration.To
ensure that at least one instance of the process is running, set
both the minimum and maximum to 1.
Minimum number of processes The minimum number of processes that should be running.
Maximum number of processes The maximum number of processes that should be running.
Duration Specifies how long the number of running processes must

exceed the specified range before the monitor is set to a
critical state. Do not set this value to less than 1 minute.
Generate an alert if the process runs longer than the specified If selected, the monitor is set to a critical state, and an alert is
duration created if one instance of the process runs for longer than the
specified duration.
Performance Data
The following options are available on the Performance Data page of the wizard.
OPTION DESCRIPTION
Generate an alert if CPU usage exceeds the specified threshold Specifies if CPU usage of the process should be monitored. A
monitor will be created to set an error state on the object and
generate an alert when the specified threshold is exceeded. A
rule is created to collect CPU usage for analysis and reporting.
CPU Usage (percentage) If CPU utilization is monitored, this option sets the threshold.
If the percentage of total CPU usage exceeds the threshold,
the object is set to an error state, and an alert is generated.
Generate an alert if memory usage exceeds the specified Specifies if memory usage of the process should be
threshold monitored. A monitor will be created to set an error state on
the object, and generate an alert when the specified threshold
is exceeded. A rule is created to collect CPU usage for analysis
and reporting.
Memory Usage (MB) If memory usage is monitored, this option sets the threshold.
If the disk space in megabytes (MB) of total CPU usage
exceeds the threshold, the object is set to an error state, and
an alert is generated.
Number of samples If CPU usage or memory is monitored, this option specifies

the number of consecutive performance samples that must be
exceeded before the object is set to an error state, and an
alert is generated. Specifying a number greater than 1 for this
option limits the noise from monitoring by ensuring that an
alert is not generated when the service only briefly exceeds
the threshold. The larger the value that you set, the longer the
period of time before you are alerted to a problem. A typical
value is 2 or 3.
Sampling interval If CPU usage or memory is monitored, specify the length of

time between performance samples.A smaller value for this
option reduces the time for detecting a problem but increases
overhead on the agent and the amount of data collected for
reporting. A typical value is between 5 and 15 minutes.
Additional monitoring
In addition to performing the specified monitoring, the Process Monitoring template creates a targeted class that
you can use for additional monitors and workflows. Any monitor or rule using this class as a target will run on any
agent-managed computer in the group specified in the template. If it creates Windows events that indicate an error,
for example, you could create a monitor or rule that detects the particular event and uses the process' class as a
target.
Creating and modifying Process Monitor Templates

To run the Process Monitoring wizard
1. Determine the target group for the monitor by using the following logic:
If you want to discover the process on all Windows-based computers in the management group, you
do not have to create a group. You can use the existing group All Windows Computers.
If you only want the process to be discovered on a certain group of computers, either ensure that an
appropriate group exists or create a new group by using the procedure in How to Create Groups in
Operations Manager.
If the process that you are monitoring is in a cluster, create a group with objects of the class Virtual
Server representing the nodes of the cluster that contain the service.
2. Start the Add Monitoring wizard.
3. On the Select Monitoring Type page, select Process Monitoring , and then click Next.
description. The name is used to describe the process in the Operations console. It is not the actual name of
the process.
6. Click Next.
7. On the Process to Monitor page, do the following:
Select whether you want to monitor a wanted or an unwanted process.
In the Process name box, type the complete name of the process to monitor. For example,
notepad.exe. You can also click the ellipse (… ) button and locate the executable file.
Click the ellipse (… ) button to the right of the Targeted Group box, and then select the group from the
first step of this procedure.
Click Next.
8. If you selected the option for a wanted process, on the Running Processes page, do the following:
If you want to monitor whether the process is running, do the following:
Select the option to Generate an alert of the number of processes is below the minimum value or
above the maximum value for longer than the specified duration.
In the Minimum number of processes box, enter the minimum number of processes that should be
running. For a single instance of the process, this is typically 1.
In the Maximum number of processes box, enter the maximum number of instances of the process
that should be running.
In the Duration box, enter the length of time that running processes must exceed the specified range
before the monitor is set to a critical state. This value should not be set to less than 1 minute. Note that
the process could stop and restart within this time window with no error detected.
If you want to monitor for the length that a process runs, do the following:
Select the option to Generate an alert if the process runs longer than the specified duration.
In the Duration box, enter the maximum length of time that you want the process to run before the
monitor is set to a critical state. This value should not be set to less than 1 minute.
9. If you selected the option for a wanted process, on the Performance Data page, select the performance
counters and thresholds that you want to monitor. For more detailed information, see the Wizard Options
section.
NOTE
This page is disabled if you selected the option for an unwanted process.
10. If you have selected performance counters, specify the monitoring interval.
11. Click Next.
To modify an existing Process Monitoring template
3. In the Authoring navigation pane, expand Management Pack Templates , and then click Process
Monitoring.
4. In the Process Monitoring pane, locate the monitor to change.
Viewing Process Monitoring Monitors and Collected Data

To view all Process Monitoring monitors
3. In the Monitoring navigation pane, select Windows Service and Process Monitoring , and then click
Process State.
1. In the Process State pane, right-click an object. Select Open , and then click Health Explorer.
To view the performance collected for a process
1. In the Process State pane, right-click an object. Select Open , and then click Performance.
See also
Watcher Nodes
TCP port template
5 minutes to read
The TCP Port template lets you monitor the availability of an application that is accessible over TCP.
The application that is being tested can reside on any computer whether an agent for Operations Manager
installed or not. Each watcher node must have an Operations Manager agent installed.
Scenarios
Use the TCP Port template in scenarios where applications rely on a service accessible over TCP. You can define
each client as a watcher node. The monitors created by the template attempt to connect to the application from
each client at the defined interval. The monitors verify that each client can connect successfully. In addition to
validating the availability of the application itself, any network connections and other required features between the
watcher node and the application are also validated.
Monitoring performed by the TCP port template

The monitoring performed by the monitors and rules created by the TCP Port template can include any of the
following settings.
Monitors Target host reachable Enabled
Connection accepted Enabled
Connection timeout Enabled
DNS resolution Enabled
Collection Rules Connection time Enabled

All data collected by the TCP Port template is available in the TCP Port Checks State view located in the
Synthetic Transaction folder. In this view, an object represents each of the watcher nodes. The state of each object
represents the worst state of the set of TCP Port monitors running on that node. If one or more of the nodes is
shown with an error while at least one other node is healthy, it could indicate a problem with that particular node
accessing the specified computer, for example, a network issue. If all of the nodes are unhealthy, it could indicate a
problem with the application itself, either the computer being offline or the application not responding on the
specified port.
You can view the state of the individual TCP Port monitors by opening the Operations Manager Health Explorer for
each object. You can view performance data by opening the Performance view for each of these objects.
Wizard options
When you run the TCP Port template, you have to provide values for options in the following tables. Each table
represents a single page in the wizard.
General Options
OPTION DESCRIPTION
Name The name used for the template. This name is displayed in the
Operations console.
Description Optional description of the service.
template created. If you create any additional monitors or
rules by using the service as a target class, you must store
them in the same management pack.For more information
about management packs, see Selecting a Management Pack
File.
Target and Port

The following options are available on the Target and Port page of the wizard.
OPTION DESCRIPTION
Computer or device name The name of the computer or device to connect to. This can
be a name or an IP address. It must be resolved by and
accessible to each watcher node that you specify.
Port The number of the port on which the application is listening.
Watcher Nodes
The following options are available on the Watcher Nodes page of the wizard.
OPTION DESCRIPTION
Select one or more agent managed computers Specify one or more computers to run the monitors and rules.
For more information, see Watcher Nodes.
Run this query every The frequency to attempt the connection to the specified
computer and port.
Creating and modifying TCP port templates

To run the TCP Port data source wizard
3. In the Authoring navigation pane, right-click Management Pack Templates , and then select Add
Monitoring Wizard.
4. On the Select Monitoring Type page, select TCP Port , and then click Next.
description.
7. Click Next.
8. In the Computer or device name box, type the name or IP address of the computer or device to connect
to.
9. In the Port box, type the port number on which the application is listening.
10. Click Test to perform a test connection by using the connection string and query that you just provided.
NOTE
The test is performed on the workstation that you are using to run the template. If this workstation cannot access
the computer or device, this test fails. When the template is completed, the test is run from the watcher nodes that
you specify.
11. Click Next when you have validated your connection.

12. Select one or more Watcher Nodes to run the monitor.
13. Specify the frequency to run the monitor in the Run this query box. Click Next.
To modify an existing TPC Port template
3. In the Authoring navigation pane, expand Management Pack Templates , and then select TCP Port.
4. In the TCP Port pane, locate the template to change.
Viewing TCP port monitors and collected data

To view all TCP port monitors
3. In the Monitoring navigation pane, select Synthetic Transaction , and then click TCP Port Checks State.
1. In the TCP Port Checks State pane, right-click an object. Select Open , and then click Health Explorer.
To view the performance collected for a monitor
1. In the TCP Port Checks State pane, right-click an object. Select Open , and then click Performance.
2. In the Legend pane, select the counters you want to view.
See also
Watcher Nodes
UNIX or Linux log file
4 minutes to read
The UNIX/Linux Log File Monitoring template lets you create an alert when a particular text is detected in a log
file.
Scenarios
Use the UNIX/Linux Log File Monitoring template for any application that writes to a log file when a particular
error occurs. You provide the path to the log file and the text that indicates an error, and an alert is created for you
anytime that text is detected.
Monitoring Performed by the UNIX/Linux Log File Monitoring

Template
The following table shows the monitoring activity that the UNIX/Linux Log FileMonitoring template performs.
Rule Creates an alert when a specified text is Enabled

detected.
Wizard options
When you run the UNIX/Linux Log File Monitoring template, you have to provide values for the options in the
following tables. Each table represents a single page in the wizard.
General options
OPTION DESCRIPTION
Name The name used for the template. This name is displayed in the
Operations console.
Description Optional description of the template.
Management Pack Management pack file to store the rule that the template
creates. For more information about management packs, see
Selecting a Management Pack File.
Log File Details

The following options are available on the Log File Details page of the wizard.
OPTION DESCRIPTION
OPTION DESCRIPTION
Computer If you want to monitor a single computer, enter the name of

the agent-managed UNIX or Linux computer with the log file
to monitor. Click the Select a Computer button to select one
of the agent-managed UNIX or Linux computers that are
installed in your management group.
Computer group name If you are going to monitor a group of computers, enter the
name of the group of agent-managed UNIX or Linux
computers with the log file to monitor. Click the Computer
Group button to select from the group in your management
group.
Log file path Complete path and name of the log file.
Expression Regular expression of the text to detect. If you want to detect

a simple string of characters, type the string of characters.
Creating and modifying UNIX/Linux log file templates

To create a UNIX/Linux log file template
1. If you want to monitor the log file on a group of computers, determine the target group for the monitor by
using the following logic:
If you want to monitor the log file on all UNIX and Linux computers in the management group, you
do not have to create a group. You can use the existing group UNIX/Linux Computer Group.
If you only want the log file to be monitored on a certain group of computers, either ensure that an
appropriate group exists or create a new computer group by using the procedure in How to Create
Groups in Operations Manager.
3. On the Select Monitoring Type page, select UNIX/Linux Log File Monitoring , and then click Next.
4. On the General Properties page, in the Name and Description boxes, type a name and description for
this new template.
5. Select a management pack in which to save the template or click New to create a new management pack.
6. If you want to monitor the log file on a single computer, do the following:
Click the Select a Computer button next to the Computer name box.
Select the computer to monitor, and then click OK.
7. If you want to monitor the log file on a group of computers, do the following:
Click the Select a Group button next to the Computer group name box.
Select the computer to monitor, and then click OK.
8. In the Log file path box, type the path and name of the log file to monitor.
9. In the Expression box, type the text to watch for, such as error. You can type a regular expression for more
complex logic.
10. Optionally, click Test to open a new dialog to test Regular expression matching against sample text that you
input.
11. Select a Run As Profile to use. The account associated with the target computer in this profile will be used
to read the log file.
12. Select an Alert Severity.
13. Click Next.
14. Verify the summary information for the template, and then click Create.
To modify an existing UNIX/Linux Log File template
3. In the Authoring navigation pane, expand Management Pack Templates , and then select UNIX/Linux Log
File.
4. In the UNIX/Linux Log File Monitoring pane, locate the template to change.
5. Right-click the template, and then select Properties.
View UNIX/Linux log file data

There is no monitor or collected data for the UNIX/Linux Log File Monitoring template. If a match is found in
the specified log file, an alert is generated. You can view this alert in the Active Alerts view with the other alerts.
See also
Watcher Nodes
UNIX or Linux process
6 minutes to read
The UNIX/Linux Process Monitoring template lets you monitor that a particular process installed on an UNIX or
Linux computer runs.
Scenarios
The UNIX/Linux Process Monitoring template is useful for monitoring any application as monitoring processes
is typically critical to the health of the application.
Monitoring performed by the UNIX/Linux process monitoring template

The following table shows the monitoring activity that the UNIX/Linux Process Monitoring template performs.
Monitors Process Count is Outside of Range Always enabled.
Wizard options
When you run the UNIX/Linux Process Monitoring template, you have to provide values for options in the
following tables. Each table represents a single page in the wizard.
General Options
OPTION DESCRIPTION
Name The name used for the template. This is the name that is
displayed in the Operations console.
Description Optional description of the template.
rules that are using the process as a targeted process, you
must store them in the same management pack.For more
information about management packs, see Selecting a
Process Monitoring Details

The following options are available on the Process Monitoring Details page of the wizard.
OPTION DESCRIPTION
OPTION DESCRIPTION
Process name The name of the process. You can use the Select a Process
button to connect to a monitored UNIX/Linux computer and
list current running processes in order to select a process by
name. If you wish to target the monitor to only a single
computer, you must use the Select a Process button to
select a computer and process.
Computer Group The name of the group of UNIX or Linux computers for the
process to monitor. Click the Select a group button to select
a group that is installed in your management group. If you
have used the Select a Process button to select a running
process from a computer, the monitor will be targeted to that
computer. After using the Select a Process button to select a
process, you can use the Select a Group button to target a
group with the monitor for the selected process.
Alert Severity The severity for the alert: Error, Warning, or Information.
Regular Expression to filter process arguments An optional Regular expression to use in filtering processes by
arguments. If this option is used, processes that match the
provided process name will be additionally filtered by their
arguments. Only processes with arguments that match the
Regular expression will be evaluated by the monitor. This is
useful to identify a process for a specific application when
other applications on the system may use a process with the
same name. The Regular expression is evaluated against a
concatenated list of process arguments.
Expression Matching Results If you use the Select a Process button to connect to a
monitored computer and select a process by name, the list of
all processes with the selected process name for that
computer are shown in this field. When you provide a
Regular expression to filter process arguments the
processes listed in this field are filtered so that you can
preview the filtering by argument.
Process Template Settings

The following options are available on the Process Template Settings page of the wizard.
OPTION DESCRIPTION
Minimum number of instances The minimum number of running instances of the monitored
process. To alert if no instances of the process are running,
check the box Generate an alert when the number of
process instances is less than the specified value , and
input a value of 1. The number of process instances is
calculated after filtering by process name and the optional
Regular expression to filter process arguments. If the number
of running instances is less than the provided value, an alert
will be generated.
OPTION DESCRIPTION
Maximum number of instances The maximum number of running instances of the monitored
process. To alert if more than a specific number of instances of
the process are running, check the box Generate an alert
when the number of process instances is greater than the
specified value , and input the maximum threshold value.
The number of process instances is calculated after filtering by
process name and the optional Regular expression to filter
process arguments. If the number of running instances is
greater than the provided value, an alert will be generated.
In addition to performing the specified monitoring, the UNIX/Linux Process Monitoring template creates a
target class that you can use for additional monitors and rules. Any monitor or rule that uses this class as a target
runs on any agent where the process is installed.
Creating and modifying UNIX/Linux process monitoring templates

To create a UNIX/Linux process monitoring template
1. If you want to monitor a process on a group of computers, determine the targeted group for the monitor by
using the following logic:
If you want to discover the process on all UNIX and Linux computers in the management group, you
do not have to create a group. You can use the existing group UNIX/Linux Computer Group.
If you only want the process to be discovered on a certain group of computers, then either ensure
that an appropriate group exists or create a one by using the procedure in How to Create Groups in
Operations Manager.
3. On the Select Monitoring Type page, select UNIX/Linux Process Monitoring , and then click Next.
4. On the General Properties page, in the Name and Description boxes, type a name and optional
description for this new template.
5. Select a management pack in which to save the monitor or click New to create a new management pack.
6. Click Next.
7. Click the Select a Process button.
8. Click the Browse button and select a computer that has the process installed, and then click OK.
9. In the Processes box, select the process to monitor.
10. Select an Alert Severity.
11. Optionally, provide a Regular expression to filter the matched process list by process arguments, in the field
Regular expression to filter process arguments.
12. If you want to monitor the process on a group of computers, do the following:
Click the Select a Group button.
Select a group that contains the computers with the process, and then click OK.
13. Click Next.
14. Check the appropriate boxes for Generate an alert when the number of process instances is less than
the specified value and Generate an alert when the number of process instances is greater than the
specified value.
15. Provide values for Minimum number of instances and Maximum number of instances , if appropriate.
16. Click Next.
17. Click Create.
To modify an existing UNIX/Linux process monitoring template
3. In the Authoring navigation pane, expand Management Pack Templates , and then select UNIX/Linux
Process Monitoring.
4. In the UNIX/Linux Process Monitoring pane, locate the template to change.
5. Right-click the template, and then select Properties.
Viewing UNIX/Linux process monitors and collected data

1. Select the UNIX/Linux Computers view.
2. In the UNIX/Linux Computers pane, right-click an object, select Open , and then click Health Explorer.
3. Expand the Availability node, and then click the Application/Service Availability Rollup node to view the
individual process monitor.
See also
14 minutes to read
The Web Application Availability Monitoring template lets you create availability monitoring tests for one or
more web application URLs and run these monitoring tests from internal locations. In addition to state and alert
views, you can display the status of these tests in a provided map dashboard and a details dashboard.
Scenarios
Use the Web Application Availability Monitoring template in scenarios where you have to monitor web-based
applications from different locations to see if they are working according to certain requirements, which you can
specify.
Internal locations
You might have web applications that must be available at all times at internal locations. Use the Web
Application Availability Monitoring template to see which web applications are available from which internal
locations.
Monitoring Performed by the Web Application Availability Monitoring

Template
By default, the Web Application Availability Monitoring template configures the following monitoring by
default. You can modify the monitor in the Change Configuration page of the Web Application Availability
Monitoring template.
Web Application Monitor - The monitor is enabled by default.
- Test Frequency: 10 minutes
- Performance data collection interval: 1 every 10 minutes
- Test time-out: 45 seconds
- HTTP status code: 400 (An alert will be generated if the

HTTP status code is 400 or greater.)
- Number of consecutive times a criteria should fail before an

alert is generated: 1
- Generate alerts from each test: enabled
- Allow redirects: enabled
- HTTP version: HTTP/1.1
- HTTP method: GET

- HTTP headers: accept "/"
- HTTP headers: accept language of your product
- HTTP headers: accept encoding GZIP
Performance Data Collection - Transaction response time: enabled
- Response time: enabled
- TCP connect time: enabled
- Time to first byte: enabled
- Time to last byte: enabled
- DNS resolution time: enabled
- Content size: enabled
- Content time: enabled
- Download time: enabled

All data collected by the Web Application Availability Monitoring template appears in the Web Application
Availability Monitoring folder in the Application Monitoring folder in the Monitoring navigation pane. The
Application Availability Monitoring folder contains the default views and subfolders that provide Test State,
Web Application Status, and alerts related to the tests being monitored. By using the Test State view, you can see
the test state of the individual tests. The state of each object matches the state of the targeted object that has the
worst health state so that you see the worst state of the monitors that are running. If one or more of the tests are
shown with an error while at least one other test is healthy, it could indicate a problem for that particular test
location. If all of the components are unhealthy, it could indicate a problem with the web application itself.
Web Application Availability Monitoring folder
To view the state of the individual monitors, open the Health Explorer for each test.
Wizard options
When you run the Web Application Availability Monitoring template, you have to provide values for options
as listed in the following tables. Each table represents a single page in the wizard.
General
The following options are available on the General page of the wizard.
OPTION DESCRIPTION
Name Enter the friendly name used for the template and test group
that you are creating. This name is displayed in the Operations
Console in the Web Application status view and is used for the
folder under the Web Application Availability Monitoring
folder.
Note: After you have given the template a name and saved
the template, this name cannot be edited without deleting
and re-creating the template.
Description Describe the template. (Optional)
Select destination management pack Select the management pack to store the views and
configuration created by the template. Use the same name for
your new management pack as the test group so you can
easily pair the two names. You can use an existing
management pack or create a new management pack. For
more information about management packs, see Selecting a
What to monitor
Add URLs to the list by typing, pasting, or importing a file into the table, including the appropriate protocol (http://
or https://). You can paste entire rows as pairs of comma-separated values (CSV ) that are in the format 'Name,
URL', or you can paste just the list of URLs.
The following options are available on the What to Monitor page of the wizard.
OPTION DESCRIPTION
Name Name of the website you want to monitor.
URL URL of the website you want to monitor in the format:

http://www.website.com
Add Add URLs to monitor from an external file. You can paste a list
of URLs or rows of a spreadsheet as pairs of comma-
separated values that are in the format: Name, URL
Where to Monitor From
Select the internal locations from which you want the URLs to be monitored.
The following options are available on the Where to Monitor From page of the wizard.
OPTION DESCRIPTION
Internal locations The internal locations you are configuring to monitor from.
Add/Remove Add or remove internal locations you want to monitor from.
Select Internal Locations

Select the internal locations from which you want to monitor the URLs you specified on the What to Monitor
page. Click Add to add internal locations and then search for and select the internal locations that you want to
monitor from.
The following options are available on the Select internal locations page of the wizard.
OPTION DESCRIPTION
Search for Option showing the kind of locations you search will look for.
You can choose agents or pools.
Filter by part of name Filter your search of internal locations.
Search Search for locations that are available to monitor from.

Available locations are displayed in the in the Location area.
Where to monitor: Name List of the internal locations from which you can select to
monitor from.
Where to monitor: Location List of the locations from which you can select to monitor
from.
Add Add the internal locations you have selected to the Selected
locations area. These are the locations you are configuring the
wizard to monitor from.
Selected locations: Name These are the internal locations you have chosen to monitor
from.
OPTION DESCRIPTION
Selected locations: Location List of the locations you have chosen to monitor from.
View and validate tests
This is a summary of all tests that will be run. Select an internal location and click Run Test to validate the test
configuration. Select Change configuration to change the default settings for all tests in this template.
The following options are available on the View and Validate Tests page of the wizard.
OPTION DESCRIPTION
Look for Search for and returns results for items in the list of test
names, URLs, Locations, and Agent/Pools. Use this to find
specific tests or sets of tests that you want to validate.
Test Name Name of a test.
URL URL for a specific test.
Agent/Pool The Agent or Pool location for your internal URL tests.
Run Test Run a validation test for internal tests that are selected.
OPTION DESCRIPTION
Change Configuration Open the Change Configuration page where you can
change the settings for all tests in the template you are
authoring.
Test results: Summary tab
The following options are available on the Test Results Summary tab of the wizard.
OPTION DESCRIPTION
Summary tab Confirms if the test request was correctly processed and
shows the URL and Location used in the test. Additionally. The
specific tests and results are shown: Status code, DNS
resolution time, and Total response time.
Test results: Details tab

The following options are available on the Test Results Details tab of the wizard.
OPTION DESCRIPTION
Details tab: URL See detailed information about the test. Displays which URL
was tested.
Details tab: Result Displays whether the test request was processed successfully
or not.
Details tab: DNS resolution time (milliseconds) Displays the DNS resolution time which checks that website
performs as you expected it to. What's the IP address of the
URL you are. Time it takes for DNS to get the IP address for
the website.
Details tab: Total response time (milliseconds) Displays the Total response time from same as transaction
time performance counter.
Details tab: HTTP status code Displays the HTTP status code when you ping a website, you
get a status code.
Details tab: Response body size (bytes) Displays the Response body size of the HTTP response
information.
Details tab: Server certificate expiration (days) Displays the certificate expiration of the date when the site
expired. Website can have expired certificates.
Test results: HTTP request tab

The following options are available on the Test Results HTTP Request tab of the wizard.
OPTION DESCRIPTION
HTTP Request tab Displays details about the HTTP request of the test what is
sent to the website.
Test results: HTTP response tab

The following options are available on the Test Results HTTP Response tab of the wizard.
OPTION DESCRIPTION
What is shown on this tab Displays details about the HTTP Response for the test comes
back from website.
Test results: Raw data tab

The following options are available on the Test Results Raw Data tab of the wizard.
OPTION DESCRIPTION
What is shown on this tab Displays all of the data unformatted that we get back from the
site. If there's a problem with the website, this information
might help you figure out what might be wrong with the
website.
Change configuration for test set

The following options are available on the Change Configuration for Test Set page of the wizard.
IMPORTANT
Settings on this page apply to all tests in the template.
OPTION DESCRIPTION
Test Frequency/Performance Data Collection Interval: Test Enter the how often you want to run each test.
frequency
Test Frequency/Performance Data Collection Interval: Enter the frequency with which you want to collect
Performance data collection interval performance data. This specifies whether you want to collect
performance data every interval or not. For example, if the
interval is 10 minutes and the collection interval is set to 2,
this means that performance data will be collected every other
interval, or once every 20 minutes.
Test Frequency/Performance Data Collection Interval: Test Enter how long you want the test to keep a request active
time-out until the test times out and cancels.
OPTION DESCRIPTION
Alerts: Criteria for error health state: Transaction response Specify if transaction response time is a factor that should or
time should not generate an error health state. If it is specified to
generate an error health state, set the threshold in seconds
that a transaction must exceed before it generates an error
health state.
Alerts: Criteria for error health state: Request (Base page): Specify if the HTTP status code is a factor that should or
HTTP status code should not generate an error health state. If it is specified to
generate an error health state, set the HTTP status code to
the number for which you want it to generate an error health
state.
Alerts: Criteria for error health state: Request (Base page): Specify if any content matches should or should not generate
Content match an error health state. If it is specified to generate an error
health state, specify the content you wish to match.
Alerts: Criteria for error health state: Request (Base page): Specify if the presence of redirects should or should not
Check for redirects generate an error health state.
Alerts: Criteria for warning health state: Transaction response Specify if the transaction response time is a factor that should
time or should not generate a warning health state. If it is specified
to generate warning health state, set the threshold in seconds
that a transaction must exceed before it generates a warning
health state.
Alerts: Criteria for warning health state: Request (Base page): Specify if the HTTP status code should or should not generate
HTTP status code a warning health state. If it is specified to generate warning
health state, set the HTTP status code to the number for
which you want it to generate a warning health state.
Alerts: Criteria for warning health state: Request (Base page): Specify if any content matches should or should not generate
Content match a warning health state. If it is specified to generate a warning
health state, specify the content you wish to match.
Alerts: Criteria for warning health state: Request (Base page): Specify if the presence of redirects should or should not
check for redirects generate a warning health state.
Alerts: Number of consecutive time a criteria should fail before Specify the number of consecutive times selected criteria in
an alert is generated the Alerts section list should fail before an alert is generated.
Alerts: Generate alerts from each test Select to receive an alert for each URL test for an application.
Alerts: Generate a single summary alert Select to receive a summary alert for an application, rather
than choosing to receive an alert for each URL test for an
application. This is helpful if you are monitoring a vertical
website or an application because this will reduce the number
of alerts you receive and keep the focus of your alerts the
overall state of the application.
You can further reduce alerts by raising the threshold for how
many failures you want to have before receiving an alert.
Together, these two approaches will focus your alerts on what
is most important to you: How well the application is running,
given the performance you require.
Performance Collection: Transaction response time Cumulative response time: DNS_RESOLUTION_TIME +

TCP_CONNECT_TIME + TIME_TO_LAST_BYTE
OPTION DESCRIPTION
Performance Collection: Request (Base page): Response time Processing time for the request, such as opening a browser
and waiting for all resources to load.
Performance Collection: Request (Base page): TCP connect Time taken to establish a TCP connection to the target server
time and receive the initial greeting from the service.
Performance Collection: Request (Base page): Time to first byte Time take since the TCP connection is established till the first
byte of response is received.
Performance Collection: Request (Base page): Time to last byte Time from when TCP connection is established until the last
byte of response is completely received.
Performance Collection: Request (Base page): DNS resolution Time taken to resolve the URL domain name to the IP
time address.
Performance Collection: Request (Base page): Content size Size of the response body received.
Performance Collection: Request (Base page): Content time Base page download time (base page only).
Performance Collection: Request (Base page): Download time Processing time for the request, such as opening a browser
and waiting for all resources to load.
General Configuration: Evaluate resource health Specify whether to evaluate the health of the entire resource.
General Configuration: Allow redirects Specify if redirects can be allowed and not cause an error or
warning state.
General Configuration: HTTP version Specify the HTTP version being tested.
General Configuration: HTTP method Specify the HTTP method.
General Configuration: Request body Represents the body of the request.
HTTP Headers: Headers column Specify which headers can be accepted.
HTTP Headers: Value column Specify the value in the header that can be accepted.
HTTP Headers: Add Add header names and values that can be accepted.
HTTP Headers: Edit Opens the HTTP Header Properties page where you can
change the Name or Value of the selected HTTP headers.
HTTP Headers: Remove Removes selected header from the accepted list.
Proxy Server: Use a proxy server Specify whether to use a proxy server.
Proxy Server: Address Specify the address of the proxy server.
Proxy Server: Port number Specify the port number.
Summary
The Summary page of the wizard lists the settings you have configured for the Web Application Availability
Monitoring template. If you want to change any of these settings, click Previous or the template page until you
reach the page with the settings that you want to change.
Creating and modifying web application availability monitoring

templates
For the procedure to run the .NET Application Performance Monitoring wizard, see How to Configure Web
Application Availability Monitoring
To modify an existing Web application availability monitoring template
1. Open the Operations console with a user account that has Author credentials in the management group.
2. Click the Authoring workspace.
3. In the Authoring navigation pane, expand Management Pack Templates , and then select Web Application
Availability Monitoring.
4. In the Web Application Availability Monitoring pane, locate the template you want to change.
5. Right-click the test group that you want to modify, and then select Properties.
6. Using the tabs to navigate the pages of settings, make the desired changes, such as reconfiguring criteria for
tests in this group, and then click OK.
Viewing web application availability monitoring monitors and collected

data
After you configure monitoring for an application, these three views will help you get started with the monitoring
experience.
To view all web application availability monitoring monitored applications
3. In the Monitoring navigation pane, expand Application Monitoring , expand Web Application
Availability Monitoring , and then click Web Application Status.
Availability Monitoring , and then click Test State.
4. In the Test State view, right-click an object. Select Open , and then click Health Explorer.
To view the performance collected for an application component
Availability Monitoring , and then click Web Application Status.
4. In the Test State pane, right-click an object. Select Open , and then click Performance View.
See also
How to Configure Web Application Availability Monitoring
Monitoring Web Application Availability Tests and Alerts
Dashboard Views for Web Application Availability Monitoring
Reporting for Web Application Availability Monitoring
2 minutes to read
The Web Application Transaction Monitoring template lets you test a website or web-based application by sending
requests over HTTP, validating their response, and measuring their performance. This can be a simple test to
determine if the website is responding, or it can be a complex set of requests to simulate a user who is performing
such actions as logging on to the site and browsing through a set of pages.
The HTTP requests are sent from one or more Watcher Nodes. The website that is being monitored can reside on
any computer whether it has an agent for Operations Manager installed. It can be an external website, but it must
be accessible from the watcher nodes. Each watcher node must have an Operations Manager agent installed.
Scenarios
Use the Web Application Transition Monitoring template for monitoring the availability and performance of
any website or web-based application to test both general availability and functionality. For internal websites, you
can use watcher nodes in different network segments to ensure that the site is available to each segment.
In addition to general availability, you can check the functionality of the website by testing different pages and
features. For example, you could check a logon process by performing a test logon with a test user account every
few minutes. You could test the functionality of a search page by performing a sample search after the test user
account is logged on. You can then analyze the HTML that is returned from these pages to verify whether the page
functioned as expected. In addition to testing this functionality, you can analyze the time it takes to fill the request
to measure the performance.
Web Application Transaction Monitoring template topics

The Web Application Transaction Monitoring is more complex than the other management pack templates
and supports a variety of monitoring scenarios. The following topics provide details on the different tools and
procedures that you can use for different scenarios.
How to Create a Single URL Web Application Monitor
This procedure explains how to run the Web Application Transaction Monitoring wizard to create a simple
Web Application Transaction Monitoring template that monitors a single URL. You can either use this
simple monitor with no modification or insert additional requests once it is completed.
How to Capture Web Application Recording
This procedure explains how to use the Web Recorder to record a browser session with multiple requests.
You can either use this session with no modification or edit the application and request settings once it is
completed.
How to Edit Settings or Requests in a Web Application
This topic includes procedures for editing a web application and its contained requests and for creating
additional requests in an existing template.
How to Replace Parameters in a URL Request
This topic includes a method to retrieve information from one request and use it in a subsequent request.
How to replace parameters in a URL request
7 minutes to read
When you capture a web application by using the Web Application Editor, it can include unique information in one
or more requests that changes each time you connect to the application. This information is typically included in
the response to a request and then used by one or more subsequent requests.
For example, an application might create a unique session ID when a user logs on. This session ID must be
included in each request after the logon process. Without the correct session ID, each of these requests fails.
Because you do not know what this value is until the first request is run, it cannot be explicitly included in the
configuration of the request. If you create the web application by recording a browser session, the session ID is
collected in the URL of each request. However, when the application is run, the requests fail because the session ID
will have a value that is different from the recorded session ID.
To configure such an application, you can extract a context parameter from the body of the response of one request
and use the value of that parameter in one or more subsequent requests. You then replace the explicit value in
subsequent requests with a variable that represents the parameter. Each time the synthetic transaction is run, the
parameter is populated in the request where it is defined. When the variable is used in the subsequent requests, it
is replaced with the collected value before the request is sent to the application.
A single application can use any number of context parameters. Any number of requests can use a single
parameter but must be run after the request where the parameter is defined.
Session ID example
Consider the example where an application creates a session ID when a user logs on. This session ID is required in
each request after the logon page. To implement this scenario, you have to capture the session ID when it is first
generated, and then use that value in each subsequent request.
You start by using the process described in How to Capture Web Application Recording to capture the logon and
subsequent actions. The recorded session for logging on to the application and performing some actions might
look similar to the following example.
http://www.myapp.com/home.aspx
http://www.myapp.com/search.aspx?query=testing&sessionid=32793279321721
http://www.myapp.com/results.aspx?sessionid=32793279321721
http://www.myapp.com/submit.aspx?sessionid=32793279321721
In this request sequence, the session ID is created by the first request and used in the second, third, and fourth
requests. When you run this monitor, it fails because the first request generates a new session ID that could not
match the session ID that was used when the session was captured.
To configure this request sequence with parameter replacement, you have to create an extraction rule on the first
request to create a context parameter for the session ID. The extraction rule inspects the body of the request to
locate the value for the sessionid variable. You would then modify the subsequent requests to use this parameter
instead of the value for the session ID.
The modified requests look similar to the following example.
http://www.myapp.com/home.aspx
http://www.myapp.com/search.aspx?query=testing&sessionid=$ParametersContext/sessionID$
http://www.myapp.com/results.aspx?sessionid=$ParametersContext/sessionID$
http://www.myapp.com/submit.aspx?sessionid=$ParametersContext/sessionID$
Creating an extraction rule

Context parameters are collected by an extraction rule, and each extraction rule collects a single context parameter.
You create an extraction rule in the Properties dialog box of the request that initially generates the required data.
To identify the value to extract, you must view the body of the response returned from the particular request. You
can either view the source of the page returned in the browser or use a tool that lets you inspect the details of
HTTP responses. You cannot view the text by using the Web Application Editor.
When you have identified the request that contains the information you have to extract, you view the Extraction
Rules tab in the properties of that request and create one or more extraction rules. The details of each extraction
rule are shown in the following table.
OPTION DESCRIPTION
Context parameter name Enter the name to give the context parameter.
Starts with Enter the text in the body of the response that identifies the
start of the parameter value. You should specify enough
characters to ensure that the string is unique. The value for
the parameter starts immediately after the last specified
character.
Ends with Enter the text in the body of the response that identifies the
end of the parameter value. The value for the parameter ends
immediately before the first specified character.
Index If the text in the Starts with box occurs more than one time,
this value indicates which value to use. If the text only appears
one time, or the first occurrence of it shows the text to extract,
the value should be 0. If the second value should be extracted,
the value should be 1, and so on.
Ignore case during search for matching text Specifies whether to ignore the case of the characters being
searched by the Starts with and Ends with boxes.
Perform URI encoding of extracted strings Specifies whether to encode the extracted string after it is
collected.
Inserting a parameter into a request

You use a parameter in a request by replacing the explicit value with a variable representing the parameter. The
format of the variable is $ParametersContext/<ContextParameterName>$. When the request is run, the variable is
replaced with the data extracted by the parameter.
You can insert the variable into the request by using one of the two following methods:
In the Request Properties dialog box, click the General tab, and then click Request URL to modify the
request URL for the request.
In the Request Properties dialog box, click the General tab, and then click the Insert parameter button. Use
the Insert Parameter dialog box for the request. This is accessed from the Insert parameter button on the
General tab in the Request Properties dialog box for the request.
Sample web application Using parameter extraction

The following procedure provides an example of using parameter extraction in a web application. This example
performs a query for the first entry in the Popular Now section of the Bing home page. Because this value
changes regularly, you have to first connect to the main page and collect the search term from the body of the
response. You then use this term to build the request to perform the actual search.
The main Bing page is shown below with the Popular Now section highlighted.
To determine where in the response body the search term appears, you can view the source of the page. A portion
of the source is shown below with the HTML code of the Popular Now section. In this HTML code, you only need
the search string which is highlighted in the following illustration. The request is formed from
http://www.bing.com followed by this string.
You could just pull out the term itself, but it is more straightforward to include the entire string in the parameter.
This string is preceded by the characters <h3>Popular now</h3><ul><li><a href=> and ends with the next
occurrence of ". Those are the values that you will use when you define the parameter extraction.
To record a sample web application
1. Use the procedure in How to Capture Web Application Recording to record a web application.
2. While recording, connect to http://www.bing.com.
3. Optionally, use the option on your browser to view the source of the Bing home page and locate the Popular
Now section of the HTML code.
4. Click the first search term under Popular Now.
5. Save the recording to the web application.
6. Remove the last request because this is not required. To remove the last request, select the request, and then
click Delete in the Actions pane. The resulting requests should look similar to the following URLs:
To create an extraction rule

1. Select the first request, and then click Properties in the Actions pane.
2. Select the Extraction Rules tab.
3. Click Add. The Add Extraction Rule dialog box opens.
4. In the Add Extraction Rule dialog box, in the Context parameter name box, type SearchString.
5. In the Starts with box, type <h3>Popular now</h3><ul><li><a href=>.
6. In the Ends with box, type ". The extraction rule should look similar to the following illustration.
7. Click OK to save and close the extraction rule.

8. Click OK to save and close the request.
To insert a parameter into a request
1. Select the second request, and then click Properties in the Actions pane.
2. On the General tab, click Insert parameter.
3. In the String box, delete all text after www.bing.com/.
4. With the cursor positioned at the end of the URL, just after www.bing.com, select SearchString in the
Parameters box, and then click Insert. This inserts the variable $ParametersContext/SearchString$. The
final request looks similar to the following illustration.
5. Click OK to close the dialog box.

6. Click OK to save and close the request. The modified request sequence should look similar to the following
illustration.
7. Click Apply to apply the changes, and then close the Web Application Editor.
Windows Service template
7 minutes to read
The Windows Service template lets you find and monitor instances of a particular service installed on a Windows-
based computer. The template locates computers that are running the service and then applies monitors and rules
to test its availability and collect performance data. The only information that you have to provide is the name of
the service and the types of monitoring that you want to perform.
Scenarios
Use the Windows Service template for any application that uses a service because typically the basic health of
the service is critical to the health of the application. You can simply provide the name of the service and have it
discovered and monitored on any computer where the application is installed.
Monitoring performed by Windows Service template

Depending on your selections in the Windows Service Template wizard, the monitoring performed by the created
monitors and rules can include any of the following settings.
Monitors Running state of the service Enabled.
CPU utilization of the service Enabled if CPU Usage monitoring is

selected in the wizard.
Memory usage of the service Enabled if Memory Usage monitoring

is selected in the wizard.
Collection Rules Collection of events indicating a change Enabled.

in service's running states.
Collection of CPU utilization for the Enabled if CPU Usage monitoring is

service selected in the wizard.
Collection of memory usage for the Enabled if Memory Usage monitoring

service is selected in the wizard.
Collection of Handle Count for the Disabled. Can be enabled with an

service override.
Collection of Thread Count for the Disabled. Can be enabled with an

service override.
Collection of Working Set for the Disabled. Can be enabled with an

service override.
Wizard options
When you run the Windows Service template, you have to provide values for options in the following tables.
Each table represents a single page in the wizard.
General Options
OPTION DESCRIPTION
Name The name used for the service. This name is displayed in the
Operations console for the wizard.
Description Optional description of the service.
rules that use the service as a target class, they have to be
stored in the same management pack. For more information
about management packs, see Selecting a Management Pack
File.
Service Details
The following options are available on the Service Details page of the wizard.
OPTION DESCRIPTION
Service name The name of the service. This name is searched on the agent-
managed computer to determine whether it is installed.
Targeted group The service is only discovered on computers that are included
in the specified group.
Monitor only automatic service If selected, only those services that are set to start
automatically when Windows starts are monitored. Any
services with their startup value set to manual or anything
other than Automatic are not monitored.
Performance Data
The following options are available on the Performance Data page of the wizard.
OPTION DESCRIPTION
Generate an alert if CPU usage exceeds the specified threshold Specifies if CPU usage should be monitored. A monitor is
created to set an error state on the object and generate an
alert when the specified threshold is exceeded. A rule is
created to collect CPU usage for analysis and reporting.
CPU Usage (percentage) If CPU usage is monitored, this option sets the threshold. If
the percentage of total CPU usage exceeds the threshold, the
object is set to an error state and an alert is generated.
Generate an alert if memory usage exceeds the specified Specifies whether memory usage should be monitored. A
threshold monitor is created to set an error state on the object and
generate an alert when the specified threshold is exceeded. A
rule is created to collect CPU usage for analysis and reporting.
OPTION DESCRIPTION
Memory Usage (MB) If memory usage is monitored, this option sets the threshold.
If the percentage of total CPU usage exceeds the threshold,
the object is set to an error state and an alert is generated.
Number of samples If CPU usage or memory is monitored, this option specifies

the number of consecutive performance samples that must be
exceeded before the object is set to an error state and an alert
is generated.
Specifying a number greater than 1 for this option limits the
noise from monitoring by ensuring that an alert is not
generated when the service only briefly exceeds the threshold.
The larger the value that you set, the longer the period of
time before you receive an alert. A typical value is 2 or 3.
Sample Interval If CPU usage or memory is monitored, this option specifies

the length of time between performance samples. A smaller
value for this option reduces the time for detecting a problem
but increases overhead on the agent and the amount of data
collected for reporting. A typical value is between 5 and 15
minutes.
In addition to performing the specified monitoring, the Windows Service template creates a class that you can
use for additional monitors and workflows. Any monitor or rule that is using this class runs on any agent where the
service is installed. If it creates Windows events that indicate an error, for example, you could create a monitor or
rule that detects the particular event and uses the service' class as a target.
Creating and modifying Windows Service templates

To create a Windows Service template
1. Determine the target group for the monitor by using the following logic:
If you want to discover the service on all Windows-based computers in the management group, you
do not have to create a group. You can use the existing group All Windows Computers.
If you only want the service to be discovered on a certain group of computers, either ensure that an
appropriate group exists or create a new group by using the procedure in How to Create Groups in
Operations Manager.
If the service you are monitoring is in a cluster, create a group with objects of the class Virtual
Server representing the nodes of the cluster that contains the service.
3. On the Select Monitoring Type page, select Windows Service , and then click Next.
4. On the General Properties page, in the Name and Description boxes, type a name and description for
this new monitor.
6. Click Next.
7. In the Service Name box, type the name of the specific service that you want to monitor, or click the ellipse
( … ) button to browse for the service. You can select any computer that has the service installed.
8. Under Targeted Group , specify the group from step 1 of this procedure.
9. Clear the Monitor only automatic services option if you want the monitor to apply to services that are
not configured to start automatically. If the service that you are monitoring is in a cluster, clear this option.
10. Click Next.
11. Select the performance counters and thresholds that you want to monitor. For more detailed information,
see the Wizard Options section.
12. If you have selected performance counters, specify the monitoring interval.
13. Click Next.
To modify an existing Windows Service template
3. In the Authoring navigation pane, expand Management Pack Templates , and then select Windows
Service.
4. In the Windows Service pane, locate the monitor to change.
Viewing Windows Service Monitors and Collected Data

To view all Windows Service monitors
3. In the Monitoring navigation pane, select Windows Service and Process Monitoring , and then click
Windows Service State.
1. In the Windows Service State pane, right-click an object. Select Open , and then click Health Explorer.
To view the performance collected for a service
1. In the Windows Service State pane, right-click an object. Select Open , and then click Performance.
Using classes and groups for overrides
5 minutes to read
This topic describes the differences between classes and groups in System Center - Operations Manager, and how
workflows, such as rules and monitors, apply to each. The following sections define classes and groups, and
provide examples for applying overrides with the available override options.
Classes
In Operations Manager, a class is a definition of an item that can be discovered and managed. A class can
represent a computer, a database, a service, a disk, an application, or any other kind of object that requires
monitoring. Monitors, rules, discoveries, overrides, and tasks can apply to a class. For example, Windows Server
2012 Logical Disk is a class that defines logical disks on a computer that is running the Windows Server 2003
operating system. A monitor that applies to the Windows Server 2012 Logical Disk class will be applied only to
objects that meet that class definition.
NOTE
In the Operations console, the term target is used instead of class.
Classes are defined in the Operations Manager management pack libraries and in individual product
management packs that you import.
Groups
In Operations Manager, a group is a logical set of objects that can be used to define the scope of overrides, views,
user roles, and notifications. Some groups are provided in the Operations Manager installation, such as All
Windows Computers group and Agent Managed Computer Group. You can create your own groups and add
members to groups explicitly or dynamically.
Overrides
You have seen that classes are used to target workflows such as rules and monitors. A monitor or rule is applied
to a specific class. To change the value for a parameter of a rule or monitor, you create an override. You have the
following options for applying your override:
For all objects of class: Class
When you select this option for your override, the override settings apply to all objects in the class at which
the rule or monitor is targeted.
For a group
When you select this option for your override, the override settings apply only to members of the group.
The rule or monitor without the override settings continues to apply to all objects in the targeted class
except for those objects that are also members of the group used for the override.
When you create a group, you save it to an unsealed management pack. However, an element in an
unsealed management pack, such as an override, cannot reference an element in a different unsealed
management pack, such as a group. If you are going to use a group to limit the application of an override,
you must either save the group to the same unsealed management pack as the override, or you must seal
the management pack that contains the group.
For a specific object of class: Class
When you select this option for your override, the override settings apply only to the specified object. The
rule or monitor without the override settings continues to apply to all other objects in the targeted class.
For all objects of another class
When you select this option for your override, the override settings apply only to objects of a class other
than the targeted class. The rule or monitor without the override settings continues to apply to all objects in
the targeted class.
Overrides that apply to a class are applied first, then overrides that apply to a group, and finally overrides that
apply to a specific object. For more information, see Using the Enforced Attribute in Overrides below.
How to apply overrides

Here are some examples of when you would use the override options.
You want to change the priority of an alert
Select to override For all objects of class: Class.
You want to change the priority of an alert for computers that meet specific criteria
Select to override For a group and create a group that dynamically adds members based on specific criteria.
You want to change the priority of an alert for a specific computer only
Select to override For a specific object of class: Class. You could also select For a group and create a group that
has the specific computer added as an explicit member.
You want to change the priority of an alert that applies to all operating systems for a specific operating system
Select For all objects of another class and select the class that represents the operating system for which you
want to have a different alert priority.
You want the rule or monitor to apply only to specific computers
In this common scenario, you must perform the following two tasks:
1. Select to override For all objects of class: Class, and change Enabled to False. This will disable the rule
or monitor.
2. Select to override For a group, For a specific object of class: Class, or For all objects of another class,
and change Enabled to True. This enables the rule or monitor for members of that group, the specified
object, or the selected class only.
Using the Enforced Attribute in Overrides

When you configure an override to a rule, monitor, or discovery in Operations Manager, you will notice an
Enforced check box in the row for each value that you can override, as shown in the following illustration.
When the Enforced attribute is selected for an override, this setting ensures that the override will take precedence
over all other overrides of the same type and context that do not have Enforced set.
apply to a specific object. The Enforced attribute assures that the override will take precedence when two
overrides of the same type and context conflict.
For example, you have two Windows computers, COMPUTER1 and COMPUTER2. COMPUTER1 is member of
GROUP -A and is also member of GROUP -B. COMPUTER2 is not a member of any group. The default threshold
for a CPU monitor is 80%.
You apply an override to the Windows Computer class that changes the CPU monitor threshold to 70%. You
create another override to that monitor that applies to GROUP -A and sets the threshold to 90%. At this point, the
threshold for COMPUTER1 is 90% and the threshold for COMPUTER2 is 70%.
If you create an override that applies to GROUP -B and sets the threshold to 95%, the resulting threshold for
COMPUTER1, which is member of both GROUP -A and GROUP -B, is unpredictable. However, if you used the
Enforced attribute on the override that applies to GROUP -B, you ensure that the 95% threshold applies to
COMPUTER1.
If you create an override that applies to COMPUTER1 and sets the threshold to 60%, the resulting threshold for
COMPUTER1 is 60% because the object override takes precedence over the class and group overrides.
Next steps
Review How to Enable Recovery and Diagnostic Tasks to understand how they can help investigate and
auto-remediate issues identified by monitors.
How to import, export, and remove an Operations
Manager management pack
10 minutes to read
There are numerous management packs available for System Center Operations Manager. A management pack
must be installed for use by Operations Manager in order to discover and monitor one or more components
depending on its complexity, and the overall health of the IT service delivered by the organization. Over time, the
knowledge of what to discover and monitor, and how to monitor and report on the operational data is updated in
newer releases of a management pack. These management packs must be reimported into the management
group when updated by the vendor or internally if developed by the team responsible for it. When the
management pack is no longer required to monitor , you can remove it from the management group.
Importing a management pack

You have several options for importing management packs:
Import a management pack from the Microsoft Catalog by using the Operations console.
Import a management pack from disk (local storage or a network file share) by using the Operations
console.
Download a management pack by using the Operations console to import at a later time.
Download a management pack by using an Internet browser to import at a later time.
NOTE
Using the management pack catalog service requires an Internet connection and your firewall needs to allow access to the
the following URL - https://www.microsoft.com/mpdownload/ManagementPackCatalogWebService.asmx?. If the
computer running Operations Manager Operations console cannot connect to the Internet, use another computer to
download the management pack, and then copy the files to a shared folder that is accessible from the console.
The Operations Manager community maintains a list of management packs developed by Microsoft on the
following web site Microsoft Management Pack List. You can obtain third-party management packs directly from
those companies and import them by following the procedure Import a management pack from disk.
NOTE
Microsoft neither endorses nor provides support for third-party products. Please contact the specific provider for support
issues.
You should always review the management pack guide before you import a management pack.
Import a management pack from the catalog
3. Right-click Management Packs, and then click Import Management Packs.
4. The Import Management Packs wizard opens. Click Add, and then click Add from catalog.
The Select Management Packs from Catalog dialog box opens. The default view lists all management
packs in the catalog. You can change the view to show the following management packs:
Updates available for management packs that are already imported on this computer
All management packs that have been released within the last three months
All management packs that have been released within the last six months
You can also use the Find field to search for a specific management pack in the catalog.
5. In the list of management packs, select the management pack that you want to import, click Select, and
then click Add.
In the list of management packs, you can select a product, or expand the product name to select a specific
version, or expand the product version to select a specific management pack file. For example, you can
select SQL Server for all SQL Server management packs, or you can expand SQL Server and select SQL
Server 2014 for all SQL Server 2014 management packs, or you can expand SQL Server 2014 and select
SQL Server Core Library Management Pack.
NOTE
When a management pack is labeled “(Online Catalog Only)”, you cannot import the management pack directly
from the catalog. You must download the .msi and import from disk.
6. On the Select Management Packs page, the management packs that you selected for import are listed.
An icon next to each management pack in the list indicates the status of the selection, as follows:
A green check mark indicates that the management pack can be imported. When all management
packs in the list display this icon, click Import.
A yellow information icon indicates that the management pack is dependent on one or more
management packs that are not in the Import list but are available in the catalog. To add the
management pack dependencies to the Import list, click Resolve in the Status column. In the
Dependency Warning dialog box that appears, click Resolve.
A red error icon indicates that the management pack is dependent on one or more management
packs that are not in the Import list and are not available in the catalog. To view the missing
management packs, click Error in the Status column. To remove the management pack with the
error from the Import list, right-click the management pack, and then click Remove.
NOTE
When you click Import, any management packs in the Import list that display the Information or Error icon are
not imported.
7. The Import Management Packs page appears and shows the progress for each management pack. Each
management pack is downloaded to a temporary directory, imported to Operations Manager, and then
deleted from the temporary directory. If there is a problem at any stage of the import process, select the
management pack in the list to view the status details. Click Close.
Import a management pack from disk
3. Right-click Management Packs, and then click Import Management Packs.
4. The Import Management Packs wizard opens. Click Add, and then click Add from disk.
5. The Select Management Packs to import dialog box appears. If necessary, change to the directory that
holds your management pack file. Click one or more management packs to import from that directory,
and then click Open.
packs in the list display this icon, click Import.
NOTE
When you click Import, any management packs in the Import list that display the Error icon are not imported.
Download a management pack by using the Operations console
3. Right-click Management Packs, and then click Download Management Packs.
4. The Download Management Packs wizard opens. Click Add.
The Select Management Packs from Catalog dialog box opens. The default view lists all management
packs in the catalog. You can change the view to show the following management packs:
Updates available for management packs that are already imported on this computer
All management packs that have been released within the last three months
All management packs that have been released within the last six months
You can also use the Find field to search for a specific management pack in the catalog.
5. In the list of management packs, select the management pack that you want to import, click Select, and
then click Add.
In the list of management packs, you can select a product, or expand the product name to select a specific
version, or expand the product version to select a specific management pack file. For example, you can
select SQL Server for all SQL Server management packs, or you can expand SQL Server and select SQL
Server 2005 for all SQL Server 2005 management packs, or you can expand SQL Server 2005 and select
SQL Server Core Library Management Pack.
6. The selected management packs are displayed in the Download list. In the Download management
packs to this folder field, enter the path where the management packs should be saved, and then click
Download.
7. The Download Management Packs page appears and shows the progress for each management pack.
If there is a problem with a download, select the management pack in the list to view the status details.
Click Close.
Download a management pack by using an Internet browser
1. Open a browser and go to the Microsoft Management Pack List.
2. Browse the list of management packs to locate the management pack that you want to download.
3. Click the name of the management pack that you want to download.
4. On the Microsoft Download Center page for the management pack, click Download.
5. In the File Download dialog box, click Run to download and extract the management pack files. Or, click
Save to download the .msi file without extracting the files.
NOTE
Some management pack download pages contain a download link for the management pack .msi file and a
download link for the management pack guide. Download both the .msi and the guide.
Before you can import the management pack in Operations Manager, you must run the .msi file to extract the files.
How to export an Operations Manager management pack

Exporting a management pack allows customizations to a sealed management pack to be saved to a writeable
management pack. Because sealed management packs cannot be changed, the modifications made to a
management pack are saved to a separate, unsealed management pack file. The unsealed management pack can
then be imported into a different management group or the same management group depending on the
situation. This unsealed management pack is dependent on the original sealed management pack and can be
imported only to management groups that have the original sealed management pack.
NOTE
Using the Operations Console, you can only export unsealed management packs. To export a sealed management pack,
you must use the Export-SCOMManagementPack cmdlet. See Operations Manager Cmdlet Reference for more
information.
To export an unsealed management pack

3. In Administration, click Management Packs to display the list of imported management packs.
4. In the Management Packs pane, right-click the management pack you want to export, and then click
Export Management Pack.
5. In the Browse For Folder dialog box, expand the path for the location to save the file, and then click OK.
The management pack is saved as an Operations Manager XML management pack file and is ready for
importing into another management group.
How to Remove an Operations Manager Management Pack

When you no longer need a management pack, you can delete it using the Operations console. When you delete
a management pack, all the settings and thresholds associated with it are removed from the management group.
Also, the .mp or .xml file for that management pack is deleted from the hard disk of the management server. You
can delete a management pack only if you have first deleted dependent management packs.
To remove a management pack
3. In Administration, click Management Packs.
4. In the Management Packs pane, right-click the management pack you would like to remove and then
click Delete.
5. On the message stating that deleting the management pack might affect the scoping of some user roles,
click Yes.
NOTE
If any other imported management packs depend on the management pack you are trying to remove, the Dependent
Management Packs error message is displayed. You must remove the dependent management packs before you can
continue.
Next steps
If you want to create your own custom knowledge for specific alerts generated by rules or monitors from
a sealed management pack, review How to Add Knowledge to a Management Pack
How to create a management pack for overrides
2 minutes to read
In System Center - Operations Manager, in a number of wizards and dialog boxes, you select a destination
management pack in which to store the settings. You can select any unsealed management pack file in your
management group or create a new one.
Management packs can be sealed or unsealed. A sealed management pack cannot be modified directly. Any
changes to the workflows in the sealed management pack, such as an override for a monitor, must be saved to
an unsealed management pack. The unsealed management pack references the sealed management pack that it
modifies.
The following illustration shows the unsealed management packs that are installed with Operations Manager.
Never use the management packs that are installed with Operations Manager to save any settings that you
change or elements that you create. When you have to select a destination management pack, always select a
management pack that you create.
You select a destination management pack when you create an override or disable a rule, monitor, or object
discovery. You also select a destination management pack when you create or configure the following elements:
A folder in the Monitoring workspace
A unit, aggregate, or dependency monitor
An attribute
A group
A rule
A task
A Run As profile
Monitoring by using a management pack template
Monitoring of a distributed application
Tracking of service level objectives
Saving overrides
As a best practice, save all overrides for each sealed management pack to an unsealed management pack that is
named ManagementPack_Override, where ManagementPack is the name of the sealed management pack to
which the overrides apply. For example, overrides to the management pack
Microsoft.SQLServer.2012.Monitoring.mp would be saved to
Microsoft.SQLServer.2012.Monitoring_Overrides.xml.
When you want to remove a sealed management pack, you must first remove any other management packs
that reference it. If the unsealed management packs that reference the sealed management pack also contain
overrides or elements that apply to a different sealed management pack, you lose those overrides and elements
when you remove the unsealed management pack.
In the following image, overrides for management packs 1, 2, and 3 are all saved to a single unsealed
management pack. If you want to remove management pack 1, you first must remove the unsealed
management pack. As you can see, you would also remove all overrides for management packs 2 and 3.
The recommended method is to create an unsealed management pack for each sealed management pack that
you want to override, as shown in the following image. Removing management pack 1 and its unsealed
management pack does not affect the other management packs.
How to create a management pack for overrides
You can create a management pack for overrides before you configure an override or as part of the override
procedure.
To create a management pack
In the Administration workspace, in the navigation pane, right-click, and then click Create
Management Pack.
-or-
In the Override Properties dialog box for a rule or monitor, in the Select destination management
pack section, click New.
Next steps
To understand what an Operations Manager management pack is and how it helps you proactively
monitor your services and applications, see What Is in an Operations Manager Management Pack?
If you want to create your own custom knowledge for specific alerts generated by rules or monitors from
a sealed management pack, review How to Add Knowledge to a Management Pack
How to override a rule or monitor
2 minutes to read
Overrides change the configuration of System Center - Operations Manager monitoring settings for monitors,
attributes, object discoveries, and rules. When you create an override, you can apply it to a single managed object
or to a group of managed objects. You must have Advanced Operator user rights to create and edit overrides.
The use of overrides is key to controlling the amount of data that is collected by Operations Manager. When you
create a monitor, rule, or attribute you target it at an object type, but often the available object types are broad in
scope. You can then use groups and overrides together to narrow the focus of the monitor, rule, attribute, or object
discovery. You can also override existing monitors, rules, attributes, or object discoveries that are from
management packs.
apply to a specific object. For more information, see Using Classes and Groups for Overrides.
The following procedure overrides a monitor, but you can also use these steps to override a rule, attribute, or
object discovery. You must have Advanced Operator or Administrator user rights to create an override.
To override a monitor
1. Log on to the computer with an account that is a member of the Operations Manager Advanced Operator
role.
2. In the Operations console, click Authoring.
3. In the Authoring workspace, expand Management Pack Objects and then click Monitors.
4. In the Monitors pane, expand an object type completely and then click a monitor.
5. On the Operations console toolbar, click Overrides and then point to Override the Monitor. You can
choose to override this monitor for objects of a specific type or for all objects within a group. After you
choose which group of object type to override, the Override Properties dialog box opens, enabling you to
view the default settings contained in this monitor. You can then choose whether to override each
individual setting contained in the monitor.
NOTE
If the Overrides button is not available, make sure you have selected a monitor and not a container object in the
Monitors pane.
6. Click to place a check mark in the Override column next to each parameter that you want to override. The
Override Value can now be edited. Change the value in Override Value to the value you want the
parameter to use.
7. Either select a management pack from the Select destination management pack list or create a new
unsealed management pack by clicking New. For more information about selecting a destination
management pack, see Creating a Management Pack for Overrides.
8. When you complete your changes, click OK.
Next steps
defined in a management pack, see Management Pack Lifecycle.
How to enable or disable a rule or monitor
2 minutes to read
In System Center - Operations Manager, if a management pack's default settings contain a monitor or rule that is
not necessary in your environment, you can use overrides to disable this monitor or rule. In addition, some
management packs ship with some rules or monitors disabled; you should read the management pack guide to
identify the workflows that are disabled by default and determine if you should enable any of them for your
monitoring needs. For example, the management packs for network monitoring contain rules and monitors that
are vendor-specific. Many vendor-specific rules and monitors in the network management pack are disabled to
avoid performance impact. You should identify the devices used in your environment and use overrides to enable
the rules and monitors specific to your devices.
To enable or disable a monitor or rule using overrides

1. Log on to the computer with an account that is a member of the Operations Manager Advanced Operator
role.
3. In the Authoring workspace, click Monitors (or Rules if you want to disable a rule).
4. In the Monitors or Rules section, click the monitor or rule that you want to disable.
5. On the Operations console toolbar, click Overrides and then point to Override the Monitor (or Rule). You
can choose to override this monitor or rule for objects of a specific type or for all objects within a group.
After you choose which group of object type to override, the Override Properties dialog box opens,
enabling you to view the default settings contained in this monitor or rule. For more information about
applying an override, see Using Classes and Groups for Overrides.
6. In the Override Properties dialog box, click to select the Override check box that corresponds to the
Enabled parameter.
NOTE
If you select Disable instead of Override, the Override Properties dialog box opens with the Override check box
selected and the Enabled value set to False.
7. In the Override Setting column, click True to enable the rule or monitor or False to disable the rule or
monitor.
8. In the Select destination management pack list, click the appropriate management pack in which to
store the override or create a new unsealed management pack by clicking New. For more information about
selecting a destination management pack, see Creating a Management Pack for Overrides.
9. When you complete your changes, click OK.
Next steps
To understand the differences between classes and groups in Operations Manage and how workflows apply
to each, review Using Classes and Groups for Overrides in Operations Manager.
Review How to Enable Recovery and Diagnostic Tasks to understand how they can help investigate and
auto-remediate issues identified by monitors.
How to add knowledge to a management pack
2 minutes to read
System Center Operations Manager management packs include knowledge for rules, monitors, and alerts that
helps you identify problems, causes, and resolutions.
Knowledge is referred to as product knowledge or company knowledge. Product knowledge is embedded in a
rule or monitor when it is authored. Company knowledge is added by management group administrators to
expand the troubleshooting information and provide company-specific information for operators. Administrators
can use company knowledge to document any overrides implemented for a monitor or rule, along with the
explanation for the customization and any other information that might be useful.
Operations Manager stores company knowledge in a management pack. Sealed management packs cannot be
modified, so Operations Manager saves customizations such as company knowledge in a custom management
pack. By default, Operations Manager saves all customizations to the Default Management Pack. As a best
practice, you should instead create a separate management pack for each sealed management pack you want to
customize.
TIP
To avoid losing your company knowledge, be sure to back up custom management packs as part of your general backup
routine.
To add or edit company knowledge, the computer must meet the following software requirements:
The Operations console is installed on the computer.
Microsoft Word 2010 or higher.
Microsoft Visual Studio 2010 Tools for Office Runtime.
To add or edit company knowledge, you must have the Author or Administrator user role.
To edit company knowledge

1. Open the Operations console with an account that is a member of the Operations Manager Author or
Administrator role.
2. Click Authoring.
3. Locate the monitor or rule to be documented.
4. Click Properties under Actions, or right-click the monitor name and select Properties from the shortcut
menu.
5. Click the Company Knowledge tab.
6. In the Management pack section, select a management pack in which to save the company knowledge.
7. Click Edit to launch Microsoft Office Word.
8. Add or edit text as desired.
The company knowledge tab displays only the sections of the Word document with custom text.
9. On the File menu, click Save to save your changes.
IMPORTANT
Do not close Word.
10. Return to the company knowledge tab and click Save, and then click Close. This will close both the
properties dialog box and Word.
Next steps
Management pack assessment
9 minutes to read
Operations Manager 2019 includes support for Linux and Unix workloads and operating systems. See the
following sections for detailed information. Updates and Recommendations feature in Operations Manager 2019
also supports a new capability called Machine Details, which provides the computer details (name and operating
system) on which a selected workload is running.
If there are management packs in the catalog that are designed to monitor those workloads, they will be displayed
on the Updates and Recommendations screen. You will also find a list of any updates that are available for
management packs that are installed in your management group.
When a new workload is deployed in your IT infrastructure that was never monitored by Operations Manager, it
will be detected and highlighted under the Updates and Recommendations node. The management packs required
to monitor that workload will be presented with a status of Not Installed. If the necessary management pack files
for a particular workload are not installed, for example the library management pack file is installed but not the
corresponding discovery and monitoring management pack files, the Updates and Recommendations feature will
list that workload with a status of Partially Installed.
Operations Manager 2019, Updates and Recommendation feature includes support for application servers
running on Linux and Unix operating systems.
This feature includes the following capabilities:
OPTION DESCRIPTION
Get MP Installs the management packs for the selected workload
Get All MPs Installs the management packs for all of the workloads
displayed
View Guide Downloads the management pack guide from the web
browser, for the selected workload, to your computer
View DLC Page Open from the web browser, the page on the Microsoft
Download Center, to download the management pack file
Machine Details (applicable only for Operations Manager Highlights the machine name and operating system for the
2019) selected workload.
More information Highlights all impacted agent-managed systems and

management pack details of selected workload (depending on
the status of the workload)
NOTE
In order to use the options highlighted in the table above, the computer you are running the Operations console from
requires an Internet connection and your firewall needs to allow access to the following URL -
https://www.microsoft.com/mpdownload/ManagementPackCatalogWebService.asmx?
NOTE
Configuring the frequency and control the discovery of workloads cannot be performed directly from the Operations
console. If you wish to modify those settings of this feature, you can download a PowerShell script from the Microsoft Script
Center.
Importing a Management Pack using Get MP

The following procedure describes how to use the Get MP option to download a management pack for a selected
workload.
3. Click on Updates and Recommendations under Management Packs.
NOTE
When accessing the Updates and Recommendations view, you may receive the following message, "An error
occurred while displaying the Updates and Recommendations View. This might be because the database query has
encountered an issue or the online catalog is down." This can be caused by having a duplicate management pack
with the same name. To help troubleshoot the issue, run the following command in the Operations Manager Shell
and review the output file to identify the duplicate MP:
Get-SCManagementPack | Sort -property Name | Format-Table Name,Version,Sealed -AutoSize | Out-File
"c:\temp\mplist_name.txt"
4. If a management pack is recommended for either an update or a new installation, select it and click Get MP
from the Actions pane.
5. The Connecting to Management Pack Catalog Web Service window appears and after it successfully
connects and synchronizes, the Import Management Packs wizard opens.
6. On the Select Management Packs page, in the list of management packs will be the management packs
identified in the Import Type column with the value of Not installed if missing but applicable, or Update
available if the management pack file is not the most recent version.
The management pack language matches the default language of the currently installed management pack
files. You can choose to import in another language by clicking on the option Languages and in the Select
Languages dialog box select the appropriate language and then click OK. The Select Management
Packs page will update the list of management pack files which include the selected languages.
packs in the list display this icon, click Install.
management pack dependencies to the Import list, click Resolve in the Status column. When the
NOTE
When you click Install, any management packs in the Install list that display the Information or Error icon
are not imported.
Importing a management pack using Get All MPs

The following procedure describes how to use the Get All MPs option to download management pack for a
selected workload.
3. Click on Updates and Recommendations under Management Packs.
4. If there are multiple management packs recommended for either an update or a new installation, you can
download and import all of them by clicking Get All MPs from the Actions pane.
5. The Connecting to Management Pack Catalog Web Service window appears and after it successfully
connects and synchronizes, the Import Management Packs wizard opens.
6. On the Select Management Packs page, in the list of management packs will be the management packs
identified in the Import Type column with the value of Not installed if missing but applicable, or Update
available if the management pack file is not the most recent version.
packs in the list display this icon, click Install.
management pack dependencies to the Import list, click Resolve in the Status column. When the
NOTE
When you click Install, any management packs in the Install list that display the Information or Error icon
are not imported.
Supported workloads
The following list includes the workloads that are supported by this feature.
BizTalk 2006, 2009, 2010, server 2013 and 2013 R2
Branch Cache 2016
CRM 2011, 2013 and 2015
Defender Technical Preview
Distributed Transaction Coordinator 2012 R2 and 2016
Dynamics AX 2009, 2012 and Retail 2012 R3
Essentials Technical Preview
Exchange Server 2013
Host Integration Server 2010 and 2013
NAV 2013 and 2013 R2
Office SharePoint Foundation 2010
SharePoint 2010 Products, Foundation Server 2013 and Server 2013
SMA 2012 R2
SPF 2012 R2
SQL Server 2005, 2008, 2012, 2012 Analysis Services, 2012 Replication, 2012 Reporting Services (Native
Mode), 2014, 2014 Analysis Services, 2014 Replication, 2014 Reporting Services (Native Mode), 2016, 2016
Analysis Services, 2016 Replication and 2016 Reporting Services (Native Mode)
System Center 2012 App Controller, Configuration Manager and Orchestrator
Windows Server Backup, Service Manager 2012 and TFS 2013
The following workloads are supported for the operating systems listed below.
FEATURE WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016 WINDOWS SERVER 2019
Active Directory Certificate Y Y

Service
Active Directory Domain Y Y Y

Services
Active Directory Federation Y Y Y

Service
Active Directory Right Y Y Y

Management Service
DHCP Server Y Y Y
DNS Server Y Y Y
Fail Over Clustering Y Y Y
File Services Y Y Y
IIS Y Y Y
FEATURE WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016 WINDOWS SERVER 2019
Network Load Balancing Y Y Y
Print Server Y Y Y
Essentials Y Y
Hyper-V Y Y
Queueing Y Y
Remote access Y
Remote Desktop Service Y Y
Web application proxy Y
Windows Deployment Y
Services
Windows Update Services Y
Windows Server 2016

Active Directory Certificate Service
Active Directory Federation Service
Active Directory Right Management Service
DHCP Server
DNS Server
Fail Over Clustering
File Services
IIS
Network Load Balancing
Print Server
Windows Server 2012 R2
Active Directory Certificate Services
Active Directory Federation Services
Active Directory Light Weight Directory Services
Active Directory Right Management Services
Branch Cache
Cluster
DHCP
DNS
Essentials
File Services
Hyper-V
NLB
Print Services
Queueing
Remote access
Remote Desktop Service
Web application proxy
Windows Deployment Services
Windows Update Services
Windows Server 2012
AD Right Management Services
Branch Cache
Cluster
DHCP
DNS
File Services
Hyper-V
IIS
Message Queueing
Print Services
Remote Access
Remote Desktop Services
Windows Deployment Services
Windows Server backup
Windows Update Services
Windows Server 2008 R2 version
Active Directory Lightweight Directory Services
Active Directory Right Management Services
Branch Cache
DHCP
DNS
File Services
Hyper-V
IIS 2008 R2
Message Queueing
Print Services
Remote Desktop Service
Routing Remote Services
Support for Linux and Unix platforms supported for application servers
workload
CentOS6 x64, CentOS7 x64
Oracle6 x64, Oracle7 x64
Sles12 x64
Rhel7 x64
Debian8 x64, Debian9 x64
Ubuntu16 x64, Ubuntu 18 x64
Aix 7.x
Supported application servers

Apache Tomcat 7, Apache Tomcat 8, Apache Tomcat 9
Red Hat JBoss 4, JBoss 5, JBoss 6, JBoss 7, Wildfly Application Server 8/9/10/11/12/13/14, Red Hat JBoss
EAP 6, Red Hat JBoss EAP 7
IBM WebSphere 7.0, WebSphere 8.0, WebSphere 8.5, WebSphere 9.0
Oracle WebLogic 10gR3, Oracle WebLogic 11, WebLogic 12cR1, WebLogic 12cR2
Next steps
To understand how to approach to managing the lifecycle of management packs deployed in your
management group, see Management pack lifecycle.
Review the Operations Manager Reports library to understand what reports are available to help you
explore the operational data and configuration information in your management group and follow the How
to create reports in Operations Manager to create reports for your operational needs.
Select a management pack file
4 minutes to read
When you create any monitoring in the Operations console, you have to specify a management pack file for the
elements that you are creating. This topic describes a basic strategy that you can follow and provides additional
details to help you understand the logic of the recommended strategy.
General strategy
For applications that already have a sealed management pack installed, typically management packs installed
from the Management Pack Catalog:
Create a separate management pack file to store overrides and new monitoring for that application.
For applications that do not have a sealed management pack installed, typically management packs that you
created yourself:
Create a separate management pack file for each application. Use this file to store overrides and any new
monitoring for that application.
For common elements that are used by other management pack files, such as groups:
Create a separate management pack file for each logical set of elements. Seal this management pack file
before installing it.
NOTE
If you created the management pack file in the Operations console, you must export it to an .xml file, and then
seal it. You must then uninstall the unsealed management pack file from the management group before you
install the sealed management pack file.
Default Management Pack

The Default Management Pack file contains common elements such as views at the top level of the
Monitoring workspace. This is an unsealed management pack file so that you can create views and folders at
this level. It should not be used for any other purpose. For creating elements such as monitors and rules, create
a new management pack file.
Logically grouping elements

Although you could simply create a single management pack file to store all custom elements that you create, it
is not a best practice. While management pack elements are treated individually by the agents that run them,
the management group works with the management pack file. When a management pack file is installed in the
management group or removed from it, it includes all of its management pack elements.
When you determine how to group different elements, take the following considerations into account:
Management pack files are delivered to any agent computer that requires at least one element in the file. If
you use a single management pack file for different applications, elements might be delivered to agents that
do not require them. The agent only actually loads the elements for the applications that it has installed, but
the entire management pack file is delivered. Breaking up management pack files according to the elements
that are relevant to a single application ensures the most efficient delivery of the files to agents.
You can remove an application from your environment and no longer require its management pack. Or you
can obtain a new management pack for an application and want to remove custom monitoring that you
implemented. In cases like these, you can uninstall all of the elements for a particular application by
removing any of its management pack files. If you combine elements for multiple applications, you limit your
ability to manage the monitoring logic for a single application.
You can develop and test some monitoring logic in a lab environment before moving it into a production
management group. Combining elements for a particular application into a single management pack lets
you manage that file through the different environments without affecting the monitoring for other
applications.
By following the recommend strategy for logically grouping management pack elements, you can ensure that
your management group runs as efficiently as possible and can most effectively handle future changes.
Sealed and unsealed Management Pack Files

When selecting a management pack file, you must consider the implications of sealed and unsealed
management packs. An element in one management pack file cannot refer to an element in another file if the
file being referenced is not sealed. For this reason, you might have to group-related elements in a single
management pack file or seal management pack files meant for general use. For more information about the
effects of sealing a management pack, see Sealed Management Pack Files.
Because a sealed management pack file cannot be modified, you can only store new management pack
elements in unsealed files. Any management pack created in the Operations console is unsealed, and any dialog
box prompting you for a management pack only includes unsealed files.
For example, you might create a set of groups that represent different aspects of your computing environment
such as the data center that certain computers reside in, the support personnel that manage particular
computers, or the applications that different computers support. You want to use those groups to override
monitors and rules that you created in different management pack files.
If you used the Operations console to create the groups in this example in an unsealed management pack file,
you could not use them with other management pack files. You have to use one of the following two strategies
to implement this solution:
Create groups in each management pack file with the overrides. This has the advantage of being easy to
implement without any requirement to seal a management pack file, but it has the disadvantage of requiring
you to potentially create multiple copies of the same group.
Create a separate management pack file for the groups. After you create the groups in the Operations
console, export the management pack to an .xml file, and then seal the .xml file by using the process
described earlier in this article. You can then install the sealed version of the management pack file so that
the groups are available to any other management pack.
See also
Monitors and Rules
Using the Operations Manager consoles
2 minutes to read
System Center – Operations Manager includes two consoles, the Operations console and Web console. The
Comparing the Operations and Web console section provides information on the difference between them, how to
configure them after installation, and how to use the consoles to view the operational data reported by the
monitored services in the enterprise.
Learn How to Connect to the Operations and Web Console in order to access and interact with the
operational data or perform administrative tasks.
Health Explorer gives you the ability to view and then take action on alerts, state changes, and other
significant issues generated by monitoring objects in your enterprise. To learn how to use this feature, see
Using Health Explorer.
In the Operations and Web console, learn how to Use My Workspace to customize views and dashboards
for your specific needs.
Learn what actions you can perform in the Monitoring workspace, Authoring workspace, Administration
workspace, and Reporting workspace.
Understand how Finding data and objects in the Operations console and Using Advanced Search help you
quickly locate the data you need.
Comparing the Operations and Web console
2 minutes to read
System Center Operations Manager includes two consoles, the Operations console and Web console. The
Operations console is the primary tool used for managing your Operations Manager deployment. In the
Operations console, you view and interact with alerts and monitoring data, manage and edit monitoring
configuration, generate and view reports, administer management group settings, and build a personal workspace
that is customized to your needs.
The Web console is a web-based user interface which provides access to all the monitoring data and tasks that are
actions that can be run against monitored computers from the Operations console. It does not have the full
functionality of the Operations console, however, and provides access to only the Monitoring and My Workspace
views.
Both consoles share a similar layout:
Each navigation button opens a specific workspace, such as Monitoring or Administration. In the Operations
console, the following navigation buttons may be available, depending on the user role you are assigned:
In the web console, only Monitoring and My Workspace are available:

TIP
In the Operations console, you can change the navigation buttons into small icons and increase the space available in the
navigation pane by clicking on the top border of the navigation buttons and dragging downward. You can also hide and
reveal the navigation and task panes.
There are a few differences between the Operations console and Web console that you should be aware of:
There are minor differences in sort. For example, in the Web console, when you sort alerts, only the alerts
visible on the page are sorted rather than all alerts.
Fewer alerts display per page in the Web console.
You cannot run tasks that require elevated access in the Web console.
You cannot access event views.
Informational alerts are not presented in an alerts view.
You do not have the options to show, hide, personalize, or create views in the Web console, although you
can create a dashboard view in My Workspace in the Web console.
There are no subscription options in the Web console.
Next steps
Learn what actions you can perform in the Monitoring workspace, Authoring workspace, Administration
workspace, and Reporting workspace.
How to connect to the Operations and Web Console
3 minutes to read
System Center Operations Manager includes two consoles, the Operations console and Web console. To view
operational data and administer the management group configuration, you use the Operations console. The Web
console provides a light-weight interface with essential functionality to view the monitoring data, which avoids
having to manage the lifecycle deployment of the Operations console.
In this section we provide information on how to connect to the Operations and Web console.
How to connect to the Operations console

The System Center Operations Manager Operations console can be installed on any computer that meets the
system requirements. When you open the Operations console on a management server, the console connects to
that management server, however you can use the following procedure to connect to a different management
server. When you initially open the Operations console on a computer that is not a management server, you must
specify the management server to connect to. The following image shows the Connect To Server dialog box.
To connect an Operations console to a management server

1. Click Start, for System Center 2016 - Operations Manager select Microsoft System Center
2016\Operations Console, or for version 1801 and later select Microsoft System Center\Operations
Console to open the Operations console.
2. In the Connect To Server dialog box, type in the server name or select a server from the list. (In the image
above, the console has not yet connected to any management group. If the console has previously
connected to any management servers, the servers will be listed in Recent Connections.)
The Operations console opens with the focus on the Monitoring workspace.
To change the management server that the Operations console is connected to
1. In the Operations console, click Tools and then click Connect... as shown in the following image, which will
open the Connect To Server window.
How to Connect to the Web console
In System Center Operations Manager, the web console provides a monitoring interface for a management group
that can be opened on any computer that has connectivity to the Web console server. The Web console is limited
to My Workspace and the Monitoring workspace.
NOTE
You must use Internet Explorer 11 to connect to the web console in both System Center 2016 - Operations Manager and
version 1801 to access the Silverlight-enabled dashboards. In addition, the Operations Manager web console requires that
JavaScript be enabled and Silverlight version 5 is installed on the client computer. To enable JavaScript in Internet Explorer,
open Internet Options, and click the Security tab. Select the zone for the Web console (Internet, Local intranet, or Trusted
sites), and then click Custom level. Enable Active scripting, click OK, click OK, and then connect to the Web console. The
web console does not support running IE in Compatibility View, otherwise you will receive a blank page when attempting to
access the console. To turn off Compatibility View feature, please see How to use Compatibility View in Internet Explorer
By default, the web console session is limited to 30 minutes. You can change this limit by editing the web.config
file (C:\Program Files\Microsoft System Center 2016\Operations Manager\WebConsole\WebHost is the default
path) and changing the autoSignOutInterval value from "30" to a shorter or longer interval, or disable the session
limit by changing the value to "0", as shown in the following example.
<connection autoSignIn="true" autoSignOutInterval="0">
NOTE
After you change the web.config file, you must open a new Web console session for the changes to take effect.
To connect to a Web console

Open a web browser on any computer and enter http://<web host>/OperationsManager , where web host is the
name of the computer hosting the web console.
For information on installing the Web console, see Install the Operations Manager Web console.
Next steps
In the Operations console, you view monitoring data, manage monitoring configuration, create your own
custom views and dashboards that are personalized for your experience, and perform management group
configuration administration by Using the Operations Manager Operations console.
Operations console refresh optimization
2 minutes to read
In Operations Manager 1801, performance improvements have been implemented in the Operations console
while a new management pack is being imported or deleted, or a configuration change to an MP is saved that
previously prevented the console from responding while these operations were being performed.
On a new install or upgrade of the Operations console, this feature is enabled by default. To provide backwards
compatibility, for any application other than the Operations console, this feature is disabled by default.
How to configure this feature

To modify this behavior for the Operations console, following registry key enables or disables this feature -
HKLM\Software\Microsoft\System Center Operations Manager\12\Setup\Console
“IsCacheUnlockedRefresh
Setting the value to True enables the feature and setting it to False disables the feature.
NOTE
For applications integrating with Operations Manager that require the Operations console, disabling this feature will also
affect the application installed on the system.
Application support
The new refresh logic only applies to your application if it has explicitly enabled it using a new parameter that
needs to be passed when doing an EnterpriseManagementGroup connect. Since this is a new parameter, existing
applications will not be affected and will continue to work fine.
To enable this feature for an application that interoperates with Operations Manager outside of the Operations
console, a new ConnectionSetting mode needs to be added:
EnterpriseManagementConnectionSettings.CacheRefreshMode = CacheRefreshMode.Unlocked .
Using Health Explorer in Operations Manager
2 minutes to read
In System Center Operations Manager, you can use the Health Explorer tool to identify and diagnose failures with
monitored objects. Health Explorer gives you the ability to view and then take action on alerts, state changes, and
other significant issues generated by monitoring objects on your network.
You can start Health Explorer from the Tasks pane after you select an object, alert, or event in the results pane.
Health Explorer organizes health information into the following categories:
Performance
Security
Availability
Configuration
All monitors that are defined for a selected object display in the appropriate category.
The icons used to indicate state are as follows:
ICON MEANING
Unknown, unmonitored (blank)
Success, health is OK (green)
Warning (yellow)
ICON MEANING
Critical (red)
Maintenance mode (gray)
Out of contact (gray)
By default, when the Health Explorer windows first opens, all monitors that are in a failed, or red state are
expanded. If a monitor contains other monitors, as in the case of a roll-up monitor, all monitors are shown in a
hierarchical layout so that monitoring data for all dependent services and applications is displayed. If you want to
view more detail on any dependent monitor, right-click that monitor and then click Monitor Properties to open
another Health Explorer window.
When the Health Explorer window is open, you can review a history of diagnostic tests that have run automatically
and the output from those tasks. You can also run additional diagnostic tasks. Any task that is formatted as a
hyperlink can run directly from the Knowledge tab.
The Health Explorer window refreshes automatically every 30 seconds. Press the F5 function key for an immediate
refresh.
For more information on using Health Explorer, see Using Health Explorer to Investigate Problems.
Next steps
administration by Using the Operations Manager Operations console.
Using My Workspace
4 minutes to read
My Workspace provides you with a private area in the Operations and Web console that you can customize for
your specific needs. Using My Workspace in the Operations console, you can create folders to organize the
workspace, add shortcuts to favorite views, save useful searches, and create views that are only visible to you. In
version 1807, you can create dashboards as well as add an existing dashboard from the Monitoring workspace.
See Using My Workspace in Web console for additional information.
Your configuration of My Workspace will be available to you in any Operations or Web console that you log in to
using the same Windows credentials.
Create folders in My Workspace

My Workspace contains two default folders: Favorite Views and Saved Searches. You can create additional
folders to better organize your workspace. All new folders that you create will be created under Favorite Views.
To create a new folder in My Workspace
1. Right-click in the navigation pane.
NOTE
To create a nested folder, right-click the folder in which you want to create a child folder, and then continue to step 2.
2. Point to New and click Folder.

3. Type a folder name, and then click OK.
Add Shortcuts to views

In My Workspace, you can add shortcuts to any existing views in the Monitoring workspace.
To add a view to My Workspace
1. In the Monitoring workspace, select a view, right-click, and then click Add to My Workspace.
2. Specify the folder in My Workspace where you want the view to appear.
3. Click OK.
When you go to My Workspace, you will see the view that you added listed in the navigation pane.
Save searches
You can save useful searches in My Workspace to run at any time.
To save a search in My Workspace
1. Click Saved Searches.
2. In the Tasks pane, click Create New Search.
3. In the Advanced Search window, select the object type for your search. Your options are:
Alerts
Events
Managed Objects
Monitors
Object Discoveries
Rules
Tasks
Views
Each object type will display a unique set of criteria for your search. For more information on advanced
search criteria, see Using Advanced Search.
4. In the displayed criteria for the object type, select the condition that you want to search against.
5. Each condition that you select is added to the Criteria description. Click the underlined value in each
condition to edit the value. After you edit a value, click OK and then edit the next value. Continue until all
conditions have values specified.
6. Click Save parameters to My Favorites.
7. Enter a name for the saved search and click OK.
You can run saved searches right-clicking a search in the list and then clicking Search Now.
Create views
Views that you create in My Workspace are unique views, not shortcuts to existing views. As an operator, you can
create views in the My Workspace pane. You must have the rights of the Author role to create a view in the
Monitoring workspace.
NOTE
The general instructions in the following procedure do not apply to Diagram, Web Page, or Dashboard views. For more
information on creating a view, see the specific view type in How to Create and Scope Views in Operations Manager.
To create a view in My Workspace

1. Right-click in the folder where you want to store the view and point to New. You can select any view type.
For more information on the view types available, see View Types in Operations Manager.
2. In the view properties, enter a name and description for the view. The view properties dialog box contains
two tabs: Criteria and Display.
On the Criteria tab, in the Show data related to field, specify the item to target. The item you select will
display related conditions in the Select conditions section. For more information, see Creating and
Scoping Views in Operations Manager.
After you select a condition, you can edit the value for that condition in the Criteria description section.
3. In the Show data contained in a specific group field, you can select a group to limit the search results to
members of that group.
4. On the Display tab, select the columns that you want displayed in the view. You can also specify how to sort
the columns and group the items.
5. After you have specified the conditions and values for the view, click OK. The new view will appear in the
navigation pane.
Next steps
administration by Using the Operations Manager Operations console.
To learn how to customize views in the Operations console defined in management packs imported in the
management group, see How to Personalize a View in Operations Manager.
Finding data and objects in the Operations Manager
consoles
3 minutes to read
System Center Operations Manager, with the appropriate management packs imported, will provide you with a
comprehensive view of what is going on with your monitored applications, hardware, and processes. This can
result in a very large volume of data being displayed in the Operations console. Learning how to quickly locate the
data you need is essential to efficient interaction with the console. You can use the Scope, Find, and Search
buttons on the Operations console toolbar to filter your view of monitoring data so that you can find the exact
monitoring object or group of objects that you need. You can also filter your data based on the number of hours or
days you would like to show.
NOTE
Any time that you do not see the information you expect in the results pane, check the scope and time filters to ensure that
the correct objects and time period are set for the results you need.
The Scope, Search, Find, and Time tools apply a temporary filter to the data you are viewing in the console.
While you can locate a specific object using Search or Find, you can also use Scope or Time to display a set of
objects that meet a set of criteria. The following table shows the differences between the different filtering options.
FILTER WHEN TO USE FOR MORE INFORMATION, SEE
Scope Use to limit the data in a view to only - How to Change Scope
those objects that meet your criteria. - Using Groups to Scope Views
This scope remains in place until you
clear it.
Search Use to display a list of objects that meet - How to Use Find and Search
your criteria. You can then act on those - Using Advanced Search
objects; however, when you navigate - Examples of Using Advanced Search in
away from this list, the filter is removed, Operations Manager
and any view will show all objects (not
just those from your search criteria).
Find Use to display a known single object. How to Use Find and Search
How to change scope

Changing the scope of the monitoring view enables you to view only those objects that meet a certain criteria,
such as management servers. For example, if you want to view only those computers in your environment that are
running Windows 2016, you can apply a scope that uses "Windows 2016" as the criteria; no other computers are
displayed.
1. In the Operations console, click Monitoring to display the objects in your monitoring environment.
2. Click the Scope button on the Operations Manager toolbar. If this button is not available, check to make
sure that you have an object, not a folder, selected in the Monitoring pane. The Change View Scope dialog
box displays a list of existing groups and distributed applications.
3. If the list is too long, you can find a specific group or distributed application by entering a word or phrase in
the Look for field. After you make a selection, click OK. Now only the objects that meet the scope criteria
are shown in the Results pane.
How to use Find and Search

Use the Find button when the list of objects in the Results pane is too long to quickly pick out a particular object.
Use the Search button when you want to find all objects that meet a certain criteria.
To use Find to create a list of of objects
1. In the Operations console, click Monitoring.
2. Select a view that is available in the Monitoring workspace. This displays a list of objects in the Results pane.
3. Check to see whether a Look for box is at the top of the Results pane. If there is no Look for box, click the
Find button on the toolbar. In Look for, type a word, such as the name of an object, that you want to find in
the list, and then click Find.
The object that you are looking for is displayed.
4. Click Clear to go back to the original list of objects.
To use Search to create a list of objects
2. Click the Search button on the toolbar.
3. In the Search window, type the word or phrase that describes the set of objects you want to find. A list of
objects that meet your criteria is displayed. The list is sorted by object type.
Next steps
See Using Advanced Search to learn how to search for a specific object type that meets your specified criteria.
Using advanced search
4 minutes to read
In System Center Operations Manager, advanced search is available in My Workspace, when you create a new
search. You can also open advanced search in the Monitoring workspace on the Tools menu.
Use advanced search to search for a specific object type that meets specified criteria. Advanced search has two
steps:
Select the specific object type and criteria
Set the criteria values
You can also save the searches you create.
Select the specific object type and criteria

Each object type will display a unique set of criteria for your search. The following table lists the object types and
the criteria available for each.
OBJECT TYPE CRITERIA ASSOCIATED WITH THE OBJECT TYPE
Alerts - Of a specific severity

- Of a specific priority
- Created by specific sources
- With specific resolution state
- With a specific name
- With specific text in the description
- Created in specific time period
- Assigned to a specific owner
- Raised by an instance with a specific name
- Last modified by a specific user
- That was modified in specific time period
- Had its resolution state changed in a specific time period
- That was resolved in a specific time period
- Resolved by specific user
- With a specific ticket ID
- Was added to the database in a specific time period
- For a specific site
- With specific text in the available custom fields
Events - Generated by specific rules

- With a specific event number
- From a specific source
- Generated in specific time period
- Raised by an instance with a specific name
- With specific severity level
- From a specific user
- Logged by a specific computer
Managed Objects - With a specific name

- In specific health state
- Contained in a specific group
OBJECT TYPE CRITERIA ASSOCIATED WITH THE OBJECT TYPE
Monitors - With a specific name

- The monitor has been overridden for any context (excluding
category overrides)
- With specific category
- Creates an alert when specific state is detected
- The monitor generates alerts of specific priority
- Auto-resolves alerts
- The monitor is a unit monitor
- The monitor is an aggregate monitor
- The monitor is a dependency monitor
Object Discoveries - With a specific name

- The object discovery has been overridden for any context
(excluding category overrides)
- Is enabled
- The object discovery confirms delivery
- The rule is remotable 1
- Was added in a specified time period
- Was modified in a specified time period
Rules - With a specific name

- The rule has been overridden for any context (excluding
category overrides)
- The rule generates alerts of specific priority
- Is enabled
- The rule confirms delivery
- The rule is remotable 1
Tasks - With a specific name

- Is enabled
Views - With a specific name

1A remotable rule or discovery can run against a computer that does not have an agent installed.
Set the criteria values

If you have ever created a rule in Microsoft Outlook, setting criteria values for an advanced search will be familiar
to you. When you select a criterion for an object, it is added to the Criteria description section. Most criteria
contain a variable value. For example, in the criterion With a specific name, specific is a variable and will be
underlined in the Criteria description section. (The criterion Is enabled is only true or false, so it contains no
variables; you either select it or you do not select it.)
To assign a value to the variable, click the underlined portion of the criterion. A dialog box appears. In the example
of With a specific name, you enter a text string for the specific name. For variables with limited values, such as
alert priorities, the dialog box provides checkboxes that you can select.
Running and saving searches

After you set the values for the search criteria, you can run the search by clicking Search or you can save the
search by clicking Save parameters to My Favorites. Saved searches are displayed in My Workspace and can be
run at any time.
When you run a search or a saved search, a window opens with a view appropriate to the object type of your
search. For example, a search on object type Alerts opens an Alert View window. A hyperlinked action, Show
parameters, is displayed below the view title bar. You can click Show parameters to change the search
parameters.
NOTE
When you run a saved search, change the parameters, click Search, and then close the results window, you will be asked if
you want to save the changes to the search.
Examples of using advanced search in Operations Manager

The following table lists examples of using advanced search to find objects in Operations Manager:
TO FIND USE THIS OBJECT, CONDITION, AND VALUE
All alerts closed in the previous 2 hours. - Object: Alerts

- Condition/Value: With specific resolution state/Closed
- Condition/Value: That was resolved in a specific time
period/Last 2 Hours
All rules that have overrides - Object: Rules

- Condition: the rule has been overridden for any context
(excluding category overrides)
All monitors that auto-resolve alerts - Object: Monitors

- Condition: auto-resolves alerts
All Unix computers in a warning or critical state - Object: Managed Objects

- Condition/Value: In specific health state/warning, critical
- Condition/Value: Contained in a specific group/Unix
Computer Group
Next steps
To filter your view of monitoring data so that you can find the exact monitoring object or group of objects that you
need, see Finding Data and Objects in the Operations Manager Consoles.
Using the Operations Manager Operations console
2 minutes to read
In System Center Operations Manager, the Monitoring workspace is the primary workspace for operators,
network and system engineers, and service desk. The Monitoring workspace is basically the same in both the
Operations and Web consoles.
When you open the Monitoring workspace, you see an overview that summarizes the health of distributed
applications and computers, as well as the objects that are in maintenance mode, as shown in the following image.
In the State and Alerts overview, click any of the numbers to see a detailed view. For example, if you click the
number shown for Maintenance Mode, a state view of all computers in maintenance mode opens.
The health states that are summarized in the overview only tell you part of what is going on in your environment.
You will also want to review the alerts that have been generated. In the navigation pane, click Active Alerts to see
all alerts. For more information about dealing with alerts, see Managing Alerts.
There are number of views and dashboards in the Monitoring workspace that allow you to view the status of
your environment. For information on each view, see Standard Views in Operations Manager. Dashboards allow
you to consolidate and visualize operational data from different perspectives to make meaningful decisions. For
more information, see Dashboards in Operations Manager. You can also change the display options of a view and
save it as a personalized view. For more information, see How to Personalize a View in Operations Manager.
As you work with Operations Manager, you may discover that there are specific views that you frequently access.
You can create a customized workspace that displays your favorite views and searches. For more information, see
Using My Workspace in Operations Manager.
Next steps
To filter your view of monitoring data so that you can find the exact monitoring object or group of objects
that you need, see Finding Data and Objects in the Operations Manager Consoles.
Learn how to use Health Explorer to understand the state of monitored objects in your environment by
reviewing Using Health Explorer to Investigate Problems.
Using the Administration workspace in Operations
Manager
6 minutes to read
In the System Center - Operations Manager Operations console, the Administration workspace is the primary
workspace for administrators. You use the Administration workspace to configure a management group.
When you first open the Administration workspace or when you click Administration in the navigation pane, the
Administration Overview opens, which displays task links for any required or optional configuration steps that
have not been completed yet.
The sections below describe the different options in the Administration workspace and link to more detailed
information about the task or option.
Connected Management Groups

You can connect management groups to enable the forwarding of alerts and other monitoring data from a
connected management group to the local management group. Tasks can be initiated from a local management
group to run on managed objects of a connected management group.
Use Connected Management Groups in the Administration workspace to connect a management group or to
edit the properties of a connected management group.
For more information, see Connecting Management Groups in Operations Manager.
Device Management
You can use Device Management to perform configuration of specific management servers, agent-managed
computers, agentless-managed computers, UNIX servers, and Linux servers. The following table summarizes the
uses of the items in Device Management and provides links to more detailed information.
ITEM USE FOR MORE INFORMATION
Agent Managed To modify the configuration of agent- - Configure agent on Windows

managed computers, such as: computers
- Upgrade and uninstall Windows agent
- Change the primary management - Upgrade and uninstall UNIX/Linux
server for agent-managed computers. agent
- Repair the agent installation. - Agentless Monitoring in Operations
- Uninstall an agent. Manager
- Override the management group
agent heartbeat settings on a specific
agent. A heartbeat is a periodic pulse
from an agent to its management
server.
- Configure an agent-managed
computer as a proxy for agentless-
managed computers.
Agentless Managed To change the proxy agent for an Agentless Monitoring in Operations
agentless-managed computer. The Manager
proxy agent can be any agent-managed
computer in the management group
configured to be a proxy.
Management Servers To modify the configuration of - How Heartbeats Work in Operations

management servers, such as: Manager
- Manage manual agent installs
- Override the management group - Agentless Monitoring in Operations
heartbeat failure setting and configure Manager
the number of missed heartbeats a - How to Configure the Internet Proxy
management server will allow for an Settings for a Management server
agent before it changes the state of the
respective computer to critical.
- Override the Management Group
Manual Agent Installs setting and
configure a management server to
reject or put in Pending Management
agents installed with MOMAgent.msi.
- Configure a management server as a
proxy for agentless managed
computers.
- Configure the Internet proxy settings
for a management server.
Pending Management To approve or reject an agent that was Process Manual Agent Installations
installed with MOMagent.msi if the
management group for the agent is
configured to Review new manual
agent installations in pending
management view but not Auto-
approve new manually installed
agents. Agents pending approval are
displayed for this item.
UNIX/Linux Servers To modify the configuration of agent- - Agent deployment planning

managed UNIX and Linux servers. - Discover and install agent on
UNIX/Linux
Management Packs
Under the Management Packs node in the Administration workspace, you can perform several tasks related to
the management of the management packs imported into your management group. The following table
summarizes the uses of the items under Management Packs and provides links to more detailed information.
Installed Management Packs Lists all management packs imported How to import, export, remove
into your management group. management packs
Tune Management Packs Highlight the management packs and Data driven alert management
its workflows which generate a high
volume of alerts.
Updates and Recommendations Identify new technologies or workloads MP Updates and Recommendations
that are not monitored by Operations
Manager or not monitored with the
latest version of a management pack.
For more information, see Management pack overview.
Network Management
You can use Network Management in the Administration workspace to discover network devices and managed
discovered network devices. The following table summarizes the uses of the items in Network Management and
provides links to more detailed information.
Discovery Rules - To create rules for discovering How to Discover Network Devices in
network devices Operations Manager
- To modify existing discovery rules
Network Devices To view properties of discovered Monitoring Networks by Using

network devices Operations Manager
Network Devices Pending Management To retry or reject discovered network How to Discover Network Devices in
devices that are pending management Operations Manager
Notifications
Notifications generate messages or run commands automatically when an alert is raised on a monitored system.
By default, notifications for alerts are not configured. For Operations Manager users to be notified immediately
when an alert is generated, you need to configure a channel for notifications, add subscribers, and then create a
notification.
In Notifications in the Administration workspace, you can create channels, subscribers, subscriptions, and modify
the channels, subscribers, and subscriptions that you create. For more information, see Subscribing to Alert
Notifications.
Product Connectors
Product connectors are used to synchronize Operations Manager data with other management systems such as
those that monitor non-Windows computers or create trouble-tickets. Product connectors can integrate a
deployment of Operations Manager into another management platform or connect other management systems
into a full Operations Manager management solution. Any product connectors that you integrate with Operations
Manager will be displayed in this section of the Administration workspace.
When you install Operations Manager, two internal product connectors are installed. These are used by
Operations Manager.
For more information, see Connecting Operations Manager With Other Management Systems.
Run As Configuration
You can use Run As Configuration in the Administration workspace to manage Run As accounts and profiles.
For more information, see Managing Run As accounts in Operations Manager.
Security
In Operations Manager, operations such as resolving alerts, running tasks, overriding monitors, viewing alerts,
viewing events, and so on have been grouped into user roles, with each user role representing a particular job
function. Role-based security allows you to limit privileges that users have for various aspects of Operations
Manager. In Security in the Administration workspace, you can add and remove users to specific user roles. You
can also modify the properties of user roles that you create.
For more information, see Implementing User Roles.
Settings
The following table summarizes the settings you can manage in Settings in the Administration workspace.
Agent Heartbeat Agents generate a heartbeat at specific How Heartbeats Work in Operations
intervals to ensure they are operating Manager
properly. You can adjust the interval.
Alerts - To configure alert resolution states. - How to Set Alert Resolution States
- To configure automatic alert - How to Configure Automatic Alert
resolution. Resolution
Database Grooming To configure how long different types of Maintenance of Operations Manager
data should be retained in the
operational database.
Privacy To modify the settings for the following Sending Data to Microsoft in the
programs: Deployment Guide
- Customer Experience Improvement

Program (CEIP)
- Operational Data Reporting
- Error Reporting
Reporting Configure the path for the reporting Using the Reporting Workspace in
server. Operations Manager
Web Addresses Designate web addresses for the Web How to Connect to the Web Console
console and online company
knowledge.
Server Heartbeat Configure the number of missed How Heartbeats Work in Operations
heartbeats before the management Manager
server pings the agent-managed
computer.
Server Security Specify how the management server Process Manual Agent Installations
should handle manually-installed
agents.
Using the Authoring Workspace in Operations
Manager
4 minutes to read
The options in the Authoring workspace allow you to create new monitoring scenarios. This could be to change or
add monitoring in an existing management pack or to create a new management pack for an application that
doesn't have one.
Authoring is described in detail in the Operations Manager Authoring Guide. The sections below describe the
different options in the Authoring workspace.

Management Pack Templates allow you to create complete monitoring scenarios with minimal input. Once you
complete a wizard, the management pack template creates monitors, rules, and even classes to implement the
particular scenario. There is no requirement for you to understand the management pack elements that are
created since you can continue to use the template to perform configuration. It will make any necessary
modifications to the underlying elements.
.NET Application Performance Monitoring Monitor your Windows ASP.NET and WCF Applications hosted
on IIS 7.0, 8.0 and 10.0, including Windows Services that use
.NET Framework.
OLE DB Data Source Monitor the availability and performance of a database.

Sample queries can be executed from one or more watcher
nodes.
Process Monitoring Monitor the availability and performance of a wanted process

or verify that an unwanted process is not running.
TCP Port Monitor the availability of an application listening on a specific

TCP port. Test can be performed from one or more watcher
nodes.
TFS Work Item Synchronization Links Operations Manager alerts and Team Foundation Server
work items.
Unix/Linux LogFile Monitor a Unix or Linux log file for a specific log entry one a
specific computer or group of computers.
Unix/Linux Service Monitor the availability of a service on a Unix or Linux

computer or group of computers.
Windows Service Monitor the availability and performance of a service running

on one or more Windows computers.
Web Application Availability Monitoring Create an availability monitoring test for one or more Web
Application URLs.
Web Application Transaction Monitoring Create a monitoring test of a Web Application to verify
availability and performance.
Distributed Applications
Distributed Applications allow you to group together multiple components that are part of a single application.
The health of each included object are used to calculate an overall health for the application itself. This health can
be used to support alerts, views, and reports.
Groups
Groups contain a particular set of managed objects. They are used to scope views, reports, and certain monitoring
scenarios. Criteria can be provided to automatically populate a group based on properties of the objects, or you
can add specific objects to a group.You can create new groups and edit existing groups. You can also view the
current members of a group. Once it has been created, a group can be used in the Monitoring workspace for
scoping views, the Reporting workspace for scoping reports, or in the Authoring workspace for overrides,
management pack templates, or service level objects.
Management Pack Objects

The Management Pack Objects section provides access to the different elements that are available. Depending on
the kind of object, you may be able to create new objects, edit existing objects, or view existing objects.
Attributes An attribute is a property of a class in a management pack.

You can add additional attributes to collect additional
information about managed objects. These attributes can be
used to support group membership or accessed by monitors
or rules.
Monitors Monitors are workflows that run on an agent and determine

the current health of an object. Each monitor uses a particular
data source as the event log, performance data, or a script to
collect its information.
You can create new monitors and edit existing monitors in the
Operations console for specific monitoring scenarios which will
address the requirements of most users. More complex
monitors must be created and modified using the Authoring
console.
Object Discoveries Object Discoveries are workflows that run on an agent and
discover objects to manage.
You cannot create new object discoveries in the Operations

console. You can view existing object discoveries in
management packs and use overrides to modify the
frequency that they run and potentially other parameters.
Overrides Overrides are used to change parameters on workflows

including monitors, rules, and discoveries.
Overrides are created from the property page of the workflow

that they apply to. This option allows you to view and modify
existing overrides.
Rules Rules are workflows that run on an agent that create an alert,
collect information for analysis and reporting, or run a
command on a schedule. Each rule uses a particular data
source as the event log, performance data, or a script to
collect its information.
You can create new rules and edit existing rules in the
address the requirements of most users. More complex rules
must be created and modified using the Authoring console.
Service Level Tracking Service Level Tracking allows you to compare the availability
of managed objects to a specific object.
This option allows you to create new Service Level Objectives

and edit existing Service Level Objectives.
Tasks Tasks are workflows that run when you request them in the
Operations console. Agent tasks run on one more agent
computers. Console tasks run on the Operations console
workstation.
You can create new tasks and edit existing tasks in the
address the requirements of most users. More complex tasks
must be created and modified using the Authoring console.
Views Views display managed objects and collected data in the

Operations Console.
Views are created and modified in the Monitoring workspace.

This option displays the existing views available for each target
class.
Next steps
Review Creating and managing groups and learn how to use groups to collect monitoring objects into
manageable units for granular configuration management in the management group.
Using the Reporting Workspace in Operations
Manager
2 minutes to read
System Center Operations Manager provides extensive reporting capabilities, including multiple report libraries
that you can select from to customize reports for your specific requirements. Reports perform a query against the
data warehouse database and return the results in an easy-to-read format.
IMPORTANT
Users must be a member of the Report Operator Users role to run reports.
Reporting
Reporting in the Reporting workspace contains all reports installed with Operations Manager, as well as those
reports included in management packs that you have imported.
The report library contains generic reports (for example, Availability and Configuration Changes reports). Generic
reports have no specified context. The context for the report is defined in the parameter header, located at the top
of the Report window. For a list of reports included with Operations Manager, review Operations Manager reports
library.
Authored Reports
Authored reports are based on existing reports from the report library. You configure a report with prepopulated
parameters, and then make it available to other users.
After you run a report, click File, and then click Publish to publish the report with the configured parameters to
Authored Reports.
Favorite Reports
You can save configured reports to Favorite Reports to make them continually available to you and to save you
the time of reconfiguring a report you run frequently.
After you run a report, click File, and then click Save to favorites to save the report.
Scheduled Reports
You can schedule configured reports to run on a one-time or recurring basis.
After you run a report, click File, and then click Schedule to configure the report subscription. For more
information, see Scheduling Reports.
Next steps
Review How to create reports in Operations Manager to learn how create reports for your operational
needs.
Operations Manager reports library
8 minutes to read
System Center Operations Manager provides the reports described in the following tables. For more information
on a report, in the Reporting workspace, click the report and view the Report Details. For information on
reports that are provided by other management packs, see the respective management pack guides.
NOTE
When you first install Operations Manager, it may take several minutes for all report libraries to appear in Reporting.
Microsoft Generic Report Library

REPORT DESCRIPTION
Alert Logging Latency This report helps to isolate issues in monitoring with
Operations Manager by showing the logging latency of an
alert for selected objects over time.
Alerts This report shows alerts raised during the selected report
duration and for given filter parameters for selected objects.
Availability This report shows the time in state for selected objects during
the selected report duration. Time in state is summarized by
default as per the objects' availability monitors.
Configuration Changes This report shows the changes in configuration for selected
objects over time.
Custom Configuration This report shows configuration data filtered by all entered
parameters.
Custom Event This report shows event data filtered by all selected
parameters.
Event Analysis This report shows a table of events and a count by server
filtered by all entered parameters.
Health This report shows the time in state for selected objects during
the selected report duration. Time in state is summarized by
default as per the objects' overall entity health.
Most Common Alerts This report shows the most common alerts raised during the
selected report duration and for given filter parameters for
selected objects.
Most Common Events This report shows the most common events raised during the
selected report duration and for given filter parameters for
selected objects.
REPORT DESCRIPTION
Overrides This report shows overrides configured in or applied to

selected management packs over time.
Performance This report shows selected objects and performance counter

values graphically over time.
Performance Detail This report shows selected objects and performance counter
values graphically over time.
Performance Top Instances This report shows the top or bottom "N" instances for
selected objects and a specific performance counter rule.
Performance Top Objects This report shows the top or bottom "N" objects for selected
objects and a specific performance counter rule.
Client Monitoring Views Library

REPORT DESCRIPTION
Top N Applications This report shows the top "N" applications based on their
crash count and provides details for each application.
Top N Applications Growth and Resolution This report shows the top "N" applications based on their
growth percentile computed against two specified time
intervals.
Top N Error Groups This report shows the top "N" error groups based on their
crash count.
Top N Error Groups Growth and Resolution This report shows the top "N" error groups based on their
growth percentile computed against two specified time
intervals.
Microsoft Data Warehouse Reports

REPORT DESCRIPTION
Data Warehouse Availability This report shows the availability of the data warehouse
components based on the monitor "Data Warehouse
Connectivity and Processes State".
Data Warehouse Events This report shows data warehouse-related events to help
determine data warehouse health.
Data Warehouse Properties This report shows data warehouse properties and grooming
settings.
Microsoft ODR Report Library

REPORT DESCRIPTION
Alerts Per Day This report shows the number of alerts generated per day
from each rule or monitor that alerted within the report
period (by default one week).
Instance Space This report shows the number of instances of each class (for
example, Exchange Servers) that are created in your
management group.
Management Group This report shows the operating system version used in the
Operations Manager infrastructure (management servers).
Management Packs This report shows the versions of each management pack
that is installed in your environment. It also summarizes all
the overrides you have defined in your environment, as well
as custom rules and monitors you have authored.
Most Common Alerts This report shows the most common alerts generated within
the report period (by default one week). It also shows this
data by management pack.
System Center Core Monitoring Reports

REPORT DESCRIPTION
Agent Counts by Date, Management Group and Version This report shows detail information for agent accounts
during specified time interval.
Agents by Health State This report shows lists of agents organized by health state.
Data Volume by Management Pack This report shows the volume of data generated by
management packs. The purpose of this report is to provide
insight into which management packs are driving the data
volumes in your environment so that you can establish
baselines and identify opportunities for tuning. From this
report, you can obtain more specific details per management
pack by clicking one of the counts cells in the table at the top
of the report to open the Data Volume by Workflow and
Instance report for the management packs.
Data Volume by Workflow and Instance This report shows the volume of data generated, organized
by workflows (discoveries, rules, monitors, etc.), as well as by
instances.
Microsoft Service Level Report Library

REPORT DESCRIPTION
Service Level Tracking Summary Report This report shows whether the configured Service Level
Objectives (SLOs) met their respective goals, for selected
service levels.
Web Application Availability Monitoring Solutions Library

REPORT DESCRIPTION
Test Availability This report shows availability reported by an individual test

over time.
Test Performance This report shows selected objects and performance counter
values over time to relate how well a web application has
performed.
Web Application Availability This report shows how available the web application was. The
web application availability is the rollup of all tests defined in
your web application.
Application Monitoring Reports

REPORT DESCRIPTION
Application Failure Analysis This report provides detailed failure analysis for a selected
application.
Application Performance Analysis This report provides detailed performance analysis for a
selected application
Application Status This report provides daily, weekly and monthly application
status summaries.
Problems Distribution Analysis This report shows the distribution of performance,

connectivity, security and code problems across all monitored
applications, highlighting the applications that are most
problematic.
Summary Failure Analysis This report provides a breakdown of problems by application.
Summary Performance Analysis This report provides a breakdown of performance violations

by application.
Summary User Analysis This report highlights the application users who experience
most of the problems.
(Client Side Monitoring) Application AJAX Calls Analysis This report provides detailed failure analysis for a selected
application.
(Client Side Monitoring) Application Analysis This report provides an overview of activity, performance and
exception statistics for a selected application.
(Client Side Monitoring) Application Status This report provides daily, weekly and monthly application
status summaries.
(Client Side Monitoring) Client Latency Distribution This report provides an analysis of client side performance in
relation to network latency.
(Client Side Monitoring) Load Time Analysis Based on Subnet This report provides an analysis of client side performance
based on client subnets.
REPORT DESCRIPTION
(Client Side Monitoring) Summary Performance Analysis This report provides an analysis of performance violations by
application.
(Client Side Monitoring) Summary Size Analysis This report provides an analysis of content size across
multiple applications and shows the correlation between
content size and load time.
(Client Side Monitoring) Summary User Analysis This report highlights the application users who experience
most of the problems.
(Problem Analysis Reports) Application Activity Breakdown This report shows application activity trends for a selected
period in relation to an application's activity during a previous
period and average application activity.
(Problem Analysis Reports) Application Daily Activity This report shows application activity trends for a selected
day in relation to an application's activity during a previous
period and average application activity.
(Problem Analysis Reports) Application Failure Breakdown by This report shows the list of application requests that
Functionality experience most of the problems.
(Problem Analysis Reports) Application Failure Breakdown by This report provides failure analysis for distributed
Resources applications based on the application components and
external resource dependencies.
(Problem Analysis Reports) Application Heavy Resources This report provides performance analysis for distributed
Analysis applications based on the application components and
external resource dependencies.
(Problem Analysis Reports) Application Slow Request Analysis This report shows the breakdown of application performance
violations based on application requests.
(Problem Analysis Reports) Day of Week Utilization This report shows application activity trends and application
resource utilization trends for a selected period.
(Problem Analysis Reports) Hour of Day Utilization This report shows application activity trends and application
(Problem Analysis Reports) Utilization Trend This report shows application activity trends and application
(Resource Utilization Analysis) Application CPU Utilization This report highlights applications that have the heaviest CPU
Analysis utilization and provides a breakdown of CPU utilization based
on the servers which host the application.
(Resource Utilization Analysis) Application IO Utilization This report highlights applications that have the heaviest IO
Analysis utilization and provides a breakdown of IO utilization based
on the servers which host each application.
(Resource Utilization Analysis) Application Memory Utilization This report highlights applications that have the heaviest
Analysis memory utilization and provides a breakdown of memory
utilization based on the servers which host each application.
(Resource Utilization Analysis) Application Request Utilization This report provides an analysis of application based on the
Analysis volume of processed requests.
REPORT DESCRIPTION
(Resource Utilization Analysis) Computer Application Load This report provides an analysis of servers based on the
Analysis volume of processed requests.
(Resource Utilization Analysis) Computer CPU Utilization This report highlights servers that have the heaviest CPU
Analysis utilization and provides a breakdown of CPU utilization based
on the monitored applications running on each server.
(Resource Utilization Analysis) Computer IO Utilization This report highlights servers that have the heaviest IO
Analysis utilization and provides a breakdown of IO utilization by
monitored applications running on each server.
(Resource Utilization Analysis) Computer Memory Utilization This report highlights servers that have the heaviest memory
Analysis utilization and provides a breakdown of memory utilization
based on the monitored applications running on each server.
Next steps
needs.
See How to Configure and Modify Report Schedules to learn how to schedule report delivery for reports
available in Operations Manager.
How to create reports in Operations Manager
6 minutes to read
Operations Manager includes a number of reports when you install a management group, to help you review the
operational telemetry and configuration information to help troubleshoot issues or problems, review the day-to-
day health of your IT services, and make decisions that drive changes in capacity planning or service operations of
the service.
Operational Data report

The Microsoft Customer Experience Improvement Program (CEIP ) collects information about how you use
Microsoft programs and about some of the issues you might encounter. Microsoft uses this information to
improve the products and features you use most often and to help solve issues. Participation in the program is
strictly voluntary.
During setup of Operations Manager Reporting, on the Operational Data Reports page, you had the option to
join CEIP. If you elected to join CEIP, Operations Manager Reporting collects information about your installation
and sends reports to Microsoft on a weekly basis. You can view the contents of these Operational Data Reports by
creating a Microsoft ODR Report.
Create an Operational Data report
1. Log on to the computer with an account that is a member of the Operations Manager Report Operators
role.
2. In the Operations console, click Reporting.
3. In the Reporting workspace, expand Reporting, and then click Microsoft ODR Report Library.
4. In the Reports pane, right-click one of the reports (for example, Management Packs), and then click
Open.
5. In the Report view, in the Parameter area, click the down arrow in the From box, point to This week, and
then click Sunday.
6. Click the down arrow in the To box, point to This week, and then click Saturday.
7. Click Run to display the ODR Report.
8. Click Close to close the report.
Create an Event Analysis report

Use the following procedure to create an event analysis report.
3. In the Monitoring workspace, expand Monitoring, and then click Windows Computers.
4. In the Windows Computers pane, click a row containing a Health Service instance.
5. In the Tasks pane, under Report Tasks, click Event Analysis.
6. In the Reporting Parameter area, click the down arrow in the From box, and then click Yesterday.
NOTE
You can further specify the timeframe for the report in the additional options in the Reporting Parameter area.
7. In the Reporting Parameter area, under Monitoring Object, click Add.

8. In the Add Object dialog box, in the Object Name list, click the down arrow, and then click Begins with.
9. In the Object name text box, type the computer name for the computer you selected in step 4, and then
click Search.
10. In the Available items list, click the computer with the Type of Health Service, click Add, and then click
OK.
11. In the Reporting Parameter area, in the Monitoring Object list, click the entry that is not of the type
Health Service, and then click Remove.
12. Click Run to display the Event Analysis Report.
Availability report
The following procedure is an example of how you create an availability report for a managed computer. The
procedure presented here is applicable to creating other types of availability reports. In this example procedure,
you generate a report for the entire week.
NOTE
Operations Manager Reporting must be installed before you can run an Availability report.
The availability report provides the following information about the selected computers:
Down - computer state is critical (red)
Up - computer state is healthy (green)
Yellow - computer state is warning (yellow )
Unmonitored - computer or monitor did not exist during reporting period
Monitor disabled - monitor has been disabled, such as by using an override
Monitoring unavailable - the System Center Management Health service monitoring the computer is
unavailable
Planned/unplanned maintenance - computer is in maintenance mode; overrides all other states
Create an Availability report
4. In the Windows Computers pane, click the row, or rows, that represent the computer for which you want
to run an availability report.
5. In the Tasks pane, under Report Tasks, click Availability.
then click Sunday.
7. Click the down arrow in the To box, point to This week and then click Saturday.
8. Click Use business hours.
NOTE
You can further specify the timeframe for the report in the additional options in the Parameter area.
9. When you have specified the timeframe for the report, click Run to display the Availability Report.
10. For a more detailed report, such as a report showing a graph for every day, click the horizontal bar graph
under Availability Tracker.
11. In the tool bar, click View, point to Go To, and then click Back to Parent Report to return to the original
report.
Alerts report
An alerts report summarizes alerts that have occurred on a managed entity. The following procedure is an
example of how you create an alerts report for a managed computer. The procedure presented here is applicable
to creating other types of alerts reports. In this example procedure, you generate a report for the previous 24-
hour period.
NOTE
Operations Manager Reporting must be installed before you can run an alerts report.
Create an Alerts report

3. In the Monitoring workspace, expand Monitoring, and then click Wndows Computers.
4. In the Windows Computers pane, click a row with a Health Service instance.
5. In the Tasks pane, under Report Tasks, click Alerts.
6. In the Reporting Parameter area, click the down arrow in the From box and then click Yesterday.
NOTE
You can further specify the timeframe for the report in the additional options in the Reporting Parameter area.
7. Click Run to display the Alert Report.

Alert Logging Latency report

The following procedure is an example of how you create an alert logging latency report for a managed computer.
An alert logging latency report shows you how much time it took from when an alert was generated until it was
written into the Operations Manager database. An alert is not displayed in the Operations console until after it is
written into the Operations Manager database. Alert latency can be a function of network delays in your
environment.
This information is useful when considering service level agreements (SLA). You might not want to commit to an
SLA of 2 minutes if alerts take longer than that to get written into the Operations Manager database.
NOTE
Operations Manager Reporting must be installed before you can run an alert logging latency report.
Create an Alert Logging Latency report

3. In the Monitoring workspace, expand Monitoring and then click Windows Computers.
4. In the Windows Computers pane, click a row with a Health Service instance.
5. In the Tasks pane, under Report Tasks, click Alert Logging Latency.
6. In the Parameter Area, click the down arrow in the From box and then click Yesterday.
NOTE
You can further specify the timeframe for the report in the additional options in the Parameter Area.
7. Click the down arrow on the Threshold list, and select the latency threshold you want to measure.
8. Click the down arrow on the Aggregation Type list, and click the value you want for this report.
9. Click Run to display the Alert Logging Latency Report.
Next steps
How to run, save, and export a report
3 minutes to read
You can view reports in Operations Manager by selecting it, entering the required parameters and executing it.
Once you run it, you can also choose to save the configuration to a linked report, which deploys that report with
different settings. You can export a report to another file format, such as PowerPoint, Image, PDF, Microsoft
Word, or Microsoft Excel for your reporting users.
Before exporting or saving the report parameters, you must first run the report.
To run a report from the Reporting pane

Use the following procedure to run a report from the Reporting workspace. In this example, you will run an
availability report.
role.
3. In the Reporting workspace, expand Reporting and then click Microsoft Generic Report Library.
4. In the Reports pane, right-click one of the reports (for example, Availability) and then click Open.
then click Sunday.
6. Click the down arrow in the To box, point to This week and then click Saturday.
7. Click Use business hours.
NOTE
You can further specify the timeframe for the report in the additional options in the Parameter area.
8. Click Add Object.

9. In the AddObject dialog box, in the ObjectName text box, type the computer name for a computer that
you want to report availability, and then click Search.
10. In the Available items list, click the computer you want to run a report for, click Add, and then click OK.
11. Click Run to display the Availability Report.
12. For a more detailed report, such as a report showing a graph for every day, click the horizontal bar graph
under Availability Tracker.
13. In the toolbar, click View, point to GoTo, and then click Back to Parent Report to return to the original
report.
How to save a report

When you run a report, you can save the report to Favorite Reports or you can save a report into an existing
management pack. A report saved to Favorite Reports is only visible to you. Saving a report to an unsealed
management pack is useful if you need to share with report users that includes a specific set of parameters.
The following steps outline the procedure for saving a report to a management pack:
1. Run a report from the Generic Report Library or from another management pack, such as the SQL Server
management pack. Specify the parameters you want to for the report and click Run.
2. When the report renders, validate that it contains the information you need.
3. On the File menu, click Save to management pack.
4. Follow the instructions in the wizard to save the report.
After the wizard completes, the management pack is saved to Operations Manager and then later deployed to the
report server and is made available for all report operators.
NOTE
Be aware of the following when saving reports:
Reports can be saved to a management pack from Favorite Reports.
Reports cannot be saved to a management pack from authored reports.
Management packs can be exported and imported into other management groups and the reports will work only when
these management groups share the same data warehouse.
Only users who are members of the Report Operators group can save reports to management packs.
How to export a Report

After a report has been run, you can export the report into one of several formats supported by SQL Server
Reporting Services. To learn about what formats are supported by SQL Server Reporting Services, please review
Export Reports
NOTE
Operations Manager Reporting must be installed before you can run a report.
If you want to manage and distribute reports securely, you can export reports to Microsoft Windows SharePoint
Services, which offers digital rights management. Consult your network security administrator.
1. After a report has been run, in the toolbar, click the File menu, point to Export, and then click the format
you want to export the file to.
2. In the Save As dialog box, select the folder where you want to save the report, and then click Save.
Next steps
explore the operational data and configuration information in your management group and follow the
How to create reports in Operations Manager to create reports for your operational needs.
See How to Schedule Reports to learn how to schedule report delivery for reports available in Operations
Manager.
If you are having issues where reports are not returning any data, review How to Troubleshoot Reports
that Return No Data.
How to configure and modify report schedules
6 minutes to read
Operations Manager Reporting server component provides report-specific schedules to help you control
processing and distribution of reports. Once you have configured a schedule for a report, it can be managed from
the Reporting workspace, under the Scheduled Reports node in the Operations console.
To create a report schedule

Use the following procedure to create a schedule from a saved report. Report schedules can be created after the
report open or when saved as a Favorite report. The following steps will show you how to create a schedule from
a saved report, however; the same steps for configuring the schedule can be performed from an open report by
selecting File, Schedule.. from the main menu.
For more information on how to run and save a report, see How to Run, Save, and Export a Report.
role.
3. In the Reporting workspace, click Favorite Reports.
4. In the Favorite Reports pane, right-click the Availability report you saved as a favorite, and then click
Schedule.
5. In the Subscribe to a Report Wizard, on the Delivery Settings page, do the following:
a. Type a description in the Description text box.
b. Click the down arrow in the Delivery method list, and then click Report Server File Share.
c. Type a file name for the report in the File name text box.
d. Type a file path for the report in the Path text box. Report scheduling supports Universal Naming
Convention (UNC ) file names and must not end in a backslash.
e. Click the down arrow in the Render Format list, and then click the file format you want for the
report.
f. Type a user name in the User name text box, and then type a password in the Password text box.
NOTE
The credentials must have Write user rights on the file share.
g. Click the down arrow in the Write mode list, select the Write mode you want for subsequent files,
6. In the Subscribe to a Report Wizard, on the Subscription Schedule page, do the following:
a. Select one of the Generate the report options.
b. Type a start date and start time for the reports to be generated in The Subscription is effective
beginning list. You can also enter the date when this subscription will end in The subscription
expires on list, and then click Next.
7. In the Subscribe to a Report Wizard, on the Parameters page, specify a span of time for the report in
the From and To lists.
8. Make any other changes you need for this report, and then click Finish.
How to Email scheduled reports

The report server e-mail delivery extension is not configured by default. You must use the Reporting Services
Configuration Manager to minimally configure the extension. For additional information on how to configure
SQL Server Reporting Services for e-mail delivery, see Configure a Report Server for E -Mail Delivery (SSRS
Configuration Manager).
Configure email settings in the SQL Server Report Server
1. Verify that the Report Server Windows service has Send As permissions on the SMTP server.
2. Start the Reporting Services Configuration Manager and connect to the report server instance.
3. On the Email Settings page, enter the name of the SMTP server. This value can be an IP address, a UNC
name of a computer on your corporate intranet, or a fully qualified domain name.
4. In Sender Address, enter the name an account that has permission to send e-mail from the SMTP server.
5. Click Apply and then click Exit.
E-mail scheduled reports
role.
4. In the Favorite Reports pane, right-click a report you saved as a favorite, and then click Schedule.
b. Click the down arrow in the Delivery method list, and then click Report Server E -Mail.
c. Type an email address of the destination inbox to receive reports in the To text box. You can also
type email addresses in the Cc, Bcc, and the Reply To text boxes.
d. Click the down arrow in the Render Format list, and then click the file format you want for the
report.
e. Click the down arrow in the Priority list, and then select the appropriate priority.
f. Type a subject for the email in the Subject text box.
g. Click Next.
6. On the Subscription Schedule page, do the following:
beginning list. You can also enter the date when this subscription will end in The subscription
expires on list, and then click Next.
7. On the Parameters page, specify a span of time for the report in the From and To lists, make any other
changes you need for this report, and then click Finish.
Edit a scheduled report

Use the following procedure to edit settings for scheduled reports from the Reporting pane in Operations
Manager.
role.
3. In the Reporting workspace, click Scheduled Reports.
4. In the Scheduled Reports pane, right-click the scheduled report you want to edit, and then click Edit
Schedule.
5. In the Subscribe to a Report Wizard, on the Delivery Settings page, if you select the Windows File
Share as a Delivery method, you must type the password in the Password text box before you can make
any other changes.
6. Type any other changes you need on the Delivery Settings page, and then click Next.
7. Type any changes you need to make on the Subscription Schedule page, and then click Next.
8. Type any changes you need to make on the Report Parameters page, and then click Finish.
Cancel a scheduled report

Use the following procedure to cancel scheduled reports.
role.
3. In the Reporting workspace, click Scheduled Reports.
4. In the Scheduled Reports pane, right-click the scheduled report you want to cancel, and then click Cancel
Schedule.
5. In the System Center Operations Manager dialog box, click OK to confirm the deletion of your schedule
or click No to keep your schedule.
Schedule the delivery of a report to the SQL Report Server Cache

You can create a schedule for sending reports to the cache in the SQL Server Report Server and thereby shorten
the time required to retrieve a report if the report is large or accessed frequently. For more information about
report caching, see Caching Reports (SSR ).
The example in this procedure uses an availability report that you have already created and saved as a favorite.
role.
4. In the Favorite Reports pane, right-click the availability report you saved as a favorite, and then click
Schedule.
b. Click the down arrow in the Delivery method list, and then click Null Delivery Provider.
c. Click Next.
6. On the Subscription Schedule page, do the following:
beginning list. You can also enter the date when this subscription will end in The subscription will
end list, and then click Next.
7. On the Parameters page, specify a span of time for the report in the From and To lists, make any other
changes you need for this report, and then click Finish.
Next steps
Monitoring Failover Cluster with Operations Manager
2 minutes to read
The purpose of this article is to explain how to use System Center Operations Manager to monitor computers that
are in clustered configurations. For information on monitoring failover clusters, see the guide for the management
pack you are using, such as Microsoft System Center Management Pack for Windows Server Cluster 2016 or
System Center Management Pack for Windows Server Cluster 2008, 2012, and 2012 R2.
To begin monitoring computers in a cluster, perform the following steps:
1. Install an agent on all cluster nodes (computers).
2. Enable agent proxy on all cluster nodes. For more information, see How to Configure a Proxy for Agentless
Monitoring.
In the Administration workspace, cluster nodes will be displayed in Agent Managed, and the cluster will be
displayed in Agentless Managed. The cluster will show as "not monitored" unless a management pack contains
monitors that specifically target the cluster object. The agent on the active cluster node will perform all monitoring.
If the node fails, the agent on the cluster node that clustering fails over to will begin monitoring, but the agent on
the failover node will have no awareness of anything the agent on other node had monitored previously, such as
alerts, state changes, and so forth. The agents are independent.
When you are monitoring virtual servers on a cluster, you must deploy agents to the cluster nodes, configure them
to be managed as a proxy, and then monitor the virtual servers as you would monitor an agentless-managed
computer.
The Windows Server Operating System Management Pack provides discovery and monitoring of cluster shared
volumes.
NOTE
You might see alerts from Cluster discovery connect functionality monitor and Cluster state connect functionality
monitor when the Action Account uses low privilege credentials. To resolve this problem, assign higher privilege credentials
to the Windows Cluster Action Account. For instructions, see the procedure "To modify Run As account properties" in How to
Create a Run As Account.
Next steps
Review Manage alerts to understand how alerts are generated and how to manage configuring, tuning, and
viewing alerts generated by monitored objects in order to effectively prioritize, escalate, and remediate
issues detected.
Create an Alert Notification to email, text message, or instant message you if an important alert is
generated that requires immediate attention.
Not monitored and gray agents
3 minutes to read
In System Center Operations Manager, you may see discovered objects in the Operations console displayed as not
monitored or gray, as shown in the following illustration.
The state view in the previous illustration contrasts two "unknown" states.
The agent is shown as healthy, but the indicator is gray.
The operating system is shown as not monitored.
The gray icon indicates that the health service watcher on the management server that is watching the health
service on the monitored computer is not receiving heartbeats from the agent anymore. The health service
watcher had received heartbeats previously and the state was reported as healthy. This also means that the
management servers are no longer receiving any information from the agent.
The not monitored icon indicates that there are no monitors for the object. In the previous illustration, the view
tells you that there are no monitors for the operating system on this computer. In this case, this is because the
management packs for the Windows Server operating systems have not been imported in this management
group.
What to do for a gray state

Some of the common reasons for a gray state are:
Heartbeat failure
Health service is not running
Incorrect configuration
System workflows failure
Operational or data warehouse database performance
Management server or gateway server performance
Network or authentication issues
Computer name changed after agent installation
The Show Gray Agent Connectivity Data task will help you identify why an agent is gray.
Check a gray agent for connectivity

1. Open the Operations console and click Monitoring.
2. Navigate to the Operations Manager\Agent Details\Agent Health State view.
3. In Agent State from Health Service Watcher, click the agent you want to check connectivity for.
4. In the Tasks pane, select the task Show Gray Agent Connectivity Data.
5. The Run Task - Show Gray Agent Connectivity Data dialog box appears. Click Run.
6. The Task Status dialog box appears. When the task is completed, you can click Copy Text or Copy HTML
and paste the task output in the appropriate tool for further review.
The task output will identify the following information:
The last time a heartbeat was received from the agent.
Whether the System Center Management Health service is running on the agent.
Whether the agent responds to ping.
The last time the configuration on the agent was updated.
Possible reasons that the agent is unavailable.
The management server that the agent reports to.
For information on troubleshooting, see the Knowledge Base article Troubleshooting gray agent state. Although
the article was written for Operations Manager 2007 and 2012, the troubleshooting steps will also be helpful for
Operations Manager 2016 and higher.
What to do for a not monitored state

When an object shows as not monitored, check whether the appropriate management pack for monitoring the
object is imported. Ensure that the appropriate monitors are enabled.
Sometimes restarting the Microsoft Monitoring Agent service on the agent-managed computer or clearing the
agent cache can resolve the issue. To clear the cache on the agent, see How to clear the cache. You can also try
placing the object in maintenance mode for several minutes. For more information, see How to Suspend
Monitoring Temporarily by Using Maintenance Mode.
Next, check the DNS configuration for the computer, both FQDN and DNS suffix.
An agent can also show as not monitored because the new agent has the same NetBIOS name as a previously
installed agent. When the agent is deleted from Operations Manager, the grooming of the deleted agent is occurs
after two days. Therefore, the agent is not immediately groomed out of the database completely. To work around
this limitation, wait three days after deleting the agent to install the new agent.
Next steps
Review Viewing Active Alerts and Details to understand how it can help you review alerts that have been
generated by rules and monitors which are still active.
To understand how Operations Manager monitors the communication channel between an agent and it's
primary management server to ensure it is responsive and available, see How Heartbeats Work in
Operations Manager.
How to view all rules and monitors running on an
agent-managed computer
2 minutes to read
Administrators for System Center Operations Manager sometimes want to know which rules and monitors are
running on a computer. This is simple to do with the Show Running Rules and Monitors for this Health
Service task.
To view all rules and monitors running on a computer

1. Open the Operations console and click Monitoring.
2. For an agent-managed computer, navigate to the Operations Manager\Agent Details\Agent Health State
view. For a management server, navigate to Operations Manager\Management Server\Management
Servers State view.
3. Click the agent you want to see rules and monitors for.
4. In the Tasks pane, select the task Show Running Rules and Monitors for this Health Service.
5. The Run Task - Show Running Rules and Monitors for this Health Service dialog box appears. Click
Run.
6. The Task Status dialog box appears. When the task is completed, you can click Copy Text or Copy HTML
and paste the task output in the appropriate tool for further review.
Next steps
If you have an agent-managed computer generating an alert that doesn't immediately help you understand
what the cause behind it was, review Identifying the Computer Experiencing a Problem for further
recommendations.
Using SharePoint to view Operations Manager data
2 minutes to read
System Center Operations Manager can display select dashboards from the Web console in SharePoint to see at a
glance the status of operational metrics, such as availability and performance of your managed services. This is
especially beneficial to members of your organization who don't need access to Operations Manager, such as
service managers, executives, and even end-users of the service.
Use the following procedures to configure dashboards on a SharePoint page. This is accomplished using the Page
Viewer Web Part included with SharePoint, which lets you view another web page from within your SharePoint
page. If the user hasn't already been granted rights to view operational data from either console available in
Operations Manager, they will need to be assigned membership to one of the built-in user roles. If the user will
only need to view the data but not interact with it from the Operations or web console, such as close an alert or
perform some other related task, consider adding them to the Read-only Operator role.
NOTE
Silverlight-based dashboards made accessible from the SharePoint web part can only be viewed using Internet Explorer.
How to configure the web part to connect to a Web console

1. Open an Internet browser, and then navigate to the SharePoint server.
2. In the Site Actions dropdown menu, click New Page.
3. Enter a name for the page, and then click Create.
4. The new page opens with editing tools available. Click Insert.
5. On the Insert toolbar, click Web Part.
6. In Categories, select Media and Content and then select Page Viewer. Click Add to the page.
7. Click the arrow in the top right of the web part, and then click Edit web part.
8. In the To specify a link, type a URL or path field, enter the URL of an Operations Manager Web console
dashboard view. For Operations Manager 2016 and version 1807, append &disabletree=true at the end of
the URL to disable the tree view from being displayed with the web part.
9. Configure the appearance, layout, and Advance properties of the SharePoint page, and then click OK.
10. On the menu bar, click Save & Close.
Next steps
You can use views and dashboards to visualize operational data from different perspectives to make
meaningful decisions. To understand how to do this, see Using Views and Dashboards in Operations
Manager.
To learn how you can use reports in Operations Manager to view historical operational data, see Using
reports in Operations Manager.
View types in Operations Manager
4 minutes to read
In Operations Manager, views provide insight into the performance of your service, its health state, or the issues
detected and presented in an alerts view. Views return independent data based on specific criteria, whereas
dashboard are a way to view operational data in a condensed, single pane of glass, which your operations,
engineering, and the business can use to make meaningful decisions. There are various types of dashboards that
can accommodate the various roles in your IT organization. You may have a data storage Manager that wants to
see the percentage of SQL servers using more than the allocated amount of disk space; you may have a systems
engineer managing a web site with high traffic and wants to know what average requests per/sec are for all his
Web servers. Dashboards convey information succinctly and in a compact format so that the end user can decide if
they need to take action immediately.
After you identify the IT services to monitor, the configuration of how to monitor them, you need to configure how
that data will be visualized and provided to the different personas in the organization who are responsible for
sustaining and maintaining the service, the end-users who want to see a summarized availability status of critical
services provided, and management who are interested in determining if IT is meeting its service objectives to the
business.
Each view type in System Center - Operations Manager displays a different aspect of monitoring data. Each view
type has a different icon as shown in the following image.
Alert view type

The alert view displays alerts that meet your specific criteria, such as alert severity, resolution state, or alerts that
are assigned to you. For information on creating an alert view, see How to Create an Alert View.
Event view type
The event view queries the event logs and displays events that are based on criteria specified in the event view
properties. For information on creating an event view, see How to Create an Event View.
State view type

The state view displays relationships between components, computers, and computer groups. For information on
creating a state view, see How to Create a State View.
Performance view type

The performance view allows you to customize how you want to view performance data collected from
performance objects and counters. This includes the ability to view historical and current operational data together.
You must select Show in the Details pane to display data from a rule in the graph in the Results pane. For
information on creating a performance view, see How to Create a Performance View.
Diagram view type

The Diagram view displays a graphical view of a set of managed objects and how they relate to one another. For
information on creating a diagram view, see How to Create a Diagram View.
Task status view type

The task status view displays tasks that meet criteria specified in the properties, such as only those tasks that apply
to certain object types. For information on creating a task status view, see How to Create a Task Status View.
NOTE
Users that are members of the Read-only Operator role cannot view or run any tasks. For this reason, no tasks appear in a
task status view that is opened by a Read-only Operator.
Web page view type

The Web page view displays a Web page in a separate window in the Operations console. For information on
creating a Web page view, see How to Create a Web Page View.
Overrides summary view type
You can only create an overrides summary view in My Workspace.
You can view all rule and monitor overrides in the overrides summary view. The overrides summary view can be
used for both sealed and unsealed management packs. You can customize this view by grouping items by multiple
column headers. For information on creating an overrides summary view, see How to Create an Overrides
Summary View.
Dashboard view type

The dashboard view allows you to present multiple types of data in a single view.
IMPORTANT
When a dashboard view uses data from the data warehouse database, operators might be able to view data that they would
not otherwise have access to in views that use data from the operational database.
For information on creating a dashboard view, see How to Create a Dashboard View.
Next steps
Manager.
To understand how to create your own custom views and dashboards in Operations Manager, see Creating
and scoping views in Operations Manager.
Views included in sealed management packs can be modified to include other monitored object properties.
To customize a view, see How to personalize a View in Operations Manager.
Dashboards in Operations Manager
7 minutes to read
A dashboard has a particular layout, which specifies the arrangement of the cells that actually host content. Each
cell in a dashboard can contain a single widget. A widget accesses a particular set of data or performs a particular
function and presents its information in the dashboard. Each widget provides a specific set of customizations that
you can modify according to your particular requirements. Depending on the Dashboard Layout that you select,
the dashboard may have a fixed set of widgets or may allow you to define a number of configuration of cells that
can each contain a widget of your choice.
Dashboards in Operations Manager deliver the following benefits:
A dashboard is defined and shared in a management pack.
Authoring a dashboard is a simple process for an Operations Manager user. A new dashboard can be created or
an existing dashboard modified in both the Operations console and the Web console with the New Dashboard
and Widget wizard. However, if the default dashboard templates do not meet your requirements, you can
author custom dashboards and create custom widgets with Visual Studio using the Visual Studio Authoring
Extensions.
Once created, a dashboard is available from the Operations console, the Web console and the SharePoint Web
Part.
Dashboard templates
The first thing that you must specify when you create a dashboard is its template, which will define the widgets that
will be included in the dashboard and their layout. You cannot change the dashboard's template once it has been
created. The following sections provide details on the available templates. Additional templates may be provided
with subsequent versions of Operations Manager or from third parties.
Service Level dashboard
A Service Level Dashboard displays information on one or more Service Level Agreements and their included
Service Level Objectives. You cannot configure the individual components but can edit the configuration of the
dashboard to define the SLAs and time period to include.
Service Levels component that lists the SLAs that you selected for the dashboard.
Service Level Objectives component which lists the SLOs for the SLA that is selected in the Service Level cell.
Service Level Details component that displays a speedometer visualization for the current measure of the
selected SLO and a line chart showing the history of the measure.
Summary dashboard
A Summary Dashboard includes a fixed set of widgets displaying a combination of state, performance, and alert
information. The widgets are independent of on another and do not display information based on the objects
selected in another widget. You do not provide any configuration when you create the dashboard other than the
name but instead configure each widget independently after the dashboard is created. Summary Dashboards
include the following widgets.
Object by Performance Widget (Top N )
Performance Widget (Performance)
State Widget (State)
Alert Widget (Alert)
Object state
An Object State dashboard includes multiple widgets showing information about a particular object or group. You
cannot configure the individual widgets but can edit the configuration of the dashboard to define the target object
or group that all the widgets will include in addition to the criteria for included alerts.
Object State dashboards include the following widgets.
Object Health Widget (Health) showing the monitors for the target object or group. If a group is selected only
monitors targeted at the group itself are included, not the monitors of the group's members.
State Tiles Widget (Host) showing the health state and open alert count for the target object's host. Note that if
you selected an unhosted target such as a group or a distributed application for the dashboard, this widget will
be empty.
State Widget (Contained objects) showing the health state of any objects contained by the target. If the target is
a group, then this will be the members of the group. If the target has no contained objects, then this widget will
be empty.
Instance Details Widget (Object Details) that displays the details of the target object or group.
Alert Widget (Alerts) showing the active alerts for the target and any of its contained objects. If the target is a
group, then alerts from the members of the group are included. You set the criteria for which alerts are
included in the configuration for the dashboard itself instead of for this individual widget.
Column layout
A Column Layout is an empty dashboard that allows you to set your own layout and add and configure your own
set of widgets. When you create the dashboard, you specify the number of columns that it will have. The
dashboard will start with one cell in each column. You can add additional cells by clicking the gear icon at the top
right of the dashboard and selecting Add Cell.
Grid layout
A Grid Layout is an empty dashboard that allows you to set your own layout and add and configure your own set
of widgets. When you create the dashboard, you specify the number of cells that it will have and select a layout for
the cells. You can change the layout of the cells after the dashboard has been created, but you can't change the
number of cells.
Dashboard widgets
The following table describes each dashboard widget and where they pull their information from.
WIDGET DESCRIPTION DATA SOURCE AGGREGATED DATA
Performance widgets
Object by Performance Displays a list of objects Data Warehouse DB Yes

sorted according to the
value of a particular
performance counter. An
average is calculated from
the collected data for each
object, and then that
average value is used for the
ranking.
Performance Chart Displays a line chart and a Data Warehouse DB Yes

table with a list of objects
and their current health
state.
Alert widgets
Alert List Displays a table with alerts Operational DB No

related to an object or group
of objects and that match a
specified criteria.
Contextual Alert Displays a table with alerts Operational DB No

related to an object selected
in another control in the
dashboard and that match a
specified criteria.
Object widgets
Instance Details Displays the health and the Operational DB N/A

values of all properties of a
specific object.
Contextual Health Displays a table that includes Operational DB No

monitors directly targeted at
an object selected in another
control in the dashboard
and that match a specified
criteria.
Details Displays the health and the Operational DB N/A

values of all properties of an
object selected in another
control in the dashboard.
Object Detail Tiles Displays the following set of Operational DB N/A

tiles for an object or the
members of a group.
- Summary tile showing the
health and number of alerts
for the object that match a
criteria.
- SLA tiles for each Service
Level Agreements that the
object is included in.
- Performance tiles for one
or more performance
counters associated with the
object or members of the
group.
Object Health Displays a table with a list of Operational DB No

monitors for the selected
object and its contained
objects.
State Displays a table with a list of Operational DB No

objects with their properties
and current health state.
State Tiles Displays a summary tile Operational DB No

showing the health and
number of alerts for the
object that match a criteria.
PowerShell widgets
PowerShell Grid Displays the results of a N/A N/A

Windows PowerShell script
in a grid.
PowerShell Web Browser Displays the output of a web N/A N/A

page retrieved by a
PowerShell script.
SLA widgets
Object SLA Graphically displays the last Data Warehouse DB N/A

measured value each Service
Level Objective in one ore
more Service Level
Agreements.
SLA Graphically displays the last Data Warehouse DB N/A

measured value of each
Service Level Objective in
one more Service Level
Agreements.
SLA Tiles Displays an SLA tile showing Data Warehouse DB N/A

the last Service Level
Objective value for the
object. If there are multiple
Service Level Objectives,
then the tile cycles through
the different values.
Miscellaneous widgets
Topology Displays an icon for one or Operations DB N/A

more objects on a selected
image.
Web Browser Displays a web, optionally Operational DB N/A

sending the ID of the
management group, the ID
of an object selected in
another widget in the
dashboard, and the ID of an
alert selected in another
widget in the dashboard.
This allows you to create a
web page that could use the
Operations Manager SDK to
retrieve information or
perform some other action
dynamically in response to a
user selection in the
dashboard.
For additional details of each widget and the configurable properties available, please see Operations Manager
Dashboard Widgets from the Management Pack Authoring Guide.
Next steps
To understand how to create your own custom views and dashboards in Operations Manager, as well as how to
scope them, see Creating and Scoping Views in Operations Manager.
Overview of HTML5 Web console and dashboards
3 minutes to read
System Center Operations Manager now delivers HTML5 based dashboards, which enhance the authoring and
visualization experiences for Web console users. With these improvements you are able to visualize operational
data with richer data visualizations, faster performance, and drill-down. You can access these dashboards from
multiple browsers (such as Chrome) and are no longer dependent on Silverlight.
Supported scenarios
You can take advantage of the following HTML5 dashboard capabilities:
1. Create HTML 5 dashboards from multiple browsers without a dependency on Silverlight.
2. Visualize monitoring data in HTML 5 dashboards with:
a. Alert widget
b. State widget
c. Performance widget (also works like the Object by performance widget)
d. Topology widget
e. Tile widget
f. Custom widget
g. In version 1807, we introduce the PowerShell widget
3. Perform create, edit and delete operations on the widgets
4. Create or edit these widgets and scope by objects or groups
5. Add custom image for topology widgets and place the health of object on top of the image
6. Create any number of widgets in the dashboard without any predefined layout selection
7. Easily move, reposition and resize the widgets in the dashboard
8. View the dashboards in full screen without the monitoring tree view
9. Define a custom refresh interval rate for each of the dashboard widgets
10. Visualize the following dashboards:
a. Web Application Status
b. Management Group Health
c. Management Group Health Trend
d. UNIX/Linux Computer Summary
e. Network Summary Dashboard
f. In version 1807, you can view Network Node and Network Interface Dashboard for Network
Node/interface from the Monitored Objects page
11. In version 1807, you can visualize the effective configuration of rules and monitors for a monitored object
from the Monitored objects drill down page
12. You can sign out from your current web console session
13. Dashboards can be saved in custom management packs and exported
14. The following drill-down capabilities are available within the dashboards:
a. Analyze the issue by visualizing the relevant data for a monitored object, individual alert, rule, monitor,
and class.
b. Navigate from one object to another
c. View the tasks associated with selected object
15. Explore the actions enabled in a widget:
a. Actions with alert widget - Set resolution state on a single alert or select multiple alerts from within the
widget. View alert details delivering the same experience provided in the Operations console when
viewing an alert - modify the alert resolution state and drill down to the monitoring object details page
by selecting the alert source.
b. Export the data visible in the widget to Excel for further analysis
c. Personalize by adding or removing columns to visualize and group alerts
16. Explore actions with state widget:
a. Export the data visible in the widget to Excel for further analysis
b. Personalize by adding or removing columns to visualize and group objects
17. Explore actions with Topology widget:
a. Edit state indicator layout and place object health icons anywhere on image
18. Explore actions with Performance widget:
a. Set vertical axis and specify the minimum and maximum values of vertical axis
b. Export to Excel the legend data to Excel for further analysis.
c. Personalize by adding or removing columns for the legend, and enable or disable visualized objects by
performance
19. Explore actions with PowerShell widget:
a. Export to Excel the legend data to Excel for further analysis.
20. Delete HTML5 dashboards from the Web console and in version 1807, you can create dashboards or views
to My workspace. In version 1801, you add dashboards or views to My Workspace from the monitoring
tree.
21. The IIS web server hosting the Web console role can be setup with network authentication mode and users
can access the Web console using network authentication
22. You can provide feedback on HTML5 dashboards from within the Web console.
Supported browsers
System Center Operations Manager version 1807 and later Web console supports Microsoft Edge, Google
Chrome, Mozilla Firefox and Internet Explorer.
NOTE
Internet Explorer compatibility mode is not supported.
How to create a dashboard with the Alert widget in
the Web console
3 minutes to read
In System Center Operations Manager version 1801 and higher, the Web console provides a monitoring interface
for a management group that can be opened on any computer using any browser that has connectivity to the Web
console server. The following steps describe how to create a dashboard in the new HTML5 web console with the
Alert widget.
Add widget to dashboard

1. Open a web browser on any computer and enter http://<web host>/OperationsManager , where web host is
the name of the computer hosting the web console.
2. From the left pane in the Web console, click + New dashboard.
3. On the Create New Dashboard page, provide a name and description for the dashboard you want to
create.
4. You can save the dashboard in an existing unsealed management pack by selecting the management pack
from the Management Pack drop-down list or you can save the dashboard by creating a new
management pack by clicking New next to the Management Pack drop-down list and provide a name,
description and optionally a version number.
5. When you have completed specifying where to save the new dashboard to, click OK.
6. Click Save after providing a name and description for the new dashboard.
7. On the blank empty dashboard, you see the dashboard name, Add Widget, Edit Dashboard, Delete
dashboard and View in fullscreen options on the top of the page.
8. Select Alert Widget from the Select Widget drop-down list.

9. In the Alert widget pane, select scope for the alert widget by clicking either Groups or Objects. For either
option selected, you can search by keyword in the list. As you begin typing, the list filters based on your
input. You can select an individual group or object or multiple from the returned results.
10. A result set for the desired search query will be returned, select the scope from the returned results.
11. Set the criteria to identify the alerts to display. To narrow the results, you can filter by selecting the
following:
Severity
Priority
Resolution state
Alert age
Data matching the defined criteria will only be displayed in the widget.
12. Select Display to choose the columns to be displayed in the dashboard. You can select or search for the
columns from the drop-down list.
13. Complete the configuration by providing a Name, Description and Widget reefresh interval (default
interval is 5 minutes) for the widget. Click Save Widget to save your new dashboard.
After the widget has been created, it displays alerts based on the scope and criteria defined. You see the name of
the alert widget along with the number of alerts in the header of widget. Alerts can also be filtered in the widget by
searching for a keyword in the filter box.
You can view alert details consistent with the experience with the alerts view in the Operations console by clicking
on an alert and drilling into it's details. In version 1807 you can modify the alert resolution state and drill down to
the monitoring object details page by clicking on the alert source.
Actions on Alert widget

For one or more alerts selected in the widget, you can perform such actions as:
Change resolution state while viewing the details of a particular alert or for one or more alerts selected in the
widget.
Export the alerts to Excel for further analysis
Modify how the alerts are presented by including or excluding columns, how to group alerts, customized to
your personal needs
To perform these actions, hover your mouse over the widget and click on the ellipse ... on the top right corner of
the widget. This will display actions available for the widget.
Select Set resolution state and select one or multiple alerts by clicking on the checkbox in the first column on
the left, for each alert resolution state you are going to change. Select the resolution state from the drop-down
list and click Save.
Select Export to Excel to export the alert data to an Excel file.
Select Personalize to change your selection of columns to be displayed or to group alerts. Click Save
personalization when you have completed making your changes.
Next steps
To learn how to create a dashboard in the new web console with the Performance widget, see How create a
dashboard with the Performance widget in the Web console.
How to create a dashboard with the State widget in
the Web console
3 minutes to read
console server. The following steps describe how to create a dashboard in the new HTML5 web console with the
Health State widget.

create.
8. Select State Widget from the Select Widget drop-down list.

9. In the State widget pane, select scope for the widget by clicking either Groups or Class.
For either option selected, you can search by keyword in the list. As you begin typing, the list filters based
on your input. You can select an individual group or class or multiple from the returned results.
10. Set the criteria to identify the health state to display. To narrow the results, you can filter by selecting the
following:
By all health states or a specific state
Display all objects or only those in maintenance mode
12. Complete the configuration by providing a Name, Description and Widget refresh interval (default
After the widget has been created, it displays health state of the objects based on the scope and criteria defined.
You see the name of the state widget along with the number of objects in the header of the widget. Objects can
also be filtered in the widget by searching for a keyword in the filter box.
When you select an object in the widget, it presents the Monitoring Object details page and from here you can
view:
Discovered inventory reported for the object instance
Alerts generated
Performance metrics
Classes
Effective configuration of the rules and monitors running on the target device or system
To learn more about the effective configuration feature, see View configuration of a monitored object.
Actions on State widget

For one or more monitored objects selected in the widget, you can perform such actions as:
Modify how the alerts are presented by included or excluding columns or how to group alerts, customized to
your personal needs
Next steps
To learn how to create a dashboard in the new web console with the Topology widget, see How create a dashboard
with the Topology widget in the Web console
How to create a dashboard with the Performance
widget in the Web console
3 minutes to read
console server. The following steps describe how to create a dashboard in the new HTML5 Web console with the
Performance widget.

create.
8. Select Performance Widget from the Select Widget drop-down list.

9. In the Performance widget pane, select scope for the widget by clicking either Groups or Class.
10. Under Metrics, search for the performance objects and counters in the search box. For the results returned,
select the object and counter. If there are multiple instances for the counter, you can select the counter
instances from the drop-down list. This will only be visible if there are multiple instances for the selected
counter.
11. Set the criteria to identify the widget to display. To narrow the results, you can filter by selecting a time
range.
13. The widget can also be visualized as Objects by performance widget. If you would wish to visualize
object by performance widget then select Visualize objects by performance.
After the widget has been created, it displays a performance graph with the selected objects based on the scope
and criteria defined. You see the name of the performance widget along with the number of objects in the header
of the widget.
Actions on Performance widget

With a performance widget, you can perform such actions as:
Specify the minimum and maximum vertical axis values
Modify your selection of legend or to enable/disable Visualize objects by performance, customized to your
personal needs
Select Set vertical axis to modify the scale values of the y axis and then click Save.
Next steps
To learn how to create a dashboard in the new web console with the State widget, see How create a dashboard
with the State widget in the Web console
How to create a dashboard with the Topology widget
in the Web console
4 minutes to read
console server. The following steps describe how to create dashboard in the new HTML5 Web console with the
Topology widget.

create.
8. Select Topology Widget from the Select Widget drop-down list.

9. In the Topology widget pane, select scope for the widget by clicking either Groups or Class.
10. Select Display to choose an image for the topology widget to display in the authoring pane. If you already
added a custom image by performing these steps earlier, then select an image shown in the pane.
Otherwise, click Add image and navigate to where the file is located.
11. After selecting the file, click Open and the image will be uploaded and presented in the pane.
12. To change the size of the state icon, select either Small or Large.
create.
8. Select Topology Widget from the Select Widget drop-down list.

9. In the Topology widget pane, select scope for the widget by clicking either Groups or Class.
10. Select Display to choose an image for the topology widget to display in the authoring pane. Click Select
Image, and on the Select Image pane if you already added a custom image earlier, then select an image
from the list. Otherwise, click Add custom image and navigate to where the file is located.
11. After selecting the file, click Open and the image will be uploaded and presented in the Select Image
pane. Click Done to complete.
When created for the first time, the health state icons for the selected objects are displayed at the left-top section
of the topology widget. These icons have to be placed manually in the appropriate position on the image by
performing the following steps:
1. Click on the ellipse … next to the X on the right most side of the widget crown, which is displayed when you
hover over the widget.
2. Click Edit icons layout action to re-position the health state icons for the selected objects on the selected
image. While editing the icon layout, the health state icons will also display the object name of the specific
object.
3. Once the selected object icons have been re-positioned appropriately, click Go under Save icons layout to
save reconfigured positioning of the icons.
Now your topology dashboard visualizes the health of objects positioned on the selected image.
Actions on Topology widget
For a topology diagram which includes monitored object health state in the widget, you can re-position the icons
of the selected objects on the selected image.
1. Hover your mouse over the widget and click on the ellipse ... on the top right corner of the widget. This will
display actions available for the widget.
2. Select the Edit state indicator layout action.
3. In the Edit state indicator layout mode, the health state icons will also display the object name of the
specific object.
4. After moving the object icons to their new position on the image, click Save to save the updated layout.
Next steps
To learn how to create a dashboard in the new web console with the Custom widget, see How create a dashboard
with the Custom widget in the Web console
How to create a dashboard with the Tile widget in
the Web console
2 minutes to read
console server. The following steps describe how to add a Tile widget to a dashboard in the new HTML5 Web
console. It displays a summary tile showing the health and number of alerts for the object that match a criteria.

create.
8. Select Tile Widget from the Select Widget drop-down list.

9. In the Tile widget pane, select scope for the widget by clicking either Groups or Class.
After the widget has been created, it displays a summary tile showing the health and number of alerts for the
object that match a criteria defined. The tile represents health information into the following categories - A for
availability, P for performance, C for configuration, and S for security. The color for each category represents the
overall health of all the monitors under that category for the specified object.
![Completed example of Tile widget in dashboard](./media/create-web-dashboard-tile/web-console-new-dashboard-

tile-01.png)
Click on the object name in the Tile widget to launch Health Explorer for the specific object.
Next steps
To learn how to create a dashboard in the new web console with the Custom widget, see How create a dashboard
with the Custom widget in the Web console
How to create a dashboard with the Custom widget
in the Web console
13 minutes to read
In System Center Operations Manager, the Web console provides a monitoring interface for a management group
that can be opened on any computer using any browser that has connectivity to the Web console server. The
following steps describe how to add a Custom widget to a dashboard in the new HTML5 Web console, which is
using a new API based on REST. It executes the HTML code specified and visualizes the desired output in a variety
of visualizations.
Using the Operations Manager REST API reference

Use the REST API reference to learn about available operations you can perform with the custom widget to
present operational data in the dashboard. If you're new to REST API, take a look at the information on getting
started with this API, if you haven't already seen it.
Script structure
A Custom Widget script has three major sections:
1. Defining the REST API and its properties. This section defines what data needs to be retrieved from
Operations Manager for visualization, such as alerts, state, or performance data.
2. Specify business logic to identify the results to present in the visualization, such as identifying a class or group,
conditions such as severity, health state, or a specific performance object instance.
3. Third-party visualization, which is open-source libraries hosted on cloudflare.com that are required to render
the data, depending on the chart type selected.
Widget properties
In order for the script to query and return data in the visualization, the URL parameter specifies the address of the
Operations Manager Web console and the data type. The URL syntax is http:///operationsmanager/data/ and
value for dataitem is one of the following:
alert represents a monitoring alert
state represents monitoring health state data
performance represents monitoring performance data
<!DOCTYPE HTML>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script type="text/javascript">
var criticalCounter = 0;
var informationCounter = 0;
var warningCounter = 0;
window.onload = function () {
$.ajax({
url: "/OperationsManager/data/alert",
type: "POST",
To scope the monitoring data for each data type, you can select a class to see all instances of that class, or to see
only a subset of objects of the selected class, you can also include a group. For example, to specify all objects of
class Windows Server DC Computer, you would modify the property value for classId.
NOTE
This is only applicable to state data, not alert or performance. For performance data, you specify a group or monitored
object.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": "Microsoft.Windows.Library!Micr…ft.Windows.Server.DC.Computer",
"objectIds": { },
To specify a group that contains a subset of objects of the same class specified for the property classId, modify the
value objectIds and specify the GUID of the group. The value must be in quotes.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": null,
"objectIds": { "3c8ac4f3-475e-44dd-4163-8a97af363705": -1 },
Once you have specified the target class and optionally a group to further scope the results, you then specify the
criteria to limit the type of data to display according to the values of one or more properties.
Widget examples
The widget supports rendering monitoring data in the following chart types:
Bar chart (state data)
Spline chart (performance data)
Bar chart (alert data)
Pie chart and 3D Pie chart
Donut and 3D Donut
Combination chart
Stacked bar chart
You can configure a chart type to present state, performance, and alert data. For each example below, alerts from
the Windows Computer group are returned for any severity, matching specific resolution states.
Bar chart (state data)
The following HTML code demonstrates rendering a bar chart with state data.
<!DOCTYPE HTML>
<html>
<head>
var healthyCounter = 0;
var unmonitoredCounter = 0;
$.ajax({
url: "/OperationsManager/data/state",
type: "POST",
data: {
"classId": "System.Library!System.Computer",
"objectIds": {
// Key value pairs => id: 0 (For objects)/-1 (For groups)
"1d62280e-f437-1369-316b-1e8659500e9a": -1
},
"criteria": "((HealthState = '0') OR (HealthState = '1') OR (HealthState = '2') OR
(HealthState = '3') OR HealthState is null)",
"displayColumns": [
"healthstate",
"displayname",
"path",
"maintenancemode"
]
},
success: function (result) {
for (var i = 0; i < result.rows.length; i++) {
switch (result.rows[i].healthstate) {
case "critical":
criticalCounter++;
break;
case "healthy":
healthyCounter++;
break;
case "warning":
warningCounter++;
break;
case "unmonitored":
unmonitoredCounter++;
break;
}
}
renderChart();
}
});
}
function renderChart() {
var chart = new CanvasJS.Chart("chartContainer", {
title: {
text: "Health State of Windows Computers"
text: "Health State of Windows Computers"
},
data: [{
type: "column",
dataPoints: [
{ y: criticalCounter, label: "Critical", color: "Red" },
{ y: healthyCounter, label: "Healthy", color: "Green" },
{ y: warningCounter, label: "Warning", color: "Yellow" },
{ y: unmonitoredCounter, label: "Unmonitored", color: "Gray" }
]
}]
});
chart.render();
}
</script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/canvasjs/1.7.0/canvasjs.min.js"></script>
<title>CanvasJS Example</title>
</head>
<body>
<div id="chartContainer" style="height: 400px; width: 100%;"></div>
</body>
</html>
Spline chart (performance data)

The following HTML code demonstrates rendering a spline chart with performance data.
<!DOCTYPE HTML>
<html>
<head>
var performanceData = [];
$.ajax({
url: "/OperationsManager/data/performance",
type: "POST",
headers: {
"Content-Type": "application/json"
},
data: JSON.stringify({
"id":"6f7e3306-beeb-2996-3795-7c1eafb925b8",
"performanceCounters":[
{
"objectname":"Health Service",
"countername":"agent processor utilization",
"instancename":""
}
],
"legends":[
"target",
"path",
"lastvalue"
],
"duration":4320
}),
let dataDictionary = result.datasets[0].data;
let sum = new Array(24).fill(0.0);
let count = new Array(24).fill(0.0);
for (var key in dataDictionary) {
if(dataDictionary.hasOwnProperty(key)) {
var datetime = new Date(key);
datetime = convertUTCDateToLocalDate(datetime);
datetime = convertUTCDateToLocalDate(datetime);
sum[datetime.getHours()] += dataDictionary[key];
count[datetime.getHours()]++;
}
}
let tDate = new Date();
tDate.setHours(0,0,0,0);
for(var i=0; i<24; i++) {
performanceData.push({
y: sum[i] / count[i],
x: new Date(tDate.getTime())
});
tDate.setHours(tDate.getHours()+1);
}
renderChart();
}
});
}
function convertUTCDateToLocalDate(date) {
var newDate = new Date(date.getTime()+date.getTimezoneOffset()*60*1000);
var offset = date.getTimezoneOffset() / 60;
newDate.setMinutes(date.getMinutes() - date.getTimezoneOffset())
return newDate;
}
title: {
text: "Average Processor Utilization for Last 3 Days"
},
axisX: {
labelFormatter: function(e) {
return CanvasJS.formatDate(e.value, "hh:mm tt");
}
},
data: [{
type: "spline",
dataPoints: performanceData
}]
});
chart.render();
}
</script>
</head>
<body>
<div id="chartContainer" style="height: 100%; width: 100%;"></div>
</body>
</html>
Bar chart (alert data)

The following HTML code demonstrates rendering a bar chart with alert data.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": null,
"criteria": "((Severity = '0') OR (Severity = '1') OR (Severity = '2') OR (Severity =
'3')) AND ((Priority = '2') OR (Priority = '1') OR (Priority = '0')) AND ((ResolutionState = '0') OR
(ResolutionState = '247') OR (ResolutionState = '248') OR (ResolutionState = '249') OR (ResolutionState =
'250') OR (ResolutionState = '254') OR (ResolutionState = '255'))",
"displayColumns":
[
"severity","monitoringobjectdisplayname","name","age","repeatcount","lastModified"
]
},
switch(result.rows[i].severity)
{
case "Error":
criticalCounter++;
break;
case "Information":
informationCounter++;
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
title: {
text: "Alerts representation in bar chart"
},
data: [{
type: "column",
dataPoints: [
{ y: criticalCounter, label: "Critical" },
{ y: warningCounter, label: "Warning" },
{ y: informationCounter, label: "Information" }
]
}]
});
chart.render();
}
</script>
</head>
<body>
</body>
</html>
Pie chart
The following HTML code demonstrates rendering a pie chart with alert data.
<!DOCTYPE HTML>
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": null,
"displayColumns":
[
]
},
{
case "Error":
criticalCounter++;
break;
case "Information":
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
var chart = new CanvasJS.Chart("chartContainer",
{
theme: "theme2",
title: {
text: "Alerts representation in Pie chart"
},
data: [
{
type: "pie",
showInLegend: true,
toolTipContent: "{y} - #percent %",
legendText: "{indexLabel}",
dataPoints: [
{ y: criticalCounter, indexLabel: "Critical" },
{ y: warningCounter, indexLabel: "Warning" },
{ y: informationCounter, indexLabel: "Information" }
]
}
]
});
chart.render();
}
</script>
</script>
</head>
<body>
</body>
</html>
3D Pie chart
The following HTML code demonstrates rendering a 3D pie chart with alert data.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": null,
"displayColumns":
[
]
},
{
case "Error":
criticalCounter++;
break;
case "Information":
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
var chart = new Highcharts.chart('container', {
chart: {
type: 'pie',
options3d: {
enabled: true,
alpha: 45,
alpha: 45,
beta: 0
}
},
title: {
text: 'Alerts share per severity'
},
tooltip: {
pointFormat: '{series.name}: <b>{point.percentage:.1f}%</b>'
},
plotOptions: {
pie: {
allowPointSelect: true,
cursor: 'pointer',
depth: 35,
dataLabels: {
enabled: true,
format: '{point.name}'
}
}
},
series: [{
type: 'pie',
name: 'Alerts share',
data: [
{
name: 'Critical',
y: 48,
sliced: true,
selected: true
},
['Warning', 39],
['Information', 13],
]
}]
});
chart.render();
}
</script>
<script src="https://code.highcharts.com/highcharts.js"></script>
<script src="https://code.highcharts.com/highcharts-3d.js"></script>
<script src="https://code.highcharts.com/modules/exporting.js"></script>
<div id="container" style="height: 400px"></div>

</head>
<body>
</body>
</html>
Donut chart
The following HTML code demonstrates rendering a donut chart with alert data.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
$.ajax({
type: "POST",
data: {
"classId": null,
"displayColumns":
[
]
},
{
case "Error":
criticalCounter++;
break;
case "Information":
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
var chart = new CanvasJS.Chart("chartContainer",
{
theme: "theme2",
animationEnabled: true,
title: {
text: "Alerts representation in doughnut"
},
data: [
{
type: "doughnut",
indexLabelFontFamily: "Garamond",
indexLabelFontSize: 20,
startAngle:0,
indexLabelFontColor: "dimgrey",
indexLabelLineColor: "darkgrey",
toolTipContent: "{y} %",
dataPoints: [
{ y: criticalCounter, indexLabel: "Critical" },
{ y: warningCounter, indexLabel: "Warning" },
{ y: informationCounter, indexLabel: "Information" }
]
}
]
});
chart.render();
}
</script>
</head>
<body>
</body>
</html>
3D Donut chart
The following HTML code demonstrates rendering a 3D donut chart with alert data.
<!DOCTYPE HTML>
<html>
<head>
$.ajax({
type: "POST",
data: {
"classId": null,
"displayColumns":
[
]
},
{
case "Error":
criticalCounter++;
break;
case "Information":
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
var chart = Highcharts.chart('container', {
chart: {
type: 'pie',
options3d: {
enabled: true,
alpha: 45
}
},
title: {
text: 'Alerts representation in 3D donut'
},
subtitle: {
text: ''
text: ''
},
plotOptions: {
pie: {
innerSize: 100,
depth: 45
}
},
series: [{
name: 'Number of alerts',
data: [
['Critical', criticalCounter],
['Warning', warningCounter ],
['Information', informationCounter]
]
}]
});
chart.render();
}
</script>
<script src="https://code.highcharts.com/highcharts-3d.js"></script>
<div id="container" style="height: 400px">

</div>
</head>
<body>
</body>
</html>
Combination chart
The following HTML code demonstrates creating a Combination chart to display alerts in a pie and spline chart.
<!DOCTYPE HTML>
<html>
<head>
var totalCounter =0;
$.ajax({
type: "POST",
data: {
"classId": null,
"displayColumns":
[
]
},
{
case "Error":
criticalCounter++;
break;
case "Information":
break;
case "Warning":
warningCounter++
break;
}
}
renderChart();
}
});
}
var chart = new Highcharts.chart('container', {
title: {
text: 'Alerts representation in combination chart'
},
xAxis: {
categories: ['Critical', 'Warning', 'Information']
},
labels: {
items: [{
html: 'Total alerts generated',
style: {
left: '50px',
top: '0px',
color: (Highcharts.theme && Highcharts.theme.textColor) || 'black'
}
}]
},
series: [{
type: 'column',
name: 'Critical',
data: [criticalCounter, 0, 0]
}, {
type: 'column',
name: 'Warning',
data: [0, warningCounter, 0]
}, {
type: 'column',
name: 'Information',
data: [0, 0, informationCounter]
}, {
type: 'spline',
name: 'Spline chart',
data: [criticalCounter, warningCounter, informationCounter],
marker: {
lineWidth: 2,
lineColor: Highcharts.getOptions().colors[3],
fillColor: 'white'
}
}, {
type: 'pie',
name: 'Total consumption',
data: [{
name: 'Critical',
y: criticalCounter,
color: Highcharts.getOptions().colors[0] // Jane's color
}, {
name: 'Warning',
y: warningCounter,
color: Highcharts.getOptions().colors[1] // John's color
}, {
}, {
name: 'Information',
y: informationCounter,
color: Highcharts.getOptions().colors[2] // Joe's color
}],
center: [150, 100],
size: 100,
showInLegend: false,
dataLabels: {
enabled: false
}
}]
});
chart.render();
}
</script>
<div id="container" style="min-width: 310px; height: 400px; margin: 0 auto"></div>
</head>
<body>
</body>
</html>

create.
description, and optionally a version number.
8. Select Custom Widget from the Select Widget drop-down list.
9. In the Custom widget pane, select criteria for the widget adding the HTML code using one of the earlier
examples, to visualize monitoring data in one of the supported chart visualizations.
10. Complete the configuration by providing a Name, Description, and Widget reefresh interval (default
After the widget has been created, it displays the output of the HTLM code.
How to create a dashboard with the PowerShell
widget in the Web console
2 minutes to read
console server. The following steps describe how to create a dashboard in the new HTML5 Web console with the
PowerShell widget.
The script will typically use the Operations Manager cmdlets to retrieve information from the management group.
It must then use the ScriptContext object to create a Data Object and then add that object to the ReturnCollection
property. Typically with the Silverlight based PowerShell widget, scripts were configured with the variable named
$dataObject, and this variable held data returned from ScriptContext object. However, this widget does not
support that variable name and will return an error when you attempt to save your changes. Replace this variable
name with a custom name such as $results.

create.
dashboard and View in fullscreen options on the top of the page. Select Add Widget.
8. Select PowerShell Widget from the Select Widget drop-down list.
9. In the PowerShell widget pane, write or copy and paste your PowerShell script into the textbox.
The following sample script creates a table of numbered Windows Computer objects and displays the ID,
health state, and display name for each.
$class = Get-SCOMClass -Name Microsoft.Windows.Computer
$computers = Get-SCOMClassInstance -Class $class
$i=1
foreach ($computer in $computers)
{
$results=$ScriptContext.CreateFromObject($computer,"Id=Id,HealthState=HealthState,DisplayName=DisplayNam
e",$null)
$results["CustomColumn"]=$i
$ScriptContext.ReturnCollection.Add($results)
$i++
}
After the widget has been created, it displays the results of your script.
Actions with PowerShell widget

With a PowerShell widget, you can perform such actions as:
Next steps
To learn how to create a dashboard in the new web console with the State widget, see How create a dashboard
with the State widget in the Web console
Manage dashboard and widget configuration in the
Web console
2 minutes to read
Delete a dashboard
To delete dashboard, click Delete dashboard option available from the top banner of the dashboard.
You are prompted to confirm you wish to proceed with deleting the dashboard. This notification appears at the
bottom of the page. Click Yes to continue or No to cancel the operation.
Add dashboards or views to My workspace

1. Right-click on a dashboard or view in the monitoring tree of the Web console and click Add to My
Workspace from the context menu.
2. On the Add to My Workspace pane on the right side of the page, specify which folder in My Workspace
this dashboard or view should be added. You can also choose to create a new folder by clicking on New
Folder to better organize your workspace.
3. After specifying the location where to create the new folder, click OK and your dashboard or view will be
added to your My Workspace view.
Modify widget configuration

To edit the widget, perform the following steps.
1. Hover your mouse over the widget and click on the ellipse … at the top right corner of the widget.
2. The options pane for the widget appears, it displays all the possible actions available for the selected widget.
Select Edit to launch the authoring pane for the widget.
3. Perform changes to the available settings for the widget and then click Update Widget.
After you update the widget, the changes are saved and the message updating widget… is displayed at the
bottom of the page.
Delete a widget from the dashboard

To delete a widget on your dashboard, perform the following steps.
1. Hover your mouse over the widget.
2. Click Delete Widget
3. You are prompted to confirm Are you sure you want to delete this widget? at the bottom of the page.
Click Yes to continue or No to cancel the operation.
Refresh widget
Each widget is automatically refreshed based on the specified refresh interval. By default, widgets update every five
minutes. To manually refresh it, then click refresh icon in the upper right-hand corner of the widget.
Edit a dashboard
You can change the presentation layout of the dashboard by resizing or repositioning the widgets to present the
information in a more attractive or meaningful way.
Reposition widget
To move the widget to a different location on the dashboard, click Edit Dashboard and hover your mouse over the
widget. You will see the cursor change appearance. Hold down the left mouse button and drag the widget to the
desired location on the dashboard.
Resize the widget
Move your cursor to the bottom right or right border of the widget. You will see the cursor change appearance.
Hold down the left mouse button and drag the window to the size you want.
To save the changes you want to keep, click Save Changes. If you want to cancel all your changes then click Undo
changes.
Next steps
To understand how to create your own custom views and dashboards in Operations Manager, see Creating and
scoping views in Operations Manager.
How to view the effective configuration of a
monitored object
2 minutes to read
In System Center Operations Manager version 1807 and later, the Web console has been enhanced to allow an
operator to view the monitoring details for a selected object and show all the rules and monitors that target it.
From the results, you are able to see the following details:
Monitor/Rule name
Target class
Instance - the instance of the monitored object
Type - Value is either Rule or Monitor
Rule/Monitored enabled - Value is either True or False
Generates alert - Value is either True or False
Alert severity
Alert priority
Overridden - Value is True or False value indicating if an override is applied
Rules or monitors with an override applied can be expanded to review the default and modified setting.
How to launch effective configuration

From the Health State widget, select a monitored object in the table and the Monitored Object details page is
shown. Scroll down to the bottom of the page and in the Effective Configuration pane, click on the refresh icon in
the upper right-hand corner of the pane.
When the pane refreshes it returns all of the workflows that are running on the monitored object. The total number
of rules and monitors is reflected in the upper left-hand corner of the pane.
All columns in the table support sorting and text entries will sort in alphabetical order and numbers will sort from
smallest to largest (or vice versa). You can use the filter textbox when you want to search on a specific word, and
the filter is case insensitive.
If a rule or monitor has an override applied, which is reflected by the workflow showing a value of True in the
Overridden column, you can view the override values applied by clicking on the on the expand icon in the first
column, and the row will expand to show the default settings and modified values for the rule or monitor.
Next steps
Before making changes to the monitoring settings defined in an Operations Manager management pack, review
How to Override a Rule or Monitor to understand how to configure the change.
Using My Workspace in the Web console
2 minutes to read
With System Center Operations Manager version 1801 and higher, in the new HTML5 Web console you can
customize how you view monitoring data for your specific needs differently than previous versions of Operations
Manager.
Using My Workspace allows you to create folders to organize dashboards, add existing views and dashboards
from the Monitoring workspace, and create custom dashboards only visible to you in the Web console.
Add views and dashboards

From the Monitoring workspace, you can add shortcuts to any existing view or dashboard in the Monitoring
workspace.
1. In the Monitoring workspace, select a view or dashboard, right-click, and then click Add to My
Workspace.
2. Specify a name for the view/dashboard to personalize it for your needs in the Name field.
3. Specify an existing folder or create a new one by clicking on New Folder and specifying a folder name, and
then click OK to save the new folder. Select the new folder where you want the view or dashboard to appear
and then click OK.
When you go to My Workspace, you will see the view or dashboard that you added listed in the navigation pane.
Create dashboards
Dashboards that you create in My Workspace are unique, they are not shortcuts to existing dashboards. As an
operator, you can create dashboards in Operations Manager version 1807 or later Web console, in My Workspace.
NOTE
The steps to create a dashboard and add a web part are similar to how you create one in the Monitoring workspace, with
one difference - you are not prompted to specify a management pack to save it to. Instead you are prompted to specify an
existing folder or create a new one in your workspace.
For detailed steps, review the following articles:

Create dashboard with Alert widget
Create dashboard with State widget
Create dashboard with Performance widget (also works like the Object by performance widget)
Create dashboard with Topology widget
Create dashboard with Tile widget
Create dashboard with Custom widget
Create dashboard with the PowerShell widget, available only with version 1807
Next steps
Standard views in Operations Manager
6 minutes to read
Several views are created by default when System Center Operations Manager is installed. Management packs
also contain views. When a management pack is imported, a folder that contains the views that are defined in the
management pack is created in the Monitoring workspace.
The following table describes the views and folders of the views available when Operations Manager is installed.
For views added by a management pack, see the management pack guide for information.
VIEW OR VIEW FOLDER DESCRIPTION
Active Alerts This view shows all alerts that are active (not closed). In this
view, select an alert to view its details, such as the rule or
monitor that generated the alert and the managed object
that has the problem.
Double-click an alert to open the properties of the alert.
Select an alert and click Health Explorer in the Tasks pane to

open Health Explorer in the context of this alert.
When appropriate, you can close the alert from this view by
clicking Close Alert in the Tasks pane.
For more information, see:
- Viewing Alerts and Alert Details

- Using Health Explorer to Investigate Problems
- Impact of Closing an Alert
- How to Close an Alert Generated by a Monitor
Discovered Inventory This view shows all objects that have been discovered and
their states.
Click Change Target Type in the Tasks pane to filter the

discovered inventory list to a single type of object. The target
type determines the type of information that will be displayed
in the details pane for a selected object. For example, if you
change the target type to Health Service, Detail View displays
information about the health service for the selected object,
such as port and action account identity. If you change the
target type to Computer, Detail View displays computer
information such as name and asset status.
Select an object and click Health Explorer in the Tasks pane to

open Health Explorer in the context of this object.
When the state of an object in Discovered Inventory is Not

monitored, that means...
For more information, see Using Health Explorer to

Investigate Problems.
Distributed Applications This view shows all monitoring objects created by the
Distributed Application Designer in your management group
and their states.
Select an object and click Health Explorer in the Tasks pane to

open Health Explorer in the context of this object.

Task Status This view shows the output from tasks that you have
executed in the console. The Task Status view shows when a
task is completed, finished, and the user who executed this
specific task.
Unix/Linux Servers This view shows the state of the following aspects of
discovered UNIX and Linux computers:
- Overall state of the computer

- State of the agent on the computer, if an agent is installed
- State of the management server role, if the computer is a
management server
- State of the operating system
To see information that is collected for a computer, select the

computer Name field for a specific computer. You can click
Properties in the Tasks pane to display all of the information
that is collected. To open other views for a computer, right-
click the computer, select Open, and click a view to open. For
example, to view a computer's performance, select the
Performance option. Using the Performance view, you may
filter to a set of counters to display by using the Look for
option in the Details pane.
Select a computer and click Health Explorer in the Tasks pane

to open Health Explorer in the context of this computer.

Windows Computers This view shows the state of the following aspects of
discovered Windows computers:
- Overall state of the computer

- State of the agent on the computer, if an agent is installed
- State of the management server role, if the computer is a
management server
- State of the Windows operating system
To see information that is collected for a computer, select the

computer Name field for a specific computer. You can click
Properties in the Tasks pane to display all of the information
that is collected. To open other views for a computer, right-
click the computer, select Open, and click a view to open. For
example, to view a computer's performance, select the
Performance option. Using the Performance view, you may
filter to a set of counters to display by using the Look for
option in the Details pane.
Select a computer and click Health Explorer in the Tasks pane

to open Health Explorer in the context of this computer.

Agentless Exception Monitoring (folder) Agentless Exception Monitoring (AEM) is used to aggregate,
view, and report on error reports that are sent by the
Windows Error Reporting service. The Agentless Exception
Monitoring folder contains four state views and one event
view, specific to data gathered by AEM.
- Application View
- Crash Listener View
- Error Events
- Error Group View
- System Error Group View
Data Warehouse (folder) The data warehouse is the database that stores operations
data which is used by Reporting Server to build reports.The
Data Warehouse folder contains views to help you monitor
the state and performance of the data warehouse.
- Active Alerts
- All Event View
- Collection Performance
- Collection Servers
- Synchronizaton Performance
Microsoft Audit Collection Services (folder) Audit Collection Services (ACS) collects records generated by
an audit policy. The ACS collector receives and processes
events from ACS forwarders and then sends this data to the
ACS database. The service that runs on ACS forwarders is
included in the Operations Manager agent. The Microsoft
Audit Collection Services folder contains views specific to ACS
operations.
- The ACS Collector folder contains an event view, a state

view, and multiple performance views.
- The ACS Fowarder folder contains an event view and a
state view.
Network Monitoring (folder) The Network Monitoring folder contains an alert view that is
scoped to discovered network devices, state views for each
type of network device, and a Network Summary Dashboard
view. For more information, see Viewing Network Devices and
Data in Operations Manager.
The Network Monitoring folder also contains views specific to

network discovery and performance.
Operations Manager (folder) One of the views in the Operations Manager folder is a
diagram of the management group. You can click an item in
the diagram to view details about the object.
The Operations Manager folder contains numerous views, and

organized as follows:
- Activated APM Agent Details

- Agent Details
- Management Configuration Service
- Management Data Access
- Management Group Details
- Management Packs and Workflows
- Management Server
- Notification
Synthetic Transaction (folder) The Synthetic Transaction folder contains state views for OLE
DB data sources and TCP port checks.
Web Application Transaction Monitoring (folder) The Web Application Transaction Monitoring folder contains a
state view of monitored Web applications.
Windows Service and Process Monitoring (folder) The Windows Service and Process Monitoring folder contains
state views for Windows services and processes.
Next steps
Manager.
To understand how to create your own custom views and dashboards in Operations Manager, see Creating
Views in Operations Manager.
Views included in sealed management packs can be modified to include other monitored object properties.
To customize a view, see How to Personalize a View in Operations Manager.
How to create and scope views in Operations
Manager
17 minutes to read
System Center Operations Manager Operations console views and dashboards display information that meets
specific criteria. When you select a view, a query is sent to the Operations Manager database and the results of
the query are displayed in the results pane. With dashboards, the performance widget queries the data
warehouse database.
You can use the standard views created when Operations Manager is installed, views provided by management
packs, or create your own custom views.
At a minimum, you must have the rights of the Author role to create a view in the Monitoring workspace.
Using groups to scope views

You can use groups to limit a view in the Operations console, making it easier to find the specific information you
need. You can change the scope for any existing view (other than dashboard views) to a specific group; however,
this change only applies to the user who makes it and does not persist when the console is restarted.
For persistent management, you can create views that are scoped to a specific group. You can also scope the
following widgets in a dashboard view:
Alert
Instance Details
Performance
State
For example, after you create a group of objects, you can create a dashboard view in which each widget is
targeted to the group, providing a single view for important information for the members of the group.
After you create views for the group, you can create a user role that is scoped to the group and limited to the
views for that group, and then assign users to that user role. This enables the individuals with that user role to
monitor the objects they are concerned with, while limiting them to information that only pertains to those
objects.
How to create an alert view

You can create a custom alert view that shows only those alerts that you want to see. For example, if you need to
track the status of UNIX-based or Linux-based computers, you can create a view that shows only critical alerts
generated by those computers.
1. In the Operations console, click My Workspace.
2. Right-click the folder where you want to store the view and point to New, and click Alert View.
3. In the Properties dialog box of the alert view, type a name and a description for the view. (The description
is optional.)
4. Set the criteria to identify the alerts to display:
a. Narrow the pool of possible alerts by identifying a class or group for alerts. For example, to create
an alert view for UNIX-based or Linux-based computers, select Unix Computer in the Show data
related to list.
b. Select the conditions that define the content of the view. There are a number of different conditions
that you can choose, from severity or priority to alerts that include text in specific fields. For
example, for the UNIX-based or Linux-based computers alert view, select of a specific severity in
the Select conditions list.
c. Refine the criteria description by clicking the underlined text in the Criteria description box.
For the UNIX-based or Linux-based computers alert view, click specific. In the Alert Type window,
select Critical, and then click OK.
NOTE
You can add multiple criteria to refine the view to fit your needs.
5. Customize the appearance of the alert view on the Display tab. You can specify the columns to display,
the sort order for the columns, and the manner in which items are grouped.
6. Click OK to create the view.
How to create an event view

An event view can only display events that are collected by a management pack. Operations Manager does not
collect all events.
2. Right-click the folder where you want to store the view, point to New, and then click Event View.
3. In the Properties dialog box of the event view, type a name and a description for the view. (The
description is optional.)
4. Set the criteria to identify the events to display:
a. Narrow the pool of possible events by identifying a class or group for events. For example, to create
an event view for UNIX-based computers, select Unix Computer in the Show data related to list.
that you can choose. For example, for the UNIX-based computers event view, select with specific
severity level in the Select conditions list.
NOTE
When you select generated by specific rules, only event collection rules can be selected. If you do not see
the rule that you want to select when you click specific, ensure that the category of the rule you want is
Event Collection.
For the UNIX-based computers event view, click specific. In the Event Type window, select Audit
Failure, and then click OK.
NOTE
5. Customize the appearance of the event view on the Display tab. You can specify the columns to display,
the sort order for the columns, and the manner in which items are grouped.
How to Create a state view

The state view in Operations Manager is like most other view types in that you use the Criteria tab in the
Properties dialog box of the view to define which objects you want shown in your view. You then use the
Display tab to customize how the data looks in your view. Each section of the Criteria tab adds an additional
filter to your view.
NOTE
When a state view is displayed, you might find that multiple objects are listed by the same name. For example, a Windows-
based computer object and management server object might have the same computer name. The Windows-based
computer object and the management server object will be listed on their own row in the state view and thus, the same
computer name will be listed twice. This is expected behavior.
1. Right-click the folder where you want to store the view, point to New, and then click State View.
2. In the Properties dialog box of the event view, type a name and a description for the view. (The
3. On the Criteria tab, click the ellipses (...) next to the Show data related to box. The Select a Target
Type dialog box displays a list of the object types available in your management group. Click to select the
object type of the objects that you want to view, and then click OK.
The object type you select is listed in the Show data related to box. If you want to narrow the focus of
the view, you can also click the ellipses (...) next to Show data contained in a specific group. Click a
group to filter the objects shown in your view, and then click OK.
NOTE
If you do not see the object type that you want, click View all targets and then type a word or phrase in Find to
filter the displayed list.
4. Use the checkboxes provided to select individual criteria to apply additional filters to the objects that you
want to display in your view. You might need to further define the criteria in the Criteria description box.
5. Click the Display tab. By default, all columns in your state view display. Click to deselect one or more
columns that you do not want to display. Choose how you want to sort the objects in your view in Sort
columns by.
How to create a performance view

Performance views use data stored in the operational database. A performance view can only display
performance counters that are collected by a management pack. Operations Manager does not collect all
performance counters.
2. Right-click the folder where you want to store the view, point to New, and then click Performance View.
3. In the Properties dialog box of the performance view, type a name and a description for the view. (The
4. Set the criteria to identify the performance data to display:
a. Identify a class or group for performance data. For example, to create a performance view for
UNIX-based computers, select Unix Computer in the Show data related to list.
that you can choose. For the UNIX-based computers performance view, select collected by
specific rules in the Select conditions list.
For the collected by specific rules condition, click specific. In the Select rules window, select a
performance collection rule, and then click OK.
NOTE
5. Customize the appearance of the alert view on the Display tab. You can specify the chart type to display,
the period of time that the chart should cover, and the display options for the X axis and Y axis.
How to create a diagram view

In Operations Manager, a diagram view uses a template to control the layout of the information in the diagram.
You can choose from an existing template or create your own template. If you choose to create your own
template, you configure the layout of the view while you are creating the view.
2. Right-click the folder where you want to store the view, point to New, and click Diagram View.
3. In the Properties dialog box of the diagram view, type a name and a description for the view. (The
4. Click Browse. In the Select Object dialog box, click the group for the type of objects that you want to
include in your diagram view, and then click OK.
5. Click Create your own template to design a layout for your diagram view.
6. If you want to accept the default settings for the diagram view, click Create. If you want to change the
default settings, continue with this procedure.
7. On the Diagram Properties tab, type a number in Levels to show to display the number of related
classes and subclasses that you want in your view. This number includes the top-level class. In Layout
Direction, click the drop-down arrow to view a list of display options for the objects in your view. North
South displays the objects in a vertical arrangement, and East West displays the objects side by side.
8. Click the Object Properties tab. Click Boxes if you want to delineate your related object types and child
object types by containing them in a box. You can also adjust the Nodes Per Row setting to define how
many of your related object types are listed before beginning another row.
9. On the Line Properties tab, choose the format for the lines of the boxes in your diagram by using the
Containment Line settings. Choose the format for objects that are not grouped by boxes using the Non
Containment Line settings. Click Create.
How to create a task status view

The task status view in Operations Manager is like most other view types in that you use the Criteria tab in the
Properties dialog box of the view to define which objects you want shown in your view. You then use the
Display tab to customize how the data looks in your view. Each section of the Criteria tab adds an additional
filter to your view.
2. Right-click the folder where you want to store the view, point to New, and then click Task Status View.
3. In the Properties dialog box of the task status view, type a name and a description for the view. (The
4. On the Criteria tab, click the ellipses (...) next to the Show data related to box. The Select a Target
Type dialog box displays a list of the object types available in your management group. Click to select the
object type that most specifically describes the objects that you want to view, and then click OK.
The object type you select is listed in the Show data related to box. If you want to narrow the focus of
the view, you can also click the ellipses (...) next to Show data contained in a specific group. Click a
group to filter the objects shown in your view, and then click OK.
NOTE
If you do not see the object type that you want, click View all targets and then type a word or phrase in Find to
filter the displayed list.
5. Use the check boxes provided to select individual criteria to apply additional filters to the objects that you
want to display in your view. You might need to further define the criteria in the Criteria description box.
6. Click the Display tab. By default, all columns in your state view display. Click to deselect one or more
columns that you do not want to display. Choose how you want to sort the objects in your view in Sort
columns by.
How to create a web page view

You can create a view that displays a specific web page. For example, you can create a web page view that points
to http://social.technet.microsoft.com/Forums/category/systemcenteroperationsmanager, which makes the
community forums for Operations Manager available to you within the Operations console. You can interact with
the web pages displayed in a web page view, just as you can in an internet browser.
2. Right-click the folder where you want to store the view, point to New, and then click Web Page View.
3. Enter a name and description for the view. (The description is optional.)
4. In the Target website field, enter the URI for the web page to be displayed in the view. You can specify an
Internet or intranet address.
NOTE
The web view will only display the specified web page on computers that have access to that web page. For
example, if you create a web page view that links to the System Center page on Microsoft.com, an Operations
console on a computer that does not have Internet access will not display the correct web page in that web page
view.
5. Click OK.
How to create a dashboard view

You can create dashboard views in the Operations Manager web console as well as the Operations console.
IMPORTANT
When a dashboard view uses data from the data warehouse database, operators might be able to view data that they
would not otherwise have access to in views that use data from the operational database.
You can use dashboard views to present multiple types of data in a single view. You select either a flow layout,
which consists of multiple columns, or a grid layout, which consists of multiple cells. In the grid layout, you also
specify the layout of the cells.
If you create a dashboard view that uses a flow layout, you can change the number of columns afterward. If you
create a dashboard view that uses a grid layout, you can change the layout afterward but you cannot change the
number of cells.
For both layouts, after you create the dashboard view, you add widgets which will display specific types of data.
NOTE
A column or cell in a dashboard view can contain a widget or another dashboard view.
Widgets in a dashboard view can display data for a particular target class or group of objects. To support the
dashboard view that you are going to create, you should first create a group containing a set of computers or
objects to include in the displayed data.
NOTE
When you create a dashboard view that includes a widget that displays data for a target class that contains instances (a
non-singleton class), that dashboard view cannot be imported into other management groups.
You can also create a service level dashboard view to track data for service level objectives that you create. For
more information, see Creating a Service Level Dashboard.
2. Right-click the folder where you want to store the view, point to New, and click Dashboard View.
3. In the New Instance Wizard, on the Template page, click either Flow Layout or Grid Layout, and then
click Next.
4. On the General Properties page, enter a name for the dashboard view. The description is optional. Click
Next.
5. For a grid layout, on the Select Layout page, choose the number of cells to display and the layout
template for the cells. The layout templates change based on the number of cells selected. Click Next.
For a flow layout, on the Specify the flow layout column count page, select the number of columns to
display. Click Next.
6. Review the settings on the Summary page, and then click Create.
7. Click Close.
The dashboard view that you created is displayed. Next, you configure the columns or cells in the dashboard
view.
To add widgets to a dashboard view
1. In a cell or column of a dashboard view, click Click to add widget.
2. In the New Instance Wizard, on the Template page, select from the available templates. The wizard pages
for the Flow Layout and Grid Layout templates are the same as in the new dashboard view procedure. The
following steps provide instructions for the other widget templates.
Alert Widget:
a. On the General Properties page, enter a name for the widget. The description is optional. Click
Next.
b. On the Specify the Scope page, select a group or object, and then click Next.
c. On the Specify the Criteria page, use the severity, priority, and resolution state checkboxes to
select the criteria for data to be displayed, and then click Next.
d. On the Display page, select the columns you want displayed. You can also configure the sort order
and how to group the data. Click Next.
e. Review the settings on the Summary page, and then click Create.
f. Click Close.
Performance Widget:
Next.
b. On the Specify the Scope and Counters page, select a group or object.
c. On the Specify the Scope and Counters page, click Add.
d. In the Select performance counters dialog box, use the Object, Counter, and Instance drop-
down menus to filter the performance counters listed in Available Items. Select performance
counters from the Available Items list, click Add, and then click OK.
NOTE
The performance counters available are scoped to the group or object you selected in Select a group or
object.
e. Click Next.
f. On the Time Range page, select the time range for the data, and click Next.
g. On the Specify the Chart Preferences page, select the items you want displayed in the
performance chart. You can configure order of the items by using the up and down arrows. For the
vertical axis, you can select Automatic or configure the minimum and maximum values manually.
Cilck Next.
h. Review the settings on the Summary page, and then click Create.
i. Click Close.
State Widget:
Next.
b. On the Specify the Scope page, click Add.
c. In the Add Groups or Objects window, click the groups or objects in Available items and click
Add, and then click OK.
d. In Select a class to scope the members of the specific groups, you can change the selected
class. (Object is selected by default.) Click Next.
e. On the Specify the Criteria page, use the health state checkboxes to select the criteria for data to
be displayed, and then click Next.
NOTE
You can also select to display only objects in maintenance mode.
f. On the Display page, select the columns you want displayed. You can also configure the sort order
and how to group the data. Click Next.
g. Review the settings on the Summary page, and then click Create.
How to create an overrides summary view

You can only create an overrides summary view in My Workspace.
You can view all rule and monitor overrides in an overrides summary view. The overrides summary view can be
used for both sealed and unsealed management packs.
2. Right-click the folder where you want to store the view, point to New, and then click Overrides
Summary Vieew.
3. In the Properties dialog box of the overrides summary view, type a name and description for the view.
(The description is optional.)
4. Set the criteria to identify the performance data to display:
a. Identify a class or group for performance data. For example, to create an overrides summary view
for all System Center agents, select Agent in the Show data related to list.
b. Select the conditions that define the content of the view.
NOTE
5. Customize the appearance of the alert view on the Display tab.
Next steps
Manager.
Operations Manager includes a number of views that are created during installation. To understand what
these views provide, see Standard Views in Operations Manager.
Views included in sealed management packs can be modified to include other monitored object
properties. To customize a view, see How to Personalize a View in Operations Manager.
How to personalize a view in Operations Manager
2 minutes to read
In System Center Operations Manager, views are contained in management packs. If a view is contained in a
sealed management pack, you can open the properties of the view but you cannot save any changes to it.
However, you can change the display options of the view and then save it as a personalized view.
NOTE
Personalized views are only visible to the user who personalized the view.
To personalize a view
2. In the Monitoring workspace, right-click the view that you want to personalize and then click Personalize
view. The Personalize view dialog box displays with the default settings of the view.
3. In Columns to display, click to place a check next to the property that you want to display in your view.
You can also click to remove any checkmarks set by the original view. In the Sort columns by box, click the
drop-down arrow to choose a property by which you want to sort the monitored objects in your view, and
then click OK.
NOTE
In a state view, the option to sort by groups is not available. This option is available in other view types, such as the
alert view and event view.
To restore view defaults

2. In the Monitoring workspace, right-click the personalized view
3. Click Reset to Default, and then click OK.
Next steps
Manager.
Operations Manager includes a number of views that are created during installation. To understand what
these views provide, see Standard Views in Operations Manager.
To understand how to create your own custom views and dashboards in Operations Manager, as well as
how to scope them, see Creating and Scoping Views in Operations Manager.
Subscribing to alert notifications
2 minutes to read
In System Center - Operations Manager, when an alert is generated, Operations Manager can notify designated
individuals by email, instant message (IM ), or text message (SMS ). Notifications can also run commands
automatically when an alert is raised on a monitored system.
A notification requires the following elements:
A Run As account that provides credentials to the Notification Account Run As profile.
A notification channel which defines the format for the notification and the method by which the
notification is sent.
A notification subscriber which defines the recipients and the schedule for sending notifications to the
subscriber.
A notification subscription which defines the criteria for sending a notification, the channel to be used, and
the subscribers to receive the notification.
An Operations Manager administrator must define the notification channels and if authentication is required,
configure the Run As account for notifications. An Operations Manager administrator, advanced operator, or
operator can create a subscriber and a subscription.
Subscribing to alert notifications topics

How to create and configure the Notification Action account
How to enable an instant message notification channel
How to enable a text message (SMS ) notification channel
How to customize message content for Notifications
How to create and configure the Notification action
account
2 minutes to read
individuals by email, instant message (IM ), or text message (SMS ). The Notification Account Run As profile is used
to send notifications. For notifications to work correctly, you must create a Run As account that provides the
credentials for sending notifications and associate the Run As account to the Notification Account profile.
To create and configure the Notification action account

1. Sign in to the computer with a user account that is a member of the Operations Manager Administrators
role.
3. In the Administration workspace, right-click Security, and then click Create Run As Account. Use the
Create Run As Account Wizard to create an account to use as the Notification action account, which is used
to send the notifications.
4. On the Introduction page, click Next.
5. On the General Properties page, select Windows in the Run As Account type list for setting up
authentication with an email server in the same organization or domain or select Simple Authentication
for setting up authentication with an external mail server, and then in Display name, type Notification
action account. Click Next.
6. On the Credentials page, type the information for the user name, password, and domain (if required) of the
user account that to be used for notifications. Click Next.
7. Select the More secure distribution security option. For more information on this option, see Distribution
and Targeting for Run As Accounts and Profiles.
8. Click Create.
9. In the navigation pane, click Accounts under Run As Configuration.
10. In the details pane, right-click Notification action account, and then click Properties.
11. On the Distribution tab, click Add.
12. In the Computer Search window, click Search to display a name of available computers.
13. Select the server or servers to distribute the credentials to, click Add, and then click OK to close the search
window.
14. Click OK to close the properties window.
15. In the navigation pane, click Profiles under Run As Configuration.
16. Right-click Notification Account and click Properties, which will open the Run As Profile Wizard.
17. On the Introduction page, click Next.
18. If you are configuring an internal email, then on the General Properties page, click Next. If you are
configuring an external email then, right-click on Profiles and click Create Run As Profile. On the
General Properties page enter a suitable Display name and for Select destination management pack,
choose Notification Internal Library from the drop-down list.
19. On the Run As Accounts page, click Add.
20. In the Add a Run As Account window, in the Run As account drop-down list, select the Run As account
that you created earlier in this procedure. If you are configuring an internal email accept the default All
targeted objects and then click OK. If you are configuring an external email, choose A selected class,
group, or object, click Select and choose Class. On the Class Search page search and select Alert
Notification Subscription server, and then click OK.
21. Click Save. When the association is completed, click Close to close the wizard.
Next steps
To designate when to send notifications and the addresses to which the notifications should be sent to,
review How to Create Notification Subscribers
Create a notification subscription to define the criteria, notification channel, and subscribers that will receive
the notification.
4 minutes to read
To configure alert notifications for System Center - Operations Manager, your first task is to enable a notification
channel. This topic describes how to configure a channel that will send alert notifications to subscribers from an
email server either within the domain of the organization or external email authentication.
Before you begin, gather the following information:
SMTP server information
Fully qualified domain name (FQDN ).
Port number for the SMTP server.
Authentication method for the SMTP server. You have three choices:
Anonymous
Windows Integrated
External Email Authentication
NOTE
Operations Manager supports configuration of any external email account to send the notifications through External
Email Authentication. You have the flexibility in terms of which email account is to be used for sending out the
notification emails.
Return email address. This address is used for all email notifications on this channel and will receive any
replies to notifications.
For internal email server, any return address that is within the domain can be specified. Multiple internal
servers can be added to the subscription channel.
For an external email server, the email account used for creating the Run As profile must match the
return address. To avoid coexistence issues with other email servers, a subscription channel with an
external email account must contain only that email server.
Email subject and body text that you want subscribers to receive. For more information, see How to
customize message content for notifications.
To enable an email notification channel

1. Log on to the computer with a user account that is a member of the Operations Manager Administrators
role.
3. In the navigation pane, under Notifications, right-click Channels. Click New channel and then click E -
mail (SMTP ).
4. Type a name for the channel, such as SMTP channel and optionally provide a description. Click Next.
5. In the SMTP servers area, click Add.
6. In the Add SMTP Server dialog box, type the fully qualified domain name (FQDN ) of a Simple Mail
Transfer Protocol (SMTP ) server, type the port number, select the authentication method used by the SMTP
server, and then click OK.
NOTE
You can add one or more additional servers to act as backup servers. If the primary SMTP server is unavailable,
notifications are sent through the secondary server.
7. Type the Return Address that should appear on email notifications, and then in the Retry interval list,
select the number of minutes to wait before trying to resend a notification to the primary SMTP server.
Click Next.
NOTE
If you have only one SMTP server and it's unavailable, the Retry interval has no effect. The Retry interval is used
when you have a secondary server and mail sending to the primary server fails. When this happens, Operations
Manager switches to the secondary server and checks the Retry interval time. If the Retry interval time has passed,
Operations Manager tries to use the primary server.
8. In the Default e-mail notification format area, specify the E -mail subject and E -mail message text or
leave the default selections, select the Importance level that you want the emails sent with, and then
specify the Encoding type. You can click the right arrow next to the E -mail subject and E -mail message
boxes for a full list of available variables. For more information, see How to customize message content for
notifications.
9. Click Finish, and then click Close.
Create an email notification in HTML format

Operations Manager 2019 introduces the ability to create and send email notifications in HTML format.
With this feature, an administrator would be able to configure an email in HTML format for sending notifications
to subscribers. The administrators can use the existing default HTML email template, edit it, or create a new HTML
message. With HTML email format, subscribers get easy access to relevant information about the alert, alert
source and the rule/monitor that generated the alert. They can view these details through the drill-down links
available at the end of the email.
To create an email in HTML format, perform the following steps:
1. Use the procedure in the above section for creating email notification channel.
2. While configuring the format of the email notifications, select Enable HTML formatting as shown in the
image below:
3. To edit or change the default content:
Copy the content by clicking Copy.
Edit or change the content in any HTML editor.
Paste the modified content back by clicking Paste.
Click Preview to view a preview of the edited text.
While editing the HTML email content, you can add the required alert property or the web console link by
using the applicable variable in the appropriate position of your HTML content.
The following table highlights the variables to use for various properties of the alert or links to the HTML
content.
ALERT PROPERTY OF THE LINK VARIABLE
Alert Source $Data[Default='Not

Present']/Context/DataItem/ManagedEntityPath$$Data[D
efault='Not
Present']/Context/DataItem/ManagedEntityDisplayName$
Alert Name $Data[Default='Not

Present']/Context/DataItem/AlertName$
Alert Description $Data[Default='Not

Present']/Context/DataItem/AlertDescription$
Alert Severity $Data[Default='Not Present']/Context/DataItem/Severity$
Alert Priority $Data[Default='Not Present']/Context/DataItem/Priority$

ALERT PROPERTY OF THE LINK VARIABLE
Alert Category $Data[Default='Not

Present']/Context/DataItem/Category$
Alert Owner $Data[Default='Not

Present']/Context/DataItem/AlertOwner$
Alert Resolved By $Data[Default='Not

Present']/Context/DataItem/ResolvedBy$
Alert Raised Time $Data[Default='Not

Present']/Context/DataItem/TimeRaisedLocal$
Alert Last Modified Time $Data[Default='Not

Present']/Context/DataItem/LastModifiedLocal$
Alert Last Modified By $Data[Default='Not

Present']/Context/DataItem/LastModifiedBy$
Custom FieldN (N varies from 1 to 10) $Data[Default='Not

Present']/Context/DataItem/CustomN$
WebConsole Alert Link $Target/Property[Type="Notification!Microsoft.SystemCen

ter.AlertNotificationSubscriptionServer"]/WebConsoleUrl$/
#/monitoring/drilldown/alert/$UrlEncodeData/Context/Da
taItem/AlertId$
WebConsole Alert Source Link $Target/Property[Type="Notification!Microsoft.SystemCen

ter.AlertNotificationSubscriptionServer"]/WebConsoleUrl$/
#/monitoring/drilldown/object/$UrlEncodeData/Context/D
ataItem/ManagedEntity$
The following example is created from a critical severity alert:
The following example is created from a warning severity alert:

Next steps
review How to create notification subscribers
the notification.
How to enable an instant message notification
channel
2 minutes to read
channel. This topic describes how to configure a channel that will send alert notifications to subscribers by using
an instant message.
Before you begin, gather the following information from your instant message server:
Fully qualified domain name (FQDN ).
Protocol used to send messages. You have two choices: TCP or Transport Layer Security (TLS ).
Port used for instant messages. The default is 5061.
Encoding used by the instant message server and notification subscribers. The default is UTF -8.
Return address to be used for the instant messages.
To enable an instant message notification channel

role.
3. In the navigation pane, under Notifications, right-click Channels. Click New channel, and then click
Instant Message (IM ).
4. Type a name for the channel, such as IM channel and optionally provide a description. Click Next.
5. In the IM server box, type the FQDN of an instant messaging server.
6. Type the Return Address that should appear on instant message notifications. Preface the address with
sip:. In the Protocol option list, select either TCP or TLS as the protocol used to send the instant
messages. In the Authentication method list, select either NTLM or Kerberos as the authentication
method for users. In the IM port box, the default instant messaging port of 5060 is entered. Type the port
number used to send instant messages.
NOTE
The return address should be a dedicated address that is used only for Operations Manager notifications.
7. Click Next.
8. In the Default instant messaging notification format area, in the IM message box, specify the text that
is sent to notification subscribers. The IM message box contains a default message that includes text and
variables. You can edit the default message or delete it and replace it with another message. You can click
the right arrow next to the IM message box for a full list of available variables. For more information, see
How to customize message content for notifications.
9. In the Encoding box, select the text format that your IM server and notification subscribers use for
transmission. By default, Unicode (UTF -8) is used.
10. Click Finish and then click Close.
Next steps
the notification.
To create an email notification channel, see How to enable an email notification channel.
To create a command channel notification, see How to enable a command notification channel.
To create a text message (SMS ) notification channel, see How to enable a text message (SMS ) notification
channel.
How to enable a text message (SMS) notification
channel
2 minutes to read
channel. This topic describes how to configure a channel that will send alert notifications to subscribers by using a
Short Message Service (SMS ) or text message.
NOTE
The modem used for SMS must support SMS Protocol Data Unit (PDU) mode.
To enable a text message notification channel

role.
3. In the navigation pane, under Notifications, right-click Channels. Click New channel and then click Text
message (SMS ).
4. Type a name for the channel, such as SMS channel and optionally provide a description. Click Next.
5. In the Text message box, specify the text that is sent to SMS notification subscribers. The Text message
box contains a default message that includes text and variables. You can edit the default message or delete
it and replace it with another message. You can click the right arrow next to the Text message box for a full
list of available variables. For more information, see How to Customize Message Content for Notifications.
6. In the Encoding box, select the text format for the SMS messages.
Next steps
the notification.
To create a command channel notification, see How to enable a command notification channel.
To create an instant message notification channel see, How to enable an instant message notification
channel.
2 minutes to read
channel. This topic describes how to configure a channel that runs an executable program automatically in
response to an alert.
To create a command notification channel, you need the following information:
Full path of the command file.
Command line parameters.
The startup folder for the command, which is the path of the program you want to run.
To enable a command notification

role.
3. In the navigation pane, under Notifications, right-click Channels. Click New channel and then click
Command.
4. Type a unique name for this command channel in the Notification command channel name box and a
brief description in the Description box. Click Next.
5. Type the path to the executable file that you want to run in the Full path to command file box. For
example, "%systemroot%\cmd.exe" or "c:\windows\system32\cscript.exe". Type any parameters that you
want to run with this command in Command line parameters box. Type the directory for this command
in the Startup folder for the command line box.
Next steps
the notification.
To create a text message (SMS ) notification channel, see How to enable a text message (SMS ) notification
channel.
To create an instant message notification channel see, How to enable an instant message notification
channel.
2 minutes to read
automatically when an alert is raised on a monitored system. A notification requires a channel, a subscriber, and
a subscription.
These procedures explain how to create subscribers for notifications. A notification subscriber defines when to
send notifications and the addresses to which the notifications should be sent. A subscriber can be an individual
user account or a distribution list.
Notification channels must be enabled before you create subscribers. After a subscriber is created, you create a
notification subscription that defines the format of the notification message and any filters such as age or
severity of the alert.
To create a notification subscriber as an administrator

3. Under Notifications, right-click Subscribers, and click New subscriber.
4. On the Description page, type a display name for this subscriber.
5. On the Schedule Notifications page, click Always send notifications, or Notify only during the
specified times and specify when notifications should be sent to this subscriber. The options available
allow you to:
Limit notifications to a specific range of dates.
Specify that notifications are sent only during certain hours or except for certain hours.
Specify that notifications will be sent only on certain days of the week.
Set a time zone to be used for the subscriber.
NOTE
The settings on the Schedule Notifications page apply globally to the subscriber. You can also specify unique
schedule settings for each address that you add to the subscriber, in the following steps. For example, you can add
one email address that receives the notifications during business hours and add a second email address that
receives the notifications outside of business hours.
6. On the Subscriber Addresses page, click Add to add subscriber addresses to the notification.
7. On the Describe the Subscriber Address page, enter a name to identify the subscriber address, and
then click Next.
8. On the Provide the Channel and Delivery Address page, perform the following steps:
a. In Channel Type, select between email, instant message, text message, or command for the
method of notification.
b. If you select command for channel type, in Command Channel, select the name of a command
channel. The command channel must be created before you create the subscriber. Skip the next
step, because no delivery address is specified for a command channel.
c. In Delivery address for the selected channel, enter the address to which the notification should
be sent.
d. Click Next.
9. On the Schedule Notifications page, click Always send notifications, or Notify only during the
specified times and click Add to create a date range, and then click Next.
10. Click Add to define another subscriber address. Otherwise, click Finish, and then click Close.
11. The new subscriber displays in the Subscribers pane.
Next steps
the notification.
8 minutes to read
automatically when an alert is raised on a monitored system. A notification requires a channel, a subscriber, and
a subscription.
These procedures will explain how to specify the criteria or conditions that determine the alerts that will generate
a notification, use of classes and groups, and criteria or conditions in your subscriptions to filter and align
notifications with your organizational escalation path. A subscription also defines the channel to be used for the
notification and the subscribers to receive the notification. You can use the combination of subscriber and
subscription to tailor which alerts are sent to individuals or teams.
Notification channels and subscribers must be configured before you create a subscription.
Subscription filtering options

Before creating a subscription, we will review the two methods you can use to filter alert notifications so that you
can deliver alerts that meet certain conditions, such as all critical severity alerts with high priority notify IT
Operations or from specific monitored objects like all systems for a particular remote location notify that on-site
IT support team.
Specifying which alerts generate notifications (Conditions)
When you create a subscription to be notified when Operations Manager generates alerts, you must specify the
criteria or conditions that determine the alerts that will generate a notification. The following illustration shows
the conditions you can choose from.
When you select a condition, it is added to the Criteria description. In the Criteria description box, the word
specific is blue and underlined, and is a placeholder for the value for the condition. Click specific to set the
value for that condition.
For example, for the condition of a specific severity, click specific, and then select from the available values:
Information, Warning, and Critical.
When you create a notification subscription from an alert that has been generated, the conditions for the
subscription are configured automatically with values from the specific alert.
Subscription filter options

Before creating a subscription, we will review the two methods that you can use to filter alert notifications so that
you can deliver alerts that meet certain conditions, such as all critical severity alerts with high priority notify IT
Operations or from specific monitored objects like all systems for a particular remote location notify that on-site
IT support team.
Specify the alerts that generate notifications (Conditions)
When you create a subscription to be notified when Operations Manager generates alerts, you must specify the
criteria or conditions that determine the alerts, which will generate a notification. Criteria builder has been
enhanced to allow you to build complex yet useful/efficient subscription criteria by leveraging the ability to
exclude objects, use AND/OR groupings and use regular expressions to notify based on the required criteria.
In Scope, you can choose the scope for a subscription by selecting the specific group(s) or class(es). Defining a
scope is optional, if scope is not defined, then the conditions defined in the next screen (Criteria) will not be
scoped to any groups/classes.
In Criteria, you can set the conditions for the notifications to be sent to the specified subscribers. If you do not
set the conditions, notifications will be sent for all alerts. These conditions will be applied on the scope defined in
the earlier screen to send notification to the specified subscribers, if scope is not defined in the earlier screen,
then these conditions will not be scoped to any groups/classes.
The following are the examples of the criteria builder showcasing single expression and groups of expressions:
Example - single expression
Example - groups of expressions
Using classes and groups to include specific alerts
You can use classes and groups to configure the subscription. Two of the conditions for alerts that you can select
for a subscription are:
Raised by any instance in a specific group.
Raised by any instance in a specific class.
You can select multiple groups or classes when you set the value for either condition.
NOTE
Operations Manager 2019 does not support "not equal to" or "not a member of" options in Scope tab.
Groups
Groups are logical collections of objects, such as Windows-based computers, hard disks, or instances of
Microsoft SQL Server. Some groups are created by Operations Manager, such as the Operations Manager
Agent Managed Computer Group and the All Windows Computers group. You can create groups to meet your
specific monitoring needs, such as all Windows computers in a specific organizational unit (OU ). For more
information on creating groups, see Creating and Managing Groups.
Groups can have explicit or dynamic membership. Suppose you wanted to create a subscription that would send
notifications for alerts generated by five specific servers to one person and notifications for alerts generated by a
different five servers to a second person. You could create two groups and explicitly assign each server to one of
the groups, and then create a subscription that would send notifications for each group to the appropriate
person.
When you select a specific group as a condition for an alert notification, notifications are sent for alerts raised by
any member of the specified group.
Classes
A class represents a kind of object, and every object in Operations Manager is considered an instance of a
particular class. All instances of a class share a common set of properties. Each object has its own values for
these properties which are determined when the object is discovered. Most management packs define a set of
classes that describe the different components that make up the application that is being monitored and to the
relationships between those classes.
Every class in Operations Manager has a base class. A class has all the properties of its base class and potentially
adds more. All of the classes from the different management packs installed in your management group can be
arranged in a tree with each class positioned under its base class. If you start at any class, and then walk up the
tree following its base class, and then the base class of that class, and so on, you eventually reach the Object
class which is the root of the System Center class library.
When you select a specific class as a condition for an alert notification, notifications are sent for alerts raised by
any instance of the specified class.
Examples
Example 1: To send notifications of alerts for UNIX computers to your UNIX administrator, you create a
subscription using the condition Raised by any instance in a specific group, select the UNIX/Linux
Computer Group as the value for the condition, and select the UNIX administrator as the subscriber.
Example 2: To send notifications of new alerts with a critical severity and high priority to your IT Operations
team, you create a subscription using the condition of Critical severity, of a High priority, with New (0)
resolution state, and select your subscriber representing the IT Operations team.
In the first example, the UNIX administrator would be notified of alerts raised by the operating system on a
UNIX computer, as well as any other alerts that are raised by a UNIX computer. In the second example, the
notifications would only be sent when new alerts are raised with critical severity and high priority.
To create a notification subscription as an administrator

3. In the Administration workspace, expand Notifications, right-click Subscriptions, and then click New
subscription. The Notification Subscription Wizard starts.
4. On the Description page, in Subscription name, type a descriptive name for the subscription, type a
short description, and then click Next.
5. On the Subscription Criteria page, you can set conditions that will determine when notifications will be
sent to specified subscribers. If you do not set conditions, notifications will be sent for all alerts. Click
Next.
NOTE
You will also receive notifications when an alert is updated.
6. On the Subscribers page, click Add to add subscribers who are already defined, or click New to add new
subscribers. For more information on defining subscribers, see How to Create Notification Subscribers.
7. Click Next.
8. On the Channels page, click Add to add a channel that is already defined, or click New to add a new
channel. For more information on defining channels, see How to Enable an Email Notification Channel,
How to Enable an Instant Message Notification Channel, How to Enable a Text Message Notification
Channel, and How to Enable a Command Notification Channel.
9. In the Alert aging section on the Channels page, select to send notifications without delay or set a value
in minutes that notification should be delayed unless conditions remain unchanged, and then click Next.
10. Review the settings on the Summary page, click Finish, and then click Close.
To create a notification subscription as an operator

1. Log on to the computer with an account that is a member of the Operations Manager Operators or
Advanced Operators role.
2. In the Operations console, click Tools in the top menu bar, and then click My Subscriptions.
3. In the Notification Subscriptions window, click New.

4. On the Description page, in Subscription name, type a descriptive name for the subscription, type a
short description, and then click Next.
5. On the Subscription Criteria page, you can set conditions that will determine when notifications will be
sent to specified subscribers. If you do not set conditions, notifications will be sent for all alerts. Click
Next.
NOTE
You will also receive notifications when an alert is updated.
6. On the Subscribers page, click Add to add subscribers who are already defined, or select a subscriber in
the Selected subscribers box and click Edit to change the settings for this subscription. For more
information on defining subscribers, see How to Create Notification Subscribers.
7. Click Next.
8. On the Channels page, click Add to add a channel that is already defined, or click New to create a
customized copy of an existing channel. For more information on defining channels, see How to Enable an
Email Notification Channel, How to Enable an Instant Message Notification Channel, How to Enable a
Text Message (SMS ) Notification Channel, and How to Enable a Command Notification Channel.
9. In the Alert aging section on the Channels page, select to send notifications without delay or set a value
in minutes that notification should be delayed unless conditions remain unchanged, and then click Next.
10. Review the settings on the Summary page, click Finish, and then click Close.
Next steps
To designate when to send notifications and the addresses to which the notifications should be sent to, review
How to Create Notification Subscribers
How to customize message content for notifications
3 minutes to read
In System Center - Operations Manager, you can customize the format that will be used for messages that notify
you of alerts. The format of an alert notification is determined by the channel by which the notification is sent.
Each channel type has a default format, as shown in the following examples.
NOTE
The command channel type is not mentioned because it generates a command rather than a notification message.
CHANNEL TYPE DEFAULT NOTIFICATION FORMAT
Email Subject: Alert: alert name Resolution state: new or closed
Alert:
Source:
Path:
Last modified by:
Last modified time:
Alert description:
Alert view link:
Notification subscription ID generating this message:
Instant message (IM) Alert: alert name Path: path to managed entity Resolution
state: new or closed Last modified by: last modified by
SMS (text message) Alert: alert name Resolution state: new or closed
You can change the format on the Format page of the channel type wizard when you create the channel or after
the channel is created. The procedure is the same for all three channel types.
Format options for notification message

VARIABLE DESCRIPTION
$Data/Context/DataItem/AlertId$ AlertID GUID
$Data/Context/DataItem/AlertName$ Alert name
$Data/Context/DataItem/Category$ Alert category
$Data/Context/DataItem/CreatedByMonitor$ True/False
$Data/Context/DataItem/Custom1$ CustomField1
$Data/Context/DataItem/DataItemCreateTime$ UTC Date/Time of Dataitem created
$Data/Context/DataItem/DataItemCreateTimeLocal$ LocalTime Date/Time of Dataitem created
$Data/Context/DataItem/LastModified$ UTC Date/Time DataItem was modified
$Data/Context/DataItem/LastModifiedLocal$ Local Date/Time DataItem was modified
$Data/Context/DataItem/LastModifiedBy$ Name of person who modified alert
$Data/Context/DataItem/ManagedEntity$ ManagedEntity GUID
$Data/Context/DataItem/ManagedEntityDisplayName$ ManagedEntity display name
$Data/Context/DataItem/ManagedEntityFullName$ ManagedEntity full name
$Data/Context/DataItem/ManagedEntityPath$ Managed entity path
$Data/Context/DataItem/Priority$ Alert priority number (High=1,Medium=2,Low=3)
$Data/Context/DataItem/Owner$ Alert owner
$Data/Context/DataItem/RepeatCount$ Alert repeat count
$Data/Context/DataItem/ResolutionState$ Resolution state ID (0=New, 255=Closed)
$Data/Context/DataItem/ResolutionStateLastModified$ UTC Date/Time ResolutionState was last modified
$Data/Context/DataItem/ResolutionStateLastModifiedLocal$ Local Date/Time ResolutionState was last modified

$Data/Context/DataItem/ResolutionStateName$ The resolution state name (New, Closed)
$Data/Context/DataItem/ResolvedBy$ Person resolving the alert
$Data/Context/DataItem/Severity$ Alert severity ID
$Data/Context/DataItem/TicketId$ TicketID
$Data/Context/DataItem/TimeAdded$ UTC time added
$Data/Context/DataItem/TimeAddedLocal$ Local time added
$Data/Context/DataItem/TimeRaised$ UTC time raised
$Data/Context/DataItem/TimeRaisedLocal$ Local time raised
$Data/Context/DataItem/TimeResolved$ UTC Date/Time the Alert was resolved
$Data/Context/DataItem/WorkflowId$ WorkflowID (GUID)
$Data/Recipients/To/Address/Address$ Name of the recipient
$Target/Property[Type="Notification!Microsoft.SystemCenter. Web console URL

AlertNotificationSubscriptionServer"/WebConsoleUrl$
Target/Property[Type="Notification!Microsoft.SystemCenter.A Principal name of the management server

lertNotificationSubscriptionServer"/PrincipalName$
To configure notification format

1. On the Format page of the channel type wizard, in the message box for the channel type (or subject box
for the email channel), delete any information from the default format that you do not want to include.
2. Position your cursor in the location of the box where you want to add information.
3. Type any non-variable text that you want in the message.
4. Click the button to the right of the box to display the information you can add to the subject or message for
notifications, as shown in the following illustration.
5. Click any item in that list to add the corresponding variable to the notification message. For example, if you
click Alert Severity, the following variable will be added to the box:
$Data/[Default='Not Present']/Context/DataItem/Severity$
NOTE
When a default value for a parameter is included, such as [Default='Not Present'] in the preceding example, it
indicates the text to provide when the alert does not contain data for that parameter.
6. When you are done, click Finish. All notification messages that use the same channel will be formatted the
same way.
Customizing a channel for a subscription

When you create a subscription, you can copy an existing channel that you can customize for that subscription.
1. In the Notification Subscription Wizard, on the Channels page, click New, and then click Create
Customized Copy.
2. In the Channel Search window, use Filter by and Search to locate the channel you want to copy. Select
the channel in Available channels, click Add, and then click OK.
3. The notification channel wizard for the selected channel opens. You can change the name, description,
settings, and message format on the corresponding wizard pages. As a best practice, change the name of
the channel to distinguish it from the original channel. Click Finish when you are done making changes.
Next steps
Create a notification subscription to define the criteria, notification channel, and subscribers that will
receive the notification.
2 minutes to read
automatically when an alert is raised on a monitored system. A notification requires a channel, a subscriber, and a
subscription.
You can create a notification subscription from an alert to ensure that you are notified if the alert is sent again. You
can either create a new subscription or add the alert to an existing subscription. In the following procedure, you
create a new subscription.
NOTE
You must have configured a notification channel and notification subscriber to perform this procedure.
To create a notification subscription from an alert

1. In the Alerts view, right-click the alert, click Notification subscription, and then click Create.
2. The text boxes for the name and description for the subscription are pre-populated with information from
the alert. Click Next.
3. The text boxes for the conditions and criteria for when the notification is sent are pre-populated with default
values from the alert. Click Next.
4. Click Add or Remove to select the notification subscriber that the notifications should be sent to.
5. Click Search to display all available subscribers.
6. Double-click the subscriber you want to use, and then click OK.
7. Click Next.
8. Click Add or Remove to select the notification channel to use.
9. Click Search to display all available channels.
10. Double-click the channel you want to use, and then click OK.
11. Click Next, and then click Finish.
12. Click Close.
Next steps
the notification.
Using the Visio Add-in and SharePoint Visio Services
Data Provider
2 minutes to read
The Visio Add-in for System Center - Operations Manager combines the strengths of two applications widely used
in enterprise IT to simplify the creation of customized dashboards that show the health of an environment. The
Visio Add-in lets you create diagrams in Visio 2010, 2013, and 2016 that shows:
Objects by geography on a map, by location in a data center or building
By role in a logical view of an application
By topology for complex distributed applications or a core infrastructure technology such as Active Directory
Domain Services
The SharePoint Visio Services Data Provider for System Center - Operations Manager enables you to take the
customized dashboards you create with the Visio Add-in and include them in SharePoint 2010, 2013, and 2016
Web sites. These Web-based dashboards are updated and provide access to instant status information through the
familiar SharePoint browser-based experience.
The Visio Add-in and SharePoint Visio Services Data Provider have the following features:
Distributed applications exported from Operations Manager as Visio documents automatically show live
health state information on the exported objects when opened in Microsoft Visio.
You can easily create new Visio documents and link shapes to any managed object (such as a computer,
database, Web site, or perspective) to show the current health state.
You can automatically link entire existing Visio documents to the computer and to network devices managed
by Operations Manager by matching computer names or IP addresses.
Health states can be automatically refreshed in Visio documents. You can use this option along with Visio's
full-screen view to create dashboard views suitable for use as a summary display in a data center control
room.
Predefined data graphics enable you to switch from Operations Manager health icons to the shape color for
health state.
Health states can be automatically refreshed in published Visio documents that are hosted in SharePoint
document libraries, when the Visio Services data provider for System Center - Operations Manager is
installed and configured on the SharePoint server farm.
The following topics provide information about how to install, configure, and use the Visio Add-in and the
SharePoint Visio Services Data Provider.
Install the Visio Add-in
Install and Configure the Visio Services Data Provider
Configure the Operations Manager Data Source in Visio
View an Operations Manager Distributed Application Diagram in Visio
Link to Operations Manager Objects in a New or Existing Visio Document
Build a simple monitoring dashboard using the Visio Web Part
Change the Way Health State is Represented in Visio
Troubleshooting the Visio Add-in
Install the Visio Add-in
2 minutes to read
You can download the Visio Add-in from the Microsoft Download Center.
NOTE
While the page on the Download Center specifies System Center 2012, the add-in does support System Center 2016 -
Operations Manager and version 1801. For version 1801, configuring the add-in to point to the HTLM5 web console is not
supported and should continue referencing the System Center 2016 - Operations Manager Web console in order to support
launching the Health Explorer and Alert view from Visio diagrams.
The Visio Add-in for System Center Operations Manager has the following prerequisites:
System Center 2016 or later - Operations Manager.
Microsoft Office Visio 2010 or 2013 Professional or Premium.
Microsoft .NET Framework 3.5 SP1. For Windows 8, 8.1 and 10 see Installing the .NET Framework 3.5 on
Windows 8, Windows 8.1 and Windows 10.
To install the Visio Add-in

When you run the Setup program for the Visio Add-in, your system is checked against these requirements. If your
system does not meet the requirements, a link is provided so that you can download the missing software.
1. In Windows Explorer, navigate to the directory where you downloaded the Add-in and then double-click
OpsMgrAddinSetup.msi. This is the installation file for the client.
2. Click Next on the Welcome page of the installation wizard.
3. Read the license agreement, select I Agree, and then click Next.
4. Specify the installation location, and then click Next.
5. Click Next to start the installation.
6. Click Close when the installation is complete.
The next time you start Visio, you are asked if you want to install the Visio Add-in. Click Install. When the
installation is complete, the Operations Manager command is available in the Visio ribbon.
Install and configure the Visio Services Data Provider
3 minutes to read
The Visio Services Data Provider for System Center - Operations Manager leverages SharePoint's Visio Services
to enable Visio diagrams to show live health state from Operations Manager in SharePoint.
The Visio Services Data Provider for Operations Manager has the following prerequisites:
System Center - Operations Manager, Operations or Authoring console
SharePoint 2010, 2013, or 2016 Enterprise
Microsoft .NET Framework 3.5 SP1. For Windows 2012 and 2012 R2 see Enable .NET Framework 3.5 by
using the Add Roles and Features Wizard.
NOTE
You must install SharePoint Server 2010, 2013, or 2016 in a farm environment versus standalone (on a single server with a
built-in database by using the default settings) so that Visio Services can be configured to run as a domain account with
Operations Manager access. For more information about installing SharePoint Server on a single server farm, see Install
SharePoint Server 2013 on a single server with SQL Server). For more information about installing SharePoint Server 2013 on
a multiple server farm, see Install SharePoint 2013 across multiple servers for a three-tier farm and for SharePoint 2016 see
Install SharePoint 2016 across multiple servers.
Install the Visio Services data provider

1. In Windows Explorer, navigate to the directory where you downloaded the Add-in and then double-click
the OpsMgrDataModuleSetup.msi.
2. Read the license agreement, select I Agree, and then click Next.
3. Specify the installation location, and then click Next.
By default, files are extracted to the C:\Program Files\ directory. You can change this to any location.
NOTE
The .msi program does not install or deploy the data provider to the SharePoint servers in the server farm. This
program simply extracts the SharePoint deployment package to a location specified by the SharePoint administrator.
4. Open the SharePoint Management Shell as an administrator.

5. Run the following command:
.\InstallOpsMgrDataModule.ps1
NOTE
The SharePoint Administration service must be running prior to running .\InstallOpsMgrDataModule.ps1
The InstallOpsMgrDataModule cmdlet installs the deployment package to the solution store for the server
farm and then deploys the data module to each of the SharePoint servers in the server farm.
6. After the cmdlet has completed, you can verify that the package was successfully deployed by running the
get-spsolution cmdlet. You should see "True" in the Deployed column next to the opsmgrdatamodule.wsp
entry.
7. Start SharePoint Central Administration to verify that the data provider is listed as a Trusted Data Provider
for Visio Services.
Grant Visio Services with Read-Only Operator permissions

In order for Visio Services to refresh the diagrams that are published and connected to Operations Manager data,
the Visio Services service application must be configured with credentials that have access to the management
server. This is because the Visio Services service application is executing the data provider that is responsible for
returning the updated dataset from the management server.
The easiest way to configure this is to make the account that Visio Services is running as a Read-Only Operator on
the management server.
If you need to determine the account that is configured for Visio Services, use SharePoint's Central Administration:
1. Open the Central Administration site.
2. In the Security section, click Configure Service Accounts.
3. In the list of Service Accounts, select Service Application Pool - SharePoint Web Services Default.
The account is listed in the Select an account for this component field.
Grant the Visio Services account Read-Only Operator access to the

management server
2. In the Administration pane, expand Administration, expand Security, and then click User Roles.
3. In the User Roles pane, right-click Read-Only Operator, and then click Properties.
4. In the Operations Manager Read-Only Operators - User Role Properties dialog box, on the General
Properties page, click Add.
5. On the Select User or Groups page, enter the account that is configured for Service Application Pool, and
then click OK.
6. Click Apply, and then click OK to close the Operations Manager Read-Only Operators - User Role
Properties dialog box.
Configure the Operations Manager data source in
Visio
2 minutes to read
Before Visio can interact with System Center - Operations Manager or version 1801, you need to configure
Operations Manager as a data source for your Visio document. You also need to configure the Operations
Manager Web console address to enable opening the Health Explorer or Alert view directly from Visio. You need
to configure these items for each Visio document you create.
NOTE
For version 1801, configuring the Visio add-in to point to the HTLM5 web console is not supported and should continue
referencing the System Center 2016 - Operations Manager Web console in order to support launching the Health Explorer
and Alert view from Visio diagrams.
To configure the Operations Manager data source and web console

address in Visio
1. Open a new drawing in Visio.
2. Click Operations Manager in the ribbon, and then click Configure.
3. In the Name field, type the computer name of a management server in the management group.
4. In the Address field, type the address for the web console. This is the console that is used to launch the
Health Explorer and Alert view from Visio.
If you do not know the address, and you have Operations Manager administrator privileges, click Look up
web console address. If you do not know the address, and you are not an Operations Manager
administrator, contact the administrator for the address, and then type it in the Address field.
5. If you want to receive regular updates of state information from the management server, select
Automatically refresh data, and then specify a refresh interval in seconds.
6. Click OK.
View an Operations Manager distributed application
diagram in Visio
2 minutes to read
When you export a distributed application from the System Center 2016 - Operations Manager or version 1801
Operations console and then open it in Microsoft Visio with the Visio Add-in for Operations Manager, the diagram
in the Visio document contains information about the health state of each object. This information is provided
through a connection to Operations Manager.
Export distributed application diagram to Visio

1. In the Operations console, open your diagram.
2. On the toolbar, click the To Visio icon.
3. Open the folder in which you want to save the diagram, type a file name, and then click Save.
4. In Visio, open the exported diagram.
Visio automatically contacts the management server.
5. If you are prompted, type the user credentials for the management server, and then click OK.
When the diagram opens, the External Data window appears in the lower pane of Visio. This window
contains detailed information about the objects in the diagram, including the health state and the last time
the object state was refreshed in the diagram.
You can drill into the status of any object by opening the Health Explorer in the Operations Manager Web
console. To do this, right click the object and select Health Explorer. To see the alerts associated with this
object, you can open the alerts view from within the Health Explorer. Before you can do this, make sure you
have configured the address for the web console. See Configure the Operations Manager Data Source in
Visio for more information.
Now that you have the initial diagram in Visio, you can customize it by adding new shapes. You can add
links to Operations Manager components by dragging an object from the External Data window to an
image or drawing in the diagram. The data is automatically linked to the image.
You can also change the way that the health state data is displayed on an object. Select the object, and then
click a data graphic on the right side of Visio.
Link to Operations Manager objects in a new or
existing Visio document
3 minutes to read
The Visio Add-in for System Center - Operations Manager lets you link to Operations Manager objects to present
health state information in a new or existing Microsoft Visio drawing.
To do this, you first specify a Operations Manager management server from which the Visio Add-in will query to
get information about the managed objects and their health state. Then, you add the links by using one of the
following methods:
Link a single shape to a managed object. You can quickly link a few shapes to any object managed by
Operations Manager.
Add multiple links to the document and then associate these to Visio shapes later. This option works best for
large documents that have many different types of managed object.
Automatically link shapes in the document to computers or network devices. This option uses a single
wizard to automatically add health state information to large and complex network or topology diagrams.
Insert a new shape that is linked to an Operations Manager object and that uses the Operations Manager
icons.
Link a single Visio shape to an object managed by Operations Manager

1. Click Operations Manager in the ribbon, and then click Link Shape.
2. Select the Operations Manager class of the object, such as Windows Computer, to display a filtered list of
available Operations Manager objects.
3. Select the object that you want to link to this shape, and then click Link.
The shape in the diagram now includes a state indicator in the upper-right corner of the image.
Add multiple links to objects managed by Operations Manager

1. Click Operations Manager in the ribbon, and then click Add Data Links.
2. Select the class for the shape, and then click OK.
3. Select the managed objects you want to link to this shape, and then click Insert.
This adds the selected managed objects to the dataset in the Visio diagram, which can be viewed in the
External Data window.
4. In the External Data window, select the object that you want to connect to a shape in the diagram or image.
For example, if you want to add the management server for a geographic location to a map, select the
management server.
5. Drag the object to the diagram or image and drop it onto the shape. This establishes the link between the
shape and that managed object's record.
Automatically link multiple Visio shapes to Operations Manager

managed computers and network devices
1. Open the Visio document.
Ensure that each shape has defined shape data, such as the network name or IP address, or shape text (such
as the IP address of the object).
To view the shape data, right-click the shape, click Data, and then click Shape Data. This opens the Shape
Data window for the selected shape.
2. Select all the shapes in the document.
3. Click Operations Manager in the ribbon, and then click Reconcile Shapes.
4. In the Automatically Link wizard, select Selected shapes or All shapes in the document, and then click
Next.
5. Match the Visio shape property to the Operations Manager object property. For example, match the Visio
network name to the Operations Manager object display name. The following Operations Manager classes
are matched automatically:
Windows Computer (Microsoft.Windows.Computer)
Unix Computer (Microsoft.Unix.Computer)
SNMP Network Device (Microsoft.SystemCenter.NetworkDevice)
Click Next.
6. Review the list of matches. Click to clear any objects you do not want to link, and then click Next.
If more than one match is found, click Select to choose the object you want to link to. If no matches are
found, click Browse to search for the object.
7. Review the list of links to define, and then click Finish.
The shapes are automatically connected to the managed objects they represent on the management server.
Insert a shape that is linked to an Operations Manager object

1. In your Visio diagram, click Operations Manager in the ribbon, and then click Insert shape.
2. Select the class of the object you want to insert. This filters the available objects to only those of the
specified class. You can also search for a specific object.
3. Select the specific object, and then click Insert.
The new shape is added to the diagram. The shape icon matches those of other Operations Manager objects of the
same class, and the shape data is populated with information from the management group.
Build a simple monitoring dashboard using the Visio
Web Part
2 minutes to read
SharePoint Enterprise edition includes a Web part for Visio Services called the Visio Web Access Web Part. You
can add this Web part to any SharePoint Web part page to build a dashboard that uses published Visio diagrams
to provide visualizations.
To build a monitoring dashboard for your Visio diagram

1. In Internet Explorer, navigate to your SharePoint site.
2. Navigate to the Shared Documents document library.
3. Click Site Actions (above the ribbon), and then click More Options.
4. Select the Web Part page and click Create.
5. Type a name for the new page.
6. Under Layout, select Header, Right Column, Body from the list of available layout templates.
7. Click Create to create the new Web page.
8. Click the Body zone. You should see a new Insert tab on the ribbon.
9. On the Insert tab, click Web Part.
10. In the Categories list, click Business Data, and then, in the Web Parts list, click Visio Web Access.
11. Click Add.
The Visio Web Access Web Part is added to the Body zone of the Web part page.
12. Edit the properties of the Visio Web Access Web Part. In the Web Part toolbar, click Edit Web Part.
13. Set the Web Drawing URL property. Click Browse and navigate to the document library where you
published a Visio diagram. Select the published diagram and click OK.
14. Set the Automatic Refresh property to 1 minute (the minimum value supported). This enables the
dashboard to automatically refresh the diagram with new data from the management server every 1
minute.
15. Clear the Show Open in Visio option in the Toolbar and User Interface section.
16. Click OK to apply the changes.
You should now see the rendered Visio diagram in the browser.
17. Click Stop Editing to exit edit mode.
Your Web part should now display with the published diagram in the Visio Web Access Web part. Notice that the
Open in Visio button (normally available by default) is no longer available in the Web part toolbar.
2 minutes to read
With the Visio Add-in installed on the client and the data provider installed on the SharePoint server, you can now
publish diagrams that you have connected to Operations Manager data to a SharePoint document library to share
them with others in your organization.
To publish a diagram to a SharePoint document library
1. From the File tab on the Visio ribbon, click Save & Send.
2. Click Save to SharePoint.
3. Click Browse for a location to specify where to save the diagram.
4. Under File Types, choose Web Drawing (*.vdw).
If you do not choose this option, the drawing will not be visible through a browser, only the client.
5. Click Save As.
6. Specify the name and location for the file. To browse to a SharePoint server, type the name of the
SharePoint server in the address field and click Go To.
7. Click Save.
When the diagram is saved to a document library, you can simply browse to the document library in your browser
and click the link to the document. The Visio diagram will open in your browser. With the data provider installed,
the data will be refreshed directly from the management server.
NOTE
When viewing a published Visio diagram on SharePoint, when you select a linked shape it will open the Operations Manager
Web console and direct you to the homepage rather than Health Explorer. This is a known issue currently being investigated.
Change the way health state is represented in Visio
2 minutes to read
By default, health state is depicted by using the System Center - Operations Manager health icons (such as the
green check mark for a healthy state). You can customize the way that health state is shown by changing the data
graphic associated with the object in your Visio drawing. For example, you can show the health state by filling the
shape with red, yellow, green, or grey color to represent the three health states and to represent a managed object
in maintenance mode.
1. Open the drawing in Visio.
2. Select the shape or shapes that you want to change.
3. On the Data tab, click Data Graphics.
4. In the Data Graphics window, click the data graphic that you want to use. The Visio Add-in for System
Center - Operations Manager includes two choices. The SCOM IconSet data graphic shows health state
using icons as in Operations Manager. The SCOM Color by Value data graphic uses red, yellow, green, or
grey color to represent the three health states and to represent a managed object in maintenance mode.
Troubleshooting the Visio Add-in
3 minutes to read
The following sections provide information about troubleshooting the Visio Add-in:
Enabling trace logging on the data provider
Known issues
Enable trace logging for the server data module

Use the following steps to enable trace logging for the server data module installed on the SharePoint server.
1. Open the Microsoft.Office.Visio.Server.OperationsManager.dll configuration file in a text editor (such as
Notepad).
2. Change the location for log files. Look for the following:
<configuration>
<appSettings>
<add key="EnableLog" value="True" />
<add key="LogPath" value=\\server\directory" />
<appSettings>
</configuration>
For the LogPath parameter, change the value to the location where you want to save log files generated by
the data provider.
3. Copy the configuration file to the directory on the GAC where the data module assembly is located.
The next time a diagram is refreshed, the configuration file is checked and log files are written to the location you
specific.
Each refresh option is recorded in a separate log file. The name of the file reflects the user who attempted the
refresh and the date and time the refresh was attempted (for example, "jdoe_3_25_2010_12-23-37_PM.log"). The
log file contains the following:
The name of the user that requested the refresh
The date and time of the refresh
The version of the assembly installed on the server
The command string that was configured in the diagram before publishing to the server
Details about the dataset to be refreshed, including table count, row count, and IDs for each row
Any error conditions or exceptions that occur within the data module for each session
For successful refresh attempts, the log file also contains the XML version of the dataset returned to Visio Services
for diagram refresh purposes.
Known issues with the Visio Add-in

You might see the following issues when you use the Visio Add-in for System Center 2016 - Operations Manager.
The font size of inserted shapes might appear too small
When you insert a new graphic by using the Insert Shape option, the font size for the shape text might appear too
small. The size is determined by the default font size set for a template.
You can change the font size by selecting the shape and then choosing a different font size in the Visio toolbar.
Hyperlinks on sub-shapes are not available
Health Explorer and Alert View hyperlinks might not be available in Edit mode or Full Screen mode if you have
grouped your shapes or added links to any shapes that were already contained within groups.
You receive a ConfigurationErrorsException error message
You might see the following error message:
System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize --->

System.Configuration.ConfigurationErrorsException: Unrecognized configuration section userSettings.
(C:\Documents and Settings\asttest\Local Settings\Application Data\Microsoft_Corporation
\OpsMgrAddin.vsto_vstoloca_Path_logwdvddmizljsrbc2bvt5gtm5juzdix\12.0.6325.5000\user.config
line 3)
.
.
.
To work around this problem, delete the configuration file identified at the top of the error message. For example,
delete the following file:
\OpsMgrAddin.vsto_vstoloca_Path_logwdvddmizljsrbc2bvt5gtm5juzdix\12.0.6325.5000\user.config
You receive a MissingMethodException error message
You might see the following error message:
System.MissingMethodException: Method not found: 'System.Security.SecureString

System.Windows.Controls.PasswordBox.get_SecurePassword()'.
at Microsoft.EnterpriseManagement.VisioAddin.EnterCredentials.get_Password()
at
Microsoft.EnterpriseManagement.VisioAddin.SCOMHelpers.EnterCredentials(ManagementGroupConnectionSettings&
connectSettings)
at Microsoft.EnterpriseManagement.VisioAddin.Document.ConnectToManagementGroup()
at Microsoft.EnterpriseManagement.VisioAddin.Document.AddDataLinkToShape()
To resolve this problem, install Microsoft .NET Framework 3.5 SP1, available from
https://www.microsoft.com/download/details.aspx?id=22.
The state graphic is not displayed
The state graphic does not appear on a stencil even though you have linked the shape with the Link Shape to
Data option.
Some stencils in Visio are not defined with a wrapping group. To resolve this problem, create a group for the
shape, and then use the Link Shape to Data option again. To create a group, right-click the shape, and then click
Shape and Group.
You see security warnings when you open a diagram
When you open a document that you previously linked to Operations Manager, you receive multiple security
warnings.
This problem occurs because the status of the document components is set to refresh automatically. To suppress
the warnings, select Don't show this message again.
You cannot re -install the Visio Add-in
If you delete the Operations Manager Visio Add-in by using the Visio Trust Center, you cannot add it again later.
This behavior occurs by design in Visio. Before you can add the Operations Manager Visio Add-in again, uninstall
it by using Add/Remove Programs (or Programs and Features) in the Control Panel, and then reinstall it.
Configure authentication for the Reporting server
2 minutes to read
Follow these steps to configure the Operations Manager Reporting server component to use algorithms that are
compliant with Federal Information Processing Standards (FIPS ) compliant. Enabling FIPS compliance for System
Center - Operations Manager requires that the underlying infrastructure used (Server OS, Active Directory etc.),
also be FIPS -compliant.
Enable FIPS on the Reporting server

To enable FIPS on the reporting server, change the configuration in the application-level Web.config file to specify
that ASP.NET use the Triple Data Encryption Standard (3DES ) algorithm. To do this, follow these steps.
1. In a text editor such as Notepad, open the Web.config file in the ReportManager and ReportServer
subfolders under the SQL Server Reporting Services installation root folder
C:\Program Files\Microsoft SQL Server\<InstanceName>\Reporting Services .
2. In the Web.config file, locate the <system.web> section.

3. Add the following <machineKey> section to in the <system.web> section:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps"
validation="3DES" decryption="3DES"/>
.
4. Save the Web.config file.
5. Restart SQL Server Reporting Services service.
6. Confirm SQL Server Report Manager works successfully before proceeding with the installation of the
Operations Manager Report Server role.
Next steps
To configure SSL encryption and FIPS compliance for the Web console server, see Configure Authentication
with the Web console
Configure authentication with the Web console
3 minutes to read
Configure SSL encryption

The following steps are necessary to configure Secure Sockets Layer (SSL ) encryption after the Operations
Manager Web console server has been installed on an Internet Information Services (IIS ) 7.0 and higher web
server. Before performing these steps, you should first review Configuring Secure Sockets Layer in IIS 7 and
configure IIS to enable SSL for the web server hosting the Web console.
NOTE
When creating the certificate, you must provide the fully qualified domain name (FQDN) of the host and domain name in the
Common name field to match the address users would enter in their web browser to access the Web console.
1. Use a plain text editor to open the web.config in

<PATH>:\Program Files\Microsoft System Center 2016\Operations Manager\WebConsole\WebHost .
2. In the <services> root element, modify the following in the <!– Logon Service –> element:
<endpoint address=”” binding=”customBinding”

contract=”Microsoft.EnterpriseManagement.Presentation.Security.Services.ILogonService”
bindingConfiguration=”DefaultHttpsBinding”/>
3. In the <services> root element, modify the following in the <!– Data Access service –> element:
<endpoint address=”” binding=”customBinding”

contract=”Microsoft.EnterpriseManagement.Presentation.DataAccess.Server.IDataAccessService”
bindingConfiguration=”DefaultHttpsBinding”/>
4. Save and close the file when finished.

5. Click Start, click Run, type regedit, and then click OK.
6. Under HKEY_LOCAL_MACHINE\Software\Microsoft\System Center Operations
Manager\12\Setup\WebConsole\, double-click the value HTTP_GET_ENABLED and change its value
to false. Double-click the value BINDING_CONFIGURATION and change its value to
DefaultHttpsBinding.
7. After completing the above steps, reset the Web site hosting the Operations Manager Web console.
Configure FIPS compliance

Follow these steps for the Operations Manager Web console server component to use algorithms that are
compliant with Federal Information Processing Standards (FIPS ). Enabling FIPS compliance for System Center
2016 - Operations Manager requires that the underlying infrastructure used (Server OS, Active Directory, etc.),
also be FIPS compliant.
To install the cryptography DLL
1. On the system hosting the Web console, use the Run as Administrator option to open a Command Prompt
window.
2. Change directories to the SupportTools directory of your installation media, and then change directory to
AMD64.
3. Run the following gacutil command: gacutil.exe –i Microsoft.EnterpriseManagement.Cryptography.dll .
To edit the machine.config files
1. Use a plain text editor to open the machine.config file in
%WinDir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\.
2. If the following content does not exist within the <Configuration> root element, add as follows:
<mscorlib>
<cryptographySettings>
<cryptoNameMapping>
<cryptoClasses>
<cryptoClass
SHA256CSP="System.Security.Cryptography.SHA256CryptoServiceProvider, System.Core, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<cryptoClass HMACSHA256CSP
="Microsoft.EnterpriseManagement.Cryptography.HMACSHA256, Microsoft.EnterpriseManagement.Cryptography,
Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</cryptoClasses>
<nameEntry name="SHA256" class="SHA256CSP"/>
<nameEntry name="HMACSHA256" class="HMACSHA256CSP"/>
</cryptoNameMapping>
</cryptographySettings>
</mscorlib>
3. Save and close the file when finished.

Repeat the preceding step on the following files:
%WinDir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
%WinDir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
To edit the web.config file in WebHost folder
1. Use a plain text editor to open the web.config file in
<Path>:\Program Files\System Center 2016\Operations Manager\WebConsole\WebHost\web.config .
2. In the <encryption> element, add the following element if it does not exist:
<symmetricAlgorithm iv="SHA256"/>
3. In the <connection autoSignIn="true" autoSignOutInterval="30"> element, in the <session> tag, add the
following attribute if it does not exist: tokenAlgorithm="SHA256"
<connection autoSignIn="True" autoSignOutInterval="30">

<session encryptionKey="SessionEncryptionKey" tokenAlgorithm="SHA256">
4. Modify the following element by changing its value from true to false:
<serviceMetadata httpGetEnabled="false"/>
5. Modify the following two elements by changing their values from DefaultHttpBinding to
DefaultHttpsBinding:
<endpoint address="" binding="customBinding"
contract="Microsoft.EnterpriseManagement.Presentation.Security.Services.ILogonService"
bindingConfiguration="DefaultHttpsBinding"/>
<endpoint address="" binding="customBinding"
contract="Microsoft.EnterpriseManagement.Presentation.DataAccess.Server.IDataAccessService"
bindingConfiguration="DefaultHttpsBinding"/>
6. Save and close the file.

To edit the web.config file in MonitoringView folder
1. Use a plain text editor to open the web.config file in
<PATH>:\Program Files\System Center 2012\Operations Manager\WebConsole\MonitoringView\web.config .
2. In the <encryption>element, add the following element if it does not exist:
<symmetricAlgorithm iv="SHA256"/> .
3. In the <connection> element, In the <connection autoSignIn="true" autoSignOutInterval="30"> element, in

the <session> tag, add the following attribute if it does not exist: tokenAlgorithm="SHA256"
<connection autoSignIn="True" autoSignOutInterval="30">

<session encryptionKey="SessionEncryptionKey" tokenAlgorithm="SHA256">
4. In the <system.web> element, add the following element if it does not exist:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps"

validation="3DES" decryption="3DES"/>
5. Save and close the file.
Next steps
To configure FIPS compliance for the Reporting server, see Configure Authentication for Reporting server
Implementing User Roles
6 minutes to read
In System Center Operations Manager, user roles are the method you use to assign the rights needed to access
monitoring data and perform actions. User roles are designed to apply to groups of users that need access to and
perform actions on the same group of monitored objects. By default, only the Operations Manager Administrator
account has the right to view and act on all monitoring data. All other users must have a user role assigned in
order to view or act on specific or all monitoring data.
User roles are created using the Create User Role Wizard. In this wizard, you configure which Active Directory
security groups are assigned this user role, which Operations Manager group or groups of monitored objects this
user can access, and which tasks. dashboards and views this user role can access.
A user role is the combination of a profile and scope as shown in as shown in the following illustration. A user can
be a part of multiple roles and the resultant scope is the union of all the user roles.
Understand profiles
Before you create user roles in your management group, select one profile that applies to the user role you are
creating. A profile determines the actions that a user can perform. Profiles have a defined set of rights and you
cannot add or remove any of these assigned rights. When creating user roles for operators and other users, select
the profile that most closely matches the responsibilities of the group of users in your System Center - Operations
Manager deployment.
Because Operations Manager is an enterprise monitoring platform which can monitor infrastructure, workload, or
applications deployed in your enterprise, you may want to align access to monitor data with your service
operation processes, so that the different incident escalation support tiers or the application developer team will
be able to see the operational data relevant to their role. Role-based security allows you to limit privileges that
users have for various aspects of Operations Manager.
IMPORTANT
Adding a machine account to a user role member allows all services on that computer to have access in Operations
Manager. It is recommended that you do not add a machine account to any user role.
In Operations Manager, operations-such as resolving alerts, running tasks, overriding monitors, creating user
roles, viewing alerts, viewing events, and so on-have been grouped into profiles, with each profile representing a
particular job function as shown in the following table. For a list of specific operations associated with each profile,
see Operations Associated with User Role Profiles.
NOTE
A scope defines the entity groups, object types, tasks, or views that a profile is restricted to. Not all scopes apply to all
profiles.
PROFILE JOB FUNCTIONS AND SCOPE
Administrator Includes full privileges available in Operations Manager. Note:

You can only add Active Directory security groups to the
Administrator role.
Advanced Operator Includes a set of privileges designed for users who need
access to limited adjustment of monitoring configurations in
addition to the Operator privileges. Grants members the
ability to override the configuration of rules and monitors for
specific targets or groups of targets within the configured
scope. Advanced Operator also inherits Operator privileges.
Application Monitoring Operator Includes a set of privileges designed for users that need access
to Application Diagnostics. A user role based on the
Application Monitoring Operator profile grants members the
ability to see the Application Monitoring events in
Application Diagnostics web console. Note: Access to the
Application Advisor feature requires the Report Operator or
Administrator profile.
Author Includes a set of privileges designed for authoring of

monitoring configurations. Grants members the ability to
create, edit, and delete monitoring configuration (for example,
tasks, rules, monitors, and views) for specific targets or groups
of targets within the configured scope.
PROFILE JOB FUNCTIONS AND SCOPE
Operator Includes a set of privileges designed for users who need

access to alerts, views, and tasks. Grants members the ability
to interact with alerts, run tasks, and access views according
to their configured scope. Security Note: When a dashboard
view uses data from the data warehouse database, operators
might be able to view data that they would not otherwise
have access to in views that use data from the operational
database.
Read-only Operator Includes a set of privileges designed for users who need read-
only access to alerts and views. Grants members the ability to
view alerts and access views according to their configured
scope. Note: Members of the Read-only Operator role are
not assigned rights to the Task Status view. Security Note:
When a dashboard view uses data from the data warehouse
database, operators might be able to view data that they
would not otherwise have access to in views that use data
from the operational database.
Report Operator Includes a set of privileges designed for users who need
access to Reports. Grants members the ability to view reports
according to their configured scope. Caution: Users assigned
to this role have access to all report data in the Reporting
Data Warehouse and are not limited by scope.
Report Security Administrator Enables the integration of SQL Server Reporting Services
security with Operations Manager user roles. This gives
Operations Manager Administrators the ability to control
access to reports. This role can have only one member
account and cannot be scoped.
Define a scope using Operations Manager groups

The scope of a user role determines which objects that user role can view and perform actions on in System
Center – Operations Manager. A scope is comprised of one or more Operations Manager groups and is defined
when creating a user role as part of the Create User Role Wizard. The Group Scope page of the Create User
Role Wizard provides a list of all existing Operations Manager groups. You can choose all or some of these
groups as the scope of the user role you are creating.
Groups, like other Operations Manager objects, are defined in management packs. In Operations Manager,
groups are logical collections of objects, such as Windows-based computers, hard disks, or instances of Microsoft
SQL Server. Several groups are created by the management packs that are imported automatically during an
Operations Manager installation. If these groups do not contain the monitored objects you need for a scope, you
can create a group that does. To do this, you must exit the Create User Role Wizard, switch to the Monitoring
workspace and use the Create Group Wizard to create a group that better suits your needs.
Assign tasks, dashboards and views

A task is a user-initiated action from the Operations console that is run on an Operations Manager agent or on the
system the console is launched from. Tasks that you grant to a user role you are creating can perform those
specific commands or actions for the user role you are creating. The default setting is that all users assigned that
user role can run all tasks and open all dashboard and views as long as their profile and scope allows it. The
alternative in the Create User Role wizard Tasks page is to list the specific tasks the user rule you are creating
can access. Similarly on the Create User Role Dashbaords and Views page is to specify dashboards and views,
as well as what specific dashboards that are available for access from the Tasks pane, can be accessed.
How to assign members to built-in user roles
Operations Manager provides eight standard user roles that are created during setup. You can assign groups and
individuals directly to these built-in user roles to provide them with the ability to perform certain tasks and to
access certain information. These built-in roles have global scope for the management group.
To limit the scope for a user, create a new user role.
To assign members to a built-in user role
2. In Security, click User Roles.
3. In the results pane, right-click any of the user roles, such as Operations Manager Operators, and click
Properties.
4. On the General Properties tab, in User role members, click Add.
5. In Enter the object names to select, type in name of the user or group account that you want to add to
the user role, and then click OK to close the dialog box.
6. Click OK to close the properties for the user role.
Operations associated with user role profiles
5 minutes to read
This topic provides a list of the operations in System Center Operations Manager that are associated with each
profile.
Report Operator
The Report Operator profile includes a set of privileges designed for users who need access to reports. A role
based on the Report Operator profile grants members the ability to view reports according to their configured
scope.
Retrieve the instance of the data warehouse for the management group
Write to favorite reports
Delete favorite reports
Read favorite reports
Update favorite reports
Read reports
Run reports
Access Application Advisor
Read-Only Operator
The Read-Only Operator profile includes a set of privileges designed for users who need read-only access to alerts
and views. A role based on the Read-Only Operators profile grants members the ability to view alerts and access
views according to their configured scope.
Read alerts
Retrieve the instance of the data warehouse for the management group
Read state of a resolution
Read instance of a connector
Read console tasks
Enumerate diagnostic objects
Enumerate the results of diagnostics
Enumerate discovery objects as defined in a management pack
Read discovery rules
Read events
Write to favorite console tasks
Delete favorite console tasks
Enumerate favorite console tasks
Update favorite console tasks
Write favorite views
Delete favorite views
Enumerate favorite views
Update favorite views
Enumerate monitoring objects
Enumerate monitoring classes
Enumerate monitoring relationship classes
Enumerate management packs
Enumerate monitor types
Enumerate module types
Enumerate monitors
Enumerate overrides
Enumerate performance data
Enumerate discovery objects as defined in a management pack
Enumerate the status of past recoveries
Enumerate relationship between monitored objects
Enumerate rules
Enumerate saved searches
Update saved searches
Write to saved searches
Delete saved searches
Enumerate state
Allows access to connected management groups
Enumerate views
Enumerate view types
Review application monitoring alerts 1
1 Permissions scope can be fine-tuned for the role.
Operator
The Operator profile includes a set of privileges designed for users who need access to alerts, views, and tasks. A
role based on the Operators profile grants members the ability to interact with alerts, run tasks, and access views
according to their configured scope. The Operator profile contains all of the privileges found in the Read-Only
Operator profile in addition to those listed below.
Update alerts
Run diagnostics
Create favorite tasks
Delete favorite tasks
Enumerate favorite tasks
Update favorite tasks
Run recovery routines
Update maintenance mode settings
Enumerate notification actions
Delete notification actions
Update notification actions
Enumerate notification endpoints
Enumerate notification recipients
Delete notification recipients
Update notification recipients
Enumerate notification subscriptions
Delete notification subscriptions
Update notification subscriptions
Enumerate tasks
Enumerate task status
Run tasks
Run monitoring compatibility check task1
NOTE
Additional permissions are required for files/folders to create report files.
Review application monitoring alerts

Close application monitoring alerts 1
Advanced Operator
The Advanced Operator profile includes a set of privileges designed for users who need access to limited tweaking
of monitoring configurations in addition to the Operators privileges. A role based on the Advanced Operators
profile grants members the ability to override the configuration of rules and monitors for specific targets or groups
of targets within the configured scope. The Advanced Operator profile contains all of the privileges found in the
Operator and Read-Only Operator profiles in addition to those listed below.
Update management packs
Enumerate templates
Customize APM configuration with the overrides1
NOTE

Application Monitoring Operator

The Application Monitoring Operator profile includes a set of privileges designed for users that need access to
Application Diagnostics. A user role based on the Application Monitoring Operator profile grants members the
ability to see the Application Monitoring events in Application Diagnostics web console.
Access Application Diagnostics
Author
The Author profile includes a set of privileges designed for authoring monitoring configurations. A role based on
the Authors profile grants members the ability to create, edit, and delete monitoring configuration (tasks, rules,
monitors, and views) within the configured scope. For convenience, Authors can also be configured to have
Advanced Operator privileges scoped by group. The Author profile contains all of the privileges found in the
Advanced Operator, Operator, and Read-Only Operator profiles in addition to those listed below.
Create management packs
Delete management packs
Enumerate Run As Profiles
Customize APM configuration with the overrides1
Author new APM workflows1
NOTE

Administrator
The Administrator profile includes full privileges to Operations Manager. No scoping of the Administrator profile
is supported. The Administrator profile contains all of the privileges found in the Author, Advanced Operator,
Operator, and Read-Only Operator profiles in addition to those listed below.
Create a resolution state
Delete a resolution state
Update a resolution state
Deploy an agent
Repair or update an installed agent
Uninstall an agent
Enumerate agent settings
Update agent settings
Enumerate agents
Start or stop managing computers or devices via a proxy health service
Enumerate computers or devices managed via a proxy health service
Insert a new instance of a computer or device
Delete an instance of a computer or device
Run discovery task
Create events
Enumerate global settings
Update global settings
Export management packs
Enumerate management servers
Delete notification endpoint
Update notification endpoint
Create performance data
Create Run As Accounts
Delete Run As Accounts
Enumerate Run As Accounts
Update Run As Accounts
Create mappings between Run As Accounts and Run As Profiles
Delete mappings between Run As Accounts and Run As Profiles
Enumerate mappings between Run As Accounts and Run As Profiles
Update mappings between Run As Accounts and Run As Profiles
Create connected management groups
Delete connected management groups
Enumerate user roles
Delete user roles
Update user roles
Write favorite reports
Delete favorite reports
Read favorite reports
Update favorite reports
Read reports
Run reports
Run APM Wizard or change APM settings
Access Application Diagnostics
Author new APM workflows
Customize APM configuration with the overrides
Run monitoring compatibility check task
Review application monitoring alerts
Close application monitoring alerts
Control access rights to application monitoring
Create group
Edit group
Delete group
Report Security Administrator

The Report Security Administrator profile includes a set of privileges designed to enable the integration of SQL
Server Reporting Services security with Operations Manager.
Export management packs
Enumerate classes as defined in the management packs
Enumerate management packs
Run reports
Enumerate rules
Next steps
Review Implementing User Roles to understand the profiles defined in Operations Manager to manage
authorization and security, and configure user roles to perform administration and access to operational data in
the management group.
How to create a new action account in Operations
Manager
2 minutes to read
Use the following procedure to create a new management server action account. The new action account will not,
by default, have access to Operations Manager database unless access is inherited in the credentials you assign to
the action account. If not, a new account for accessing the Operations Manager database will need to be created.
To create a new action account

3. In the Administration workspace, right-click Run As Accounts, and then click Create Run As Account.
4. In the Create Run As Account Wizard, on the Introduction page, click Next.
5. On the General page, do the following:
a. In the RunAsAccounttype list, select Action Account.
b. Type a display name in the Display Name text box.
NOTE
The display name you enter here becomes the Run As account you will add to a new Run As profile in the
following steps.
c. You can also type a description in the Description text box.

d. Click Next.
6. On the Account page, type a user name, password, and then select the domain for the account that you
want to make a member of this Run As account, and then click Next.
7. On the Distribution Security page, the More secure option is selected and cannot be changed. Click
Create.
8. In the Administration workspace, click Run As Profiles.
9. In Run As Profiles, right-click Default Action Account, and then click Properties.
10. On the Introduction and General Properties pages, click Next.
11. On the Run As Accounts page, click Add, select the Run As account you created, and then click OK twice.
12. Click Save.
Next steps
To understand how to create a Run As account and associate with a Run As profile, see How to Create a
Run As Account and Associate with a Run As Profile.
The Report Server unattended execution account is used to query data from the Reporting Data Warehouse.
See How to Manage the Report Server Unattended Execution Account in Operations Manager to
understand how to reconfigure the user name or password for this account.
To learn about how you can use the The Health Service lockdown tool to limit the identities used to run a
rule, task, or monitor on agent-managed systems, see Control Access by Using the Health Service
Lockdown Tool in Operations Manager.
Control access by using the Health Service Lockdown
Tool in Operations Manager
2 minutes to read
On computers requiring high security, for example a domain controller, you may need to deny certain identities
access to rules, tasks, and monitors that might jeopardize the security of your server. The Health Service lockdown
tool (HSLockdown.exe) enables you to use various command-line options to control and limit the identities used to
run a rule, task, or monitor.
NOTE
You will be unable to start the Microsoft Monitoring Agent service if you have used the Health Service Lockdown tool to lock
out the Action Account. To be able to restart the Microsoft Monitoring Agent service, follow the second procedure in this
topic to unlock the Action Account.
The following command-line options are available:

HSLockdown [ManagementGroupName] /L - List Accounts/groups
HSLockdown [ManagementGroupName] /A - Add an allowed account|group
HSLockdown [ManagementGroupName] /D - Add a denied account|group
HSLockdown [ManagementGroupName] /R - Remove an allowed/denied account|group
Accounts must be specified in one of the following fully qualified domain name (FQDN ) formats:
NetBios : DOMAIN\username
UPN : username@fqdn.com
If you used the add or deny options when running the Health Service Lockdown tool, you will need to restart the
System Center Management service before the changes take effect.
When evaluating allowed and denied listings, know that denies takes priority over allows. If a user is listed as
allowed, and the same user is a member of a group that is listed as denied, the user will be denied.
To use the health service lockdown tool

3. In the Run dialog box, type cmd and then click OK.
4. At the command prompt, type <drive_letter>: (where <drive_letter> is the drive where the Operations
Manager agent is installed) and then press ENTER.
5. Type cd\Program Files\Microsoft Monitoring Agent\Agent and then press ENTER.
6. Type HSLockdown [Management Group Name] /D [account or group] to deny the group or account,
and then press ENTER.
To unlock the Action account
3. In the Run dialog box, type cmd and then click OK.
4. At the command prompt, type <drive_letter>: (where <drive_letter> is the drive where the Operations
Manager agent is installed) and then press ENTER.
5. Type cd\Program Files\Microsoft Monitoring Agent\Agent and then press ENTER.
6. Type HSLockdown [Management Group Name] /A <Action Account> and then press ENTER.
Next steps
To understand how to create a Run As account and associate with a Run As profile, see How to Create a
Run As Account and Associate with a Run As Profile.
If you need to create new credentials for the management server action account, see How to Create a New
Action Account in Operations Manager.
Review Distribution and Targeting for Run As Accounts and Profiles to understand how to target Run As
account distribution to agent-managed computers securely.
Managing Run As accounts and profiles
2 minutes to read
System Center Operations Manager workflows, such as rules, tasks, monitors, and discoveries, require credentials
to run on a targeted agent or computer. By default, workflows use the default action account for the agent or
computer. The credentials for the default action account are configured when Operations Manager is installed.
When a workflow requires rights and privileges that the default action account cannot provide, the workflow can
be written to use a Run As profile. A Run As profile can have multiple Run As accounts associated with it. The Run
As accounts allow you to specify the necessary credentials for specific computers. Multiple workflows can use the
same Run As profile. The following image illustrates the relationship between workflows, Run As profiles, and Run
As accounts.
In the image, three workflows use the same Run As profile. The Run As profile has three associated Run As
accounts. In this example, each workflow that uses the Run As profile will run on Computer A using the credentials
for Run As account 1, on Computer B and C using the credentials for Run As account 2, and on Computer D using
the credentials for Run As account 3.
Run As profiles are defined in management packs by the management pack author. A Run As profile is used
wherever its parent management pack is active. For example, the SQL Server 2014 management pack contains the
SQL Run As profile, so the SQL Run As profile would be active on all servers running SQL Server 2014 that are
monitored by the SQL Server 2014 management pack. The Run As profile is an association of one or more Run
As accounts and the managed objects that the Run As accounts should be applied to.
In some cases, the Run As profile is imported into Operations Manager when the management pack that contains
it is imported. In other cases, you may need to create it manually. In all cases, Run As profiles must be manually
associated with a Run As account.
A Run As account contains a single set of credentials which are stored in the Operations Manager operational
database. Each Run As account has a security classification (more secure or less secure) that controls how the
credentials are distributed for use. If you elect more secure credential distribution, you must configure the
mapping of which computers the credentials are distributed to.
Next steps
Distribution and Targeting for Run As Accounts and Profiles
This topic explains the difference between distribution and targeting, the options for distributing Run As
accounts, and the options for selecting targets for Run As profiles.
How to Create a Run As Account and Associate with a Run As Profile
This topic explains how to create a Run As account, how to modify an existing Run As account, and how to
configure a Run As profile to use a Run As account.
How to Create a New Action Account
This topic explains how to create a new Run As action account that will be used by management servers in
the management group.
Distribution and targeting for Run As accounts and
profiles
3 minutes to read
Run As accounts are associated with Run As profiles to provide the necessary credentials for workflows that use
that Run As profile to run successfully. Both distribution and targeting of Run As accounts must be correctly
configured for the Run As profile to work properly.
When you configure a Run As profile, you select the Run As accounts you want to associate with the Run As
profile. When you create that association, you specify the class, group, or object that the Run As account will be
used to manage, as shown in the following image. This establishes the target of the Run As account.
Distribution is an attribute of a Run As account in which you specify which computers will receive the Run As
account credentials. You can choose to distribute the Run As account credentials to every agent-managed
computer or only to selected computers.
Example of Run As account targeting and distribution:
Physical computer ABC hosts two instances of Microsoft SQL Server, instance X and instance Y. Each instance
uses a different set of credentials for the sa account. You create a Run As account with the sa credentials for
instance X, and a different Run As account with the sa credentials for instance Y. When you configure the SQL
Server Run As profile, you associate both Run As account credentials for instance X and Y with the profile and
specify that the Run As account instance X credentials are to be used for SQL Server instance X and that the Run
As account Y credentials are to be used for SQL Server instance Y. Then, you configure both Run As accounts to
be distributed to physical computer ABC.
Selecting a target for a Run As account

As shown in the previous image, your options for selecting a target for a Run As account are All targeted
objects and A selected class, group, or object.
When you select All targeted objects, the Run As profile will use this Run As account for all objects for the
workflows that use the Run As profile.
When you select A selected class, group, or object, you can limit the use of the Run As account to the class,
group, or object that you specify.
NOTE
The Run As account credentials must be distributed the specific agent-managed systems the Run As credential should be
authenticating with before configuring the Run As profile.
Comparing more secure and less secure distribution

Operations Manager distributes the Run As account credentials to either all agent-managed computers (the less
secure option) or only to computers that you specify (the more secure option). If Operations Manager
automatically distributed the Runs As account according to discovery a security risk would be introduced into
your environment as illustrated in the following example. This is why an automatic distribution option was not
included in Operations Manager.
For example, Operations Manager identifies a computer as hosting SQL Server 2014 based on the presence of a
registry key. It is possible to create that same registry key on a computer that is not actually running an instance
of SQL Server 2014. If Operations Manager were to automatically distribute the credentials to all agent managed
computers that have been identified as SQL Server 2014 computers, then the credentials would be sent to the
imposter SQL Server and they would be available to someone with administrator rights on that server.
When you create a Run As account, you are prompted to choose whether the Run As account should be treated in
a Less secure or More secure fashion. More secure means that when you associate the Run As account with a
Run As Profile, you have to provide the specific computer names that you want the Run As credentials distributed
to. By positively identifying the destination computers, you can prevent the spoofing scenario that was described
before. If you choose the less secure option, you will not have to provide any specific computers and the
credentials will be distributed to all agent-managed computers.
NOTE
Operations Manager will perform tests to validate the Run As credentials, including whether the credentials can be used to
log on locally to the computer. If the account does not have the right to log on locally, an alert will be generated.
Next steps
To understand how to create a Run As account, how to modify an existing Run As account, and how to
configure a Run As profile to use a Run As account see, How to Create a Run As Account and Associate with a
Run As Profile.
How to create a Run As account and associate with a
Run As profile
5 minutes to read
This procedure describes how you create a Run As Account by using a set of Windows credentials as an example.
Then it shows you how to edit the properties of the Run As Account to modify the security level and distribution
of the credentials. You use this same procedure for all other account types. Once you are completed creating the
Run As account, you will associate it with a Run As Profile.
The credentials that you provide in a Run As Account are used to run tasks, rules, monitors and discoveries as
defined by the management pack that they are in. The management pack guide has the settings that you need for
configuring the Run As Account and the Run As Profile. When you create a Run As Account you are warned that
you must associate the Run As Account with a Run As profile, and you are not presented with the option to
configure Run As Account credential distribution. Both of these activities can be accomplished in the Run As
Profile wizard. Alternately, you can configure Run As Account credential distribution by editing the properties of
the Run As Account as shown below.
Both distribution and targeting of Run As accounts must be correctly configured for the Run As profile to work
properly.
Create a Run As account

3. In the Administration workspace, right-click Accounts, and then click Create Run As Account.
4. In the Create Run As Account Wizard, on the Introduction page click Next.
5. On the General Properties page, do the following:
a. Select Windows in the Run As Account type: list.
b. Type a display name in the Display Name text box.
c. Optionally, type a description in the Description box.
d. Click Next.
6. On the Credentials page, type a user name, and its password, and then select the domain for the account
that you want to make a member of this Run As account.
7. Click Next.
8. On the Distribution Security page, select the Less secure or More secure option as appropriate. For
more information, see Distribution and Targeting for Run As Accounts and Profiles.
9. Click Create.
10. On the Run As Account Creation Progress page, click Close.
Modify Run As account properties

2. In the Administration workspace, click Accounts.
3. In the results pane, double-click the Run As account that you want to edit to open its properties.
4. On the Run As Account Properties page, you can edit values on the General Properties, Credentials,
or the Distribution tabs. In this case, select the Distribution tab.
5. On the Distribution tab, in the Selected computers: area, click Add to open the Computer Search tool.
6. On the Computer Search page, click the Option: list and select one of the following options:
a. Search by computer name (Default), then type in the computer name in the Filter by: (Optional)
box.
b. Show suggested computers, if you have already associated the Run As Account object with a Run As
profile, a list of discovered computers that host the monitored service are presented here.
c. Show management servers, in some cases, for example cross platform monitoring, all monitoring is
performed by a management server and therefore the credentials have be distributed to the management
servers that is performing the monitoring.
7. Optionally, type in a value in the Filter by: (Optional) box to narrow the search result set and click
Search. A list of computers that match the search criteria is displayed in the Available items box.
8. Select the computers that you want to distribute the credentials to, and click Add. The computers appear in
the Selected Items box.
9. Click OK. This returns you to the Distribution tab and the computers are displayed.
10. Click OK.
Associate a Run As account to a Run As profile

This procedure can be used for creating and configuring a new Run As profile, or you can use the configuring
section to modify or configure Run As profiles that are pre-existing in your management group. This procedure
assumes that you have not previously created a Run As account.
3. In the Administration workspace, click Profiles.
4. In the results pane, double-click the Run As profile that you want to configure. The Run As Profile
Wizard opens.
5. In the left pane, click Run As Accounts.
6. On the Run As Accounts page, click Add.
7. In the Add a Run As Account window, in the Run As account field, select an existing Run As account
from the dropdown menu. You can also create an account by clicking New and following Create a Run As
Account steps above.
8. Select All targeted objects or A selected class, group, or object. If you select A selected class, group,
or object, click Select, and then locate and select the class, group, or object that you want the Run As
account to be used for. For more information, see Distribution and Targeting for Run As Accounts and
Profiles.
9. Click OK to close the Add a Run As Account window.
10. On the Run As Accounts page, click Save.
11. On the Run As Profile Wizard Completion page, if every account you associated is configured for Less
Secure distribution, click Close. If you associated a Run As account that is configured for More Secure
distribution, you will see the Run As account listed as a link. Click the link to configure credential
distribution, using the following procedure.
Configure distribution of a Run As account
1. Open the properties for the Run As account using one of the following methods:
On the Run As Profile Wizard Completion page, click the account link.
In the Operations console, in the Administration workspace, under Run As Configuration, click
Accounts, and then in the results pane, double-click the account you want to configure.
2. On the Distribution tab, click Add for the Selected computers box and do the following:
a. Select Search by computer name (Default) or Show suggested computers, or Show
management servers.
b. Optionally type in a value in the Filter by: (Optional) box.
c. Click Search. The result set is returned in the Available items box.
d. Select the computers you want from the result set, and click Add. This adds the selected computers to
the Selected objects box.
e. Click OK.
3. Click OK.
Next steps
Review Distribution and Targeting for Run As Accounts and Profiles to understand how to target Run As
account distribution to agent-managed computers securely.
If you need to create new credentials for the management server action account, see How to Create a New
Action Account in Operations Manager.
To learn about how you can use the The Health Service lockdown tool to limit the identities used to run a
rule, task, or monitor on agent-managed systems, see Control Access by Using the Health Service
Lockdown Tool in Operations Manager.
How to configure Run As accounts and profiles for
UNIX and Linux access
3 minutes to read
If you are the system administrator in charge of the monitoring of UNIX and Linux computers, you must create
Run As accounts for agent maintenance operations, and for health and performance monitoring. These Run As
accounts must then be associated with the Run As profiles defined in the UNIX and Linux management packs, so
they can access the agents on UNIX and Linux computers. For an overview of the process, see Planning Security
Credentials for Accessing UNIX and Linux Computers.
Configuring Run As accounts

The UNIX/Linux Run As Accounts Wizard creates Run As accounts that can be of two Run As account types:
A monitoring account
An agent maintenance account.
Use this wizard three or more times as needed so that you have the following Run As accounts:
A monitoring Run As account for unprivileged monitoring.
A monitoring Run As account for privileged monitoring.
An agent maintenance Run As account for upgrading, uninstalling, and other agent maintenance
operations.
To run this wizard, you must have the following credentials information:
Username and password for unprivileged access to the UNIX or Linux computer.
Secure Shell (SSH) credentials for root-level privileged access to the UNIX or Linux computer. This can be
either a username and password, or a username and a key. A passphrase can be optionally provided with a
key. If you prefer not to provide credentials for a privileged account, you can use unprivileged credentials
and have the credentials on the UNIX or Linux computer elevated.
Username and password for privileged access to the UNIX or Linux computer. If you prefer not to provide
credentials for a privileged account, you can use unprivileged credentials and have the credentials on the
UNIX or Linux computer elevated.
You can choose between su or sudo elevation. If the account is to be elevated using 'su', you will need the
'su' password.
To create a Run As account
2. In Run As Configuration, click UNIX/Linux Accounts.
3. In the Tasks pane, click Create Run As Account.
4. On the Account Type page, choose a Monitoring Account or an Agent Maintenance Account.
5. On the General Properties page, provide a name and description for the account. The description is
optional.
6. On the Account Credentials page, provide account credentials that can be used for the Run As account
type that you selected.
7. On the Distribution Security page, select the More Secure or Less Secure option.
8. Click Create.
Repeat as needed until all the needed Run As accounts are created.
Configuring Run As profiles

Now that you have created the Run As accounts, you must add each Run As account to the applicable profile.
There are three profiles to configure:
UNIX/Linux Action Account
Add a monitoring Run As account that has unprivileged credentials, to this profile.
UNIX/Linux Privileged Account
Add a monitoring Run As account that has privileged credentials or credentials to be elevated, to this
profile.
UNIX/Linux Agent Maintenance Account
Add a monitoring Run As account that has privileged credentials or credentials to be elevated, to this
profile.
NOTE
There is no need to run the Create Run As Profile Wizard unless you have authored a new management pack that
requires it.
To add a Run As account to a profile

2. In Run As Configuration, click Profiles.
3. In the list of profiles, right click and then select Properties on one of the following profiles:
UNIX/Linux Action Account
UNIX/Linux Privileged Account
UNIX/Linux Agent Maintenance Account
4. In the Run As Profile wizard, click Next until you get to the Run As Accounts page.
5. On the Run As Accounts page, click Add to add a Run As account that you created. Select the class, group,
or object that will be accessed using the credentials in the Run As account.
6. Click Save.
Repeat as needed until all three profiles have been configured with one or more Run As accounts.
Accessing UNIX and Linux computers in Operations
Manager
2 minutes to read
In System Center - Operations Manager, the management server uses two protocols to communicate with the
Secure Shell (SSH)
Used for installing, upgrading, and removing agents.
actions, such as agent maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined profiles
according to their requirement for an unprivileged or privileged account.
NOTE
All credentials referred to in this topic pertain to accounts that have been established on the UNIX or Linux computer, not to
the Operations Manager accounts that are configured during the installation of Operations Manager. Contact your system
administrator for credentials and authentication information.
For detailed instructions for specifying credentials and configuring accounts, see How to Set Credentials for
Accessing UNIX and Linux Computers.
Authentication on the UNIX or Linux computer

In Operations Manager, the system administrator is no longer is required to provide the root password of the
UNIX or Linux computer to the management server. Now by elevation, an unprivileged account can assume the
identity of a privileged account on the UNIX or Linux computer. The elevation process is performed by the UNIX su
(superuser) and sudo programs that use the credentials that the management server supplies. For privileged agent
maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstall, and agent recovery),
support for su, sudo elevation, and support for SSH key authentication (with or without passphrase) is provided.
For privileged WS -Management operations (such as viewing secure log file), support for sudo elevation (without
password) is added.
Accessing UNIX and Linux computers topics

Planning Security Credentials for Accessing UNIX and Linux Computers
Provides an overview of using credentials to install and maintain agents on UNIX and Linux computers and
how they are configured to use Run As accounts and Run As profiles.
How to Set Credentials for Accessing UNIX and Linux Computers
Contains specific procedures for specifying credentials for different wizards in Operations Manager.
How to Configure sudo Elevation and SSH Keys
Describes how to configure an unprivileged account to be elevated to have privileged access on a UNIX or
Linux computer.
Required Capabilities for UNIX and Linux Accounts
Describes the permissions on the UNIX or Linux computers that are required to be configured with Run As
profiles for use by Operations Manager.
Administering and Configuring the UNIX - Linux Agent
Describes options to administer and configure the UNIX/Linux agent for System Center 2016 - Operations
Manager.
How to set credentials for Accessing UNIX and Linux
computers
10 minutes to read
This topic contains procedures for how to set credentials in wizards for the following tasks, as set by wizards in
System Center - Operations Manager:
Credentials for Installing Agents
Credentials for Run As Accounts
Credentials for Upgrading an Agent
Credentials for Uninstalling an Agent
These wizards define credentials to be authenticated on the UNIX or Linux computer and follow a similar
process. For an overview of how credentials are provided, see Planning Security Credentials for Accessing Unix
and Linux Computers.
Credentials for discovering UNIX and Linux computers

The following procedure begins in Computer and Device Management Wizard, on the Discovery Criteria
page, when you click the Set Credentials button. For more information, see Install Agent on UNIX and Linux
Using the Discovery Wizard.
To set a user (unprivileged) account for discovery of an installed agent with a signed certificate.
1. On the Credential Settingspage, click the Default Credentials tab, and then click the Password option.
2. Type a user name, a password, and the password confirmation.
3. In the Does this account have privileged access list, click This account does not have privileged
access, and then click OK.
4. Click OK to return to the Discovery Criteria page and continue with the wizard.
Credentials for installing agents or signing certificates of installed

agents
The following procedures begin in the Computer and Device Management Wizard, on the Discovery
Criteria page, when you click the Set Credentials button.
To set a privileged credential by using an SSH key
1. On the Credential Settingspage, click the Default Credentials tab, and then click the SSH key option.
2. Type a user name, the path, and name of the key, or click Browse.
3. Enter a passphrase if the key requires it.
4. In the Does this account have privileged access list, click This account has privileged access, and
then click OK.
5. Click the Agent Verification tab, and on the Agent Verification page, type a user name and password
for an account on the targeted computer. This can be a user (unprivileged) account.
To set a unprivileged credential with elevation by using an SSH key
1. On the Credential Settingspage, click the Default Credentials tab, and then click the SSH key option.
5. Click the Elevation page, and select su or sudo elevation.
If you select su elevation, type the superuser password as established on the UNIX or Linux computer.
The su password is also used for agent verification.
If you selected sudo elevation, click the Agent Verification tab, and type a user name and password for
an account on the targeted computer. This can be a user (unprivileged) account.
To set a privileged credential by using a password
1. On the Credential Settings page, click the Default Credentials tab, and then click the Password option.
2. Type a user name, a password, and password confirmation.
This password is used for agent verification.
3. In the Does this account have privileged access list, click This account has privileged access.
To set an unprivileged credential with elevation by using a password
1. On the Credential Settings page, click the Default Credentials tab, and then click the Password option.
3. In the Does this account have privileged access list, click This account does not privileged access,
and then click OK.
If you select su elevation, type the superuser password you established on the UNIX or Linux computer.
Credentials for Run As accounts

The following procedures begin in the Create UNIX/Linux Run As Account Wizard when you select the type
for a Run As Account (Monitoring Account or Agent Maintenance Account), a name and password and
provided a description. For more information, see How to Configure Run As Accounts and Profiles for UNIX and
Linux Access.
To set a privileged credential for a monitoring account
1. On the Account Credentials page, type a user name, a password, and the password confirmation.
2. In the Do you want to use elevation for privileged access list, click Do not use elevation with this
account.
3. Click Next to continue with the wizard.
To set an unprivileged credential with elevation for a monitoring account
1. On the Account Credentials page, type a user name, a password, and the password confirmation.
2. In the Do you want to use elevation for privileged access list, click Elevate this account using sudo
for privileged access.
To set a privileged credential by using an SSH key for an agent maintenance account
1. On the Account Credentials page, click the SSH key option.
4. In the Does the account have privileged access list, click This account has privileged access.
To set an unprivileged credential by using an SSH key with elevation for an agent maintenance account
1. On the Account Credentials page, click the SSH key option.
access, and then click Next.
5. Select the Elevation tab, and select su or sudo elevation.
To set a privileged credential by using a password for an agent maintenance account
1. On the Account Credentials page, click the Password option.
3. In the Does this account have privileged access list, click This account has privileged access.
To set a privileged credential by using a password with elevation for an agent maintenance account
1. On the Account Credentials page, click the Password option.
access, and then click Next.
4. Click the Elevation tab, and select su or sudo elevation.
Credentials for upgrading an agent

The following procedures begin in the UNIX/Linux Agent Upgrade Wizard on the Credentials page, when
you select Provide Upgrade Credentials. For more information, see Upgrading and Uninstalling Agents on
UNIX and Linux Computers.
1. On the Credential Settings page, click the SSH key option.
then click OK.
5. On the Agent Verification page, type a user name and password for an account on the targeted
computer. This can be a user (unprivileged) account.
6. Click OK to return to the Credentials page and continue with the wizard.
If you select su elevation, type the superuser password as established on the UNIX or Linux computer,
and then click OK. The su password is also used for agent verification.
If you select sudo elevation, click Agent Verification. On the Agent Verification page, type a user
name and password for an account on the targeted computer. This can be a user (unprivileged) account.
1. On the Credential Settings page, click the Password option.
3. In the Does this account have privileged access list, click This account has privileged access .
and then click OK.
4. On the Elevation page, select su or sudo elevation.
Credentials for uninstalling an agent
The following procedures begin in the UNIX/Linux Agent Uninstall Wizard, on the Credentials page, when
you select Provide Uninstall Credentials. For more information, see, Upgrading and Uninstalling Agents on
UNIX and Linux Computers.
then click OK.
If you select su elevation, type the superuser password as established on the UNIX or Linux computer,
and then click OK. The su password is also used for agent verification.
3. In the Does this account have privileged access list, select This account has privileged access .
and then click OK.
Next steps
To understand how to authenticate and monitor your UNIX and Linux computers, review Credentials You
Must Have to Access UNIX and Linux Computers
To understand how to elevate an unprivileged account for effective monitoring of UNIX and Linux
computers, review How to Configure sudo Elevation and SSH Keys
Review the Configuring SSL Ciphers if you need to reconfigure Operations Manager to use a different
cipher.
How to configure sudo elevation and SSH keys
4 minutes to read
With System Center 2016 - Operations Manager, you can provide credentials for an unprivileged account to be
elevated on a UNIX or Linux computer by using the sudo program, which allows users to run programs that have
the security privileges of another user account. You can also use Secure Shell (SSH) keys instead of a password for
secure communication between Operations Manager and the targeted computer.
This topic provides examples for creating an account for a low -privileged user, implementing sudo, and creating an
SSH key on a computer that is running Red Hat Enterprise Linux Server 6. These are examples only, and might not
reflect your environment. The following examples provide a user with access to a full set of privileges.
To obtain and configure the SSH key from the UNIX and Linux computer, you have to install the following
software on your Windows-based computer:
A file transfer tool, such as WinSCP, to transfer files from the UNIX or Linux computer to the Windows-
based computer.
The PuTTY program, or a similar program, to run commands on the UNIX or Linux computer.
The PuTTYgen program to save the private SHH key in OpenSSH format on the Windows-based computer.
NOTE
The sudo program exists at different locations on UNIX and Linux operating systems. To provide uniform access to sudo, the
UNIX and Linux agent installation script creates the symbolic link /etc/opt/microsoft/scx/conf/sudodir to point to the
directory expected to contain the sudo program. The agent uses this symbolic link to invoke sudo. The installation script
automatically creates the symbolic link, so you do not need to take any action on standard UNIX and Linux configurations;
however, if you have sudo installed at a non-standard location, you should change the symbolic link to point to the
directory where sudo is installed. If you change the symbolic link, its value is preserved across uninstall, re-install, and
upgrade operations with the agent.
Configure a low-privileged account for sudo elevation

The following procedures create a low -privileged account and sudo elevation by using opsuser for a user name.
To create a low-privileged user
1. Log on to the UNIX or Linux computer as root .
2. Add the user:
useradd opsuser
3. Add a password and confirm the password:

passwd opsuser
You can now configure sudo elevation and create an SSH key for opsuser , as described in the following
procedures.
To configure sudo elevation for the low-privileged user
1. Log on to the UNIX or Linux computer as root .
2. Use the visudo program to edit the sudo configuration in a vi text editor. Run the following command:
visudo
3. Find the following line:

root ALL=(ALL) ALL
4. Insert the following line after it:

opsuser ALL=(ALL) NOPASSWD: ALL
5. TTY allocation is not supported. Ensure the following line is commented out:
# Defaults requiretty
IMPORTANT
This step is required for sudo to work.
6. Save the file and exit visudo:

Press ESC + : (colon) followed by wq! , and then press Enter.
7. Test the configuration by entering in the following two commands. The result should be a listing of the
directory without being prompted for a password:
su - opsuser
sudo ls /etc
You can use the opsuser account by using the password and sudo elevation for specifying credentials in
Operations Manager wizards and for configuring Run As accounts.
Create an SSH key for authentication

The following procedures create an SSH key for the opsuser account that was created in the previous examples.
To generate the SSH key
1. Log on as opsuser .
2. Generate the key by using the Digital Signature Algorithm (DSA) algorithm:
ssh-keygen -t dsa
Note the optional passphrase if you provided it.

The ssh-keygen creates the /home/opsuser/.ssh directory with the private key file ( id_dsa ) and the public key
file ( id_dsa.pub ). You can now configure the key to be supported by opsuser as described in the next procedure.
To configure a user account to support the SSH key
1. At the command prompt, type the following commands. To navigate to the user account directory:
cd /home/opsuser
2. Specify exclusive owner access to the directory:

chmod 700 .ssh
3. Navigate to the .ssh directory:

cd .ssh
4. Create an authorized keys file with the public key:

cat id_dsa.pub >> authorized_keys
5. Give the user read and write permissions to the authorized keys file:
chmod 600 authorized_keys
You can now copy the private SSH key to the Windows-based computer, as described in the next procedure.
To copy the private SSH key to the Windows-based computer and save in OpenSSH format
1. Use a tool, such as WinSCP, to transfer the private key file ( id_dsa - with no extension) from the UNIX or
Linux computer to a directory on your Windows-based computer.
2. Run PuTTYgen.
3. In the PuTTY Key Generator dialog box, click the Load button, and then select the private key (id_dsa )
that you transferred from the UNIX or Linux computer.
4. Click Save private key and name and save the file to the desired directory.
You can use the opsuser account by using the SSH key and sudo elevation for specifying credentials in
Operations Manager wizards and for configuring Run As accounts.
Next steps
cipher.
Kerberos Authentication Support for Unix and Linux
computers
2 minutes to read
System Center Operations Manager version 1801 communicates with UNIX and Linux computers using the
Secure Shell (SSH) protocol and Web Services for Management (WS -Management). Agent actions such as agent
install, uninstall, and update occur over SSH and require a privileged account. Agent discovery and Monitoring
utilize WS -Management and only require a low privileged account.
the Management Server to communicate with UNIX and Linux computers. Adding Kerberos support for UNIX and
Linux computers provides greater security by allowing the Management Server to no longer need to enable basic
authentication for Windows Remote Management (WinRM ).
Operations Manager Unix and Linux Kerberos Support by Activity

ACTIVITY PROTOCOL SUPPORT FOR KERBEROS
Agent Install SSH No
Agent Uninstall SSH No
Agent Update SSH No
Agent Recovery SSH No
Agent Monitoring WS-Man Yes
Agent Discovery WS-Man Yes
Prerequisites
UNIX and Linux Monitoring with Operations Manager is supported on a number of operating systems.
The following subset of those operating systems now support WS -Management communication over Kerberos:
(Only the most recently released version of each distribution will be supported.)
OPERATING SYSTEM VERSION
CentOS 6
CentOS 7
UBUNTU Server 14
OPERATING SYSTEM VERSION
UBUNTU Server 15
UNIX or Linux agent must be domain joined.

Run as accounts must be configured to use domain-based accounts that are associated with the appropriate
Unix/Linux Run As Profile.
Enabling Kerberos authentication assumes all UNIX and Linux agents communicating with the management
server support Kerberos. Mixed mode authentication where some agents use basic authentication and
others leverage Kerberos is not supported.
Steps to enable Kerberos Authentication on a management server

1. Open the Operations console with an account that is a member of the Operations Manager Administrators
role.
2. Select Monitoring > Data Warehouse > Collection Servers > Management Server Name.
3. In the right-hand task pane, select Enable Linux Authentication Type
This task will enable/disable Kerberos authentication for Linux monitoring on the management server.
4. Click Run.
NOTE
The task sets the registry entry Authentication at the following location:
HKLM:\Software\Microsoft\Microsoft Operations Manager\3.0\Setup\Linux Auth to Kerberos.
Repeat the above steps on all management servers that communicate with UNIX or Linux agents.
Verify Kerberos Authentication via Console

To validate that Kerberos authentication is working successfully from the Operations Manager console:
1. Click Monitoring > UNIX/Linux Computers > Select a UNIX or Linux computer
2. In the right-hand Task pane, select Memory Information.
3. Confirm that the task runs successfully.
Verify Kerberos Authentication from the Command Line
To validate Kerberos authentication between a management server and a UNIX or Linux agent from the command
line, perform the following:
1. Launch a command prompt as administrator from the management server, and run the script below while
substituting the applicable information for servername, username, and password.
winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -
r:https://<UNIX/Linux servername>:1270 -u:<username@contoso.com> -p:<password> -auth:Kerberos -
skipcacheck -skipcncheck -encoding:utf-8
2. Verify the output indicates the command was successful.

Required capabilities for UNIX and Linux accounts
5 minutes to read
Access to UNIX and Linux computers in System Center 2016 - Operations Manager uses three Run as profiles.
One profile is associated with an unprivileged account while the other two accounts are associated with a
privileged account or an unprivileged account that is elevated by using sudo or su .
In the simplest case, a privileged account has capabilities equivalent to a UNIX and Linux root account, while an
unprivileged account has capabilities equivalent to a normal user account. However, with some computer versions
of UNIX and Linux, and when you use sudo for privilege elevation, you can assign more specific capabilities to
accounts. In support of such specific assignments, the following table lists the specific capabilities required by
accounts that are assigned to each of the three Run as profiles. These descriptions are somewhat generic because
information, such as exact file system paths, can vary among different UNIX and Linux computer versions.
NOTE
The following table describes the required capabilities for accounts to communicate with the Operations Manager agent on a
managed UNIX or Linux computer, but the agent itself must always run under the root account on the UNIX or Linux
computer.
UNIX AND LINUX PROFILE REQUIRED CAPABILITIES
Action profile - To log the UNIX or Linux computer on to the network,

authenticated by the Pluggable Authentication Modules
(PAM). Must have the ability to run a background shell (not
connected to a TTY). Interactive logons are not required.
- To read any log file that was specified as unprivileged when a
custom log file monitor was created, plus the ability to run
/opt/microsoft/scx/bin/scxlogfilereader.
- To fully run any command shell command that was specified
as unprivileged when a command-line monitor, rule, or task
was created.
- To run /usr/bin/vmstat for the Run VMStat task.
UNIX AND LINUX PROFILE REQUIRED CAPABILITIES
Privileged profile - To log the UNIX or Linux computer on to the network,

authenticated by the PAM. Must have the ability to run a
background shell (not connected to a TTY). Interactive logons
are not required. In the case of an account that is elevated by
using sudo , this requirement applies to the account before it
is elevated. - To fully run any shell command line that was
specified as privileged when a command-line monitor, rule, or
discovery was created. - To have the following log file
monitoring capabilities:
- To read the log file to be monitored.
By default, log files such as Syslog are usually set to be

readable only by root, and accounts assigned to this profile
must be able to read these files. Instead of giving accounts full
root privileges, the log file permissions could be changed to
grant read access to a secure group, and accounts made a
member of that group. Note that if the log file is periodically
rotated, you must ensure that the rotation procedure
maintains the group permissions. - To read any log file that
was specified as privileged when a custom log file monitor was
created. - To run /opt/microsoft/sc/bin/scxlogfilereader. -
To run tasks, recoveries, and diagnostics. These requirements
must be met only if the Operations Manager operator
explicitly decides to run them.
- Many recoveries include stopping and restarting a daemon

process. These recoveries require the ability to run the service
control interfaces (such as /et/init.d for Linux, and svcadm
for Solaris) in order to stop and restart it. Such service control
interfaces typically require the ability to run the kill command
against the daemon process and to run other basic UNIX and
Linux commands. - The requirements for other tasks,
recoveries, and diagnostics depend on the details of that
particular action.
Agent maintenance profile, and for accounts used to install - To log the UNIX or Linux computer on to the network by
agents for initial monitoring. using Secure Shell (SSH), authenticated by the PAM. Must
have the ability to run a background shell (not connected to a
TTY). Interactive logons are not required. In the case of an
account that is elevated by using sudo , this requirement
applies to the account before it is elevated. - To run the
system package installation program, such as rpm on Linux,
to install the Operations Manager agent. - To read and write
the following directories, and to create them and any
subdirectories under them if they do not exist:
- /opt - /opt/microsoft - /opt/microsoft/scx -

/etc/opt/microsoft/scx - /var/opt/microsoft/scx -
/opt/omi - /etc/opt/omi - /var/opt/omi - To run the kill
command against the running Operations Manager agent
processes. - To start the Operations Manager agent. - To add
and remove a system daemon, including the Operations
Manager agent, by using platform tools to do so. - To run
basic UNIX and Linux commands, such as cat, ls, pwd, cp,
mv, rm, gzip (or equivalent).
Important security considerations

The Operations Manager Linux/UNIX agent uses the standard PAM (Pluggable Authentication Module)
mechanism on the Linux or UNIX computer to authenticate the user name and password specified in the Action
Profile and Privilege Profile. Any user name with a password that PAM authenticates can perform monitoring
functions, including running command lines and scripts that collect monitoring data. Such monitoring functions
are always performed in the context of that user name (unless sudo elevation is explicitly enabled for that user
name), so the Operations Manager agent provides no more capability than if the user name were to login to the
Linux/UNIX system.
However, the PAM authentication used by the Operations Manager agent does not require that the user name
have an interactive shell associated with it. If your Linux/UNIX account management practices include removing
the interactive shell as a way to pseudo-disable an account, such removal does not prevent the account from being
used to connect to the Operations Manager agent and perform monitoring functions. In these cases, you should
use additional PAM configuration to ensure that these pseudo-disabled accounts do not authenticate to the
Operations Manager agent.
Next steps
cipher.
Configuring SSL ciphers
3 minutes to read
System Center - Operations Manager correctly manages UNIX and Linux computers without changes to the
default Secure Sockets Layer (SSL ) cipher configuration. For most organizations, the default configuration is
acceptable, but you should check your organization's security policies to determine whether changes are required.
Using the SSL cipher configuration

The Operations Manager UNIX and Linux agent communicates with the Operations Manager management
server by accepting requests on port 1270 and supplying information in response to those requests. Requests are
made by using the WS -Management protocol that is running on an SSL connection.
When the SSL connection is first established for each request, the standard SSL protocol negotiates the
encryption algorithm, known as a cipher for the connection to use. For Operations Manager, the management
server always negotiates to use a high strength cipher so that strong encryption is used on the network
connection between the management server and the UNIX or Linux computer.
The default SSL cipher configuration on UNIX or Linux computer is governed by the SSL package that is installed
as part of the operating system. The SSL cipher configuration typically allows connections with a variety of
ciphers, including older ciphers of lower strength. While Operations Manager does not use these lower strength
ciphers, having port 1270 open with the possibility of using a lower strength cipher contradicts the security policy
of some organizations.
If the default SSL cipher configuration meets your organization's security policy, no action is needed.
If the default SSL cipher configuration contradicts your organization's security policy, the Operations Manager
UNIX and Linux agent provides a configuration option to specify the ciphers that SSL can accept on port 1270.
This option can be used to control the ciphers and bring the SSL configuration into conformance with your
policies. After the Operations Manager UNIX and Linux agent is installed on each managed computer, the
configuration option must be set by using the procedures described in the next section. Operations Manager does
not provide any automatic or built-in way to apply these configurations; each organization must perform the
configuration by using an external mechanism that works best for it.
Setting the sslCipherSuite configuration option
The SSL ciphers for port 1270 are controlled by setting the sslciphersuite option in the OMI configuration file,
omiserver.conf. The omiserver.conf file is located in the directory /etc/opt/omi/conf/ .
The format for the sslciphersuite option in this file is:
sslciphersuite=<cipher spec>
where <cipher spec> specifies the ciphers that are allowed, disallowed, and the order in which allowed ciphers are
chosen.
The format for <cipher spec> is the same as the format for the sslCipherSuite option in the Apache HTTP Server
version 2.0. For detailed information, see SSLCipherSuite Directive in the Apache documentation. All information
on this site is provided by the owner or the users of the website. Microsoft makes no warranties, express, implied
or statutory, as to the information at this website.
After setting the sslCipherSuite configuration option, you must restart the UNIX and Linux agent for the change
to take effect. To restart the UNIX and Linux agent, run the following command, which is located in the
/etc/opt/microsoft/scx/bin/tools directory.
. setup.sh
scxadmin -restart
Enabling or Disabling the SSLv3 Protocol

Operations Manager communicates with UNIX and Linux agents over HTTPS, using either TLS or SSL
encryption. The SSL handshaking process negotiates the strongest encryption that is mutually available on the
agent and the management server. You may wish to prohibit SSLv3 so that an agent that cannot negotiate TLS
encryption does not fall back to SSLv3.
For System Center – Operations Manager, omiserver.conf is located at: /etc/opt/omi/conf/omiserver.conf
To disable SSLv3
Modify omiserver.conf, set the NoSSLv3 line to be: NoSSLv3=true
To enable SSLv3
Modify omiserver.conf, set the NoSSLv3 line to be: NoSSLv3=false
Next steps
To configure Operations Manager to authenticate with your UNIX and Linux computers, please see How to
Set Credentials for Accessing UNIX and Linux Computers
Administering and configuring the UNIX - Linux
agent
4 minutes to read
This topic describes options to administer and configure the UNIX/Linux agent for System Center - Operations
Manager.
Agent directories
Open Management Infrastructure (OMI) is installed to the directory: /opt/omi
The UNIX/Linux agent installs to the directory: /opt/microsoft/scx/
The UNIX/Linux agent maintains log files in the directory: /var/opt/microsoft/scx/log/
OMI maintains log files in the directory: /var/opt/omi/log/
Agent configuration files, including certificates, are stored in the directory: /etc/opt/microsoft/scx/
OMI configuration files are stored in the directory: /etc/opt/omi
Agent administration tools

In this section, tools to administer and configure the UNIX/Linux agent are described.
Running the agent administration tools
The tools for configuring the UNIX/Linux Agent are located in the directory:
/opt/microsoft/scx/bin/tools
Scxadmin
The scxadmin tool is used to control the state of the UNIX/Linux agent (start, stop, or restart) as well as control
logging performed by the agent. The usage of the tool can be displayed with the following command: scxadmin -?
# /opt/microsoft/scx/bin/tools/scxadmin -?
Usage: scxadmin
Generic options (for all commands)
[-quiet] Set quiet mode (no output)
General Options
scxadmin -version
Service Management
scxadmin {-start|-stop|-restart|-status} [all|cimom|provider]
Providers Management
scxadmin -config-list {RunAs}
scxadmin -config-set {RunAs} {CWD=<directory>|ChRootPath=<directory>|AllowRoot={true|false}}
scxadmin -config-reset {RunAs} [CWD|ChRootPath|AllowRoot]
Log Configuration Management

scxadmin {-log-list|-log-rotate|-log-reset} [all|cimom|provider]
scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}
scxadmin -log-set provider {{FILE:<path>|STDOUT}:<module-id>={SUPPRESS|ERROR|WARNING|INFO|TRACE|HYSTERICAL}}
scxadmin {-log-reset|-log-remove} provider [{FILE:<path>|STDOUT}]
Examples
Restarting the agent:
cd /opt/microsoft/scx/bin/tools/
./scxadmin –log-set all intermediate
Increase all logging to the Intermediate level:
./scxadmin –log-set all intermediate
scxsslconfig
The scxsslconfig tool is used to generate the certificate in /etc/opt/Microsoft/scx/ssl/ . This tool is useful in
correcting issues in which the fully-qualified domain name cannot be determined from the UNIX or Linux host
itself, or the FQDN known to the UNIX/Linux host does not match the FQDN used by the management server to
reach the host.
NOTE
The generated certificate must be signed by Operations Manager management server in order to be used in WS-
Management communication. Overwriting a previously signed certificate will require that the certificate be signed again.
Usage for the scxsslconfig tool can be displayed with the following command: scxsslconfig -?
# /opt/microsoft/scx/bin/tools/scxsslconfig -?
Usage: /opt/microsoft/scx/bin/tools/.scxsslconfig [-v] [-s days] [-e days] [-d domain] [-h host] [-g
targetpath]
-v - toggle debug flag

-g targetpath - generate certificates in targetpath
-s days - days to offset valid start date with (0)
-e days - days to offset valid end date with (3650)
-f - force certificate to be generated even if one exists
-d domain - domain name
-h host - host name
-b bits - number of key bits
-? - this help message
Examples
Regenerate the certificate, forcing overwrite of an existing certificate, with verbose output:
. setup.sh
/opt/microsoft/scx/bin/tools/scxsslconfig -f -v
Regenerate the certificate, forcing overwrite of an existing certificate, with a specified hostname and
DNS domain name:
. setup.sh
/opt/microsoft/scx/bin/tools/scxsslconfig -f -h myserver -d contoso.com
Additional configuration topics

SSL ciphers
If required, the SSL cipher list used by the UNIX/Linux agent can be customized. For more information about this
configuration, see the Configuring SSL Ciphers topic.
Specifying an alternate temporary path for scripts
If you create a UNIX/Linux Script rule or monitor in a custom management pack, the script contents will be written
to a file in /tmp on the agent computer before being run. You may wish to specify an alternate directory for script
execution. To specify an alternate directory, overwrite the symbolic link at: /etc/opt/microsoft/scx/conf/tmpdir to
point to another directory. The destination of this symbolic link must be writeable by the user account defined in
the UNIX/Linux Action Account and/or UNIX/Linux Privileged Account RunAs Profiles.
Universal Linux - operating system name/version
The Universal Linux Agent, which supports Linux operating systems such as CentOS, Debian GNU/Linux, Oracle
Linux, and Ubuntu Server, parses release files to determine the host's operating system name and version. If
required, these properties can be customized. To customize the operating system properties presented to
Operations Manager for a Universal Linux Agent host, use the following procedure:
Create the file disablereleasefileupdates in the directory: /etc/opt/microsoft/scx/conf/ .
touch /etc/opt/microsoft/scx/conf/disablereleasefileupdates
If this file exists, the agent will not attempt to update the operating system properties that are returned to
Operations Manager. This ensures that the customizations are preserved.
Edit the file scx-release in the directory: /etc/opt/microsoft/scx/conf . This file has the format:
OSName=CentOS
OSVersion=6.0
OSFullName=CentOS 6.0 (x86_64)
OSAlias=UniversalR
OSManufacturer=
The values of the OSName, OSVersion, and OSFullName properties can be edited to reflect customized values.
NOTE
The OSAlias property should not be edited. All properties in this file (except for OSManufacturer) are mandatory and should
not be null.
Next steps
For more information on how to install the agent and understand the steps for signing the agent certificate,
see Install Agent and Certificate on UNIX and Linux Computers Using the Command Line
Uninstalling Agents on UNIX and Linux Computers
Troubleshooting monitoring of UNIX and Linux
computers
10 minutes to read
System Center - Operations Manager provides monitoring of UNIX and Linux computers similar to monitoring of
Windows computers. You can monitor health, performance, obtain reports, run tasks, and implement custom
monitoring instrumentation.
You can monitor the following aspects of UNIX and Linux computers:
Services and applications
File system, disk space, swap space, system memory
Network interfaces
Core processes and attributes
Key configurations
Before you can monitor UNIX and Linux computers, you must complete the following steps:
1. Import management packs by downloading the latest versions from the Microsoft Download Center
2. Create a dedicated resource pool for monitoring UNIX and Linux computers
3. Configure the certificates for each management server in the pool
4. Create and configure Run As accounts
5. Install agent on UNIX and Linux using the Discovery Wizard
After you complete the steps above and successfully discover and deploy the agent to one or more UNIX and
Linux computers, you should verify they are being monitored correctly. After an agent is deployed, the Run As
accounts are used to perform discoveries running using the applicable discovery rules, and then start monitoring.
After several minutes, under the Administration workspace, navigate to Device Management/UNIX/Linux
Computers, and verify the computers are not listed as Unknown. They should be discovered and showing the
specific version of the OS and distro.
By default, Operations Manager monitors the following operating system objects:
Operating System
Logical disk
Network Adapters
You can provide additional monitoring and interaction capabilities with your managed UNIX and Linux computers
by using the UNIX and Linux monitoring pack templates. For more information, see UNIX or Linux Log File and
UNIX or Linux Process in the Authoring Guide.
Troubleshooting UNIX and Linux monitoring

The following section provides information about issues that might occur with monitoring UNIX and Linux
computers in Operations Manager.
Certificate Signing Error Message
During the installation of UNIX/Linux agents, you might see the following error.
Event Type: Error
Event Source: Cross Platform Modules
Event Category: None
Event ID: 256
Date: 4/1/2009
Time: 4:02:27 PM
User: N/A
Computer: COMPUTER1
Description: Unexpected ScxCertLibException: Can't decode from base64
; input data is:
This error occurs when the certificate signing module is called but the certificate itself is empty. This error can be
caused by an SSH connection failure to the remote system.
If you see this error, do the following:
1. Make sure that the SSH daemon on the remote host is running.
2. Make sure that you can open an SSH session with the remote host by using the credentials specified in the
Discovery Wizard.
3. Make sure that the credentials specified in the Discovery Wizard have the required privileges for discovery.
For more information, see Credentials You Must Have to Access UNIX and Linux Computers.
Certificate Name and Host Name do not Match
The common name (CN ) that is used in the certificate must match the fully qualified domain name (FQDN ) that is
resolved by Operations Manager. If the CN does not match, you will see the following error when you run the
Discovery Wizard:
The SSL certificate contains a common name (CN) that does not match the hostname
You can view the basic details of the certificate on the UNIX or Linux computer by entering the following
command:
openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates
When you do this, you will see output that is similar to the following:
subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
notBefore=Mar 25 05:21:18 2008 GMT
notAfter=Mar 20 05:21:18 2029 GMT
Validate the hostnames and dates and ensure that they match the name being resolved by the Operations
Manager management server.
If the hostnames do not match, use one of the following actions to resolve the issue:
If the UNIX or Linux hostname is correct but the Operations Manager management server is resolving it
incorrectly, either modify the DNS entry to match the correct FQDN or add an entry to the hosts file on the
Operations Manager server.
If the UNIX or Linux hostname is incorrect, do one of the following:
Change the hostname on the UNIX or Linux host to the correct one and create a new certificate.
Create a new certificate with the desired hostname.
To Change the Name on the Certificate:
If the certificate was created with an incorrect name, you can change the host name and re-create the certificate
and private key. To do this, run the following command on the UNIX or Linux computer:
/opt/microsoft/scx/bin/tools/scxsslconfig -f -v
The -f option forces the files in /etc/opt/microsoft/scx/ssl to be overwritten.

You can also change the hostname and domain name on the certificate by using the -h and -d switches, as in the
following example:
/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>
Restart the agent by running the following command:
/opt/microsoft/scx/bin/tools/scxadmin -restart
To add an entry to the hosts file:

If the FQDN is not in Reverse DNS, you can add an entry to the hosts file located on the management server to
provide name resolution. The hosts file is located in the Windows\System32\Drivers\etc folder. An entry in the
hosts file is a combination of the IP address and the FQDN.
For example, to add an entry for the host named "newhostname.newdomain.name" with an IP address of
192.168.1.1, add the following to the end of the hosts file:
192.168.1.1 newhostname.newdomain.name
Management pack issues

ExecuteCommand Does Not Support Pipeline Operators or Aliases
When you use an alias or a pipeline operator with the ExecuteCommand parameter, the command fails. The
ExecuteCommand parameter does not support the pipeline operator, aliases, and shell-specific syntax.
In System Center Operations Manager management packs that are designed to manage UNIX and Linux
computers, the ExecuteCommand parameter does not start a shell process, causing the custom action to fail.
For each of the following custom action types, you specify how the command arguments are invoked by using
either the ExecuteCommand parameter or the ExecuteShellCommand parameter:
Microsoft.Unix.WSMan.Invoke.ProbeAction
Microsoft.Unix.WSMan.Invoke.WriteAction
Microsoft.Unix.WSMan.Invoke.Privileged.ProbeAction
Microsoft.Unix.WSMan.Invoke.Privileged.WriteAction
The ExecuteCommand parameter passes the command-line arguments to the console without starting a shell
process.
The ExecuteShellCommand parameter passes the command arguments to a shell process using the user's default
shell; this shell supports pipeline, aliases, and shell-specific syntax.
NOTE
The ExecuteShellCommand parameter uses the default shell of the user who is running the command. If you require a
specific shell, use the ExecuteCommand parameter, and prefix the command arguments with the required shell.
The following examples show how to use the ExecuteCommand and ExecuteShellCommand parameters:
To pass the command-line arguments to the console without starting a shell process:
<p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-
schema/2/SCX_OperatingSystem"> <p:Command> service syslog status </p:Command> <p:timeout>10</p:timeout>
</p:ExecuteCommand_INPUT>
To pass the command-line arguments to a shell process that references an explicit shell:
<p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-
schema/2/SCX_OperatingSystem"> <p:Command> /bin/sh ps -ef syslog | grep -v grep </p:Command>
<p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>
To pass the command arguments to a shell process that uses the user's default shell:
<p:ExecuteShellCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-
schema/2/SCX_OperatingSystem"> <p:Command> uptime | awk '{print $10}' |awk -F"," '{print $1}'
</p:Command> <p:timeout>10</p:timeout> </p:ExecuteShellCommand_INPUT>
Logging and Debugging

This topic describes how to enable logging and debug tools for troubleshooting issues with monitoring UNIX and
Linux computers.
Enable Operations Manager Module Logging
The Operations Manager Agents for UNIX and Linux maintain several log files that can be useful when
troubleshooting client issues. These log files are located on the managed UNIX or Linux computer. The logging
level for the agent log files can be configured as needed. More verbose logging can be useful in diagnosing an
issue. For normal operation, log levels should not be set to a value more verbose than the default configurations
(Intermediate) in order to prevent excessive log file growth
NOTE
Calls made outside of Windows Remote Management (WinRM) are made using SSH/SFTP. These components rely on a
separate logging mechanism than Operations Manager.
NOTE
The logging level for the omiserver.log log file cannot be changed from the default in this version of the Operations Manager
Agents for UNIX and Linux.
1. Create a blank file named EnableOpsmgrModuleLogging in the Temp directory for the user account
calling these modules by typing at a command-line prompt COPY /Y NUL
%windir%\TEMP\EnableOpsMgrModuleLogging.
NOTE
Generally, it is the SYSTEM account making the calls, and C:\Windows\Temp is the default SYSTEM temp folder.
2. After creation of the blank file, Operations Manager will immediately begin logging SSH and Certificate
activity to the Temp directory. Scripts that call into SSH modules will log to <Scriptname.vbs>.log. Other
modules have their own logs.
In some cases, it may be required to restart the HealthService to get the EnableOpsmgrModuleLogging logging to
take effect.
Enable Logging on the UNIX Agent

These logs will report the UNIX agent actions. If there is a problem with the data returned to Operations Manager,
look in this log. You can set the amount of information logged with the scxadmin command. The syntax for this
command is:
scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}
The following table lists the possible parameter values:
LEVEL DESCRIPTION
Errors Log only Warning or Error messages.
Intermediate Log Info, Warning and Error messages.
Verbose Log Info, Warning, and Error messages with debug logging.
Note that This level of logging is likely to cause rapid growth
in the size of the log files. It is strongly recommended that this
option only be used for short periods of time to diagnose a
specific issue.
Use DebugView to Troubleshoot Discovery Issues

DebugView is an alternative method to EnableOpsmgrModuleLogging for troubleshooting discovery issues.
1. Download DebugView from: https://go.microsoft.comfwlink/?Linkid=129486.
2. Launch DebugView on the Management Server performing the discovery.
3. Start discovering the UNIX Agents. You should start seeing output in your DebugView windows.
4. DebugView will present a step-by-step readout of the discovery wizard process. This is often the fastest
method of troubleshooting discovery issues.
Enable Operations Manager Logging for Windows Remote Management
This verbose tracing method is used to see the Windows Remote Management (WinRM ) queries used by
Operations Manager to gather data from the agent. If you suspect there is a problem with the WinRM connection,
this log provides detailed information that can help with troubleshooting.
1. On the Management server that is monitoring the UNIX or Linux agent, open a command prompt.
2. Type the following commands at the command prompt:
a. cd C:\Program Files\Microsoft System Center 2016\Operations Manager\Tools
b. StopTracing.cmd
c. StartTracing.cmd VER
3. Reproduce the failing issue in Operations Manager.
4. Type the following commands at the command prompt:
a. StopTracing.cmd
b. FormatTracing.cmd
5. Search for WS -Man in the TracingGuidsNative.log file.
NOTE
WinRM is also known as WS-Management (WS-Man).
NOTE
The FormatTracing command opens a Windows Explorer window displaying the c:\Windows\temp\OpsMgrTrace directory.
The TracingGuidsNative.log file is in that directory.
Manage UNIX and Linux Log Files

The Operations Manager Agents for UNIX and Linux do not limit the size of the agent log files. In order to control
the maximum size of the log files, implement a process to manage the log files. For example, the standard utility
logrotate is available on many UNIX and Linux operating systems. The logrotate utility can be configured to
control the log files used by the Operations Manager Agents for UNIX or Linux. After rotating or modifying the log
files of the agent, the agent must be signaled that logs have rotated in order to resume logging. The scxadmin
command can be used with the -log-rotate parameter with the following syntax:
scxadmin -log-rotate all
Example Logrotate configuration file

The following example demonstrates a configuration file to rotate the scx.log files as well as omiserver.log with the
logrotate utility of Linux. Typically, logrotate will run as a scheduled job (with crond) and act on configuration files
found in /etc/logrotate.d. To test and use this configuration file, modify the configuration to be appropriate for your
environment, and link or save the file in /etc/logrotate.d.
#opsmgr.lr
#Rotate scx.log
#Weekly rotation, retain four weeks of compressed logs
#Invoke scxadmin -log-rotate to resume logging after rotation
/var/opt/microsoft/scx/log/scx.log {
rotate 4
weekly
compress
missingok
notifempty
postrotate
/usr/sbin/scxadmin -log-rotate all
endscript
}#Rotate scx.log for the monitoring user account named: monuser
#Weekly rotation, retain four weeks of compressed logs
#Invoke scxadmin -log-rotate to resume logging after rotation
/var/opt/microsoft/scx/log/monuser/scx.log {
rotate 4
weekly
compress
missingok
notifempty
postrotate
/usr/sbin/scxadmin -log-rotate all
endscript
}
#Optionally, rotate omiserver.log. This requires that OMI be stopped and started to prevent
#impact to logging. Monthly rotation, retain two weeks of compressed logs
#Uncomment these lines if rotation of omiserver.log is needed
#/var/opt/microsoft/scx/log/omiserver.log{
# rotate 2
# monthly
# compress
# missingok
# notifempty
# prerotate
# /usr/sbin/scxadmin -stop
# endscript
# postrotate
# /usr/sbin/scxadmin -start
# endscript#}
Next steps
For additional guidance to help resolve common agent deployment issues, review the SCOM 2012
Troubleshooting: UNIX/Linux Agent Discovery Wiki.
Agentless Monitoring in Operations Manager
7 minutes to read
System Center Operations Manager can gather performance and availability data on a computer that does not
have an agent installed by using a proxy agent that is installed on another computer. Use agentless-monitoring of
computers when it is not possible or desirable to install an agent on a computer.
An agentless-managed computer is a Windows-based computer that is discovered by using the Operations
console. You assign a management server or agent-managed computer to provide remote (proxy) agent
functionality for the computers.
Agentless-managed computers are managed as if there is an agent installed on them. Not all management packs
work in agentless mode. For more information, see the documentation for the management packs you are
running.
IMPORTANT
Agentless management of a computer will not work if the agentless-managed computer and its proxy communicate
through a firewall. A management server will not collect descriptions for events or publishers that are present on an
agentless managed computer but are not present on the proxy agent.
For information about configuring an agent-managed computer as a proxy for agentless-managed computers,
see How to configure a proxy for agentless monitoring.
IMPORTANT
An agentless-managed computer places additional resource utilization on a management server than an agent-managed
computer.
To change an agentless-managed computer to an agent-managed computer, do the following:

1. Delete the agentless-managed computer from the management group by right-clicking the computer in
Agentless Managed in the Administration workspace and then clicking Delete.
2. Deploy the agent to the computer. For more information, first review the planning guidance Operations
Manager agents.
Agentless monitoring compared to Agentless Exception Monitoring

Agentless monitoring provides monitoring of computers without agents by using a proxy agent and applying
those management packs that support agentless monitoring. Agentless Exception Monitoring (AEM ) redirects
hardware, operating system, and application crash information to Operations Manager, which can aggregate,
view, and report on error reports that are sent by the Windows Error Reporting service. For information on AEM,
see Client monitoring using Agentless Exception Monitoring in Operations Manager.
You can monitor a computer without an agent by using either agentless monitoring, AEM, or both.
To configure Windows-based computers for agentless management

Administrators role for the management group.
4. On the Discovery Type page, click Windows computers.
5. On the Auto or Advanced? page, do the following:
a. Select either Automatic computer discovery or Advanced discovery. Automatic computer
discovery scans for Windows-based computers in the domain. Advanced discovery allows you to
specify criteria for the computers that the wizard will return, such as computer names starting with
WKS. If you select Automatic computer discovery, click Next, and then go to step 7. If you select
Advanced discovery, continue with the following steps.
b. In the Computer and Device Classes list, select Servers and Clients, Servers Only, or Clients
Only.
c. In the Management Server list, click the management server or gateway server to discover the
computers.
d. If you selected Servers and Clients, you can select the Verify discovered computers can be
contacted check box. This is likely to increase the success rate of agent deployment, but discovery
can take longer.
NOTE
If the Active Directory catalog does not contain the NetBIOS names for computers in a domain, select Verify
discovered computers can be contacted. Otherwise, the Browse, or Type In option fails to find
computers. This affects computers in the same domain as the management server, in another domain with a
full trust relationship, and in untrusted domains by using a gateway server.
e. Click Next.
NOTE
The wizard can return approximately 4000 computers if Verify discovered computers can be contacted is
selected, and it can return 10,000 computers if this option is not selected. Automatic computer discovery verifies
that discovered computers can be contacted. A computer that is already managed by the management group is not
returned.
6. On the Discovery Method page, you can locate the computers that you want to manage by either
scanning or browsing Active Directory Domain Services or typing the computer names.
If you want to scan, do the following:
a. If it is not already selected, select Scan Active Directory and then click Configure.
b. In the Find Computers dialog box, type the criteria that you want to use for discovering computers,
and then click OK.
c. In the Domain list, click the domain of the computers that you want to discover.
If you want to browse Active Directory Domain Services or type the computer names, do the following:
Select Browse for, or type-in computer names, click Browse, specify the names of the computers
that you want to manage, and then click OK.
In the Browse for, or type-in computer names box, type the computer names, separated by a
semi-colon, comma, or a new line. You can use NetBIOS computer names or fully qualified domain
names (FQDN ).
7. Click Next, and on the Administrator Account page, do one of the following:
Select Use selected Management Server Action Account if it is not already selected.
Select Other user account, type the User name and Password, and then select the Domain from
the list. If the user name is not a domain account, select This is a local computer account, not a
domain account.
IMPORTANT
The account must have administrative privileges on the targeted computers. If This is a local computer
account, not a domain account is selected, the management server action account will be used to perform
discovery.
8. Click Discover to display the Discovery Progress page. The time it takes discovery to finish depends on
many factors, such as the criteria specified and the configuration of the environment.
NOTE
Computers that are already managed by the management group will not be returned by the wizard.
9. On the Select Objects to Manage page, do the following:

a. Select the computers that you want to be agent-managed computers.
b. In the Management Mode list, click Agentless and then click Next.
c. Click Change, select the proxy agent that you want to use, click OK, and then click Next.
10. On the Summary page, do the following:
a. Leave the Agent installation directory set to the default of %ProgramFiles%\Microsoft
IMPORTANT
b. Leave Agent Action Account set to the default, Local System, or select Other and type the User
c. Click Finish.
NOTE
If the task fails for a computer, click the targeted computer. The reason for the failure is displayed in the Task Output
text box.
12. Click Close. The computers will be listed in the Administration workspace in Agentless Managed.
How to configure a proxy for agentless monitoring

When you set up agentless monitoring of a computer, you select a proxy for each agentless-managed computer.
Being configured as a proxy agent allows an agent to submit data on behalf of another source. A management
group can serve as a proxy, but this takes up system resources. A best practice is using an agent-managed
computer as a proxy agent.
You might also configure a computer to act as a proxy to support specific features of a management pack. For
example, the Active Directory Management Pack requires enabling domain controllers to act as proxy agents.
NOTE
If a proxy agent is removed from management, its agentless systems are no longer managed.
Both the agentless-managed system and its proxy need to have access to the managing server through any
firewalls. For more information about interacting with firewalls, see Configuring a firewall for Operations
Manager.
1. In the Administration workspace, click Agent Managed, right-click the computer, and then click
Properties.
2. In the Agent Properties dialog box, click the Security tab.
3. On the Security tab, select Allow this agent to act as a proxy and discover managed objects on
other computers, and then click OK.
How to configure a management server as a proxy for agentless-managed computers
1. In the Administration workspace, click Management Servers, right-click the management server, and
then click Properties.
2. In the Management Server Properties dialog box, click the Security tab.
3. On the Security tab, select Allow this server to act as a proxy and discover managed objects on
other computers, and then click OK.
How to change the proxy agent for agentless-managed computers
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role
for the management group.
3. Click Agentless Managed.
4. In the Agentless Managed pane, select the agentless-managed computers for which you want to change
the proxy agent, right-click them, and then select Change Proxy Agent.
5. In the Change Proxy Agent dialog box, select the computer you want to be the new proxy agent, and
then click OK.
Next steps
Monitoring of applications, features, and services are enabled by importing management packs. See What is an
Operations Manager management pack for an explanation of what management packs do, and how to import
and manage them.
Client monitoring using error reporting in Operations
Manager
11 minutes to read
The Client Monitoring feature of System Center Operations Manager enables you to monitor operating systems
and applications for errors and participate in the Error Reporting program. The Error Reporting program collects
diagnostics and usage data about Operations Manager, which is used by Microsoft to improve the installation
experience, quality, and security of future releases.
Agentless Exception Monitoring (AEM ) is a component of the Client Monitoring feature in Operations Manager.
AEM enables you to monitor operating systems and applications for errors within your organization. By default,
when a Microsoft application encounters a severe error, it creates a report that can be sent to Microsoft to
consolidate data that can lead to a reduction in errors. Using AEM, you can direct these reports to an Operations
Manager management server. Operations Manager can then provide detailed views and reports on this
consolidated error data. Using this data, you can determine how often an operating system or application
experiences an error and the number of affected computers and users.
AEM views
By default, the following views display AEM data in the Monitoring area of the Operations console:
Application view
A state view that lists applications that have failures.
Crash listener view
A state view that lists the computers that are listening for failures that occur on other computers or applications.
Error events
An event view that lists the application error reports generated by severe application or operating system failures.
Error group view
A state view that lists application errors by error group.
System error group view
A state view that lists the computers that have an operating system failure.
Forwarding client error reports (Client Monitoring)

The Microsoft Error Reporting (MER ) service collects information about how you use Microsoft programs and
about some of the issues you might encounter. Microsoft uses this information to improve the products and
features you use most often and to help solve issues. Participation in the program is strictly voluntary.
When you choose to participate in the reporting service, you configure clients with Group Policy to redirect error
reports to an Operations Manager management server, instead of reporting directly to Microsoft. The
management servers are configured to forward these reports to Microsoft.
IMPORTANT
The reports do not contain contact information about you or your organization, such as names or an address.
The error reports forwarded from your organization to Microsoft are combined with reports from other
organizations and individual customers to help Microsoft solve issues and improve the Microsoft products and
features that customers use most often. For more information about the Microsoft Error Reporting service, see the
privacy statement for Microsoft Error Reporting Service page.
Use the following procedure to configure error reporting settings. The management server must have access to
the Internet to participate in the program.
1. Log on to a management server with an account that is a member of the Operations Manager
3. In the Administration workspace, expand Administration, and then click Settings.
4. In Settings, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Group Settings - Privacy dialog box, on the Diagnostic and
Usage Data Settings tab, click Yes, I am willing to send data to Microsoft to send collected data to
Microsoft or click No, I do not prefer to send data to Microsoft to decline participation. Then click OK.
NOTE
You can click Operations Manager Privacy Statement to view information about the program, including the
privacy statement.
How to configure a management server for client monitoring

Use the following procedures to configure a management server for the server component of the Client
Monitoring feature of System Center Operations Manager.
IMPORTANT
If you plan to configure the management server to forward error reports to Microsoft and receive links to available solutions
for those errors or participate in Microsoft Error Reporting, you must first configure the management server's proxy settings
if it uses a proxy server to access the Internet.
The Operations Manager Client Monitoring Configuration Wizard is used to configure the server component of
the feature on an Operations Manager management server. To configure the server component of Client
Monitoring on multiple management servers, run the wizard once for each management server. An example of
when you might configure multiple management servers for Client Monitoring is if the connection between
specific clients and management servers is less expensive.
IMPORTANT
The management server and error reporting clients must be in the same or fully trusted domains.
3. In the Administration workspace, click Management Servers.
4. In the Management Servers pane, right-click the management server on which you want to enable Client
Monitoring, and then click Configure Client Monitoring. This will start the Client Monitoring
Configuration Wizard. Use the same procedure to Disable Client Monitoring on the management
server. You must also disable Client Monitoring on the clients.
NOTE
The Configure Client Monitoring option will be unavailable if the selected computer is a gateway server.
5. On the Introduction page of the Client Monitoring Configuration Wizard, click Next. The
Introduction page is skipped if the wizard has run previously and the Do not show this page again check
box was selected.
6. On the Diagnostic and Usage Data page, do one of the following:
Leave the default option of No if you do not want your organization to participate in the program, and
then click Next.
Or
a. Select Yes, if you want your organization to participate in the program.
b. Leave Use Secure Socket Layer (SSL ) protocol selected if you have installed a certificate on your
management server, leave Use Windows Authentication selected if you want the client computers
to authenticate with the management server; otherwise, clear the options.
c. Type the appropriate Port, or leave the default of 51907, and then click Next.
7. On the Error Collection page, do the following:
a. Type the local or attached File Share Path, such as C:\ErrorData, for the management server that
will be used to collect error reports. The file share will be created at the local path on the
management server and shared with the necessary permissions.
IMPORTANT
The file share path must be on an NTFS partition and have at least 2 GB of free disk space. It is
recommended that the path is no longer than 120 characters. The file share path can be a local drive path on
the selected management server such as C:\ErrorData, or a UNC path to an existing network share such as
\Server\FileShare\ErrorData.
b. Select Collect application errors from Windows Vista-based or later clients if you are
managing Windows Vista or later operating systems with Operations Manager. Type a Port number,
or leave the default 51906. Leave Use Secure Socket Layer protocol selected if you have installed
a certificate on your management server, leave Use Windows Authentication selected if you want
the client computers to authenticate with the management server; otherwise, clear the options.
c. Type the Organization Name to Use, using no more than 22 characters, and then click Next.
8. On the Configure Error Forwarding to Microsoft page, do one of the following:
Leave the Forward all collected errors to Microsoft (Recommended) check box cleared, and then
click Next.
Or
a. Select Forward all collected errors to Microsoft (Recommended) if the management server is
connected to the Internet and you want to forward error reports to Microsoft and receive links to
available solutions for those errors.
b. Select Detailed (the error signature and requested additional data) to help ensure Microsoft
can provide a solution to the issue, or leave the default setting of Basic (only the error signature).
c. Click Next.
9. On the Create File Share page, do one of the following:
Select an Existing user account from the list, and then click Next.
Select Other user account (will not be saved), type the User name and Password, select the
Domain from the list, and then click Next.
IMPORTANT
The account must have the permissions necessary to create a file share on the path provided in step 7a.
10. On the Create file Share: Task Status page, after the file share is successfully created, click Next.
NOTE
To modify the Client Monitoring settings on the management server, such as the file share, you must disable and
then re-enable Client Monitoring on the management server. You must also then modify the Client Monitoring
Group Policy settings on the clients.
11. On the Client Configuration Settings page, type or Browse to the location you want to save the settings
from the Client Monitoring Configuration Wizard. These settings are saved in a Group Policy template file
named ServerNameFQDN.ADM. Click Finish.
IMPORTANT
You must use the ServerNameFQDN.ADM file to configure clients to redirect their Client Monitoring data to the
management server. For more information, see the procedure below.
How to configure clients for client monitoring

1. Run the Group Policy Object Editor (gpedit.msc) for the domain or local computer.
NOTE
For information about Group Policy, see http://go.microsoft.com/fwlink/?LinkId=156845.
2. If needed, disable the Turn off Windows Error Reporting policy. This policy can be found in Computer
Configuration/Administrative Templates/System/Internet Communication Management/Internet
Communication settings.
3. Add the Agentless Exception Monitoring (AEM ) Group Policy administrative template
(ServerNameFQDN.ADM ) to the domain or local computer policy. The ADM file is created when the Client
Monitoring Configuration Wizard is run.
NOTE
Use the same procedure to Disable the Group Policy settings, thereby disabling Client Monitoring on the clients.
How to customize client monitoring data collection and solution

response URLs for error groups
You can help decrease the time it takes to diagnose and resolve operating system and application errors in your
organization by customizing the data that is collected in error reports by computers experiencing errors and the
solution response URL for an error group. The solution response URL can point to an appropriate location in a
knowledge base.
1. Log on to the computer with an account that is a member of the Operations Manager Administrator role.
3. In the Monitoring workspace, expand Agentless Exception Monitoring, and then click Error Group
View.
4. In the Error Group View, select an entry.
5. In the Tasks pane, click Show or Edit Error Group Properties.
6. In the Error Group Responses dialog box, select Custom Collection, and then click Edit.
7. In the Diagnostic Data Collection Configuration dialog box, specify the Files, WMI Queries, and
Registry Keys you want to collect from the computers experiencing the error, and then click OK. A
computer will send the specified data in an error report to the management server on the next occurrence
of an error in the error group.
NOTE
You can use variables, such as %ProgramFiles%, for file paths. For information about WMI, see WMI
Documentation.
8. In the Error Group Responses dialog box, select Custom error information, type the URL for the custom
error information, such as http://server/errors/100.htm, click Test Link, and then click OK.
How to configure error transmission settings for client monitoring

When you enable Client Monitoring for a management group, you can configure it to forward error reports for
Microsoft products to Microsoft. Error Transmission settings allow you to specify which error reports are sent to
Microsoft and the additional diagnostic data that is included with the error reports.
3. In the Administration workspace, click Settings.
4. In the Settings pane, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Group Settings - Privacy dialog box, click the Error Transmission
tab.
NOTE
Click Read the privacy statement to view the privacy statement.
How to filter errors that are sent to Microsoft

1. On the Error Transmission tab of the Global Management Server Group Settings - Privacy dialog
box, click Filter.
2. In the Error Forwarding Filters dialog box, select one or more of the options for sources of errors that you
do not want forwarded to Microsoft, such as that come from specific computers.
3. In the Criteria description text box, click specific, and provide the values for the criteria of errors that you
do not want forwarded to Microsoft, such as contoso.com.
4. Click OK twice.
How to configure diagnostic data sent to Microsoft with error reports
1. On the Error Transmission tab of the Global Management Server Settings - Privacy dialog box, do
one or more of the following:
a. Select Upload diagnostic data collection request, select the additional diagnostic data that you
want to send with error reports from computers reporting errors to the management servers, and
then forward from the management server to Microsoft with the error reports.
b. Set Maximum number of CAB files to send to Microsoft per error group to help Microsoft
diagnose the error. Ten is the recommended number.
c. Select Display links to solutions from Microsoft on error reporting computers. A link to
available solutions will display to end users after the error is first encountered and the link to the
solution is downloaded to the management server.
d. Select Display links to surveys from Microsoft on error reporting computers.
e. Specify the Default solution link when no Microsoft solution is available. This could be an
internal Web page for technical support, for example.
2. Click OK.
Viewing and investigating alerts for .NET applications
6 minutes to read
In System Center – Operations Manager, you can monitor web applications from server- and client-side
perspectives to get details about application performance and reliability that can help you pinpoint the root causes
of incidents. When you specify settings, the types of events to collect, the performance goals to measure, and
servers to monitor, Operations Manager application monitoring reveals how web-based applications are running.
You can see how frequently a problem is occurring, how a server was performing when a problem occurred, and
the chain of events related to the slow request or method that is unreliable. This information is required to partner
with software developers and database administrators to help ensure that applications perform correctly and
reliably at optimal levels.
A new 2-step application monitoring strategy

Application monitoring in Operations Manager has two new monitoring features that allow you to prioritize alerts
and then investigate and troubleshoot individual issues:
Step 1: Identify problem areas. Use Application Advisor to help you prioritize and manage which performance
and exception events to address. Application Advisor identifies and lists which applications are causing the
most problems within an environment. These are the applications you should address first because they are
causing most SLA violations. If you are responsible for applications, Application Advisor provides a helpful
view into your application’s overall health.
Step 2: Diagnose problems. Use Application Diagnostics to help you investigate and troubleshoot specific
events. You can view event properties, performance counters, distributed chains, similar and related events to
narrow the cause of the issue and help identify who should correct the problem. Application Diagnostics is
available as a standalone web console or through links in the Alert descriptions in the Operations Manager
consoles.
After you have configured .NET applications to be monitored, you can view alerts and begin investigating the
issues. To configure monitoring of your .NET application, review the Before you begin monitoring .NET
applications topic to understand requirements and configuration steps.
View and investigate alerts for .NET applications (server-side example )
1. To view active alerts by application group, in the System Center - Operations Manager Operations console,
in the navigation pane, select Monitoring, expand Application Monitoring.NET Monitoring and
expand the folder with the name of the application group you configured for monitoring, and then click
Active Alerts.
View alerts by application group
Additional views:
To see why a monitoring aspect is unhealthy, use the application group state view and click the state
view cell related to it. The Details View will show you the instance and the state of the Availability,
Configuration, Performance, and Security monitors. You can also start the Health Explorer in context
of the application instance to see which monitors have gone into a critical or warning state.
Application group state view
To see application performance, in the application component folder, click All Performance Data.
This gives you the base information about each component, shown by instance.
All performance data
To see the overall health dashboard view of the components you selected for the application you are
monitoring, in the application component folder, click Overall Component Health. You will see the
application state, active alerts, and a detail view.
Overall component health
To work with data collected by client-side monitoring, in the Operations console, on the navigation pane,
click the Monitoring button, expand Application Monitoring.NET Monitoring, and then application
name (client) folder. The client-side monitoring process is very similar to server-side monitoring, except that
you click All Performance Data and Overall Component Health in the application name (client) folder
to view alerts pertaining to the client-side monitoring for the application group.
To verify client-side application monitoring is working, go to the application group state view and the CSM
Application Component will have application monitoring status filled in.
NOTE
Client-side monitoring is an extension of server-side monitoring that is not enabled by default. You set it up through
the same template as server-side monitoring. It might take a few minutes to discover the objects after you set up
client-side monitoring.
2. To see general details about an alert, click an alert. The Alert Details pane describes the alert, including
information about its source, rule, creation date, and the monitoring setting that caused the alert to be
raised.
3. To begin investigating an alert and view the alert description, double-click an alert. The Alert Properties
page will open.
Begin investigating alerts on the Alert Properties page
NOTE
To see details about an alert in any of these views, click the alert you want to investigate and look in the Alert
Details pane for the Knowledge section. You can also open the Alert Properties page, which shows the details of an
alert and you can enter alert status. To open the Alert Properties page, double-click an alert or in the Tasks pane, in
the Tasks section, click Alert Properties.
4. On the Alert Properties page, click the link in the Alert Description pane. This opens Application
Diagnostics, a new monitoring feature in Operations Manager in a web browser. Here on the Event
properties tab you can see information, such as the performance metrics, the call stack, and collection
notes. For more information on the Event properties tab, see Performance Event Details. Click Yes to close
the main window once the event information has loaded.
NOTE
This link to Application Diagnostics is also on the Alert Context tab.
5. Application Diagnostics Event properties
6. On the Event Properties tab, expand the Stack section. The stack is the order in which events happened.
The Resource Group View and Execution Tree View allow you to expand nodes to investigate the
various calls. This view helps answer which tier the problem is in, or where is it occurring.
Application Diagnostics tree views lets you see exactly what went wrong where and when.
7. To see how this event relates to other events in the chain of events, on the Application Diagnostics page,
click the Distributed chains tab. This view shows all of the components that are involved in the request.
Application Diagnostics Distributed chains show how events relate to each other.
8. To pinpoint the root cause of the problem or incident, click the last event in the chain. This is the latest event
that broke the performance threshold. The Event Properties tab for that event will open.
9. On the Application Diagnostics page, click the Performance counters tab. Performance counters show
the system 15 minutes before the event happened. This gives a baseline measure before the event, which
allows you to see your system state before the event so that you know if the system was impacting the
performance of the application.
Application Diagnostics Performance counters allow you to compare system performance before,
during, and after an event.
10. On the Application Diagnostics page, click the Similar events tab. Similar events are the other events
that are in the same problem group. On this page you can filter similar events by Problem and Heaviest
Resource to help you identify trends.
Application Diagnostics Similar events allow you to compare similar events to identify trends.
11. On the Application Diagnostics page, click the Related events tab. Related events are events that
occurred around the same time as the event you are investigating. Related events tell you what else is going
on about the same time as the event you are investigating. You can increase or decrease the range of time in
which other related events occurred relative to the event you are investigating. In general, specifying a
greater time range shows you more related events.
Application Diagnostics Related events allows you to see what other events are occurring about
the same time as the event you are investigating.
Next steps
For information about working with events, see Working with events by using Application Diagnostics.
Working with the Application Diagnostics console
7 minutes to read
The Application Diagnostics console is an event management system for .NET Application Performance
Monitoring in System Center - Operations Manager. You can use Application Diagnostics console to monitor
deployed .NET applications for slowdowns, faults, and failures, and immediately pinpoint the source of the
problem.
User roles for Application Performance Monitoring

The following table shows the Operations Manager .NET Application Performance Monitoring tasks and the user
roles with their permissions.
Legend:
Yes - Can always use the feature
No - Cannot use the feature unless the user also belongs to a group that grants access to this functionality.
APPLICATI
ON REPORT
ADVANCE MONITORI READ- SECURITY
ADMINIST D NG ONLY REPORT ADMINIST
RATOR AUTHOR OPERATOR OPERATOR OPERATOR OPERATOR OPERATOR RATOR
Run APM Yes No No No No No No No

Wizard or
change
APM
settings
Access Yes No No Yes No No No No

Applicatio
n
Diagnosti
cs
Access Yes No No Yes* No No Yes* Yes

Applicatio
n Advisor
NOTE
* The Application Monitoring Operator role and Report Operator role are both required to access Application Advisor.
The Application Diagnostics console

The Application Diagnostics console is the place to look at the individual performance and reliability events that are
being raised within your environment. You can look at all of the events, or group them into "problem groups" in
which events coming from the same sources are grouped together to highlight the problems with the monitored
applications. Use Application Diagnostics to look at events and the transaction chains related to those events to
understand how the performance and reliability issues are impacting your applications. The Application Advisor
console provides analytics and telemetry of the data presented in Application Diagnostics. Through the Application
Advisor console you gain insights into which events are causing the most problems. For more information about
Application Advisor, see Prioritizing alerts by using Application Advisor
Open the Application Diagnostics console
1. Application Diagnostics and Application Advisor are installed along with the Operations Manager web
console. To find the web address of the Operations Manager web console, open the Operations console. In
the navigation pane, select Administration, click Settings, and then double-click Web Addresses. The
Operations Manager web console URL will be specified as: http(s)://<web host>/OperationsManager . Using
this URL format and the same web host, here are the links to Application Advisor and Application
Diagnostics:
The Application Diagnostics console address is: http(s)://<web host>/AppDiagnostics
The Application Advisor console address is: http(s)://<web host>/AppAdvisor
To make access to the consoles easy, add all three console URLs to your web browser's favorites list.
To open Application Diagnostics, paste the Application Diagnostics URL into your browser. Application
Diagnostics opens in the web browser window.
NOTE
If you are running Operations Manager on a server rather than a client computer, you can access Application
Diagnostics and Application Advisor from the Start menu.
Access to Application Diagnostics is controlled through the Application Monitoring Operator and
Administrator roles. You must be a member of one of these roles to have rights to the console.
Viewing Events by Areas of Interest

In Application Diagnostics, there are two major types of events, those related to application performance and those
related to application failures and errors. The failures and errors can be divided further into connectivity, security,
and failure issues. Failure issues are typically related to a problem with the application code. In Application
Diagnostics, you can view events grouped in these ways:
All (displays all events)
Application Errors (displays exception events)
Performance (displays performance events)
1. Open Application Diagnostics and select Events from the Navigation pane.
2. In the Navigation pane, use the Search for menu to select the category of events you want to view.
Grouping Events within Areas of Interest

Grouping application events by similarity provides the best method for determining if the same issue has occurred
before and ensuring that resources responsible for the issue resolution are allocated in the most efficient way.
2. In the Navigation pane, use the Search for menu to select the category of events you want to view.
3. In the Group By menu, select the way you want to group the events.
Your first selection (Application Errors and Performance) affects the grouping options you see for your second
selection.
Grouping Application Errors
Problem What it displays: All events in this grouping are coming from the same entry point into the
application (for example, a method or a web page) and have the same call stack. Value: Consolidating events
by problem allows you to prioritize your efforts to correct an issue based on the number of events in the
group.
Action What it displays: Action-based consolidation categorizes events based on entry points, such as page
calls, button clicks, web service calls, or some other action representing a particular process. Value: This
grouping is valuable for determine under what circumstances a failure occurs.
Exception Class What it displays: The bottom level exception thrown by each event is the same. Value:
Consolidating by exception class is a good way to find the most typical coding mistakes and promotes
improved coding practices.
Failed Function What it displays: The exception occurred in the same function for each event. Value: This
grouping is valuable for two reasons: First, it allows you to identify cases where a shared function is used
incorrectly. Second, it allows you to identify how many applications are impacted by an error in a shared
function.
None This option does not group the events.
Grouping Performance Events
Problem What it displays: All events in this grouping have the identical call stack. Value: Consolidating
events by problem allows you to prioritize your efforts to correct an issue based on the number of events in
the group.
Heaviest Resource What it displays: All events triggered by the same resource call. This grouping is
valuable for determine which events exceeded their thresholds more than other resources.
None This option does not group the events.
Example: Grouping Application Errors by Exception Class

Filtering by application errors and exception class quickly shows you which kinds, or classes, of exception events
you are receiving most often.
2. In the Navigation pane, in the Search for menu, select Application Errors.
3. In the Group By menu, select Exception Class.
4. To sort by count, at the top of the Count column, click Count. The exception classes that have occurred most
often are ranked from highest to lowest.
5. To begin investigating the issue and open Event properties, click an Exception Class entry. For information
about working with events, see Working with events by using Application Diagnostics
Example: Grouping Application Errors by Failed Function

Filtering by application errors and failed function quickly shows you which functions are failing most often. The
functions that are failing the most are the ones you should investigate first to have the highest impact on your
application's reliability.
1. In the navigation pane, in the Search for menu, select Application Errors.
2. In the Group By menu, select Failed Function.
3. To sort by count, at the top of the Count column, click Count. The functions that have failed most often are
ranked from highest to lowest.
4. To begin investigating the issue and open Event properties, click a Failed Function entry. For information
about working with events, see Working with events by using Application Diagnostics
Example: Grouping Performance Events by Heaviest Resource

Filtering by application errors and exception class quickly shows you which performance events are triggered by
the same resource call. The performance events that are most often triggered by the same resource call are the
ones you should investigate first to have the highest impact on you application's performance.
1. In the navigation pane on the left, in the Search for menu, select Performance.
2. In the Group By menu, select Heaviest Resource.
3. To sort by count, at the top of the Count column, click Count. The exception classes that have occurred most
often are ranked from highest to lowest. You can also sort by average duration and maximum duration to
see if some events that are occurring less often are still causing long delays and therefore should receive
your attention.
4. To begin investigating the issue and open Event properties, click a Heaviest Resource entry. For
information about working with events, see Working with events by using Application Diagnostics
Next steps
Review prioritizing alerts by using Application Advisor to learn how to prioritize and manage which alerts to
address find out and where the most events are occurring.
Review viewing and investigating alerts for .NET applications to learn how to view alerts and begin
investigating the issues raised.
Working with events by using Application
Diagnostics
10 minutes to read
Working with alerts is a standard part of working with System Center - Operations Manager. Alerts for .NET
application monitoring show you the information you will recognize from other alerts, such as the general
information and product knowledge. However, a .NET application alert also provides a link in the alert
description. This link opens the event that raised the alert in Application Diagnostics. Here you can see far more
information that will help you troubleshoot and identify your problem and solution.
NOTE
Deep troubleshooting of alerts from Application Performance Monitoring often requires access to the application source
code and might require input from developers. You can install the Team Foundation Server Work Item Synchronization
Management Pack and forward alerts to Team Foundation Server used by the development team. The Team Foundation
Server Work Item Synchronization Management Pack tracks and synchronizes changes made to Team Foundation Server
work items and changes made to associated Operations Manager alerts.
Investigating .NET Application alerts

Decreasing the time it takes to determine, assign, and resolve issues is the central goal of application monitoring
in Operations Manager. When you receive an alert, you need to know what caused it - the system hosting the
application or the code, be able to show the data to back up that conclusion, and clearly see who should fix the
problem. To know if it is a system issue, you need to know the state of your system at the time of the event. To
know where the root problem occurred, you need to know the chain of calls that occurred. To further investigate
you need to compare similar events and related events that happened at the same time. Together, the event
details, performance counters, and distributed chains will help you triage who should look at this problem first. If
it is a system error you can adjust the available resources or configuration of the host system and address the
issue at the host level. If it is an application failure, the problem will need to go to the application team along with
the line of code where the failure occurred. Here are some strategies for using the views, filters, and settings in
Application Diagnostics to help you get to the root cause, find a resolution, and better know who needs to be
involved to fix the problem.
Open Application Diagnostics from an alert
1. Since you are responding to alerts related to specific application groups that you configured, it is helpful to
scope active alerts and view them by application group. In the Operations console, in the navigation pane,
select Monitoring, expand Application Monitoring.NET Monitoring, click the folder with the name of
the application group you configured for monitoring whose alerts you want to investigate, and then click
Active Alerts.
2. Double-click the alert you want to open.
3. On the Alert Properties page, click the link in the Alert Description pane. This opens Application
Diagnostics, a new monitoring feature in Operations Manager in a web browser. Here on the Event
properties tab you can see information, such as the performance metrics, the call stack, and collection
notes about the alert. Using the tabs, you can see similar events, related events, event chains, and
performance counters. This is detailed information about the performance or exception event that was
raised for the application that will help you diagnose whether the issue is coming from the application
itself, a call to a web service, or a call to a database. For more information on the Event properties tab, see
Performance Event Details. Click Yes to close the main window once the event information has loaded.
NOTE
This link to Application Diagnostics is also on the on the Alert Context tab.
Use the following procedures to investigate your alert. IT Pros will most likely want to use information on the
Event properties, Performance counters, and Distributed chains tabs to find out what happened, understand if a
system issue caused the problem, and investigate where the root cause occurred. Developers will most likely need
to use the information on the Distributed chains, Similar events, and Related events tabs to understand the
specific context around a code problem.
Troubleshoot by using Exception Event properties in Application Diagnostics
1. In the Application Diagnostics window for the exception alert you are investigating, click the Event
properties tab to view key details about the alert. This is the first place to check to see if the alert problem
is apparent. Some of the key categories of information you will see on the Event properties page are as
follows:
Source To display the application load and response times, click the Source link in the upper-left
corner. This information shows the load the system was under in the context of the exception event
failure. To view performance counters and further assess system state, on the Source page, click the
Trend reports tab. To see which computers this application is working on and see if there might be
a load balancing problem across computers, click the Computers tab. To see a breakdown of related
calls, or where the events are happening based on chains, click the Topology tab.
Exception Chain This displays for exception events. Expand Exception Chain to view the actual
exception that occurred.
Exception Data This displays for exception events and shows parameters and variables set for the
class through the exception.
Stack This is the call stack, or order in which things happened. The Execution Tree View allows you
to expand nodes to investigate the calls. Click the Resource Group View radio button to display an
overview of where time was spent. This answers which tier the problem is in, or where is it
occurring.
Modules List This displays for exception events and shows modules loaded at time of exception.
Collection Notes This displays any notes about the event.
TIP
Use the same troubleshooting steps for Performance events, Similar events, Related events, Distributed chains, and
Performance counters as you did for Exception events.
Troubleshoot by using Performance Event properties in Application Diagnostics

1. In the Application Diagnostics window for the performance alert you are investigating, click the Event
properties tab to view key details about the alert. This is the first place to check to see if the alert problem
is apparent. Some of the key categories of information you will see on the Performance properties page
are as follows:
Source To display the application load and response times, click the Source link in the upper-left
corner. This information shows the load the system was under in the context of the exception event
failure. To view performance counters and further assess system state, on the Source page, click the
Trend reports tab. To see which computers this application is working on and see if there might be
a load balancing problem across computers, click the Computers tab. To see a breakdown of related
calls, or where the events are happening based on chains, click the Topology tab.
Slowest Nodes This is a list of the slowest nodes in the Execution Tree View and the most likely
cause of the performance issues in the application.
Stack This is the call stack, or order in which things happened. The Execution Tree View allows you
to expand nodes to investigate the calls. Click the Resource Group View radio button to display an
overview of where time was spent. This answers which tier the problem is in-where is it occurring?
Collection Notes This displays any notes about the event.
Troubleshoot the state of the system by using Performance counters
1. To view a table or diagram of key performance counters, click the Performance counters tab.
NOTE
Fifteen minutes of performance data is collected and cached on the monitored system. When a performance or
exception is raised, the performance data is sent back to Operations Manager along with the event.
2. Select the performance counter checkboxes for the performance counters you want to include in your
information, and then click Apply.
3. Use the information in this display to assess the system performance state around the event you are
investigating. For example, if the performance is uniformly slow at the time of the event, then your alert is
likely due to a system performance problem.
Find the root problem by using Distributed chains
1. Click the Distributed chains tab to view the order of calls-the chain of events of which the event is part.
This helps you understand how the event you are investigating was impacted by other events from the
application or related applications.
2. In the Distributed chains view, click one of the calls, or links, in the chain. If there are multiple events for the
same object, the Chaining Wizard will open. This wizard allows you to select possible events to correlate
into a chain of events. To begin the Wizard, click Next.
NOTE
Get the time stamp from the call you select as you will pair this with an event on the next page.
3. The Select Possible Chain Event page, select the event that you want to examine. Ideally it will be the
event with the time stamp that is closest to call you selected in the Distributed Chains view.
4. What you see next depends on the kind of problem you are investigating. For example, if you select a
transaction where a server is not found, you might go to the event properties page for that event. This will
let you pair the server error with the event you were initially investigating. Since it is a server error, you
know that the problem is not on the client side, but server side. You might see a graph of the event you
selected and be able to breakdown a performance event in terms of the page load time.
5. From event properties, click the server-side call, and click the Performance Counters tab for more details.
Troubleshoot by viewing similar events
1. Click the Similar events tab to see if similar alerts have been thrown more times, which could mean that
there is a problem with the application.
2. There are several ways to filter similar events. Click the Similar by dropdown menu to select how you
want to group the similar events: by problem, action, exception class, or failed function. In the From and To
text boxes, you can set the range of dates from which you want to view the similar events. Use the Similar
events tab to view if similar alerts has been thrown more times, which could mean that there is a problem
with the application.
Filtering by Problem shows you similar events that are of the same type. For example you can see
all similar events where the object reference is not set to an instance of an object. Click the Diagram
View button and you can see the ratio of total number of events for the current problem and the
total number of events from other problems. This information gives you a quick view into the
magnitude of the problem that this particular event has. If many of the current total similar events
have the same problem, it might be a higher priority problem to resolve since it will have high
impact in reducing the number of alerts you receive.
Filtering by Action groups the similar events by aspect: security, performance, connectivity, and
application failure. Click the Diagram View button and you can see the number of similar events by
these aspect categories and more easily see which ones the problem might be related to.
Filtering by Exception class groups the similar events according to how you named them during
configuration. Presumably, these would be names that would help you identify the kind of
exceptions they are, such as System.NullReferenceException class.
Filtering by Failed function groups the similar events by the same function is throwing the
exception. This could mean that there is a problem with the entry point.
Keep in mind that these are all similar events-related by definition-and these filters give you a better idea of
exactly how they are related. So, using the Similar Events filters, you might find that most of your total
events have the same problem as the event you are viewing, that it is a performance problem, that they
belong to an exception class you configured, and that half of the similar events had the same failed
function. Action: The function goes to the developer who needs to update the function code.
Troubleshoot by viewing related events
1. Click the Related events tab to view events that are related by time. These are exceptions correlated with
other events that might give you an insight to the problem.
2. To view the event details of an event in the list, click the link in the Description column.
In the related events you might notice that response time is very slow for all events during a certain time.
This could indicate a problem with the system, not the code, and so it might be redirected to the IT pro for
a solution.
Next steps
Review viewing and investigating alerts for .NET applications to learn how to view alerts and begin
investigating the issues raised.
Prioritizing alerts by using Application Advisor
6 minutes to read
Application Advisor works with .NET Application Performance Monitoring in System Center - Operations
Manager and helps you prioritize and manage which alerts to address. It identifies which applications are causing
the most alerts within an environment. These are the applications you should investigate first because they are
causing the most service level agreement (SLA) violations. Use Application Advisor as a first step in alert
management and as a view into the overall health of an application. Essentially, Application Advisor helps you
"follow the noise" and find out where the most events are occurring. Application failure and analysis reports let
you view those individual applications in fine detail. Summary reports give you key information at a glance, such
as the top-five alerts to resolve.
Scope and run an Application Advisor report
1. Application Advisor and Application Diagnostics are installed along with the Operations Manager web
console. To find the web address of the Operations Manager web console, open the Operations console. In
the navigation pane, select Administration, click Settings, and then double-click Web Addresses. The
Operations Manager web console URL will be specified as: http(s)://<web host>/OperationsManager . Using
this URL format and the same web host, here are the links to Application Advisor and Application
Diagnostics:
The Application Advisor console address is: http(s)://<web host>/AppAdvisor
The Application Diagnostics console address is: http(s)://<web host>/AppDiagnostics
To make access easy, add all three console URLs to your web browser's favorites list.
To open Application Advisor, paste the Application Advisor URL into your browser. Application Advisor
opens in the web browser window. Different application monitoring reports display in the context of the
application features and services you configured when you created application groups to monitor.
Access to Application Advisor is controlled through the Application Monitoring Operator, Report Operator
and Administrator roles. You must be a member of Application Monitoring Operator and Report Operator
roles or the Administrator role. For more information, see User roles for Application Performance
Monitoring.
Administrator roles. You must be a member of one of these roles to have rights to the console.
NOTE
Application Advisor requires SQL Server Report Services (SSRS). You must have Operations Manager Reporting server
installed before using Application Advisor.
2. In the Navigation pane, in the All application groups dropdown menu, select whether you want reports
to include information for all application groups or a subset of application groups.
NOTE
Application groups are created in the Application Diagnostics console. Use them to create a group of applications to
which you would like to scope your reports. Using many application groups can have a performance impact.
3. In the Select report menu, select how you want to scope the reports, and then click the report you want to
run. You can scope reports by Client-Side Monitoring, Problem Analysis Reports, Resource Utilization
analysis, or choose just one of the individual reports to view.
You can also select a report by clicking on one of the report graphics.
4. Use the Start Date and End Date fields to select the time or date range for the alerts you want included in
the reports.
5. Click the Status text box to filter alerts by those that are New, Reviewed, Deleted, or By Design.
TIP
Viewing alerts categorized as By Design can show you if the way an application is designed is actually causing issues.
6. Click Source dropdown menu to select the application component you want to include in the report.
NOTE
Only applications that are part of the application group you initially selected are available to be used as a source.
7. Click the Computer dropdown menu to select which computer or computers you want reported on.
8. In the Problem dropdown menu, you can filter by all problems detected or only critical problems.
9. Click Apply to save this report configuration and run the report.
Example: To Prioritize Alerts by Using the Problems Distribution

Analysis Report
A first step in working with application monitoring alerts is to try to see which ones you should address first to
have the greatest impact on the applications in your environment. This is the role of Application Advisor - to
identify the applications causing the most alerts and to see the types of alerts being raised. This introduces a
proactive approach to managing application health because you are smartly addressing the most problematic
areas of your applications and not merely reacting to alerts as they arrive.
To show how Application Advisor prioritizes alerts, this walkthrough uses a report that is helpful when first
investigating application issues: the Problems Distribution Analysis report. This report shows the distribution of
application failure, performance, connectivity, and security problems across all monitored applications-and
highlights the applications that are the most problematic. For the applications that contributed to the majority of
problems, this report provides more details by showing application components and external dependencies that
are the root cause of those problems.
Interpret key elements of the Problems Distribution Analysis Report
1. Following the procedure to scope and run an Application Advisor report, choose the information you want
to include in the report, and then click Apply to run the report.
2. Here there are three views that will show top issues:
To view only performance problems and top performance events for the applications, click
Summary Performance Analysis.
To view only exceptions and top exception events for the applications, click the Summary Failure
Analysis link.
You can view all problem types and top problems for the individual application, in the Overall
Source Statistics section. This section shows you what percentage of performance and exception
events are being raised by the application resources, such as function calls or database queries.
3. Click the first link in whichever view you want to investigate. This first link shows the highest cause of alerts
and launches a list of all problems related to that application or source.
IMPORTANT
This is the stage where you shift from a prioritized list to investigating individual alerts related to the most important
issue. None of the events in this list is more important than another, but each can help highlight the route cause.
4. Click a link in Event Description and the Application Diagnostics Event Properties page opens. Here you
are viewing data about the event itself. And this is the place to start troubleshooting. See Working with
events by using Application Diagnostics for more information.
Beginning with Event properties tab, use this and other tabs to discover more about what happened,
whether it was likely a system issue as shown by performance data, and what application tier the problem
occurred in, using distributed chains. Following this information should reveal if it was a system problem or
an application code problem, and thus who should resolve the issue.
Add an Application Advisor report to Favorites

1. If you want to save a report with certain scoped information that you can easily view later, add it to your
Favorites list. In the Select report menu or by clicking the report graphic, select the report you want to run.
NOTE
You can scope the information you want included in the report before making it a favorite or create the scoping
information in the Favorite Management Wizard.
2. In the Results pane, to open the Favorite Management Wizard, click the Favorites icon.
3. In the Favorite Management Wizard, you can either keep the settings you used to scope the information to
be included in your report, reset them, or set them for the first time.
4. As you make or confirm your scoping settings, click Next to proceed through the wizard settings pages,
and then click Finish.
5. In the Favorites namespace, click Favorites and you will be able to view the report you just configured.
6. To view a report in your Favorites, just click the report you want to view.
Next steps
Review Working with sensitive data for .NET applications to understand how to work with sensitive data that
would be collected and be available for viewing by Application Performance Monitoring.
How to configure grooming settings for .NET
Application performance monitoring events
5 minutes to read
When you have been monitoring applications using .NET Application Performance Monitoring (APM ), a new data
type, APM events, will begin to take up space. Eventually, you will want to groom your database for APM events.
Changing the grooming settings for your database for APM events requires the following procedures. You can
groom APM events in three locations:
In Application Diagnostics you can configure grooming settings for APM events in the Operations Manager
Database
In Application Advisor you can configure grooming settings for APM events in the Data Warehouse
Using the Data Transfer rule, you can override parameters related to time-based APM event grooming in
the Data Warehouse
Using Application Diagnostics to configure grooming settings for APM

events in the Operations database
In Application Diagnostics you can select how many APM events you want in the Operations database and how
long you want to keep them.
1. Application Diagnostics is installed along with the Operations Manager web console. To find the web
address of the Operations Manager web console, open the Operations console. In the navigation pane,
select Administration, click Settings, and then double-click Web Addresses. The Operations Manager
web console URL will be specified as: http(s)://<web host>/OperationsManager . Using this URL format and
the same web host, the Application Diagnostics console address is: http(s)://<web host>/AppDiagnostics
To open Application Diagnostics, paste the Application Diagnostics URL into your browser. Application
Diagnostics opens in the web browser window.
NOTE
If you are running Operations Manager on a server rather than a client computer, you can access Application
Diagnostics from the Start menu.
Administrator roles. You must be a member of one of these roles to have rights to the console. For more
information, see User roles for Application Performance Monitoring.
2. In Application Diagnostics, click Tools, select Options, and then click the Data tab.
3. Change the Event data options to define how you want to groom the database, and then click OK.
Using Application Advisor to configure grooming settings for "Deleted"

or "By Design" APM events in Data Warehouse
In Application Advisor you can choose the how long you want to keep APM events that have a Deleted or By
Design status in Data Warehouse.
1. Application Advisor is installed along with the Operations Manager web console. To find the web address of
the Operations Manager web console, open the Operations console. In the navigation pane, select
Administration, click Settings, and then double-click Web Addresses. The Operations Manager web
console URL will be specified as: http(s)://<web host>/OperationsManager . Using this URL format and the
same web host, the Application Advisor console address is: http(s)://<web host>/AppAdvisor
To open Application Advisor, paste the Application Advisor URL into your browser. Application Advisor
opens in the web browser window. Different application monitoring reports display in the context of the
application features and services you configured when you created application groups to monitor.
Access to Application Advisor is controlled through the Application Monitoring Operator, Report Operator
and Administrator roles. You must be a member of Application Monitoring Operator and Report Operator
roles or the Administrator role. For more information, see User roles for Application Performance
Monitoring.
NOTE
Application Advisor requires SQL Server Report Services (SSRS). You must have Operations Manager Reporting server
installed before using Application Advisor.
2. In Application Advisor, click Tools, select Options, and then click the Data tab.
3. Change the Event data options to define how you want to groom the database, and then click OK.
Using the Data Transfer rule to configure grooming settings for APM
events and performance data from the Data Warehouse
The Data Transfer rule lets you override time-based grooming for the Data Warehouse. This rule triggers the Data
Transfer, Aggregation, and Grooming activities related to APM events on the Operations or Data Warehouse
databases. It provides overrides control to the retention settings for APM events in the Data Warehouse database.
WARNING
Disabling this rule or overriding any other setting will have an adverse negative impact on the overall health, functionality,
and consistency of the APM feature, the Data Warehouse, and Application Advisor reports, among other things.
The Operations Manager APM Data Transfer Rule is targeted to the Operations Manager APM Data Transfer
Service object and has two overrides for those settings: for events and for counters. The setting for Events applies
to events that had not been previously marked as "Deleted" or "By Design", for which grooming is controlled by
Advisor, as described in the previous paragraph. If events have been left in status "New", then they will be retained
in the Data Warehouse for as many days as this setting indicates.
The Performance Counter setting is intended for hourly performance aggregations, which potentially can take a lot
of space. There is no configurable setting for daily performance aggregations. The default for this is 182. Typically,
daily aggregations consume a lot less disk space.
To use the Data Transfer Rule to configure grooming settings for APM events in the Data Warehouse
1. In the Operations Manager Operations console, in the navigation pane, select Authoring, click
Management Pack Objects.
2. Click Rules, click Change Scope, click View All Targets, search for Operations Manager APM Data
Transfer Service, and then click OK.
3. Right-click and select Overrides, select Override the Rule, and then select For all objects of class. You
see the Override Properties page.
4. On the Override Properties page, make your changes to Store Event Period and Store Performance
Counters Interval, and then click OK.
Store Event Period lets you determine how many days you want to keep APM events. Store Performance
Counters Interval lets you determine how many days of performance counters you want to keep in Data
Warehouse.
Next steps
To learn more about the default retention period for the different data types stored in the Operations
Manager operational database and how to modify those settings, please see How to configure grooming
settings for the Operations Manager database.
Manager Reporting data warehouse database and how to modify those settings, please see How to
configure grooming settings for the Operations Manager Reporting data warehouse database.
Working with sensitive data for .NET applications
2 minutes to read
Here are some ways to work with sensitive data and .NET Application Performance Monitoring in System Center -
Operations Manager.
Masking sensitive data for .NET applications

Masking sensitive data allows you to use a regular expression to filter out common parameters and insert ** or
some other character in place of the real value. This is used for functions and exceptions where you might capture
sensitive information, such as credit card information, passwords, and other personally identifiable information.
1. To open the .NET Application Performance Monitoring template, in the Operations Manager Operations
console, in the navigation pane, select Authoring, expand Management Pack Objects, click Rules, and
then click change scope in the right-hand side of the information bar to see the current scoping.
2. In the Scope Management Packs objects page, select .NET Application Monitoring Agent to the
current scope, and click OK.
3. To override the Sensitive Data Rules property of the Apply APM Agent Configuration rule, right-click
Apply APM Agent configuration, select Overrides, select Override the Rule, and then select For all
objects of class: .NET Application Monitoring Agent.
4. On the Override Properties page, in the Override-controlled parameters section, select Sensitive data
rules.
5. In the Sensitive data rules row, in the Override Value column, enter the formula for the mask you want to
apply, using the syntax
<Hidden><Expression>((pwd|password)=?)[^;]*</Expression><CompareExpression>((pwd|password)=?)[^;]*
</CompareExpression><Replacement>$1*****</Replacement><Type>all</Type></Hidden>
, where the <Expression> and <CompareExpression> use regular expression syntax and <Replacement>
defines the characters to use when masking out the actual value of the parameter.
6. In the Management Pack section, select an existing management pack or create a new one where the
override will be stored.
7. Click OK.
Avoid Collecting Sensitive Data

If you do not want to capture this sensitive information at all, here is how to avoid it. Some applications will pass
sensitive information embedded in the exceptions raised or parameters collected. To avoid the sensitive
information, you can disable monitoring for specific methods and restrict collection of specific exceptions. To do
this, you disable parameter collection of a method or you disable collection of exceptions thrown from specific
namespaces or classes.
Disable parameter collection of a method
console, in the navigation pane, select Authoring, click Management Pack Templates, click .NET
Application Performance Monitoring, right-click the application group you want to modify, and then
click Properties.
2. On the What to Monitor tab, select the application component you want to change and click Customize.
NOTE
Methods can also be defined at the application group level and be applied to all application components. To do this,
follow the same steps after clicking the Advanced Settings button on the Server-Side Defaults tab.
3. On the Modifying Settings page, click Set Methods. Specify the method name for the function where
you want to disable parameter collection, and then clear the Collect function parameters checkbox.
Additionally, if you do not want to continue monitoring this method, clear the Enable monitoring
checkbox.
4. Click OK.
Disable collection of exceptions
console, in the navigation pane, select Authoring, click Management Pack Templates, click .NET
Application Performance Monitoring, right-click the application group you want to modify, and then
click Properties.
3. On the Advanced settings page, click Exception Tracking.
4. On the Exception tracking list page, click Add, enter the namespace or class where you want to stop
collecting exceptions, and then clear the Enable monitoring checkbox.
5. Click OK.
Monitoring Java applications
5 minutes to read
Java Application Performance Monitoring (APM ) in System Center - Operations Manager lets you monitor Java
applications to get details about application performance and exception events that can help you determine the
root causes of problems. The System Center Management Pack for Java Application Performance Monitoring lets
you monitor Java application performance and exception events by using Operations Manager Application
Advisor. With Operations Manager Application Advisor, you can investigate method and resource timing for
performance events, stack traces for exception events, Java-specific counters for events (such as Average Request
Time, Requests Per Second, JVM Memory, and Class Loader), and run some of the standard Application
Performance Monitoring reports. Additionally, you get Operations Manager level alerting on Java application
server counters. Download the Management Pack for Java Application Performance Monitoring from the
Microsoft Download Center.
Java Application Performance Monitoring shares many concepts with .NET Application Performance Monitoring.
However, there are some important differences, including: object hierarchy, the method for working with overrides
and alerting (Java Application Performance Monitoring has no authoring and configuration template, so you
change configurations with management pack overrides), and sever-level information is not handled in Java
Application Performance Monitoring reports.
Supported configurations
The Management Pack for Java Application Performance Monitoring requires Windows Server 2012 R2 and
Operations Manager.
Supported configurations:
Tomcat 5, Tomcat 6, and Tomcat 7
Windows
Linux
Java JDK 5, Java JDK 6
Web Technologies
GenericServlet
Struts
Struts2
Axis2
Prerequisites
To run the Management Pack for Java Application Performance Monitoring, you must have the Management Pack
for Java Enterprise Edition (JEE ) configured for deep monitoring. This management pack monitors JEE application
servers and provides initial application level discovery. For more information, see How to Configure Monitoring
for Java Applications and the Management Pack Guide for JEE for your particular type of application server,
available on the Microsoft Download Center.
How to monitor Java applications
When you have a new Java application that you are learning about, you use Java Application Performance
Monitoring to get baseline measures before you gradually scale up deployment. Here are some settings to start
with that helps you get to know your new application. In addition, it is ideal that you begin monitoring in a test or
development environment to establish a baseline configuration before implementing in production.
Monitoring settings for a new application

Following this strategy for monitoring a new Java application will help you get to know how the application
behaves within your environment and for your customer.
Start monitoring with a simple monitored system and short-term settings
First, keep the configuration simple: monitor one application on one server. Second, when you first configure Java
Application Performance Monitoring to monitor a new application, plan to keep the settings you implement long
enough for you to understand some trends. A day's worth of data should provide you with insight into the
performance and usage patterns of the application.
Establish baseline performance using default settings and some specific settings
Usually, you will want to keep default settings. The default settings ensure that you will see any large issues with
the application and keep the impact on the monitored application at a minimum.
If you are not getting any performance or exception events raised, you can use the following steps to get a feel for
what the baseline performance looks like.
To begin monitoring, here are some settings you might want to adjust as noted here:
Lower the thresholds for performance. This helps you establish a baseline performance measure by seeing
what the current performance characteristics of the application are. For more information about
performance thresholds, see How to Configure Monitoring for Java Applications.
Examine all exceptions. You need to know what kinds of exceptions are being thrown. Using known
exception handlers limits the exceptions you will receive.
This can result in signifcant data, more than you would want for long-term monitoring. Initially, this amount of
data will be helpful as you will see trends, such as the kinds of paths customers are taking through the system and
what normal performance looks like.
With the data collection complete, use the Application Advisor reports, such as Application Performance Analysis,
to see how the monitored applications are looking. Using the report you will see what the average duration is for
the heaviest (longest running) calls through the system as well as the maximum amount of time spent processing
requests. This allows you to set customized smart thresholds based on real application performance. You will also
see which functions are running faster than others, and you can create specific web page, web method, and
function transactions for the critical methods so that you can ensure they are responding under a tighter SLA than
the application as a whole. For more information on viewing reports, see how to scope and run an Application
Advisor report in Prioritizing Alerts by Using Application Advisor.
Adjust settings and compare to the baseline
Once you have established a baseline performance measure, begin to adjust the settings to tune the monitoring so
it catches the kinds of exceptions that are being raised. By reporting all exceptions, you will see if there are any
default exception handlers in the application that are catching exceptions for which you would prefer receiving
alerts. The data you get will be more meaningful and lower in volume with each adjustment.
Remove the custom settings and set thresholds based on the data collected.
Add exception handlers for any application level "catch all" handlers that keep exceptions from going
outside the application.
Add specialized transactions to monitor the performance of common methods that should be held to a
stronger SLA than the application as a whole.
Compare the new data to your baseline. You will begin to see the real average response time, for instance. Now
that you know the various performance exceptions the application is sending, you can add the specific namespaces
you want rather than monitoring all namespaces. Your application will be configured to be monitored based on the
observed performance levels and will be alerted if things move outside of normal levels.
Gradually deploy the application to more monitored servers
After monitoring the application for a time with the new monitoring configuration, when you feel your application
is healthy, increase the number of servers you are running the application on and monitoring from one to 10, for
example. Once you have it running healthy at that level, increase the deployment and monitoring to more servers,
and so on. This gradual rollout approach will help you gain confidence in the monitoring for that application and
help ensure the health of your system.
What the operator can do with this information
Using this basic information, the operator can have a better idea where the problem is with the application or with
the infrastructure and know whether it is something only to the development team can fix or the operator can
address directly.
Next steps
For details about configuring monitoring of Java applications, see How to Configure Monitoring for Java
Applications.
How to Configure Monitoring for Java applications
5 minutes to read
Getting started with monitoring Java applications requires these four general steps:
1. Import and configure the Management Pack for Java Enterprise Edition (JEE )
2. Import the Management Pack for Java Application Performance Monitoring
3. Manually deploy the Java Application Performance Monitoring Agent
4. Verify the Java Application Performance Monitoring Agent deployment
Import and configure the management pack for Java Enterprise Edition
1. Import and configure the Management Pack for Java Enterprise Edition (JEE ), including installation of
BeanSpy application. Java Application Performance Monitoring will not work without the JEE management
pack configured and BeanSpy installed.
IMPORTANT
Although the Management Pack for JEE supports several types of application servers, Java Application Monitoring
only supports Tomcat.
Download the Management Pack for JEE and the Management Pack Guide for JEE. This management pack
monitors JEE application servers and is available for IBM WebSphere, Oracle WebLogic, Red Hat JBoss,
and Apache Tomcat. Go to the System Center Management Pack for Java Enterprise Edition (JEE ) on the
Microsoft Download Center, click Download, and then select the files you want to download. For example,
select the management pack (SC2012OM_JEE_MP.msi) and select the Management Pack Guide for Tomcat
(OpsMgr_MP_Tomcat.docx).
IMPORTANT
Make sure to download the corresponding management pack guide (.docx file) for the application server you are
using. It contains the details of how to install the management pack and describes what is monitored.
The System Center Management Pack for Tomcat, for example, allows an IT administrator to monitor the
health of JEE application server instances in Operations Manager. In addition, it provides the option to
deploy BeanSpy, an open source technology from Microsoft, that provides deeper monitoring, which
includes memory usage.
2. After the management packs for the JEE application servers are imported, the instances of Tomcat
application servers will be automatically discovered. The discovery interval is set to 4 hours by default, so
discovery can take up to that length of time. On Tomcat, an application server must be running for
Operations Manager to discover it for the first time. After an instance of an application is discovered, the
configuration is removed only when the application server is uninstalled.
To monitor instances of the Tomcat Application Server, in the Operations console, click Monitoring,
expand Application Monitoring, expand Java Monitoring, expand JEE Application Servers, expand
Tomcat Application Server, and then select the monitoring folder you want. For details, see the
Management Pack Guide for Tomcat or the management pack guide for JEE monitoring that you chose to
download.
3. Follow the procedure to deploy BeanSpy to an application server. BeanSpy is an open source technology
from Microsoft that relies on Java Management Extension (JMX) to enable the monitoring pack to get
detailed information from the application server instances.
4. Using instructions in the Management Pack Guide for JEE, follow the procedure to enable deep monitoring
mode.
Import the management pack for Java Application Performance Monitoring
1. Now that the Management Pack for Java Enterprise Edition is imported and configured and BeanSpy
deployed, import the Management Pack for Java Application Performance Monitoring. Download the
management pack from the Microsoft Download Center.
2. The Management Pack for Java Application Performance Monitoring (JavaAPMManagementPack.msi)
contains these files:
Microsoft.JEE.APM.Library.mpb
Microsoft.JEE.Tomcat.APM.Library.mp
Microsoft.JEE.Tomcat.5.Apm.mp
Import these library management packs:
Microsoft.JEE.APM.Library.mpb
Microsoft.JEE.Tomcat.APM.Library.mp
3. Import the management packs for the versions of the Tomcat application servers that you are monitoring.
Manually deploy the Java Application Performance Monitoring agent and enable Java Application Performance
Monitoring
1. Now that you have configured the Management Pack for Java Enterprise Edition (JEE ) through deep
monitoring and imported the Management Pack for Java Application Performance Monitoring, you are
ready to manually deploy the Java Application Performance Monitoring agent. To see application servers
you have configured for monitoring, in Monitoring, click Configurations.
2. To enable Java Application Performance Monitoring, in the Monitoring pane, in the Tasks pane, click
Deep Monitored Configurations, and then select a deep monitoring application server.
3. After you select an application server to enable Java Application Performance Monitoring on, in the Tasks
pane, in Monitored application server instance Tasks, click Extract APM Jar files. This extracts the
Java agent files to either the monitored machine (when a server is running Windows), or to the gateway or
management server (when a server is running Linux). The Task output tells you which machine the files
have been extracted to and where they were extracted. For more information, see the Management Pack
Guide for Java Application Performance Monitoring.
4. Next, reconfigure the Java application server. To enable Java Application Performance Monitoring, specify
command line options that use Jar file as class loader and then restart the application. Another discovery
after you install the agent enables Application Performance Monitoring.
Verify Application Performance Monitoring agent deployment and override monitors
1. To verify if Application Performance Monitoring is monitoring an application, right click an application and
you can see a list of counters: Monitored Requests/sec, Average Request Time, Performance Events/sec,
Exception Events/sec, and, importantly, values for each counter. Five monitors apply to these. For more
information about monitors, see the Management Pack Guide for Java Application Performance
Monitoring.
IMPORTANT
If you do not see values for the counters, Application Performance Monitoring is not enabled for these applications.
This means that you might need to wait for Application Performance Monitoring discovery.
2. To see monitors, in Health Explorer, right-click an application, click Open, and then click Performance
View. Some monitors some are disabled.
3. To override monitors, in Health Explorer, right-click a monitor and click Monitor properties. On the
monitor's Properties page, click Overrides tab, click Override and then select the rule you want to
override. On the Override Properties page you can enable/disable monitors and change the monitor
threshold settings.
View events using Application Diagnostics
Like .NET Application Performance Monitoring, you can use Application Diagnostics to view event information for
Java Application Performance Monitoring. For information about opening and using Application Diagnostics, see
Working with the Application Diagnostics Console and Working with Events by Using Application Diagnostics.
Due to the way Java statistics are reported, some of the standard Application Performance Monitoring reports do
not apply to Java Application Performance Monitoring. For instance, you might see NA in some of the report
columns where Java Application Performance Monitoring does not apply. Additionally, due to the way that Java
application containers map to servers, many server-level reports do not have data.
Monitoring networks by using Operations Manager
8 minutes to read
System Center Operations Manager can monitor physical network routers and switches, including the interfaces
and ports on those devices, and the virtual local area networks (VLANs) and Hot Standby Router Protocol (HSRP )
groups that they participate in, as well as firewalls and load balancers. Increased visibility into your network
infrastructure can help you identify failures in critical services and applications that were caused by the network.
For example, you observe an alert informing you that a critical server is unavailable. If you have configured
network monitoring, you would also observe an alert informing you that a port is offline. When you view the
computer vicinity diagram for the server, you see that the unavailable computer is connected to the offline port.
Thus, you can focus on troubleshooting the root cause for the unavailable computers.
Operations Manager can show you how your network is connected to the computers you are monitoring through
the Network Vicinity View dashboard. Using Network Vicinity View, you can see how your topology is laid out, as
well as the health of each network device, computer, and the connection between each.
Operations Manager can discover and monitor network devices that use the Simple Network Management
Protocol (SNMP v1, v2c, and v3. For a complete list of supported devices, see Network Devices with Extended
Monitoring Capability spreadsheet. The devices worksheet includes processor and memory columns for each
device to indicate whether Operations Manager can provide extended monitoring for either or both aspects for
each device.
System Center 2016 - Operations Manager introduced a Network Monitoring Management Pack generation tool
to help you create a custom management pack to add extended monitoring support for new network devices,
without the need of Microsoft device certification. Additionally, this tool enables you to add monitoring of
additional device components such as fan, temperature sensor, voltage sensor and power supply. You can
download the tool and user guide from the Microsoft Download Center. This tool is also supported with newer
releases of Operations Manager.
Network device monitoring capabilities and scope

Operations Manager provides the following monitoring for discovered network devices:
Connection health - Based on looking at both ends of a connection
VLAN health - Based on health state of switches in VLAN
HSRP group health - Based on health state of individual HSRP end points
Port/Interface
Up/down (operational & administrative status)
Volumes of inbound/outbound traffic (includes abort, broadcast, carrier sense, collision, CRC rates,
discard, error, FCS error, frame, giants, runts, ignored, MAC transmit/receive error, queue rates)
% Utilization
Drop and broadcast rates
NOTE
Ports that are connected to a computer are not monitored; only ports that connect to other network devices are
monitored. You can monitor a port that is connected to a computer that is not agent-managed in the same
management group by adding the port to the Critical Network Adapters Group.
Processor - % Utilization (for some certified devices)

Memory - including high utilization, high buffer utilization, excessive fragmentation, and buffer allocation
failures (for some certified devices)
In-depth memory counters (Cisco devices only)
Free memory
NOTE
Some monitoring capabilities are disabled by default. For more information, see How to configure monitoring of network
devices.
Operations Manager supports monitoring of the following number of network devices:

2000 network devices (approximately 25,000 monitored ports) managed by two resource pools
1000 network devices (approximately 12,500 monitored ports) managed by a resource pool that has three
or more management servers
500 network devices (approximately 6,250 monitored ports) managed by a resource pool that has two or
more gateway servers
Required management packs

Network discovery and monitoring requires the following management packs, which are installed with
Operations Manager:
Microsoft.Windows.Server.NetworkDiscovery
Microsoft.Windows.Client.NetworkDiscovery
There are additional management packs that are required to relate network devices to each other and to the agent
computers they are connected to. Network monitoring requires discovery of the network adapter for each agent
computer, which is performed by the management pack for the agent computer's operating system. Verify that the
management packs from the following list are installed for each of the operating systems in your environment.
Windows Server 2003, 2008, 2008 R2, 2012, and 2012 R2 Operating System
Windows Client 2000/XP/Vista/Windows 7 Operating Systems
Windows 8 and 8.1 Client Operating System
Windows 10 Client Operating System
How Network device discovery works

Network device discovery is performed by discovery rules that you create. For instructions on creating a
discovery rule, see How to discover network devices in Operations Manager and How to configure network
device discovery settings.
When you create a discovery rule, you designate a management server or gateway server to run the rule. Each
management server or gateway server can run only one discovery rule. You may need to strategically place
management servers on different network segments so that they can access the network devices that they are
discovering.
Discovery rules run on a schedule that you can specify, and you can also run a rule on demand. Each time the
discovery rule runs, it attempts to find new devices within its definition or changes to devices that were previously
discovered. A discovery rule can perform explicit discovery or recursive discovery.
Explicit discovery - An explicit discovery rule will only attempt to discover those devices that you explicitly
specify in the wizard by IP address or FQDN. It will only monitor those devices that it can successfully
access. The rule will attempt to access the device by using ICMP, SNMP, or both depending on the
configuration of the rule.
Recursive discovery - A recursive discovery rule will attempt to discover those devices that you explicitly
specify in the wizard by IP address, as well as other network devices that are connected to the specified
SNMP v1 or v2 device and that the specified SNMP v1 or v2 device knows about through the device's
Address Routing Protocol (ARP ) table, its IP address table, or the topology Management Information Block
(MIB ).
If you use recursive discovery, you can elect to discover all the other network devices that the specified
SNMP v1 or v2 device knows about or only network devices that are connected to the specified SNMP v1
or v2 device that are in a specified IP address range. You can also filter recursive discovery by using such
properties as the device type, name, and object identifier (OID ).
NOTE
Operations Manager can identify connected devices in a recursive discovery that use an IPv6 address; however, the
initial device that is discovered must use an IPv4 address.
A discovery rule can perform only explicit or recursive discovery, but cannot perform a combination of discovery
types. You can change the discovery type of a rule after the rule is created. If you know all of the network devices
that you want discovered, you should use explicit discovery. Recursive discovery can discover devices that you
have no business need to monitor and as a result, can increase the administrative workload of monitoring your
network.
A discovery rule can discover any combination of SNMP v1, v2, and v3 devices. SNMP v3 devices can only be
discovered by explicit discovery or by being specified in a recursive discovery rule. If you specify an SNMP v3
device in a recursive discovery rule, the SNMP v3 device will be discovered but devices connected to it will not be
discovered. If you specify an SNMP v1 or v2 device in a recursive discovery rule, only SNMP v1 and v2 devices
connected to it will be included in the recursive discovery.
SNMP trap rules are not supported for SNMP v3 devices.
NOTE
Windows computers running SNMP are filtered out of discovery results if:
The device type is "Host" and the vendor is "Microsoft"
The sysDescription field contains "Microsoft"
The sysOid starts with .1.3.6.1.4.1.311.1.1.3.1
The sysOid contains 1.3.6.1.4.1.199.1.1.3.11
In the discovery rule configuration, you specify whether Operations Manager will use ICMP, SNMP, or both to
communicate with the network device. The network device must support the protocol that you specify. When the
discovery rule runs, Operations Manager attempts to contact the network devices that you specify, using the
protocol or protocols that you specified. If you specify that a device uses both ICMP and SNMP, Operations
Manager must be able to contact the device by using both methods or discovery will fail. If you specify ICMP as
the only protocol to use, discovery is limited to the specified device and monitoring is limited to whether the
device is online or offline.
Credentials are also needed to communicate with the device. You associate each discovery rule with Run As
accounts that supply the community string (for SNMP v1 and v2 devices) or access credentials (SNMP v3) to
Operations Manager. For more information, see Run As Accounts for Network Monitoring in Operations
Manager.
After Operations Manager successfully accesses a specified network device, if you selected recursive discovery, it
attempts to discover other network devices that the specified device knows about through the device's ARP table,
its IP address table, or the topology MIB files.
Network device discovery consists of the following phases, which are displayed in the status of the discovery task:
1. Probing
During the probing phase, Operations Manager attempts to contact device using the specified protocol, as
follows:
ICMP only: ping the device
ICMP and SNMP: contact the device using both protocols
SNMP only: uses the SNMP GET message
2. Processing
After probing is complete, Operations Manager processes all of the components of the device, such as
ports and interfaces, memory, processors, VLAN membership, and HSRP groups.
3. Post Processing
Operations Manager correlates network device ports to the servers that the ports are connected to, inserts
items into the operational database, and associates Run As accounts.
After discovery is complete, the management server resource pool that you specify in the discovery rule begins
monitoring the discovered network devices. For more information on monitoring network devices, see [Viewing
Network Devices and Data in Operations Manager]../om/manage/viewing-network-devices-and-data-in-
operations-manager.md) and Reports for Network Monitoring in Operations Manager.
Next steps
Review Configuring a Firewall for Operations Manager to understand the firewall ports and direction the
communication flows in preparing your environment for network device monitoring with Operations
Manager.
Learn How to discover network devices in Operations Manager.
Review Run As accounts for network monitoring in Operations Manager to understand how to configure
the Run As accounts before configuring the Run As accounts or network device discovery rules.
To view information about the network devices you are monitoring, see Viewing Network Devices and Data
in Operations Manager.
How to discover network devices in Operations
Manager
13 minutes to read
System Center Operations Manager performs network discovery by running discovery rules that you create. Each
time the rule runs, it will attempt to find new devices within its definition or changes to devices that were
previously discovered.
NOTE
Discovery of a large number of devices can take several hours to complete.
Each management server or gateway server can run only one discovery rule. You specify a single management
server or gateway server to run the discovery rule and a management server resource pool to perform the actual
monitoring of the network devices. If you plan to monitor more than 1000 network devices, you should use two
resource pools and split the number of devices evenly between the pools.
NOTE
If you create discovery rules on multiple management servers, you should create a management pool for each and make
sure that each discovery defines a different set of devices. If a single device is managed in different pools, it will not be able
to be deleted.
Prerequisites
To create a network devices discovery rule, you need the following information:
The IP address or FQDN of each device that you want to discover and monitor.
NOTE
Operations Manager can identify connected devices in a recursive discovery that use an IPv6 address; however, the
initial device that is discovered must use an IPv4 address.
The version of SNMP that each devices uses. This can be SNMP v1, v2, or v3.
The SNMP community string of each SNMP v1 or v2 device that you want to discover and monitor.
The user name, context, authentication protocol, authentication key, privacy protocol, and privacy key for
each SNMP v3 device that you want to discover and monitor.
If you are using recursive discovery and you only want to discover network devices that have interfaces
whose addresses fall within a specified IP address range, you must have the IP address range.
The name of the management server resource pool that will monitor the discovered devices.
NOTE
When Network Load Balancing (NLB) is used, the destination MAC address for the network adapter (cluster adapter) uses
the format of 02-BF-1-2-3-4 and the cluster hosts use a format of 02-h-1-2-3-4, where h is the host's priority within the
cluster (set in the Network Load Balancing Properties dialog box). Operations Manager will create a network connection
between the devices using 02-h-1-2-3-4 to the destination MAC address of 02-BF-1-2-3-4.
Firewall configuration
You must ensure the following firewall configuration before creating the network devices discovery rule:
All firewalls between the management server and the network devices need to allow SNMP (UDP ) and
ICMP bi-directionally, and ports 161 and 162 need to be open bi-directionally. This includes Windows
Firewall on the management server itself.
If your network devices are using a port other than 161 and 162, you need to open bi-directional UDP
traffic on these ports.
IMPORTANT
Note for customers who used EMC Solutions for Microsoft System Center Operations Manager: EMC Smarts included tools
to create an isolation layer to prevent denial of service attacks. In System Center - Operations Manager, you need to protect
your network against packet storms by using external tools.
To create a network devices discovery rule

1. Open the Operations console with an account that is a member of Operations Manager Administrators.
2. In the Administration workspace, right-click Administration, and then click Discovery Wizard.
3. On the What would you like to manage? page, select Network devices, and then click Next.
4. On the General Properties page, do the following:
a. In the Name box, type a name, such as My Network Devices.
b. In the Available servers drop-down list, select a management server that has access to the devices
you are discovering to run the discovery rule. Servers that already run a network devices discovery
rule will not be listed.
c. Click Create Resource Pool to create a management server resource pool for monitoring the
devices, or in the Select a resource pool drop-down list, click a resource pool, and then click Next.
5. On the Discovery Method page, select Explicit discovery or Recursive discovery, and then click Next.
NOTE
If you know all of the network devices that you want discovered, you should use explicit discovery. Recursive
discovery can discover devices that you have no business need to monitor and as a result, can increase the
administrative workload of monitoring your network
6. On the Default Accounts page, if you are discovering only SNMP v3 devices, click Next. If you are
discovering any SNMP v1 or v2 devices, do the following:
a. If you previously created Run As accounts for SNMP v1 or v2 devices, the Run As accounts will be
listed and you can select a listed account for this discovery rule. If no accounts are listed or the listed
accounts are not appropriate for this discovery rule, continue to the next step.
NOTE
If you are creating a recursive discovery rule, you must create a default account, which will be used to
connect to and discover devices connected to the device that you specify on the Devices page. If you do not
create and select an account on the Default Accounts page, the recursive discovery will discover the device
that you specify but will not discover devices connected to it.
b. Click Create Account.

c. In the Create Run As Account Wizard, on the Introduction page, click Next.
d. In the Display Name text box, type a name such as Router Credentials.
e. Optionally, type a description in the Description box. Click Next.
f. On the Credentials page, type the SNMP community string for your network devices, and then click
Create.
NOTE
If the rule will discover devices that use more than one SNMP community string, you must create one Run As
account for each SNMP community string.
g. On the Default Accounts page, you will see that the Run As account that you just created is listed
in the SNMPv1/v2 Run As accounts box and is selected. Click Next
7. If you are adding an SNMP v1 or v2 device, on the Devices page, do the following:
NOTE
This procedure describes how to add devices one at a time. You can also add multiple devices by clicking the Import
button to import a text file with a list of IPv4 addresses. This file should have a single IP address on each line. After
import, the IP addresses are part of the discovery rule and the text file is no longer needed.
a. Click Add to open the Add Device page.

b. On the Add Device page, type the IPv4 address or FQDN of the device that you want to discover
and monitor. If you are creating a recursive discovery, the discovery will access this device to locate
other devices on your network.
c. In Access Mode, select ICMP, SNMP, or ICMP and SNMP. This specifies how the device will be
discovered and how it will be monitored after discovery.
NOTE
If you select ICMP and SNMP, the device must be accessible by both protocols or it will not be discovered. If
you select ICMP, discovery will be limited to the specified device, and monitoring will be limited to whether
the device is online or offline.
d. In Port number, retain the default port (161) or select another port number for the device.
e. Select v1 or v2 from the SNMP version drop-down box.
f. In SNMP V1 or V2 Run As account, select Use selected default account. If you specify an
account in this window, then only the specified account will be used for discovery.
NOTE
If you are discovering devices that use more than one SNMP community string and therefore have multiple
Run As accounts, you can retain the default value of Use selected default accounts in the SNMP V1 or V2
Run As account field. When you do this, the Network Devices Discovery Wizard will attempt to use the
community string for every Run As account that you selected on the Default Accounts page against every
device that you add to the discovery list until a community string succeeds.
g. Click OK. This returns you to the Devices page and you should see the device that you just added
listed.
NOTE
The Advanced Discovery Settings button on the Devices page opens a dialog box that contains a number
of settings that you can use to configure discovery of network devices, such as number of retry attempts. If
you know you are going to discover more than 1500 devices, you must change the Maximum number of
devices to discover in Advanced Discovery Settings.
h. Add other SNMP v1 or v2 devices and Run As accounts as necessary, and then click Next.
NOTE
If you add multiple devices to the rule, you can set a common Run As Account for all of them by selecting all
of the devices and then clicking Edit.
8. If you are adding an SNMP v3 device, on the Devices page, do the following:
NOTE
This procedure describes how to add devices one at a time. You can also add multiple devices by clicking the Import
button to import a text file with a list of IPv4 addresses. This file should have a single IP address on each line. After
import, the IP addresses are part of the discovery rule and the text file is no longer needed. Each device requires an
SNMP v3 credential. After you import the addresses, you can edit each device to add the credential or you can select
multiple devices and provide the same credential for all selected devices.
a. Click Add. This opens the Add Device page.

b. On the Add a Device page, type the IPv4 address or FQDN of the SNMP v3 device that you want
to discovery and monitor.
c. In Access Mode, select ICMP, SNMP, or ICMP and SNMP. This specifies how the device will be
discovered and how it will be monitored after discovery.
NOTE
If you select ICMP and SNMP, the device must be accessible by both protocols or it will not be discovered. If
you select ICMP, discovery will be limited to the specified device, and monitoring will be limited to whether
the device is online or offline.
d. In Port number, retain the default port (161) or select another port number for the device.
e. Select v3 from the SNMP version drop-down box.
f. Click Add SNMP V3 Run As Account.
NOTE
Each SNMP v3 device requires its own Run As account.
g. In the Create Run As Account Wizard, on the Introduction page, click Next.
h. Type a value in the Display name box, optionally type a description, and then click Next.
i. On the Credentials page, enter the values for User name, Context, Authentication protocol,
Authentication key, Privacy protocol and Privacy key for the SNMP v3 device. Click Create.
Click OK. This returns you to the Devices page.
j. The Advanced Discovery Settings button on the Devices page opens a dialog box that contains a
number of settings that you can use to configure discovery of network devices, such as number of
retry attempts. If you know you are going to discover more than 1500 devices, you must change the
Maximum number of devices to discover in Advanced Discovery Settings. For more
information on the available settings, see [How to configure network device discovery settings]
(manage-monitor-networkdevice- discovery-settings.md).
k. Add other SNMP v3 devices and Run As accounts as necessary, and then click Next.
9. If you are creating an explicit discovery rule, go to the next step. If you are creating a recursive discovery
rule, do the following:
a. On the Include Filters page, leave the default setting to discover all devices. If you want to filter for
only a particular set of devices, select Discover only network devices within the specific IP
address ranges, and then click Add to configure a filter. Click Next when complete.
In the IP address range field, you can enter addresses such as the following:
10.193.220.25 (a single IP address to include one specific device)
172.23.136<1-100> (include any IP address from 1 to 100 in 172.23.136/255.255.255.0)
172.23.135.\* (include any IP address in 172.23.135/255.255.255.0)
NOTE
For more information on formatting an IP address range, see How to configure network device discovery
settings.
b. On the Exclude Filters page, leave the default setting to not exclude any of the discovered devices.
If you want to filter an IP address from being discovered, click Add and specify an IP address. Click
Next when complete.
NOTE
Although the dialog box states that an IP address or host name can be entered for an exclude filter, only an
IP address is valid. A host name cannot be specified here.
10. On the Schedule Discovery page, either accept the default value of Saturday at 2 AM or specify an
alternate schedule, and then click Next.
NOTE
We recommend that you do not run network discovery more frequently than twice per week because network
discovery can take hours to complete and may place an excessive load on the management server or gateway server
during discovery.
11. Review your settings on the Summary page, and then click Finish when you are ready to proceed.
12. You will see a Warning popup that reads "The following accounts need to be distributed to the health
service management server name in order for the discovery to work: DiscoveryName\Run As Account.
Would you like Operations Manager to distribute the accounts? Yes: Distribute the accounts and create the
discovery. No: Do not distribute the accounts and do not create the discovery." Click Yes.
13. The wizard completes and you see the message The network discovery rule was successfully created.
Ensure Run the network discovery rule after the wizard is closed is selected if you want the rule to run
immediately, and then click Close. The network devices discovery rule is created. If you did not select Run
the network discovery rule after the wizard is closed, the discovery rule will run on the scheduled day
and time.
NOTE
It can take several minutes for the network discovery rule to appear in the Operations console and begin discovery if
you select Run the network discovery rule after the wizard is closed.
14. To monitor the progress of network device discovery, watch the status column of the discovery rule. It will
provide the following statuses while it is running, along with the number of devices that it has located:
a. Probing
During the probing phase, Operations Manager attempts to contact device using the specified
protocol, as follows:
ICMP only: ping the device
ICMP and SNMP: contact the device using both protocols
SNMP only: uses the SNMP GET message
b. Processing
After probing is complete, Operations Manager processes all of the components of the device, such
as ports and interfaces, memory, processors, VLAN membership, and HSRP groups.
c. Post Processing
Operations Manager correlates network device ports to the servers that the ports are connected to,
inserts items into the operational database, and associates Run As accounts.
15. To confirm the successful discovery and management of the devices, select Device Management, and
then select Network Devices. You should see your discovered devices listed in the results pane.
If a network device discovery rule fails, the device or devices will be listed in Network Devices Pending
Management. This can be a subset of the devices specified in the discovery rule. Use one of the following
methods to retry the discovery:
To attempt to discover that specific device only, right-click the device in Network Devices Pending
Management and then click Submit rediscovery.
To retry a recursive discovery that begins with that device, click Discovery Rules, right-click the respective
rule, and then click Run.
To change the discovery type of a network devices discovery rule
1. In the Operations console, in the Administration workspace, click Discovery Rules.
2. In the results pane, right-click the discovery rule that you want to change and click Properties.
3. On the General Properties page, click Next.
4. On the Discovery Method page, click the type of discovery you want the rule to use.
5. Follow the instructions for creating a discovery rule to complete the remaining wizard pages, and then click
Save.
Next steps
To understand how to configure what to monitor and alert with your network devices, see How to configure
monitoring of network devices.
To understand how to stop monitoring a network device, see How to Delete or Restore a Network Device in
Operations Manager.
Network device discovery settings
6 minutes to read
System Center Operations Manager offers a number of settings that you can use to configure discovery of
network devices. The following table explains the available settings and how to configure them in the Network
Devices Discovery Wizard.
SETTING LOCATION NOTES
Name or IP address Devices page, Add button Enter either a fully qualified domain
name (FQDN) or an IPv4 address.
Operations Manager can identify
connected devices in a recursive
discovery that use an IPv6 address;
however, the initial device that is
discovered must use an IPv4 address.
Access mode Devices page, Add button Select either ICMP and SNMP, ICMP,
or SNMP. This specifies the protocol
that will be used for both discovery and
monitoring. If you select ICMP and
SNMP, the device must be accessible
by both protocols, or discovery will fail.
SNMP version Devices page, Add button Select either v1 or v2 or v3. SNMP v1
and v2 devices can use the same Run
As account. SNMP v3 devices require a
different format Run As account.
Port number Devices page, Add button The default port is 161. You can change
this value if you are discovering a
network device that uses another port.
Run As account Devices page, Add button The available accounts in the menu are
populated based on your selection in
the SNMP version box. You can create
the appropriate Run As account by
clicking Add SNMPversionRun As
Account.
Number of retry attempts Devices page, Advanced Discovery This setting specifies how many times
Settings button the management server should attempt
to contact the network device before
reporting that discovery failed.
ICMP time-out (in milliseconds) Devices page, Advanced Discovery If you specify ICMP and SNMP or
Settings button ICMP for Access mode, the
management server attempts to
contact the network device by using
ping. The default setting is 1500
milliseconds (1.5 seconds).
SETTING LOCATION NOTES
SNMP time-out (in milliseconds) Devices page, Advanced Discovery If you specify ICMP and SNMP or
Settings button SNMP for Access mode, the
management server attempts to
contact the network device by using
SNMP. The default setting is 1500
milliseconds (1.5 seconds).
Maximum number of devices to Devices page, Advanced Discovery This setting applies during recursive
discover Settings button discovery and sets a limit on the
number of devices to discover. The
default is 1500. If you know you are
going to discovery more than 1500
devices, you must change this setting.
IP address range Include Filters page, Add button, Use this field to limit the recursive
when configuring a recursive discovery discovery to IP addresses that meet the
rule specified criteria. This field uses a
wildcard format.
For example, if you enter 192.168.1.,

the discovery rule discovers devices
that use any IP address between
192.168.1.1 and 192.168.1.255.
If you enter 192.168.1.<1-140>, the

discovery rule discovers devices that
use any IP address between 192.168.1
and 192.168.140.
Included device types Include Filters page, Add button, Any devices that you select are included
when configuring a recursive discovery in the recursive discovery. Clear the
rule selection for any type of device that you
do not want discovered.
Include only network devices with Include Filters page, Add button, If you enter a value here, only devices
the following system attributes when configuring a recursive discovery with a matching name are discovered.
(OIDs) - Name rule This field allows a wildcard format.
the following system attributes when configuring a recursive discovery with a matching OID are discovered.
(OIDs) - Object ID (OID) rule This field allows a wildcard format.
the following system attributes when configuring a recursive discovery with a matching description are
(OIDs) - Description rule discovered. This field allows a wildcard
format.
IP Address or Host Name Exclude Filters page, Add button, Enter either a fully qualified domain
when configuring a recursive discovery name (FQDN), an IPv4 address, or an
rule IPv6 address to exclude from discovery.
You can add multiple IP address
individually.
Wildcard matching for IP address range

Wildcard pattern matching is done from left to right, one character or basic wildcard pattern at a time. The pattern
and the incoming string must match exactly, so for example, the pattern abc does not match the string abcd.
Compound patterns consist of basic patterns separated by an ampersand (&) or a tilde (~). If the first character of
a compound pattern is an ampersand or tilde, it is interpreted as if there were an asterisk at the beginning. For
example, the pattern ~[0-9] matches any string that does not contain a digit. A trailing ampersand can only match
an empty string, and a trailing tilde indicates "except for an empty string."
Spaces are significant characters, and are subject to matching.
The wildcard patterns consist of the following.
CHARACTER DESCRIPTION EXAMPLE
? Matches any single character Example?.com matches Example1.com

and Example2.com, but not
Example01.com
* Matches zero or more characters Example*.com matches example.com,

example1.com, and
examplereallylong.com
[set] Matches any single character in set, or if Ex[abc]mple matches Example, Exbmple,
the first character ^, it matches any and Excmple.
character not in set.
Ex[^abc]mple does not match Example,
A hyphen indicates a range. A caret (^) Exbmple, and Excmple, but does match
not in the first position, and a hyphen ExZmple
in the first or last position has no
special meaning. Ex[0-9] matches Ex followed by a single
digit.
Matches any integer greater than or 10.193.220.<1-25> matches all IP

equal to the non-negative n1 and less addresses between 10.193.220.1 and
than or equal to the non-negative n2. 10.193.220.25 inclusive.
Omitting n1 or n2 indicates no bound
<10-> matches any string of digits
greater than or equal to 10.
<1-10>* Matches any number

between 1 and 10 with an option
following character such as 1, 20x, 5z,
but it does not match 11 since that is
not a number between 1 and 10.
| Alternative matches AB|DC matches either AB or DC
ABC| matches either ABC or an empty

string
|Escape character
\|Escape character for (,), [,], <, and > \$A\$ matches (A)
& And also *NY*ROUTER matches all strings

containing NY and ROUTER
<1-100>&*[02468] matches all even

numbers between 1 and 100.
*A*|*B*&*C* matches strings that

contain either an A or a B, and also a C.
CHARACTER DESCRIPTION EXAMPLE
~ Except 10.20.30.*~10.20.30.50 matches all

hosts on 10.20.30 except for
10.20.30.50.
*Router*~*Cisco*&*10.20.30.<5-10>
matches routers except Cisco routers
with the addresses between 10.20.30.5
and 10.20.30.10.
Configuring a VLAN tag

To differentiate between VLANs, you can configure a tag for a virtual local area network (VLAN ) by editing the
vlan-tag-settings.conf file on each management server that runs a network discovery rule. Vlan-tag-settings.conf is
located in the Operations Manager installation directory in \Server\NetworkMonitoring\conf\discovery.
To configure a VLAN tag
1. On each management server that runs a network discovery rule, open vlan-tag-settings.conf in a text editor.
2. Add the following text to the file. You can use wildcard matching.
config name
match Type type
match Description text to match
settings VLAN_Provisioning_Setting
param Tag tag name
3. Save vlan-tag-settings.conf.
The following is an example of the configuration of a VLAN tag "LDSwitch" to be used for all switches that have a
description that starts with "Cisco":
config LanceSwitch
match Type SWITCH
match Description Cisco*
settings VLAN_Provisioning_Setting
param Tag LDSwitch
Run As accounts for network monitoring in
Operations Manager
2 minutes to read
System Center - Operations Manager uses Run As accounts to discover and monitor network devices. The
information you include in the Run As account enable management servers to communicate with the network
devices. You can monitor devices that use SNMP v1, v2, and v3.
Network devices that use SNMP v1 or v2 require a Run As account that specifies a community string, which acts
like a password to provide read-only access to the device.
Each network device that uses SNMP v3 requires a unique Run As account that provides the following credentials:
User name: Obtained from device configuration.
Context: Name that together with the user name determines the access permissions of a request sent to the
SNMPv3 agent.
Authentication protocol: MD5 for Message Digest 5, SHA for Secure Hash Algorithm, or NONE
Authentication key: String consisting of 1 to 64 characters; required if the authentication protocol is MD5 or
SHA
Privacy protocol: DES for Data Encryption Standard, AES for Advanced Encryption Standard, or NONE
Privacy key: String consisting of 1 to 64 characters; required if the privacy protocol is DES or AES
NOTE
The authentication key and privacy key are masked as you enter them.
You can create the required Run As accounts when you create a network devices discovery rule, or you can create
the Run As accounts beforehand and then select the appropriate account when you create the discovery rule.
Two Run As profiles are created when you install Operations Manager: SNMP Monitoring Account and SNMPv3
Monitoring Account. When you create a discovery rule, the Run As accounts you create for network device
discovery are automatically associated with the appropriate Run As profile.
Next steps
Learn How to discover network devices in Operations Manager.
Operations Manager.
Operations Manager includes several reports that help analyze performance of monitored network devices.
To learn more, see Reports for network monitoring in Operations Manager.
How to delete or restore a network device in
Operations Manager
2 minutes to read
After System Center - Operations Manager has discovered and is monitoring a network device, you might want to
stop monitoring the device because it is being replaced or because there is no business value in monitoring that
particular device or for any other reason. To stop monitoring a device, you can use maintenance mode or you can
delete the network device from the discovery rule. You can also restore a deleted device that was discovered by a
recursive discovery rule.
To delete a device that is the starting point for recursive discovery, you must first delete the discovery rule or
remove the device from the discovery rule.
NOTE
You can identify the discovery rule associated with a discovered network device by right-clicking the device in Network
Devices or Network Devices Pending Management and then clicking Discovery Rule Properties.
If you delete a device that was discovered by a recursive discovery rule, it will be added to the exclude list of the
rule. If you want to have that device discovered and monitored again, you must remove the device from the
Exclude Filters page of the rule's properties and run the discovery again.
To delete a network device discovered by explicit discovery

2. Click Network Devices, right-click the device that you want to delete, and then click Delete.
NOTE
You can select multiple devices to delete.
To delete a network device specified in a recursive discovery rule

2. Open Properties for the discovery rule and remove the device on the Devices page.
To delete a network device discovered by recursive discovery

2. Click Network Devices in Network Management.
3. In the Network Devices pane, right-click a device that was discovered by recursive discovery, and then
select Delete.
4. You will be prompted with a message asking you to confirm that you want to stop monitoring the selected
network device. Click Yes.
5. Click Discovery Rules.
6. Right-click the recursive discovery rule, and then select Properties.
7. Click Exclude Filters.
8. Verify that an exclude filter has been created for the deleted device. This may take a few minutes to occur.
To restore a network device that was deleted from recursive discovery
2. Click Discovery Rules.
3. Right-click the recursive discovery rule, and then select Properties.
4. Click Exclude Filters.
5. Click the network device and then click Remove.
6. Click Summary, and then click Save to save and close the discovery rule.
7. With the discovery rule selected, click Run in the Actions pane to rerun the discovery rule.
Note the status of the rule as it runs and wait until it shows a blank status.
8. Verify that the device is rediscovered. This may take a few minutes to a few hours depending on the
number of devices in the environment. You can view the status of the discovery rule to determine when it
has completed.
Next steps
To understand how to configure what to monitor and alert with your network devices, see How to configure
monitoring of network devices.
How to configure monitoring of network devices
10 minutes to read
System Center Operations Manager includes the following management packs specific to network device
discovery and monitoring:
Network Management - Core Monitoring
This management pack contains monitoring logic for network devices.
Windows Client Network Discovery
This management pack contains discovery rules to set the properties of discovered network adapters
connected to computers running client operating systems.
Windows Server Network Discovery
This management pack contains discovery rules to set the properties of discovered network adapters
connected to computers running server operating systems.
Network Discovery Internal
This management pack contains definitions and rules for discovering network devices.
Network Management Library
This management pack contains definitions for core network device management.
Network Management Reports
This management pack contains reports for network management.
Network Management Templates
This management pack contains templates for authoring network management workflows.
Tuning network rules

The following rules are disabled by default. Using overrides, enable these rules only for the specific device types in
your environment. To view these rules grouped by type, in the Authoring workspace, scope Management Pack
Objects to the network monitoring management packs listed in the previous section, and then click Rules.
RULE DESCRIPTION TYPES

Internal Network Management Internal rule to initiate rediscovery via - Bridge

Discovery Trap Rediscovery trap requests - Call Server
- Card (Multilayer Switch Feature)
- Firewall
- Host
- Hub
- Load Balancer
- Media Gateway
- Network Device
- Node
- Probe
- Relay Device
- Route Switch Feature Card
- Route Switch Module
- Router
- Switch
- Terminal Server
Output Packet Error Percentage Collects the percentage of output - Interface (if-mib dot3)
packet errors - Interface (if-mib ethernet)
- Interface (if-mib netcor)
- Interface (if-mib router)
- Interface (netcor cisco ethernet)
- Interface (netcor if-mib cisco ethernet)
- Interface (netcor if-mib cisco)
- Interface (netcor if-mib MIB2)
- Interface (netcor MIB2)
- Interface (netcor router)
- Network adapter (dot3)
- Network adapter (if-mib cisco)
- Network adapter (if-mib performance)
- Network adapter (if-mib)
- Network adapter (MIB2)
- Network adapter (netcor cisco)
- Network adapter (netcor ethernet)
- Network adapter (netcor if-mib)
- Network adapter (netcor
performance)
- Network adapter (netcor)
- Port (MIB2 Dot3 ethernet)
- Port (netcor if-mib dot3)
Input Broadcast Packets Percentage Collects the percentage of input - Interface (if-mib dot3)
broadcast packets. - Interface (if-mib ethernet)
performance)
Input Packet Error Percentage Collects the percentage of input packet -* Interface (if-mib dot3)
errors - Interface (if-mib ethernet)
performance)
Collision Percentage Collects the rate of Ethernet packet - Interface (if-mib dot3)
collisions - Interface (if-mib ethernet)
Outbound Multicast Packets per Collects outbound multicast packets - Interface (if-mib dot3)
Second per second - Interface (if-mib ethernet)
- Network adapter (if-mib base)
Inbound Unicast Packets per Second Collects inbound unicast packets per - Interface (if-mib dot3)
second - Interface (if-mib ethernet)
- Network adapter (netcor base)
performance)
Outbound Broadcast Packets per Collects outbound broadcast packets - Interface (if-mib dot3)
Second per second - Interface (if-mib ethernet)
Outbound Unicast Packets per Collects outbound unicast packets per - Interface (if-mib dot3)
Second second - Interface (if-mib ethernet)
performance)
Input Packet Discard Rate Collects the percentage of discarded - Interface (if-mib dot3)
input packets - Interface (if-mib ethernet)
performance)
Outbound Bits per Second Collects outbound bits per second - Interface (if-mib dot3)
- Interface (if-mib ethernet)
performance)
Inbound Broadcast Packets per Collects inbound broadcast packets per - Interface (if-mib dot3)
Inbound Bits per Second Collects inbound bits per second - Interface (if-mib dot3)
performance)
Inbound Multicast Packets per Collects inbound multicast packets per - Interface (if-mib dot3)
Interface Utilization Collects the utilization of the interface - Interface (if-mib dot3)
performance)
Output Packet Discard Rate Collects the percentage of discarded - Interface (if-mib dot3)
output packets - Interface (if-mib ethernet)
performance)
Inbound Queue Packets Dropped Collects the number of packets Interface (Cisco Router)
Per Second dropped per second due to the input
queue being full.
Inbound Giant Packets per Second Collects giant inbound packets per Interface (Cisco Router)
second.
Inbound Packets with CRC Error per Collects the number of inbound packets Interface (Cisco Router)
Second per second with CRC errors.
Inbound Packets Aborted per Collects the number of inbound packets Interface (Cisco Router)
Second aborted per second.
Inbound Misaligned Packets per Collects the number of inbound Interface (Cisco Router)
Second misaligned packets per second.
Output Queue Packets Dropped per Collects the number of packets Interface (Cisco Router)
Second dropped per second due to the output
queue being full.
Inbound Runts per Second Collects the number of inbound packets Interface (Cisco Router)
smaller than permitted by the physical
media.
Inbound Packets Ignored per Collects inbound packets ignored per Interface (Cisco Router)
Second second.
Output Packet Queue Drop Collects the number of output packets - Interface (if-mib ethernet)
Percentage discarded because of output queue - Interface (if-mib router)
overflow. - Interface (netcor cisco ethernet)
Input Packet Queue Drop Collects the number of input packets - Interface (if-mib ethernet)
Percentage discarded because of input queue - Interface (if-mib router)
overflow. - Interface (netcor cisco ethernet)
Outbound Non-Unicast Packets per Collects outbound non-unicast packets - Interface (netcor cisco ethernet)
Second per second. - Interface (netcor if-mib cisco ethernet)
performance)
Inbound Non-Unicast Packets per Collects inbound non-unicast packets - Interface (netcor cisco ethernet)
Second per second. - Interface (netcor if-mib cisco ethernet)
performance)
Port Alignment Errors Rate Determines the change in the SNMP Port (Dot3 ethernet)
dot3StatsAlignmentErrorsRate value for
the dot3_Ethernet_Performance_Port
since the last polling.
Port Carrier Sense Errors Rate Determines the change in the SNMP Port (Dot3 ethernet)
dot3StatsCarrierSenseErrorsRate value
for the
dot3_Ethernet_Performance_Port since
the last polling.
Port FCS Errors Rate Determines the change in the SNMP Port (Dot3 ethernet)
dot3StatsFCSErrorsRate value for the
the last polling.
Port Frame Too Longs Rate Determines the change in the SNMP Port (Dot3 ethernet)
dot3StatsFrameTooLongsRate value for
the dot3_Ethernet_Performance_Port
since the last polling.
Port Internal Mac Receive Errors Determines the change in the SNMP Port (Dot3 ethernet)
Rate dot3StatsInternalMacReceiveErrorsRate
value for the
the last polling.
Port Internal Mac Transmit Errors Determines the change in the SNMP Port (Dot3 ethernet)
Rate dot3StatsInternalMacTransmitErrorsRat
e value for the
the last polling.
Tuning alerts for network monitoring

The following monitors that generate alerts are disabled by default. Using overrides, enable these monitors if you
want to receive alerts for the issue.
MONITOR DESCRIPTION TARGETS
Interface Is Flapping Monitors whether the interface link is - BPX Port (Cisco)
switching - Interface
frequently between up and down based - Network Adapter
on SNMP traps received. - Port
- Token Ring Port
- VR Interface
Interface Status Aggregate monitor that rolls up - BPX Port (Cisco)

interface health states - Interface
for Operational Status and - Network Adapter
Administrative Status monitors. - Port
- Token Ring Port
- VR Interface
MONITOR DESCRIPTION TARGETS
High Discard Percentage Aggregate monitor that rolls up discard - BPX Port (Cisco)
percentage health monitors. - Interface
- Network Adapter
- Port
- Token Ring Port
- VR Interface
High Error Percentage Aggregate monitor that rolls up error - BPX Port (Cisco)
percentage - Interface
health monitors. - Network Adapter
- Port
- Token Ring Port
- VR Interface
High Queue Drop Percentage Aggregate monitor that rolls up queue - BPX Port (Cisco)
drop - Interface
percentage health monitors - Network Adapter
- Port
- Token Ring Port
- VR Interface
ICMP (Ping) Monitor Monitors the response of network ICMP IP

devices to ping.
ICMPv6 (Ping) Monitor Monitors the response of network ICMPv6 IPv6

devices to an IPv6 ping.
Collision Rate (Dot3 Ethernet) Monitors the packet collision rate on - Interface
this device - Network Adapter
High Input Broadcast Rate (if MIB Monitors the level of input broadcast - Interface
Dot3 Ethernet Port) packets on this device - Network Adapter
Next steps
Operations Manager.
Viewing network devices and data in Operations
Manager
5 minutes to read
After System Center Operations Manager discovers your network devices, you can view information about the
devices using the following procedures.
IMPORTANT
You must open the Operations console as an Operations Manager administrator to view the dashboard views.
This topic describes the following views:

Network Summary Dashboard View
Network Node Dashboard View
Network Interface Dashboard View
Network Vicinity Dashboard
Network Summary Dashboard view

The Network Summary Dashboard view provides a view of important data for the nodes and interfaces of the
network. A node can be any device connected to a network. Nodes can be switches, routers, firewalls, load
balancers, or any other networked device. An interface is a physical entity with which network connections are
made, such as a port.
Use the Network Summary Dashboard view to view the following information:
Nodes with Slowest Response (ICMP ping)
Nodes with Highest CPU Usage
Interfaces with Highest Utilization
Interfaces with Most Send Errors
Interfaces with Most Receive Errors
Nodes with the Most Alerts
Interfaces with the Most Alerts
You can select a particular node or interface name in the Network Summary Dashboard view and then select
related tasks in the Tasks pane, such as starting the Network Node Dashboard view and the Network Interface
Dashboard view.
To open the Network Summary Dashboard view
1. Open the Operations console, and then select the Monitoring workspace.
2. Expand Network Monitoring.
3. Click Network Summary Dashboard.
Network Node Dashboard view
A node can be any device connected to a network. Nodes can be switches, routers, firewalls, load balancers, or any
other networked device. Use the Network Node Dashboard view to view the following information:
Vicinity view of the node
Availability statistics of the node over the last 24 hours, last 48 hours, past 7 days, or past 30 days
NOTE
Periods of time that were not monitored are counted as available in the availability statistics.
Node properties
Average response time of the node
Processor usage of the node over the last 24 hours
Current health of interfaces on the node
Alerts generated by this node
Alert details
To open the Network Node Dashboard view
3. Click the view for the desired node, such as Switches.
4. Select a node.
5. In the Tasks pane, select Network Node Dashboard.
Network Interface Dashboard view

An interface is a physical entity with which network connections are made, such as a port. By default, Operations
Manager will only monitor ports that are connected to another device that is being monitored. Ports that are not
connected will not be monitored. Use the Network Interface Dashboard view to view the following information:
Bytes sent and received over the past 24 hours
Packets sent and received over the past 24 hours
Interface properties
Send and receive errors and discards over the past 24 hours
Network interface usage percentage
Alerts generated by this interface
Alert details
To open the Network Interface Dashboard view
3. Click the view for the desired node, such as Switches.
4. Select a node.
5. In the Tasks pane, select Network Node Dashboard.
6. In the Health of Interfaces on this Node section, click an interface, and then in the Tasks pane, select
Network Interface Dashboard.
Network Vicinity Dashboard

Use the Network Vicinity Dashboard to view a diagram of a node and all nodes and agent computers that are
connected to that node. The Network Vicinity Dashboard view displays one "hop", or level of connection.
However, you can configure the view to display up to five levels of connection. The diagram displays the health of
the nodes and the health of the connections between nodes.
The vicinity view shows the relation between network devices and the Windows computers and other network
devices that are connected to them. This logic is performed by relating the network adapter on the agent
computer with the network device that it is connected to. Because of this, the network adapter must be discovered
before this association can occur. You can view the discovered network adapters by either creating a new view or
using the Discovered Inventory view to list instances of the Computer Network Adapter class.
NOTE
Because devices that use OSI layer 1, such as hubs, do not have MAC addresses, layer 1 devices will not be connected to
computers in the Network Vicinity Dashboard. The vicinity view will only show connections between layer 1 devices and
layer 2 or 3 devices.
NOTE
Network adapters using NIC teaming will not be identified as "teamed" in the Network Vicinity Dashboard.
NOTE
Virtual machines are associated with the same network device as their host. This version of Operations Manager does not
show a relationship between the two computers.
NOTE
Operations Manager does not display UNIX- and Linux-based devices in the Network Vicinity Dashboard.
To open Network Vicinity view

1. Open Operations console, and then select the Monitoring workspace.
3. Click a node state view, such as Network Devices.
4. In the Tasks pane, click Vicinity Dashboard.
Things to try in the vicinity view:
Select a node or connection to view details for that node or connection in the Details view.
Change the levels of connection to be displayed in the diagram by selecting a new value for Hops in the
toolbar.
To include agent computers in the view in addition to network devices, select the Show Computers check
box.
Select a node in the vicinity view. In the Tasks pane, click the option to launch the Network Node
dashboard.
To change the central device of the view, select a device, and then click Vicinity View.
Next steps
To understand how to configure what to monitor and alert with your network devices, see How to
configure monitoring of network devices.
Operations Manager includes several reports that help analyze performance of monitored network
devices. To learn more, see Reports for network monitoring in Operations Manager.
To understand how to stop monitoring a network device, see How to Delete or Restore a Network Device
Reports for network monitoring in Operations
Manager
2 minutes to read
System Center - Operations Manager provides the reports described in the following table. For more information
on a report, in the Reporting workspace, click the report and view the Report Details.
NOTE
When you first install Operations Manager, it may take several minutes for all report libraries to appear in Reporting.
REPORT DESCRIPTION
Processor Utilization report This report displays the processor utilization of a particular
network device over a period of time.
Memory Utilization report This report displays the percentage of free memory on a
particular network device over a period of time.
Interface Traffic Volume report This report displays the rate of inbound and outbound traffic
that goes through the selected port or interface over time.
Interface Error Packet Analysis report This report displays the percentage of error packets or
discarded packets, both inbound and outbound, for the
selected port or interface.
Interface Packet Analysis report This report displays the types of packets (unicast or
nonunicast) that traverse the selected port or interface.
Custom Performance report This report displays performance counter values.
Port Traffic Volume report This report displays the rate of inbound and outbound traffic
that goes through the selected port or interface over time.
Port Packet Analysis report This report displays the types of packets (unicast or
nonunicast) that traverse the selected port or interface.
Port Error Packet Analysis report This report displays the types of error packets that traverse
the selected port or interface.
Processor Utilization report This report displays the process utilization of a particular
network device over a period of time.
Memory Utilization report This report displays the percentage of free memory on a
particular network device over a period of time.
Next steps
needs.
How to edit settings or requests in a Web application
2 minutes to read
You can use the Web Application Editor to manually create or edit a request in a Web Application Transaction
Monitoring template. For editing a particular request, there is no difference whether the request was created
manually or by capturing a browser session. For detailed information about the properties that you can set for the
request, see Web Application Request Properties.
Edit the settings in Web Application Editor

1. Open the operations console with an account that has Author credentials in the management group.
2. Open the authoring workspace.
3. In the Authoring navigation pane, expand Management Pack Templates, and then click Web
Application Transaction Monitoring.
4. Select the template that you want to edit, and then click Edit Web Application settings.
5. Set the properties of the application and then click Apply.
Edit an existing request in a Web Application

1. In the Web Application Editor, select the request that you want to edit.
2. In the Actions pane, click Properties.
3. Set the properties of the request and then click OK.
4. Click Apply to save the web application settings.
Add a request to a Web application

1. In the Web Application Editor, select the request that you want to edit.
2. In the Actions pane, click Insert Request.
3. Type the URL of the request in the Request URL box.
4. Optionally, set other properties of the request, and then click OK.
Web Application Properties
4 minutes to read
The following sections describe the settings available for a Web Application Transaction Monitoring template
in Operations Manager. You can set the properties of these requests by using the procedure in How to Edit
Settings or Requests in a Web Application.
Ignore server certificate errors

Web application URL monitoring, web application availability and transaction monitoring are used to test a
URL/website/web-based application, by sending WinHttp requests, validating their response, and measuring their
performance.
The Website that is being monitored can be an internal or an external URL. The monitoring is done from a watcher
node computer, on which you need to install the Operations Manager agent. You need to configure the web-based
URL that you want to test (this configuration is written to a custom MP ). The monitoring module establishes and
connects to a HTTP/HTTPS session depending on URL, and then sends a WinHttp request. In releases prior to
Operations Manager 2019, if this send request fails due to a security error, it sets the flags to ignore the server
certificate CN, expiry date, untrusted CA, and incorrect usage, and then retries the send request. This retry ignores
the server certificate errors.
With Operations Manager 2019, web application URL monitoring capability has been improved to not ignore
server certificate errors by default. Send requests will not be retried for the URLs with certificate errors.
However, you can ignore the server certificate errors if you wish to, while monitoring a website. To support this
feature, we have added the option Ignore Server Certificate Errors in the Web Application Editor. To monitor a
website for which there is no valid SSL certificate, select this option.
For existing websites that are being monitored, you can either select this new option on the Web Application
Properties General tab or edit in the management pack. To support this enhancement, schema changes were
made to the URLProbe module. Learn more.
General Tab
Use the General tab to specify the general details of the web application. Available options are explained in the
following table.
ITEM DESCRIPTION
Web Application Name The name of the application that appears in the Operations
console.
Description Optional description of the application that appears in the

Details pane in the Operations console.
Retry Count Number of times to retry connecting to a site if the first

attempt fails.
Ignore Server Certificate Errors When selected, Operational Manager ignores any certificate
errors for the monitored servers. Learn more.
Management Pack The management pack in which the Web Application

Transaction Monitoring template is stored. This cannot be
changed.
Authentication Method Specifies the authentication method to use for the website. If
no authentication is required, select None.
User Account The Run As account to use for authenticating on the site. Only
existing accounts that match the selected authentication
method are listed. For more information about Run As
accounts, see Managing Run As Accounts and Profiles.
Use a proxy server to connect Select this option if the watcher nodes must connect to the
website through a proxy server.
Address The address of the proxy server if one is required.
Port The port for the proxy server if one is required.
Authentication Method Specifies the authentication method to use for the proxy
server. If no authentication is required, select None.
User Account The Run As account to use for authenticating on the proxy
server. Only existing accounts that match the selected
authentication method are listed. For more information about
Run As accounts, see Managing Run As Accounts and Profiles.
The following sections describe the details for each of the tabs in the Web Application Properties window.
Watcher Node Tab

Use the Watcher Node tab to specify the watcher nodes that you want to use for this web application and the
frequency that you want to run the web application. For more information about watcher nodes, see Watcher
Nodes.
Performance Criteria Tab

Use the Performance Criteria tab to enable the Transaction response time monitor for the application to
monitor the transaction time of all of the requests in the browser session. The various options are explained in the
following table.
ITEM DESCRIPTION
Error Transaction Response Time Select this option and provide a criteria and number of
seconds if you want to monitor for a critical state. If the time
to process the complete set of requests matches this criteria,
the monitor is set to a critical state.
Warning Transaction Response Time Select this option and provide a criteria and number of
seconds if you want to monitor for a warning state. If the time
to process the complete set of requests matches this criteria,
and the error criteria is not also true, the monitor is set to a
warning state.
Performance Counter Tab

Use the Performance Counter tab to enable collection of performance counters for the web application. The
various options are explained in the following table.
ITEM DESCRIPTION
Transaction Response Time If this option is selected, then the collective time to process all
the requests in the browser session is collected.
Request Performance Counters Select the performance counters that are collected for the
application. Any selected counters are collected as an
aggregate for all requests in the browser session. Each will also
be added to the list of counters for every request in the
browser session.
Reduction Factor Select to reduce the number of counters selected for the web
application and the requests. It specifies how many query
intervals must be completed before each collection. If the
value is 1, the counters are collected every time the browser
session is run. If it is 2, the counters are only collected every
second time the browser session is run, and so on.
Next steps
Web Application Request Properties
Web Application Request Properties
5 minutes to read
The following sections describe the settings available for each request in a Web Application Transaction
Monitor template in Operations Manager. You can set the properties of these requests by using the procedure in
How to Edit Settings or Requests in a Web Application. Each section in the following sections represents a tab in
the Request Properties window.
General tab
Use the General tab to specify the general details of the request. The different options are explained in the
following table.
ITEM DESCRIPTION
Request URL The URL that you are requesting. You can specify whether the
protocol will be http or https.
HTTP Method The method to use for the request. Most requests use a GET
method. The POST method is typically used when selecting an
option to submit information to a website, such as clicking a
button to submit a name and password.
HTTP Version The version of HTTP that the request specifies to the receiving
website.
Request Body Only enabled when the HTTP method is POST. This is the
body of the request that the post submits.
Insert Parameter There is an Insert parameter button for both the Request
URL and the Request Body. Use these options to replace
part of the text with a variable that is populated from a
previous request. For more information, see How to Replace
Parameters in a URL Request.
HTTP headers tab

The HTTP Headers tab is used to define the different fields that will be included in the header of the request. If the
request is from a recorded session, it includes the headers that your browser used. If you manually created the
request, it includes a default set of headers and values. You can use the Edit button to modify an existing header
field or the Add button to add a new field. The Insert parameter options are used to replace part of the text with a
variable that is populated from a previous request. For more information, see How to Replace Parameters in a URL
Request.
Performance counter tab

The Performance Counter tab lets you select the performance counters that will be collected for the request. Any
selected counters are added to the list of counters specified in the Web Application settings which enable the
counter for an aggregate of all requests in a browser session. The value for any selected counter is collected every
time that the request is made.
Monitoring
Use the Monitoring tab to control certain monitoring settings for the request and to specify the details of the
request that will be collected when one of the monitors enters a warning or critical state. You can view this
collected information in the State Change Events tab of the Health Explorer for the monitor. The different
options are described in the following table.
ITEM DESCRIPTION
Monitor SSL health on secure sites If the request is using https, monitors that measure the health
of the related Secure Sockets Layer (SSL) certificates.
Enable health evaluation and performance collection for If selected, a monitor is enabled that displays the status of the
resources resources for the page. Instead of measuring every resource,
the total of all resources is evaluated. If this option is not
selected, the resource monitor does not function for the
request.
Enable health evaluation and performance collection for Enables the collection of the status of each internal link and
Internal links includes internal links in the evaluation of the Links Status
Code monitor for the request. An internal link is a link that
refers to a location on the same page.
Enable health evaluation and performance collection for Enables the collection of the status of each external link and
External Links includes external links in the evaluation of the Links Status
Code monitor for the request. An external link is a link that
refers to a location outside the current page.
Link traversal Specifies the number of levels of external links to collect. If the
value is 0, only the links on the page itself are evaluated. If the
value is 1, the links on each target page are evaluated. If the
value is 2, the links on those target pages are evaluated, and
so on.
Process response body Specifies whether to evaluate the response body. You must
select this value if you want to use content matching or
parameter extraction for the request to work. You can clear
this option if you only want to perform simple tests for the
page such as monitoring status code and response time.
Response body collection Specifies whether to collect the body of the request response.
Select one of the following options:
Always collect if you want to collect the response body any
time any monitor for the request enters a warning or error
state.
Do not collect if you never want to collect the response body.
Collect on content match criteria if you want to collect the
response body only when the Content Match monitor enters
a warning or critical state.
Collect headers If selected, the header of the request is collected.
Collect link headers If selected, the header of each link is collected.
Collect resource headers If selected, the header of each resource is collected.
Custom error
The Custom Error tab lets you specify error criteria for the request by using information that is not available in the
Request Details pane of the Web Application Editor. You can either provide simple criteria by using a single
metric, or you can use multiple metrics to specify complex logic. Click the Insert button to add a criterion or a
group specifying AND or OR logic. If the criteria that you specify resolve to true when the request is run, the
monitor indicates an error for the web application.
Custom warning
The Custom Warning tab lets you specify error criteria for the request by using information that is not available
in the Request Details pane of the Web Application Editor. You can either provide simple criteria by using a
single metric, or you can use multiple metrics to specify complex logic. Click the Insert button to add a criterion or
a group specifying AND or OR logic. If the criteria that you specify resolve to true when the request is run, the
monitor indicates a warning for the web application.
Extraction rules
The Extraction Rules tab lets you extract a string of text from the body of the response of the request to use in
one or more subsequent requests. For more information, see How to Replace Parameters in a URL Request.
Next steps
Web Application Properties
Linux Log file monitoring in System Center
Operations Manager
9 minutes to read
System Center Operations Manager now has enhanced log file monitoring capabilities for Linux servers by using
the newest version of the agent that uses Fluentd. This update provides the following improvements over previous
log file monitoring:
Wild card characters in log file name and path.
correlation and exclusive correlation.
Support for generic Fluentd plugins published by the fluentd community.
Basic operation
The basic operation of log file monitoring in Linux includes the following steps:
1. Record is written to a log on a Linux agent.
2. Fluentd collects the record and creates an event on pattern match.
3. Event is sent to OMED service on management server.
4. Rules and monitors in a custom management pack collect events and create alerts in Operations Manager.
Overview of configuration
The following steps are required to enable log file monitoring on Linux agents. Each of these steps is described in
detail in the following sections.
1. Import the latest Linux management pack.
2. Install the latest version of the Linux agent on each Linux computer to be monitored.
3. Create Fluentd configuration file to collect logs.
4. Copy configuration file to Linux agents.
5. Create rules and monitors using the sample management pack to collect events from the log and create alerts.
Install the latest version of the Linux agent

The latest version of the Linux agent supports Fluentd, which is required for enhanced log file monitoring. You can
get details and the installation process for the new agent at Install agent on UNIX and Linux from command line.
log file monitoring

In Operations Manager 2019, you must install Microsoft.Linux.Log.Monitoring management pack to enable
Linux log file monitoring.
NOTE
If you have the OMS agent configured, and you try to uninstall UNIX and LINUX agent from the console, then OMS
component will not be uninstalled from the agent.
Configure Linux Log File monitoring
The Linux Management pack bundle has the latest Operations Manager agent (with Fluentd). To configure Linux
log file monitoring, users should perform the following:
1. Import the latest Linux Management pack using the standard process for installing a management pack.
2. Install the new Linux agent on the Linux servers, this can be done through discovery wizard or manually.
3. Enable the OMED service on each management server in the resource pool managing the Linux agents.
The OMED service collects events from Fluentd and converts them to Operations Manager events. Users should
import a custom management pack which can generate alerts based on the events received from the Linux
servers.
You enable the OMED service either from the Operations console or manually on the management server or
gateway server.
From Operations console
1. From the Operations Console, go to Monitoring > Operations Manager > Management Server >
Management Servers State.
2. Select the management server in the Management Servers state pane.
3. In the Tasks pane, select Health Service Tasks > Enable System Center OMED Server.
Manually
1. Click Start, in the Start Search box, type services.msc , and then press Enter.
2. In the details pane, right-click the service System Center Operations Manager External DataSource
Service, and then click Properties.
3. On the General tab, in Startup type , click Automatic, and then click OK.
4. In the details pane, right-click the service and then click Start.
Create FluentD configuration file

You configure Fluentd operation with a configuration file. For log monitoring, you need to create a configuration
file that includes such information as source log file name and path and filters to define which data to collect.
The master Fluentd configuration file omsagent.conf is located in /etc/opt/microsoft/omsagent/scom/conf/.
You can add log file monitoring configuration directly to this file, but you should create a separate configuration
file to better manage the different settings. You then use an @include directive in the master file to include your
custom file.
For example, if you created logmonitoring.conf in /etc/opt/microsoft/omsagent/scom/conf/omsagent.d,
you would add one of the following lines to fluent.conf:
#Include all configuration files

@include omsagent.d/*.conf
or
#include single configuration file

@include omsagent.d/logmonitoring.conf
You can get details on Fluentd configuration files at Fluentd Configuration file syntax. The following sections
describe settings in different directives of the configuration file unique to log file monitoring. Each includes sample
settings that you can paste into a configuration file and modify for your requirements.
A complete sample configuration file for log monitoring is available for you to review and evaluate before creating
your own.
Source
The Source directive defines the source of the data you're collecting. This is where you define the details of your
log file. Fluentd picks up each record written to the source and submits an event for it into Fluentd's routing
engine. You need to specify a tag here in this directive. The tag is a string that is used as the directions for
Fluentd’s internal routing engine to correlate different directives.
This example shows syslog records collected and tagged for processing by Operations Manager.
<source>
# Specifies input plugin. Tail is a fluentd input plugin - http://docs.fluentd.org/v0.12/articles/in_tail

type tail
# Specify the log file path. Supports wild cards.

path /var/log/syslog
# Recommended so that Fluentd will record the position it last read into this file.
pos_file /home/user1/fluent-test/demo_syslog.log.pos
# Used to correlate the directives.

tag scom.log.syslog
format /(?<message>.*)/
</source>
Match
The match directive defines how to process events collected from the source with matching tags. Only events
with a tag matching the pattern will be sent to the output destination. When multiple patterns are listed inside one
match tag, events can match any of the listed patterns. The type parameter that specifies which plugin to use for
these events.
This example processes events with tags matching scom.log.** and scom.alert (** matches zero or more tag
parts). It specifies the out_scom plugin which allows the events to be collected by the Operations Manager
management pack.
<match scom.log.** scom.event>
# Output plugin to use

type out_scom
log_level trace
num_threads 5
# Size of the buffer chunk. If the top chunk exceeds this limit or the time limit flush_interval, a new
empty chunk is pushed to the top of the
queue and bottom chunk is written out.
buffer_chunk_limit 5m
flush_interval 15s
# Specifies the buffer plugin to use.

buffer_type file
# Specifies the file path for buffer. Fluentd must have write access to this directory.
buffer_path /var/opt/microsoft/omsagent/scom/state/out_scom_common*.buffer
# If queue length exceeds the specified limit, events are rejected.

buffer_queue_limit 10
# Control the buffer behavior when the queue becomes full: exception, block, drop_oldest_chunk
buffer_queue_full_action drop_oldest_chunk
# Number of times Fluentd will attempt to write the chunk if it fails.

retry_limit 10
# If the bottom chunk fails to be written out, it will remain in the queue and Fluentd will retry after
waiting retry_wait seconds
retry_wait 30s
# The retry wait time doubles each time until max_retry_wait.

max_retry_wait 9m
</match>
NOTE
To disable Server Auth on the Linux machines that are using Fluentd communication, add a parameter enable_server_auth
false to the SCOM out plugin for Fluentd, such as the following:

type out_scom
max_retry_wait 9m
enable_server_auth false
</match>
Filter
The filter directive has same syntax as match but allows for more complex filtering of which data to process.
Collected events must match the criteria of all filters to be added to the output.
There are six filter plugins for log file monitoring described here. Use one or more of these filters to define the
events that you want to collect from your log file.
Simple match: filter_scom_simple_match
Takes up to 20 input patterns. Sends an event to Operations Manager whenever any pattern is matched.
<filter tag>
type filter_scom_simple_match
regexp1 <key> <pattern>
event_id1 <event ID>
.
.
.
</filter>
Exclusive match: filter_scom_excl_match

Takes two input patterns. Sends an event to Operations Manager when a single record matches pattern 1 but does
not match pattern 2.
<filter tag>
type filter_scom_excl_match
regexp1 <key> <pattern1>
event_id <event ID>
</filter>
Repeated correlation: filter_scom_repeated_cor

Takes three inputs: a patterns, a time interval, and a number of occurrences. When a match is found for the first
pattern, a timer starts. An event is sent to Operations Manager if the pattern is matched the specified number of
times before the timer ends.
<filter tag>
type filter_scom_repeated_cor
regexp <key> <pattern>
event_id <event ID>
time_interval <interval in seconds>
num_occurences <number of occurrences>
</filter>
Correlated match: filter_scom_cor_match

Takes three inputs: two patterns and a time interval. When a match is found for the first pattern, a timer starts. An
event is sent to Operations Manager if there is a match for the second pattern before the timer ends.
<filter tag>
type filter_scom_cor_match
event_id <event ID>
</filter>
Exclusive correlation: filter_scom_excl_correlation

Takes three inputs: two patterns and a time interval. When a match is found for the first pattern, a timer starts. An
event is sent to Operations Manager if there is no match for the second pattern before the timer ends.
<filter tag>
type filter_scom_excl_correlation
event_id <event ID>
</filter>
Operations Manager converter: filter_scom_converter

Sends an event to Operations Manager for all records it receives. Sends the specified event ID and description as
part of the event.
<filter tag>
type filter_scom_converter
event_id <event ID>
event_desc <event description>
</filter>
Copy configuration file to agent

The fluentd configuration file must be copied to /etc/opt/microsoft/omsagent/scom/conf/omsagent.d on all
Linux computers you want to monitor. You must also add an @include directive in the master configuration file as
described above.
Create rules and monitors

The Linux MP does not provide modules to collect events from FluentD. The Linux MP is bundled with the Linux
agent. It is the fluentd module in the Linux agent and the OMED service on the management and gateway server
that provides the capabilities for enhanced log file monitoring.
You need to create your own management pack with custom rules and monitors that use the module
Microsoft.Linux.OMED.EventDataSource which collects the events from Fluentd.
The following table lists the parameters of Microsoft.Linux.OMED.EventDataSource.
PARAMETER TYPE DESCRIPTION
ComputerName String Required. Specifies the name of the

Linux computer for which events to be
read. The ComputerName parameter is
most commonly passed to the module
by using the $Target notation, although
it can be specified as any string. This
module attempts to read events
generated by the given Linux computer.
ManagedEntityId String Required. Specifies the managed entity

ID of monitored entity. The
ManagedEntityId parameter is most
commonly passed to module by using
$Target\Id$.
EventNumber Integer Optional. Indicates the event number of

the event to retrieve. If this option is
omitted, the module returns all events
generated for that computer and
managed entity.
Next steps
To create a custom view to review the monitoring data from your custom log file management pack, review
Using views in Operations Manager.
Review Viewing active alerts and details to learn how to investigate issues identified by your custom log file
management pack.
Sample configuration file for collecting Linux log files
4 minutes to read
This article details a sample configuration for collecting log files from Linux with System Center Operations
Manager version 1801 and later.
Sample configuration
# Have a source directive for each log file source file.
<source>
# Fluentd input tail plugin, will start reading from the tail of the log
type tail
# Specify the log file path. This supports wild card character
path /root/demo/log/demo*.log
# This is recommended – Fluentd will record the position it last read into this file. Change this folder
according to your server
pos_file /home/ user1/fluent-test/demo_simple_match.log.pos
# tag is used to correlate the directives. For example, source with corresponding filter and match
directives.
tag scom.log
reads the fields from the log file in the specified format
</source>
<source>
type tail
# Specify the log file path.

path /var/log/mongodb/mongod.log
# tag is used to correlate the directives.

tag scom.mongo.log
#reads the fields from the log file in the specified format
format /(?<timestamp>[^ ]*) (?<severity>[A-Z]) (?<component>(-|([^ ]*)))\s* \[(?<context>[^\]]*)\] ((?

<query>.*) (?<querytime_ms>[\d\.]+(?=ms))|(?<message>.*))/
</source>
<source>
type tail
# Specify the log file path. This supports wild card character
path /var/log/syslog
# This is recommended – Fluentd will record the position it last read into this file
pos_file /home/user1/fluent-test/demo_syslog.log.pos
# tag is used to correlate the directives. For example, source with corresponding filter and match
directives.
tag scom.log.syslog
</source>
<source>
type tail
# Log file that needs to be monitored

path /var/log/mongodb/mongod.log
# tag to correlate with filter and match directives

tag scom.log.mongo
# reads the following fields from the log file

format /(?<timestamp>[^ ]*) (?<severity>[A-Z]) (?<component>(-|([^ ]*)))\s* \[(?<context>[^\]]*)\] ((?
<query>.*) (?<querytime_ms>[\d\.]+(?=ms))|(?<message>.*))/
#type of the parsed field

types querytime_ms:float
</source>
<filter scom.log>
# new scom fluentd plugin for simple match - Input – Pattern A; Action: log record = A à Send Event
type filter_scom_simple_match
# Input Pattern to look for. In this case looking for Invalid guest user
regexp1 message Invalid user guest
# Event to be generated and sent to SCOM OMED service.

event_id1 6201
# Event description to be sent to SCOM

event_desc Failed login attempt. Invalid User guest attempted to log in
</filter>
<filter scom.mongo.log>
# Standard published Fluentd grep filter plugin,

type grep
# Filters the log record with the match pattern specified here
regexp1 message AuthenticationFailed
</filter>
<filter scom.mongo.log>
# new scom converter fluentd plugin. This plugin converts data from generic fluentd filter plugins to
format acceptable by SCOM
type filter_scom_converter
# Event to be generated and sent to SCOM OMED service.

event_id 6207
# Event description to be sent to SCOM
event_desc MongoDB Authentication Failed
</filter>
<filter scom.log.syslog>
# SCOM filter plugin for exclusive match - 2 Inputs – Pattern A and B; Action: (log record = A & log
record != B) then Send Event.
type filter_scom_excl_match
# Example where user monitors if insertion of a record in MongoDB succeeds.
regexp1 message Insertion of [a-z0-9]*
regexp2 message succeeded
event_id 6206
event_desc Failed to insert a record in MongoDB
</filter>
<filter scom.log.syslog>
# SCOM filter plugin for correlated match - 3 Inputs – Pattern A, B and Timer T; Action:
(log record = A; within T if log record = B) then
send Event.
type filter_scom_cor_match
# User verifies if a particular package installation fails

regexp1 message Starting install of package [A-Za-z0-9]*
regexp2 message Install failed for package [A-Za-z0-9]*
event_id 6210
event_desc Package installation failed
</filter>
<filter scom.log.mongo>
# SCOM filter plugin for Repeated correlation - 3 Inputs – Pattern A, Timer T and Count N; Action: (within
T if log record = A, N number
of times) then send an Event
type filter_scom_repeated_cor
# If a user tries to log into MongoDB using incorrect credentials and authentication fails for 5 times, an
event is generated.
regexp1 message AuthenticationFailed:
num_occurences 5
time_interval 5
event_id 6206
event_desc User Authentication failed 5 times. User had tried to authenticate with incorrect credentials.
</filter>
<filter scom.log.mongo>
# SCOM filter plugin for Exclusive correlation - 3 Inputs – Pattern A, B and Timer T; Action: (log record
= A, within T if log record != B)
then send an Event.
type filter_scom_excl_correlation
# If Mongo DB fails to restart, an event would be sent.

regexp1 message dbexit:
regexp2 message waiting for connections
time_interval 5
event_id 6210
event_desc MongoDB restart failure
</filter>
# output plugin to use – this is a dedicated output plugin for SCOM

type out_scom
log_level trace
num_threads 5
# size of the buffer chunk. If the top chunk exceeds this limit or the time limit flush_interval, a new
empty chunk is pushed to the top of the queue and bottom chunk is written out.
empty chunk is pushed to the top of the queue and bottom chunk is written out.
buffer_chunk_limit 5m
flush_interval 15s
# specifies the buffer plugin to use. Here buffer type used it “file”
buffer_type file
# specifies the file path for buffer. Make sure fluentd has write access to the directory.
buffer_path /var/opt/microsoft/omsagent/scom/state/out_scom_common*.buffer
# If queue length exceeds the specified limit, events are rejected.

buffer_queue_limit 10
# Control the buffer behavior when the queue becomes full – 3 modes supported – exception, block, drop
oldest chunk
buffer_queue_full_action drop_oldest_chunk
retry_limit 10
# If the bottom chunk fails to be written out, it will remain in the queue and Fluentd will retry after
waiting retry_wait seconds
retry_wait 30s
# The retry wait time doubles each time until max_retry_wait.

max_retry_wait 9m
</match>
Next steps
To configure agents to collect log files for monitoring using the configuration file, see Copy configuration file to
agent.
Sample Linux log file management pack
2 minutes to read
This is a sample management pack to create an alert from a log file in Linux with System Center Operations
Manager version 1801 and later. You can copy and paste the contents into an XML file and install in your
Operations Manager management group.
This management pack will create an alert for every collected event. There is another rule in the comments of the
management pack that will only create an alert for events with a specific event number. To use this rule, remove the
comments and replace the event number with one that you require.
<ManagementPack>
<Manifest>
<Identity>
<ID>OMEDEvent</ID>
<Version>1.0.0.1</Version>
</Identity>
<Name>OMEDEvent</Name>
<References>
<Reference Alias="Health">
<ID>System.Health.Library</ID>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="SystemCenter">
<ID>Microsoft.SystemCenter.Library</ID>
</Reference>
<Reference Alias="Windows">
<ID>Microsoft.Windows.Library</ID>
</Reference>
<Reference Alias="System">
<ID>System.Library</ID>
</Reference>
<Reference Alias="Unix">
<ID>Microsoft.Unix.Library</ID>
</Reference>
<Reference Alias="Linux">
<ID>Microsoft.Linux.Library</ID>
</Reference>
</References>
</Manifest>
<Monitoring>

<Rules>
<Rule ID="RuleForAllEvents" Enabled="true" Target="Linux!Microsoft.Linux.Computer" >
<Category>EventCollection</Category>
<DataSources>

<DataSource TypeID="Linux!Microsoft.Linux.OMED.EventDataSource" ID="Rule0DS0">
<ComputerName>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/NetworkName$</ComputerName>
<ManagedEntityId>$Target/Id$</ManagedEntityId>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="GenerateAlert" TypeID="Health!System.Health.GenerateAlert">

<Priority>2</Priority>
<Severity>2</Severity>

<AlertMessageId>$MPElement[Name="EventProvider.Alert"]$</AlertMessageId>
<AlertParameters>
<AlertParameter1>$Data/EventDescription$</AlertParameter1>
</AlertParameters>
<Suppression />
</WriteAction>
</WriteActions>
</Rule>


</Rules>
</Monitoring>
<Presentation>
<StringResources>
<StringResource ID="EventProvider.Alert" />
</StringResources>
</Presentation>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
<DisplayString ElementID="EventProvider.Alert">
<Name> Event Provider Alert</Name>
<Description>{0}</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPack>
Next steps
To create a Fluentd configuration file to collect logs, see Sample configuration file for collecting Linux log files.
Monitoring service level objectives by using
Operations Manager
6 minutes to read
To ensure that resources, such as applications and systems, are available and performing at acceptable levels,
companies set goals for their service availability and response times. System Center Operations Manager provides
the capability to monitor these service goals by tracking service level objectives.
Service level objectives are measurements to ensure that you are meeting defined service level commitments. In
Operations Manager, you define a service level objective - the set of monitors that you need to track (such as
performance or availability) - and then run reports against that service level objective to ensure that you are
meeting your goals.
Using the information from these reports, you can identify any shortfalls between your service level objectives and
your actual performance. This means that you are not only aware of problems, but also can track the relative
business effect of these problems.
For example, if you have a group of servers running instances of Microsoft Exchange Server, which are critical to
your internal e-mail network, you can define a service level objective that states that 95% of the servers must be
available at all times. Then, you can generate a report that compares the actual availability of those servers against
the service level objective.
You can also create dashboard views to track service level objectives.
Define a service level objective for an application

You can define a service level objective (SLO ) to establish the availability and performance goals for an application.
In the following procedure, you create a service level objective against a distributed application, define a monitor
SLO that is based on availability (99.9% up-time), and define a collection rule SLO that is based on a performance
rule (80% average processor time).
user role.
2. Click Authoring.
3. In the navigation pane, expand Management Pack Objects, and then click Service Level Tracking.
4. In the Tasks pane, click Create.
5. In the Service Level Tracking dialog box, type a name for the service level that you are defining. For
example, type LOB Application 1. Optionally, you can provide a description. Click Next.
6. On the Objects to Track page, under Targeted class, click Select.
7. In the Select a Target Class dialog box, select a class for the service level, such as Distributed
Application, from the list in the text box. You can search for a class by typing its name into the Look For
text box. Click OK to close the Select a Target dialog box.
8. You can use the Scope option to specify the scope for the service level. The default selection is to use all
objects of the targeted class.
9. Select the management pack that this service level will be saved in. You can use an existing management
pack or create a new one.
10. Click Next.
11. On the Service Level Objectives page, click Add, and then click Monitor state SLO to create a new
monitor. This monitor will track the availability of the application.
12. Define the state monitor as follows:
a. In the Service level objective name text box, type a name for the service level objective. For this
scenario, type Availability.
b. From the Monitor drop-down list, choose the specific monitor that you want to use to measure the
objective. For this scenario, choose Availability.
c. Using the Service level objective goal (%) spin box, provide the numerical measure for your
objective. For example, select 99.990 to indicate that your goal is 99.99% availability.
d. You can refine what the monitor tracks to determine availability by selecting or clearing any of the
following state criteria:
Unplanned maintenance
Unmonitored
Monitoring unavailable
Monitor disabled
Planned maintenance
Warning
13. Click OK.
14. On the Service Level Objectives page, click Add, and then click Collection rule SLO to create a new
collection rule. This rule will track the performance of the application
15. Define the performance collection rule as follows:
a. In the Service level objective name: text box, type a name for the service level objective. For this
scenario, type Performance.
b. Under Targeted class, click Select to open the Select a Target Class dialog box. Specify the target
class for the rule from the list of targets in the text box. Note that this class must be contained in the
distributed application. For this scenario, select the specific class the rule is targeted to, such as
Windows Server 2008 Operating System.
c. Under Performance collection rule, click Select to open the Select a Rule dialog box. Specify the
performance collection rule to use. For this scenario, choose Collect Processor\ % Processor Time
performance counter, and then click OK.
d. Using one of the Aggregation method options, choose one of the following:
Average
Min
Max
e. Use the Service level objective goal drop-down list to specify either Less than or More than, and
enter a value in the adjacent text box. For this scenario, choose Less Than and 80. This indicates that
the performance goal is to never exceed 80% processor time.
f. Click OK.
16. On the Service Level Objectives page, click Next.
17. On the Summary page, review the settings, and then click Finish.
18. When the Completion page appears, click Close.
Defining a service level objective against a group

You can configure a service level objective (SLO ) against a group of computers to ensure their availability. In the
following scenario, you create a service level that consists of a group of servers (Exchange Servers) and then
define a service level objective of 99.99% availability.
user role.
2. Click Authoring.
3. In the navigation pane, expand Management Pack Objects, and then click Service Level Tracking.
4. In the Tasks pane, click Create.
5. In the Service Level Tracking dialog box, type a name for the service level that you are defining. For
example, type Exchange Servers. Optionally, you can provide a description. Click Next.
6. On the Objects to Track page, under Targeted class, click Select.
7. In the Select a Target Class dialog box, select a class for the service level, such as Operations
Management Group, from the list in the text box. You can search for a class by typing its name into the
Look for text box. Click OK to close the Select a Target dialog box.
8. You can use the Scope options to specify the scope of the service level. The default selection is to use all
objects of the targeted class.
9. Select the management pack that this service level will be saved in. You can use an existing management
pack or create a new one.
10. Click Next.
11. On the Service Level Objectives page, click Add, and then click Monitor state SLO to create a new
monitor. This monitor will track the availability of the application.
12. Define the state monitor as follows:
a. In the Service level objective name text box, type a name for the service level objective. For this
scenario, type Availability.
b. From the Monitor drop-down list, choose the specific monitor that you want to use to measure the
objective. For this scenario, choose Availability.
c. For the Service level objective goal, provide the numerical measure for your objective. For
example, select 99.990 to indicate that your goal is 99.99% availability.
d. You can refine what the monitor tracks to determine availability by selecting or clearing any of the
following state criteria:
Unplanned maintenance
Unmonitored
Monitoring unavailable
Monitor disabled
Planned maintenance
Warning
e. Click OK to close the Service Level Tracking dialog box.
13. On the Service Level Objectives page, click Next.
14. On the Summary page, review the settings, and then click Finish.
15. When the Completion page appears, click Close.
After you create a service level objective, you can monitor it by using a Service Level Tracking dashboard view and
the Service Level Tracking Report.
Next steps
See Running a Service Level Tracking Report, to view the service level objective over time to verify the
organization is delivering against availability targets defined in your SLAs.
Create a Service Level Dashboard to view the service level objective and verify the organization is
delivering against availability targets defined in your SLAs.
Creating a service level dashboard
2 minutes to read
After you configure a service level objective, you can create a service level dashboard view to monitor the service
level objective. The service level dashboard view displays a grid of service levels and a grid of service level
objectives grid which lists the various objectives which have a goal or target value and whether success is either
above or below that target value for the currently selected SLA/instance. When you select an objective in the
Service Level Objectives grid, a gauge and chart is displayed, as shown in the following image.
The gauge will show the average actual value, along with the target value and a indication as to whether the value
and goal relationship corresponds to success (green) or failure (red). The chart will show a time history of the
actual values, which will be a function of the aggregation of the values in the data warehouse, which will depend
on the timeframe of the configured dashboard, as to whether the values come from the Hourly or Daily
aggregation table.
To create a service level dashboard view

2. Right-click the folder where you want to store the view, point to New, and click Dashboard View.
3. In the New Instance Wizard, on the Template page, click either Flow Layout or Grid Layout, and then
click Next.
4. On the General Properties page, enter a name for the dashboard view. The description is optional. Click
Next.
5. On the Specify the Scope page, click Add.
6. In the Add SLA window, select the service level objective that you created, click Add, and then click OK.
You can add multiple service level objectives.
7. On the Specify the Scope page, in the Last section, set the period of time that you want to display in the
dashboard view, and then click Next.
8. Review the settings on the Summary page, and then click Create.
9. Click Close.
Next steps
Learn how to create a service level objective to measure service availability of an application or a set of
grouped computers for your service level dashboard by reviewing Monitoring Service Level Objectives by
Using Operations Manager.
See Running a Service Level Tracking Report, to view the service level objective over time to verify the
organization is delivering against availability targets defined in your SLAs.
Running a service level tracking report
2 minutes to read
You can create a report that shows how your application or group is performing in relation to the defined service
level objectives. The report that is generated provides both high-level information to give you a picture of the
overall status at a glance, and detailed low -level information to provide specific information on availability and
performance metrics.
The Service Level Tracking Summary report shows the results for one or more service levels in comparison to the
defined target objectives. From this report, you can examine a more detailed report, the State view, or the Service
Level Agreement view.
Use the following steps to generate a Service Level Tracking Summary report.
To generate a Service Level Tracking Summary report

user role.
2. In the Reporting workspace, click Microsoft Service Level Report Library.
3. In the results pane, right-click Service Level Tracking Summary Report, and then click Open.
4. Click Add SLA.
5. In SLA Name, type the name of the defined service level and then click Search.
6. Select the service level, and then click Add.
7. Click OK to close the Add SLA window.
8. Define the data period for the report. You can select the following options:
Data aggregation
Day range
Time range
9. Under Report Fields, select the fields that you want to include in the report. The fields that are available
depend on the day and time range selection. For example, if you have specified a day range of Thursday to
Wednesday, you do not have the option to include the Last 30 Days field.
10. Click Run to generate the report.
Next steps
Learn how to create a service level objective to measure service availability of an application or a set of
grouped computers for your service level dashboard by reviewing Monitoring Service Level Objectives by
Using Operations Manager.
Create a Service Level Dashboard to view the service level objective and verify the organization is
delivering against availability targets defined in your SLAs.
Connecting Operations Manager with other
management systems
8 minutes to read
Microsoft System Center - Operations Manager interoperates with other management solutions through System
Center - Orchestrator or product connectors built on the Operations Manager Connector Framework (OMCF ),
which are developed from the Operations Manager Software Development Kit (SDK). The OMCF provides
methods and types that you can use to initialize and manage a connector and to get or send operations data. With
earlier versions of Operations Manager, the primary means of synchronizing alerts between Operations Manager
and other systems was through a connector. An Operations Manager connector specifically created for the other
system was required for this purpose, and a variety of connectors have been released by vendors of those
management solutions.
Orchestrator integrates with System Center, other Microsoft products, and non-Microsoft products to enable
interoperability across the data center.
In Operations Manager, alerts occur when an issue requires action. An ITSM incident management system can
automatically create incident records it receives from an alert generated from Operations Manager via a product
connector or Orchestrator runbook.
Orchestrator runbooks
Starting with System Center 2012, Orchestrator runbooks have replaced product connectors as the preferred
method for synchronizing alert data between Operations Manager and other systems. Runbooks provide the
following advantages over connectors:
More complex logic that potentially includes multiple systems.
A wider range of supported systems.
No need for a specific connector since Integration Packs are general purpose.
The System Center Integration Pack for System Center Operations Manager includes activities that retrieve and
modify alerts from an Operations Manager management group. The only requirement for the other system is to
have an Integration Pack available. An Integration Pack provides a set of activities that work with a particular
application or component, and a single runbook can be made up of activities from multiple Integration Packs. In a
connector scenario, the Integration Pack only needs activities specific to the other system and has no specific
knowledge of Operations Manager. Information on the Integration Packs are currently available at Integration
Packs for System Center - Orchestrator
Connections to other management systems

Product connectors allow communication between Operations Manager and other management systems,
regardless of whether Operations Manager is the highest level management system or not. If Operations
Manager is not the top-tier management system, a product connector can forward all Windows-generated alerts
for consolidation at another management system. If the connector is bidirectional, Operations Manager can
update the state of the monitored component in the Operations Console when it receives notification from the
top-level management system. If Operations Manager is the top-tier management system, a product connector
allows it to receive and consolidate alert information from another management system.
The one challenge that Orchestrator runbooks have in comparison to connectors is throughput. System Center -
Orchestrator is a scalable product with the ability to distribute runbooks across multiple servers. Alert
synchronization though typically requires relatively few runbooks (or even a single runbook depending on
requirements and complexity) running every time an alert is created or modified. This can create a bottleneck
when handling a high volume of alerts.
The connector framework in Operations Manager was designed to be lightweight technology focused on a single
function supporting a high volume of alerts. System Center 2016 and later has the same connector framework
from Operations Manager 2012/2012 R2 and 2007 R2. New connectors can be created using the Operations
Manager Connector Framework. Verify from your vendor if the existing connector released for Operations
Manager 2012/2012 R2 will work without modification for Operations Manager 2016 and later.
System Center Integration

Virtual Machine Manager
In System Center, Virtual Machine Manager integrates directly with Operations Manager in addition to using the
System Center Monitoring Pack for System Center - Virtual Machine Manager for monitoring of the health of all
resources in a VMM environment. This additional integration is what allows VMM to display Operations Manager
data in the VMM console and to control maintenance mode during VMM operations. You can also manage the
installation of management packs through VMM rather than performing this installation directly in Operations
Manager as you do with the other components. Guidance on configuring this integration is provided in
Configuring Operations Manager Integration with VMM.
VMM performs some actions using the Operations Manager SDK that are typically performed with management
packs for other products. For example, several VMM objects are created without using object discoveries. One
example of this is the Virtual Machine object. If you select this class in the Object Discoveries node in the
Authoring workspace of the Operations Manager, no object discoveries are listed. Instead of relying on a
discovery in the management pack, VMM creates these objects through the Operations Manager SDK whenever
a new virtual machine is created or modified.
There is nothing that the vendor of resources that are used by VMM must do to have those resources discovered
and monitored. If the resource is recognized by VMM, then it will be discovered and monitored by the monitoring
pack. Vendors are still encouraged to create monitoring packs for their own resources though to provide any
deep monitoring specific to their product. While the VMM monitoring pack may be able to identify that the
resource is offline, it would be unable to provide detailed analysis to the root cause of the problem at potential
remedies.
Service Manager
Service Manager integrates with Operations Manager through two types of connectors that are both created and
configured in the Service Manager console.
The Configuration Items connector imports objects from Operations Manager as Configuration Items in
Service Manager. Discoveries in Operations Manager locate resources and their properties on managed
computers, and the connector allows these objects to be automatically imported into Service Manager.
The Alerts connector imports alerts as they are created from Operations Manager into Service Manager. They
are created in Service manager as incidents where they can be managed. The incident then remains in
synchronization with the alert allowing it to be closed when the incident is resolved.
Management Pack
The System Center Monitoring Pack for System Center - Service Manager allows Operations Manager to monitor
the health of a Service Manager environment. It discovers Service Manager management servers and data
warehouse and measures the health of its services.
The Operations Manager agent cannot be installed on a Service Manager management server because Service
Manager uses the System Center Management service to process its own management packs. To monitor a
Service Manager management server, you must configure it to use agentless monitoring, which allows Operations
Manager to process its management packs on an Operations Manager management server. Once the computer is
added to the Operations Manager management group in this manner, it is monitored like any other computer.
The only exception is that it will not run any rules or monitors that do not support an agentless scenario.
Orchestrator
The [System Center Integration Pack for System Center Operations Manager includes activities that allow you to
create a runbook in System Center - Orchestrator that interacts with Operations Manager. You can perform many
of the functions that you can perform with Windows PowerShell cmdlets only within the context of an
Orchestrator runbook. The activities included in the Operations Manager Integration Pack address the following
scenarios:
Retrieve and modify alerts. This includes the ability to monitor for an alert to be created or changed, a feature
which directly supports the connector scenario with other management systems.
Get the current health state of one or more monitored objects.
Start and stop maintenance mode.
The Operations Manager Integration Pack allows you to create one or more connections to Operations Manager
management servers that can be used by its activities. Each connection holds the security configuration required
to access a management group. You can create a runbook with multiple activities that share a single configuration
so that you don’t have to maintain separate credentials and connections for each activity.
If you need to perform an Operations Manager action from a runbook that doesn’t have an activity, then you can
write a script using one or more of the Operations Manager cmdlets and then run this script from a Run .NET
Script activity. In this case, the Operations Manager cmdlets would need to be installed on the runbook server.
The script would also need to include a connection to the Operations Manager management group using the
New -SCOMManagementGroupConnection cmdlet. If the account used for the Orchestrator Runbook Service
does not have authority to the Operations Manager management group, then alternate credentials would need to
be provided for this connection. In this case, the name and password could be stored as encrypted variables in
Orchestrator so that they would not have to be hardcoded into the script.
The activities in the Operations Manager Integration Pack connect to Operations Manager using the Operations
Manager SDK which means that they connect to the Data Access service on a management server.
Management Pack
In System Center, the management pack for Orchestrator discovers and measures the health of Orchestrator
components such as management servers and runbook servers. It does not discover runbooks, nor does it
monitor at the runbook level. For example, the management pack will send an alert if the runbook service on a
runbook server fails, but it will not alert if a runbook fails.
The recommended strategy to raise an alert in Operations Manager if a runbook fails is to include one or more
Create Alert activities that raise an alert if a previous activity does not succeed.
Product Connector installation

If you want to connect to a particular management system, you should ask the vendor of that management
system for a product connector. Installation instructions should be included in the download of the product
connector files. After a product connector is installed, you can configure which events you want the product
connector to accept or forward using subscriptions. The product connectors you install are displayed in the
Administration workspace in Product Connectors. See How to Configure a Product Connector Subscription for
more information.
Next steps
To learn more about System Center - Orchestrator and how it can support integration between Operations
Manager and other System Center or third-party management systems, see Getting Started with
Orchestrator.
Review the Operations Manager SDK to understand how to write a custom product connector to integrate
with an enterprise management system or automate and extend Operations Manager depending on your
advanced requirements.
How to configure a product connector subscription
2 minutes to read
System Center - Operations Manager supports the ability to synchronize alert data with other applications, such as
other management systems, using product connectors. After a product connector is installed, by default, all alerts
are forwarded through the product connector. In the following procedure, you use the Product Connector
Subscription Wizard to specify which alerts you want the product connector to forward.
NOTE
You must have a product connector installed prior to beginning this procedure. Install the product connector according to
the product connector vendor's installation instructions.
To configure a subscription for a product connector

1. Log on to the computer with an account that is a member of the Operations Manager Administrators user
role.
3. In the Administration pane, click Product Connectors. In the Product Connectors pane, right-click the
product connector and then click Properties. The Product Connector Properties dialog box displays. In
the Subscriptions section, click the Add button. The Product Connector Subscription Wizard starts.
NOTE
Operations Manager internal product connectors are listed in the Operations console. These connectors are used for
discovery workflows. Do not create subscriptions for these internal product connectors.
4. On the General page, type a name and a short description for the subscription you are creating, and then
click Next.
5. On the Groups page, you can filter which alerts this connector forwards to an external management system
based on groups. By default, all check boxes are selected, so alerts from all groups are forwarded. To enable
the child check boxes, clear the top-level check box. After you make your selections, click Next.
6. On the Targets page, you can filter which alerts this connector forwards based on object type. By default,
alerts are accepted from all object types in all management packs. You can specify particular management
packs or certain monitored objects from which you want to forward alerts. To accept alerts from only
specified types of objects, click Forward alerts from targets explicitly added to the 'Approved targets'
grid are approved and then click the Add button to select individual targets.
7. On the Criteria page, you can filter which alerts this connector forwards based on the severity, priority,
resolution state, and category of the alert. By default, all criteria are selected, so all alerts are forwarded.
However, you can individually select which alerts you want forwarded. After you make your selections, click
Create to create the product connector subscription. You can view the newly created subscription in the
details pane.
Next steps
Review Connecting Operations Manager With Other Management Systems to learn how to integrate Operations
Manager with another monitoring platform or ITSM system using a product connector developed using the
Operations Manager SDK.
Monitoring Operations Manager from a second
management group
2 minutes to read
Businesses using System Center – Operations Manager in multiple management groups might monitor one
management group from another management group. This topic provides the steps for monitoring one
management group (management group A) from a second management group (management group B ).
Steps to monitor from a second management group

1. Install an agent on management servers in management group A from management group B. If you install the
agent manually, configure the agent to report to a management server in management group B.
2. Disable Active Directory integration for the agent you install on the management server in management group
A.
3. To upgrade the management server in management group A, you must remove the management group B
agent first.
4. After the agent is installed, ensure that you do not configure the agent to also report to management group A
("multihome" the agent).
5. Ensure that the Run As accounts for the Default Action Account and Privileged Monitoring Account profiles for
the management server in management group B are using credentials that can remotely authenticate and that
have sufficient permissions on the management servers in management group A.
Next steps
Operations Manager Monitoring Scenarios
Connecting Operations Manager With Other Management Systems
How heartbeats work in Operations Manager
2 minutes to read
System Center Operations Manager uses heartbeats to monitor communication channels between an agent and
the agent's primary management server. A heartbeat is a packet of data sent from the agent to the management
server on a regular basis, by default every 60 seconds, using port 5723 (UDP ).
When an agent fails to send a heartbeat 4 times, a Health Service Heartbeat Failure alert is generated and
the management server attempts to contact the computer by using ping. If the computer does not respond to
the ping, a Failed to Connect to Computer alert is generated. The following illustration shows this process.
When you see both alerts, you know the computer cannot be contacted by the management server. When you
see only the heartbeat failure alert, you know the computer can be contacted but there is a problem with the
agent. Both alerts are closed automatically when heartbeats resume.
NOTE
By default, alerts for missed heartbeats and response to ping are disabled for client operating systems. To receive alerts
for client operating systems, override the Health Service Heartbeat Failure and Computer Not Reachable monitors
for the class Windows Client Operating System and set the Generates Alert parameter to True.
For agents reporting to a gateway server, you need to configure the Automatic Agent Management
Account that is used to automatically diagnose agent failures (eg. heartbeat failures, failure to receive data) so
the RunAs account has privileges to both the Management Server and the gateway. Otherwise, the recovery
task will fail on a gateway server. This scenario is only supported if:
1. The gateway server is a member of an Active Directory trusted forest, but outside the Kerberos trust
boundary of the management group.
2. The gateway server is a member of the same Active Directory forest as the Operations Manager
management servers. The gateway server in this case is used because of a firewall or member of a local
resource pool.
The health state for the agent-managed computer will change to critical (red) when the Health Service
Heartbeat Failure alert is generated. To view details for the health state, right-click the computer in Active
Alerts, point to Open, and click Health Explorer. The Availability node will be expanded to display the critical
item. Click Health Service Heartbeat Failure, and then click the State Change Events tab. You will see a list
of state changes with the date and time of occurrence. Select any occurrence to display information in the
Details pane. The health state will change to healthy (green) when heartbeats resume.
You can change the heartbeat interval for all agents and number of missed heartbeats for all management
servers in Settings in the Administration workspace, as shown in the following illustration.
You can also override the global heartbeat interval for individual agents and the number of missed heartbeats
for individual management servers by opening the properties for the computer in Agent Managed or
Management Servers in the Administration workspace. For example, you might increase the heartbeat
interval for a computer that has a slow connection to the network.
Next steps
To learn more about how to investigate an agent heartbeat failure and ways to resolve them, review
Resolving Heartbeat Alerts
Review Configure Computer Not Reachable Recovery Task for Gateway Servers when agents report to a
gateway server in a secure network environment.
Resolving heartbeat alerts
2 minutes to read
The Health Service sends a heartbeat to a management server to verify that the system is still responding. When a
specified number of heartbeats fail to arrive, System Center - Operations Manager displays an alert.
This section shows how to investigate a Health Service Heartbeat Failure alert as an example. Different alerts have
different causes and different resolutions.
If you want to walk through these procedures, you can cause this alert by disabling the Microsoft Monitoring
Agent service on a test system.
To cause a Health Service heartbeat failure alert for testing

1. On a computer with an agent installed, open Control Panel.
2. Double-click Administrative Tools.
3. Double-click Services.
4. Right-click the Microsoft Monitoring Agent service, and then click Stop.
NOTE
Use this same procedure and select Start in step 4 when you are done testing.
How to investigate agent heartbeat issues

The Monitoring workspace displays active alerts. Looking at an alert provides information and tools to
investigate with.
To investigate an active alert
2. Click Monitoring.
3. Click Active Alerts to view the Health Service Heartbeat Alert.
NOTE
Depending on the heartbeat interval and the number of missing heartbeats, a few minutes might be required to see
the alert.
4. Click the alert to highlight it and read the information in the Alert Details area. The Alert Details area
provides information about the alert, including a description and knowledge about the cause and
resolution.
How to troubleshoot agent heartbeat issues

Use the tasks in the Tasks pane to diagnose the cause of the alert. Different alerts have different tasks. For a
Health Service Heartbeat Failure alert, the tasks deal with pinging the system and verifying or restarting the
service.
To use the action tasks in troubleshooting
1. In the Tasks pane, under Health Service Watcher Tasks, click Ping Computer. The task opens a dialog
box to display its progress.
NOTE
If the ping fails, use standard networking troubleshooting to figure out the issue with connectivity. Verify that the
system is turned on.
2. Click Close to close the dialog box.

3. Under Health Service Watcher Tasks, click Computer Management. A Computer Management
dialog box for the target system opens.
4. Click Services and Applications to expand it.
5. Click Services to display services.
6. Right-click the Microsoft Monitoring Agent service, and then click Start.
NOTE
After the connection with the agent is restored, the alert will be automatically resolved and the computer status will
return to healthy.
These steps will fix the test failure created in this topic, as well as address a number of possible causes of a Health
Service Heartbeat Failure. If an actual failure is not resolved by these steps, use standard troubleshooting
techniques to figure out the cause of the issue. For instance, the alert displayed in Active Alerts shows how old
the alert is. Check for events that happened at this time to see what might have caused an issue.
A sudden increase in the number of alerts is called an alert storm. An alert storm can be a symptom of massive
changes of some kind within your management group, such as catastrophic failure of networks. An alert storm
can also be a symptom of configuration issues within Operations Manager. A newly imported management pack
starts monitoring immediately. If you have a large number of managed computers, an unforeseen configuration
issue could cause a large increase in alerts.
Next steps
Before changing the number of missed heartbeats allowed, first review How Heartbeats Work in Operations
Manager.
Configure Computer Not Reachable recovery task for
gateway servers
3 minutes to read
When an agent fails to send a heartbeat, a Health Service Heartbeat Failure alert is generated and the
management server attempts to contact the computer by performing a ping using Windows Management
Instrumentation (WMI) based on its recovery task Ping Computer on Heartbeat Failure. If the computer does
not respond to the ping, a Failed to Connect to Computer alert is generated. By default, this recovery task is
performed from its assigned management server. But when agents report to a gateway server that communicates
with its assigned management server through a firewall, the attempt to ping the remote agent will fail. The
following steps describe how to configure the gateway server in this scenario to attempt to contact the computer
and verify it is responding to a ping.
Prerequisites
RPC port 135 (DCOM/RPC ) must be open between the management server and the gateway server in order for it
to remotely connect to the WMI provider on the gateway server. Initially the management server binds to port 135
and then a dynamically assigned port above 1024 is selected. For further information, review How to configure
RPC dynamic port allocation to work with firewalls.
Configuration
NOTE
connect.
3. In the Authoring workspace, in the navigation pane under Management Pack Objects, click Monitors.
4. From the toolbar, click Change Scope... and in the Scope Management Pack Objects window, select the
option View all targets and then click Clear All if enabled, to deselect any pre-selected classes you may
have filtered earlier.
5. Search for the class Health Service Watcher and select it by clicking the checkbox to the left of the class
name under the Target column. Click OK to accept your selection.
6. Expand the health category Availability and select the Health Service Heartbeat Failure monitor. From
the Operations console toolbar, click Overrides and then point to Override Diagnostic, select Ping
Computer on Heartbeat Failure and then choose to override For a group... or For all objects of class:
Health Service Watcher
7. Override the value for Source Computer parameter with the Fully Qualified Domain Name (FQDN ) of the
gateway server that you want the ping to be performed from when this monitored object reports a
heartbeat failure.
For agents reporting to a gateway server, you need to configure the Automatic Agent Management Account
Run As account that is used to automatically diagnose agent failures (example, heartbeat failures, failure to receive
data) so the Run As account has privileges to both the management server and the gateway. Otherwise, the
recovery task will fail on a gateway server. This scenario is only supported if:
1. The gateway server is a member of an Active Directory trusted forest, but outside the Kerberos trust boundary
of the management group.
2. The gateway server is a member of the same Active Directory forest as the Operations Manager management
servers. The gateway server in this case is used because of a firewall or member of a local resource pool.
Perform the following steps to configure the Run As account.
1. Create a new Run as account of type Windows. To perform this task, see How to create a Run As account
and associate with a Run As profile. When you are at the step to configure distribution of the account, select
More Secure and distribute the credentials to the gateway servers and All Management Servers
Resource Pool.
2. Add the Run As account to the Automatic Agent Management Account Profile and then chose the
option All targeted objects.
NOTE
While the gateway server pings the agent, initiation occurs from management server using a WMI query that runs
against agents reporting to the gateway server. For this reason, the Automatic Agent Management Account Run
As account needs to have the necessary privileges on both the management and gateway server to execute this
WMI query from both roles. For more information on how to properly configure privileges to remotely connect to a
computer using WMI, see Securing a Remote WMI Connection.
Next steps
To learn more about how to investigate an agent heartbeat failure and ways to resolve them, review Resolving
Heartbeat Alerts.
How an alert is produced
3 minutes to read
In System Center - Operations Manager, an alert can be generated by a rule or a monitor. For an explanation of
rules and monitors, see What is in an Operations Manager Management Pack?
Some rules and monitors are configured to send an alert when specific conditions are met, such as a certain event
occurring or an operation failing. Every rule and monitor does not generate an alert. When the default
configuration of a monitor is to not send alerts, you can configure an override on the monitor to enable alerts. For
information about configuring overrides, see How to Override a Rule or Monitor.
A monitor can be configured to generate an alert when health state changes to warning (yellow ) or critical (red), or
only when state changes to critical. For example, a monitor for free disk space detects that disk space on a
computer is below the configured threshold. The monitor changes the health state to critical and sends a single
alert. After the monitor has sent the alert, it will not generate future alerts so long as the health state does not
change from critical to healthy (green). If, however, the health state is reset to healthy and then the disk space
drops below the threshold again, another alert will be sent when the health state changes to critical.
If a monitor sends an alert for warning or critical, and the monitor sent an alert when the state changed to
warning, it will only send a second alert when the stage changes from warning to critical if the first alert has been
closed. If the alert that was sent when the state changed to warning remains open, no alert will be sent when the
state changes from warning to critical.
The following illustration shows the state changes that can generate an alert.
Most alerts generated by monitors will be automatically resolved when the health state returns to healthy. If a
monitor is not configured to automatically resolve its alert, you can configure an override on the parameter Auto-
Resolve Alert for the monitor.
NOTE
Rules cannot automatically resolve alerts.
Unlike monitors, rules can continue to send alerts as long as the condition that caused the alert persists or repeats.
Depending on what the rule is checking for, a single issue could possibly generate a huge number of alerts. To
prevent the noise of too many alerts, alert suppression can be enabled for a rule.
NOTE
Alert suppression can only be enabled when the rule is created. You cannot enable alert suppression by using an override.
When alert suppression is enabled for a rule, only the first alert is sent and further alerts are suppressed. A
suppressed alert is not displayed in the Operations console. Operations Manager suppresses only duplicate alerts
as defined by the alert suppression criteria. Fields stated in the suppression criteria must be identical for the alert
to be considered a duplicate and suppressed. An alert must be created by the same rule and be unresolved to be
considered a duplicate.
You can personalize the Active Alerts view to add the Repeat Count column. The repeat count for an alert with
suppression enabled will be incremented for each suppressed alert. You can also view the repeat count in the
properties for an alert.
IMPORTANT
By default, all alerts that are generated by monitors and that use the same instance ID are suppressed, however nothing in
the alert properties as viewed in a console will indicate that suppression is enabled. Alerts that are generated by rules will
also be suppressed by default if the rule definition in the management pack contains an empty Suppression Value tag,
however nothing in the alert properties as viewed in a console will indicate that suppression is enabled. You will only be
aware of the suppression if you view the Repeat Count column for the alert.
Next steps
Review How to Close an Alert Generated by a Monitor to understand the behavior of alerts generated by
monitors and how to approach managing alerts from them.
After investigating and resolving the issue detected by one or more monitors, review How to Reset Health
to manually reset health if the monitor isn't configured to auto-resolve or you don't want to wait for the
monitor to detect health state.
To help investigate health issues detected with monitors, review Using Health Explorer to Investigate
Problems.
Viewing active alerts and details
2 minutes to read
In the Operations Manager console, alerts matching a specific criteria and related to an object or group of
objects, are presented in an alerts view. From this view, you can review alerts that have been generated by rules
and monitors which are still active and have not been closed automatically or manually by an operator.
Viewing active alerts

To view active alerts, open the Operations console and click Monitoring. The Monitoring Overview displays a
summary of health states and alerts:
To view the actual alerts, click Active Alerts in the navigation pane.
TIP
If you are using the web console, you can filter the view of alerts by severity:
The list of alerts in the Results pane includes the severity, source, maintenance mode status, name, resolution
state, and when the alert was created:
The following folders in the Monitoring workspace include a standard Active Alerts view scoped to the objects for
that folder.
Data Warehouse
Network Monitoring
Operations Manager
Operations Manager\Agent Details
Operations Manager\APM Agent Details
Management Server
Notification
UNIX/Linux Servers
Web Application Availability Monitoring
Management packs that you import typically include a standard Active Alerts view in its folder or within a
dashboard included.
Viewing alert details

Alerts in System Center - Operations Manager include information to help you investigate and resolve the issues
affecting your IT services that caused the alerts.
To view the details for an alert, in the Monitoring workspace, click Active Alerts, and then click an alert in the
results pane.
Tips
Locate and investigate monitors in the Warning and Error states in the Health Explorer of the computer
that was the source of the alert. (To open Health Explorer, right-click the alert, point to Open, and click
Health Explorer.) If there are unhealthy monitors, they may correlate with the alert you are researching.
Check out the Context pane of the State Change Events tab for possible additional clues to the root
cause.
Read all text in the alert properties. (Right-click the alert, and select Properties.) In particular, carefully
review the Alert Description field on the General tab and the Description field on the Alert Context
tab.
Right-click the alert, and open the Event view. Sort the events by the Level column, and then locate the
events with the Error and Warning event levels. Events may correlate with the alert you are investigating
and provide insight to its resolution.
Next steps
Before changing the number of missed heartbeats allowed, first review How Heartbeats Work in
Operations Manager.
To understand how alerts are generated for monitored objects in your management group, see How an
Alert is Produced.
Examining properties of alerts, rules, and monitors
3 minutes to read
The properties pages for alerts, rules, and monitors offer useful information and actions that you can take. The
following tables explain what you can learn from properties for alerts, rules, and monitors and include tips on using
the properties tabs.
Properties for alerts

TAB DESCRIPTION
General The general tab contains key details about the alert, such as
source (the monitored object on which the alert condition
occurred), severity, priority, and repeat count (the number of
times the alert condition has occurred). The alert description
and status are also displayed on the general tab.
You can assign an owner and ticket ID for an alert on the

general tab.
The rule or monitor that generated the alert is not displayed

anywhere in the alert properties; for that information, see the
alert details in the Operations console.
Product Knowledge Product knowledge is information about the alert written by

the author of the management pack that contains the alert. It
should include information about the probable causes for the
condition that caused the alert and guidance on resolving the
condition.
Company Knowledge Administrators can add knowledge to rules, monitors, and

alerts to expand the troubleshooting information in the
product knowledge to provide company-specific information
for operators.
History You can add comments on the history tab that will be added
to the alert history. This is useful for tracking actions related to
the alert. Comments are limited to 85 characters.
The alert history is specific to this occurrence of the alert, and

is not contained in the same alert that is generated for
another source or at another time. For notes that are useful
for all occurrences of an alert, information should be added to
the company knowledge tab.
Alert Context Some alerts may display an alert context. The specific
information provided in the alert context depends on the
specific alert.
Custom Fields Administrators can add information to any of the nine custom
fields in an alert when an alert has been generated. The
information added only applies to this unique alert. The
custom fields can be searched on by using advanced search.
Properties for rules
TAB DESCRIPTION
General The general tab provides the name and description of the rule,
the management pack that it is contained in, the rule target,
and whether the rule is enabled.
Configuration The configuration tab provides information about the data

source, condition, and responses configured for the rule.
Unlike monitors which have alert configuration on an Alerting
tab, alert configuration for a rule is on the Configuration tab,
in Responses.
Product Knowledge Product knowledge is information about the rule written by

the author of the management pack that contains the rule.

for operators.
Overrides Administrators can apply overrides to the monitor on the

overrides tab. Click View summary to view all overrides
applied to the monitor.
Properties for monitors

TAB DESCRIPTION
General The general tab provides the name and description of the
monitor, the management pack that it is contained in, the
parent monitor, and whether the monitor is enabled.
Health The health tab tells you how health is defined for the monitor.
Alerting The alerting tab provides information about an alert

generated by the monitor. You can also see on thise tab
whether alerts generated by this monitor are automatically
resolved.
Diagnostic and Recovery This tab lists any diagnostic or recovery tasks associated with
this monitor. Administrators can add either type of task to the
monitor on this tab.
Configuration If there is a user interface for configuration of this monitor, it

will be displayed on the configuration tab. If there is no user
interface define, the XML that defines the configuration of this
monitor is displayed.
Product Knowledge Product knowledge is information about the monitor written

by the author of the management pack that contains the
monitor.
TAB DESCRIPTION

for operators.
Overrides Administrators can apply overrides to the monitor on the

overrides tab. Click View summary to view all overrides
applied to the monitor.
Next steps
After investigating and resolving the issue detected by one or more monitors, review How to Reset Health to
manually reset health if the monitor isn't configured to auto-resolve or you don't want to wait for the
Problems.
Impact of closing an alert
2 minutes to read
In System Center Operations Manager, an alert can be generated by a rule or a monitor. Alerts have two possible
resolution states, by default: New and Closed. (Administrators can add custom alert resolution states to a
management group. For more information, see How to Set Alert Resolution States.
The impact of setting the alert resolution state to Closed depends on whether the alert was generated by a rule or
a monitor. Click the alert to display the alert details. The details for an alert will either list Alert Rule or Alert
Monitor.
If you close an alert that was generated by a rule and the issue continues or occurs again, another alert will be sent.
Closing an alert that was generated by a rule when the issue is not fixed is not a problem, because the rule will
generate another alert.
However, an alert that is generated by a monitor is sent only when the state for the monitor changes from healthy
to some other state (warning or critical). If you close an alert that is generated by a monitor when the issue is not
fixed, no other alerts will be sent.
For example, a monitor for free disk space detects that disk space on a computer is below the configured threshold.
The monitor changes the health state to critical (red) and sends a single alert. After the monitor has sent the alert, it
will not generate future alerts so long as the health state does not change from critical to healthy (green). If you
close the alert while the object is in a warning or unhealthy state, the problem remains unresolved but no further
alerts will be generated.
Generally, before you close an alert, you should verify that the issue is resolved. If the alert was generated by a
monitor and the alert does not resolve automatically, check Health Explorer and the health state of the computer to
ensure that the states have returned to healthy before you close the alert.
Next steps
Before changing the number of missed heartbeats allowed, first review How Heartbeats Work in Operations
Manager.
Resolving Heartbeat Alerts.
When an alert is generated, you can View Active Alerts and Details in the Operations and Web console to
identify possible issues and help identify next steps towards resolving them.
How to close an alert generated by a monitor
7 minutes to read
Monitors define the health states of objects. An object can have one of three health states: green (successful or
healthy), yellow (warning), or red (critical or unhealthy). For example, a monitor for disk drive capacity might
define green as less than 85 percent full, yellow as over 85 percent full, and red as over 90 percent full. A monitor
can be configured to generate an alert when a state change occurs.
When you receive an alert, you can see in the alert details whether the alert was generated by a rule or a monitor.
If the alert was generated by a monitor, as a best practice, you should allow the monitor to auto-resolve the alert
when the health state returns to healthy. If you close the alert while the object is in a warning or unhealthy state,
the problem remains unresolved but no further alerts will be generated.
If the monitor generates an alert when the health state changes to red and you do resolve the alert, you must also
reset the health state for the monitor. If the monitor is not reset, the same condition that generated an alert can
occur again but no alert will be generated because the health state has not changed.
In Operations Manager prior to 2019, if you close the alert while the object is in a warning or unhealthy state, the
problem remain unresolved, but no further alerts are generated. This behavior, which often led to a scenario
where there is no active alert in the system, while an underlying problem exists, is fixed in Operations Manager
2019.
With Operations Manager 2019, an alert that is generated by a monitor cannot be closed unless the health state
of the corresponding monitor is healthy. If you try to close an alert generated by an unhealthy monitor, an error
message appears, and the alert will not be closed.
You can check this new behavior from both Operations console and Web console.
Operations console
Follow these steps:
1. Open the Operations Manager console and click Monitoring
Monitoring Overview displays a summary of health states of the monitors and the current alerts.
2. Click Active Alerts in the navigation pane.
3. Right-click an alert, which is generated by a monitor in unhealthy state.
4. Set the resolution state as Closed.
The following message appears to state the reason for non-closure of the alert:
Alert(s) in the current selection cannot be closed as the monitor(s), which generated these alerts
are still unhealthy. For more details on the alert that could not be closed, view the “Alert Closure
Failure” dashboard in the Operations Manager Web Console
NOTE
To close this alert, the health state of the corresponding monitor has to be manually reset to healthy state. If
autoresolve for this monitor is set to true, then the alert will be auto closed after the health state is reset. Else, the
alert has to be manually closed after the health state is reset.
Web Console
1. Open the Web Console and click Monitoring. Monitoring Overview displays a summary of health
states of the monitors and the current alerts.
2. Click Active Alerts in the navigation pane.
3. Open an alert, which has been generated by a monitor in unhealthy state.
4. Set the resolution state as Closed and Save changes.
The following message appears to state the reason for non-closure of the alert:
The current alert cannot be closed as the monitor that has generated this alert is still unhealthy
NOTE
To close this alert, you must manually reset the health of the corresponding monitors that generated this alert.
Manually reset the health state of a monitor for a corresponding alert
Follow these steps:
1. Click Alert Closure Failure dashboard in the navigation pane. The dashboard lists the alerts, which
Operations Manager was unable to close because the monitor, which has generated the alert is unhealthy.
2. You can reset the health state of the monitor for the corresponding alert, in the following two ways:
Select an alert in the dashboard and then select the dashboard action Reset Health for Alert. Or
Click an alert in this dashboard to navigate to the alerts drill-down page (where you can visualize all the
relevant information for an alert), select the Reset Health task in the task pane.
Alert update APIs

If an alert closure is triggered from external systems like incident management and the alert was not closed due
to the corresponding monitor being unhealthy, then, an exception would be passed with the alert details, which
may be consumed by external systems.
The following existing alert update APIs can be leveraged for externalizing alert update data. These two APIs have
been enhanced to enable externalization of this new behavior:
Alert update API 1
Alert update API 2
The following sample shows the details on how to use the exception AlertMonitorUnhealthyException.
namespace MonitorAlertClosureFailureExample
{
class Program
{
static void Main(string[] args)
{
ManagementGroup mg = new ManagementGroup("localhost");
// Get database availability alerts.

MonitoringAlertCriteria alertCriteria = new MonitoringAlertCriteria(
"Name LIKE '%DBStatusMonitor' AND Category = 'AvailabilityHealth'");
IList<MonitoringAlert> alerts =
mg.OperationalData.GetMonitoringAlerts(alertCriteria, default(DateTime));
// Find the "Closed" resolution state that is defined

// for this Management Group.
IList<MonitoringAlertResolutionState> alertStates =
mg.OperationalData.GetMonitoringAlertResolutionStates();
MonitoringAlertResolutionState closedState = null;
foreach (MonitoringAlertResolutionState thisState in alertStates)
{
if (thisState.Name == "Closed")
{
closedState = thisState;
}
}
// Close all alerts not already in the "Closed" resolution state.

foreach (MonitoringAlert a in alerts)
{
a.ResolutionState = closedState.ResolutionState;
string comment = "Closing the Alert";
try
{
a.Update(comment);
}
catch (AlertMonitorUnhealthyException e)
{
// It mean the alert being closed is a monitor alert and the monitor which generated this
alert is still unhealthy
// take an appropriate action. Here an error message is being displayed at console
Console.WriteLine("The alert with Alert Name" + a.Name + "cannot be closed as the monitor
which genrated the alert is still unhealthy.")
}
catch (Exception e)
{
// generic exception during the update of the alert
Console.WriteLine("Closing the alert with alert name" + a.Name + "is failing because" +
e.Message)
}
}
}
namespace MonitorAlertClosureFailureExample
{
class Program
{
static void Main(string[] args)
{
ManagementGroup mg = new ManagementGroup("localhost");
// Get database availability alerts.

MonitoringAlertCriteria alertCriteria = new MonitoringAlertCriteria(
"Name LIKE '%DBStatusMonitor' AND Category = 'AvailabilityHealth'");
IList<MonitoringAlert> alerts =
mg.OperationalData.GetMonitoringAlerts(alertCriteria, default(DateTime));
// Find the "Closed" resolution state that is defined

// for this Management Group.
IList<MonitoringAlertResolutionState> alertStates =
mg.OperationalData.GetMonitoringAlertResolutionStates();
MonitoringAlertResolutionState closedState = null;
foreach (MonitoringAlertResolutionState thisState in alertStates)
{
if (thisState.Name == "Closed")
{
closedState = thisState;
}
}
// Close all alerts not already in the "Closed" resolution state.

string comment = "Closing the alert";
foreach(MonitoringAlert a in alerts)
{
a.ResolutionState = closedState.ResolutionState;
}
IList<MonitoringAlertUpdateFailure> updateFailures =
mg.OperationalData.UpdateMonitoringAlerts(alerts, comment);
if (updateFailures != null && updateFailures.Count > 0)

{
foreach (MonitoringAlertUpdateFailure failure in updateFailures)
{
if(failure.Exception is AlertMonitorUnhealthyException)
{
// It means the alert being closed is a monitor alert and the monitor which generated
this alert is still unhealthy
// take an appropriate action. Here an error message is being displayed at console
Console.WriteLine("The alert with Alert Name" + a.Name + "cannot be closed as the
monitor which genrated the alert is still unhealthy.")
}
}
}
}
}
To determine if an alert is resolved automatically

Follow these steps:
1. Select the alert, and then in the alert details, click the name of the alert monitor. The properties dialog box
for the monitor opens.
2. In the monitor properties, click the Alerting tab to see if the option Automatically resolve the alert
when the monitor returns to a healthy state is selected.
To close an alert that is generated by a monitor

Follow these steps:
1. Read the alert and examine its properties. Check the alert details to determine if the alert was generated by
a monitor or a rule. Use the product knowledge for the alert to help determine the cause of the alert.
2. Troubleshoot the cause(s) of the alert and take the actions needed to resolve the problem.
3. When the problem is resolved, click Source in the alert details. This will open the State view for the object
associated with the alert.
4. Right-click the object, point to Open, and then click Health Explorer for object name.
5. Select the monitor that generated the alert and click Reset Health on the toolbar. Close the Health
Explorer and the State view.
6. Refresh the alerts view. If the alert is still listed, click the alert and then click Close Alert in the Actions
pane.
Next steps
How to reset health
2 minutes to read
Some monitors can set state to critical (red), warning (yellow ), and healthy (green). Other monitors are only able
to change state to critical or warning and cannot detect that state has returned to healthy. In that situation, the
monitor must be reset manually. Administrators or authors can check whether a monitor is type Manual Reset in
the Authoring workspace.
NOTE
Only reset health for a monitor when you are sure that all issues have been resolved.
To reset the health for a monitor

1. In the Monitoring workspace of the Operations console, right-click an alert, point to Open, and then click
Health Explorer.
2. In Health Explorer, select a monitor, and on the toolbar, click Reset Health.
NOTE
You may also notice Recalculate Health on the toolbar. This function reexamines the health state of a monitor or
monitors; however, it only works with monitors that implement On Demand Detection. Most monitors do not
implement On Demand Detection.
The following message displays: Resetting the health of a monitor may take several minutes and will
not be reflected in the Health Explorer immediately. The health state of some monitors cannot be
reset and will not be updated as a result of this request. Do you wish to continue?
3. If you are sure that you want to reset the monitor, click Yes.
4. Return to the Monitoring workspace, right-click the alert, point to Set Resolution State, and click Closed.
Next steps
Problems.
Using Health Explorer to investigate problems
2 minutes to read
Use Health Explorer to find out which monitor is reflecting a health state issue and review knowledge about the
monitor and possible causes for actions related to it. In the Active Alerts view, click the alert to highlight it. The
Health Explorer link under Alert Actions in the Tasks pane becomes active. Health Explorer is also accessible
when selecting a monitored object from any health state view in the console.
By default, when the Health Explorer window opens, all monitors in a failed state are expanded. If a monitor
contains other monitors, as in the case of a roll-up monitor, Health Explorer shows all child monitors in a
hierarchical layout, displaying monitoring data for all dependent services and applications. To view more
information about any dependent monitor, you can right-click that monitor, and then click Monitor Properties
to open another Health Explorer window.
Monitor health states

The following illustration shows monitors in a healthy state:
The following illustration shows some monitors in a critical state:

Click a monitor to view more information about the monitor in the Details pane. The State Change Events tab
in the Details pane shows you when the state for the monitor changed, and the details give you information for
the context of the state change:
Next steps
Operations Manager.
How to set alert resolution states
2 minutes to read
In System Center Operations Manager there are seven default resolution states for alerts:
RESOLUTION STATE ID
New 0
Closed 255
Acknowledge 249
Assigned to Engineering 248
Awaiting Evidence 247
Resolved 254
Scheduled 250
When an alert is generated, its resolution state is New. Operators can change the resolution state for a new alert
to Closed or to a custom resolution state that an administrator has created for the management group.
Custom alert resolution states can used any descriptor you want, such as "Assigned to support" or "Requires
investigation". The default resolution states cannot be changed or deleted.
Each resolution state is assigned an ID, a number which uniquely identifies that resolution state. You can assign
custom resolution states any that is not already used, and you cannot use a value higher than 255.
To set the resolution state for an alert

2. Click any view that displays alerts, such as Active Alerts.
3. Right-click an alert, point to Set Resolution State, and then click the desired resolution state.
To create an alert resolution state

2. Click Settings.
3. Double-click Alerts.
4. On the Alert Resolution States tab, click New.
5. In Add Alert Resolution State, type a name for the resolution state and select a value in the Unique ID
box, and then click OK.
6. In Global Management Group Settings - Alerts, click OK.
Next steps
Operations Manager.
How to configure automatic alert resolution
2 minutes to read
In System Center Operations Manager, alerts are resolved automatically after a specific number of days. You can
change the automatic alert resolution settings globally for the management group. Using automatic alert
resolution, you can configure all active alerts with a resolution state of New to be changed to Closed after a
specific number of days. You can also configure all active alerts with a resolution state of New to be changed to
Closed after a specific number of days when the alert source is healthy.
To change the global settings for automatic alert resolution

2. Click Settings.
3. Double-click Alerts.
4. Click the Automatic Alert Resolution tab.
5. Change the days for either or both of the following settings:
6. Click OK.
Next steps
To get better visibility with the alerts being generated in your environment and determine which are
candidates for additional configuration to reduce alert noise and improve alert accuracy, see Data-driven
Alert Management from the Operations console.
To understand how alerts are generated for monitored objects in your management group, see How an
Alert is Produced.
Review Viewing Active Alerts to understand how it can help you review alerts that have been generated by
rules and monitors which are still active.
Data driven alert management
4 minutes to read
To drive towards improved accuracy of issues detected and alerted for infrastructure services and application
monitored by System Center - Operations Manager, the Tune Management Packs feature is available to highlight
the management packs and its workflows which generate a high volume of alerts.
Now you can get better visibility with the alerts being generated in your environment through the console as
opposed having to run reports or utilize custom scripts to expose this data. For monitors and rules from a
management pack that are generating a significant volume of alerts, you can directly review the configuration of
the rule or monitor, review which monitored objects are generating the alert volume, or modify its configuration
by setting an override without having to navigate to the Monitoring or Authoring view.
By default, the view is scoped to present 30 or more alerts that have been generated during the past 90 days.
Reviewing alerts to tune

3. In the navigation pane, select Tune Management Packs under Management Packs.
4. This view gives you an overall picture of the alerts generated (by alert count) by management packs in your
management group for the specified duration.
5. To get more information on a specific management pack, select that particular management pack and this
will enable the “Properties” and “Tune Alerts” actions in the Tasks pane.
6. To review properties of the selected management pack, select Properties from the Tasks pane. The
Management Pack General Properties dialog box will appear for the specified management pack.
7. To review additional information for the alerts generated by the selected management pack, select Tune
Alerts from the Tasks pane. The Alerts view window will appear, which displays the following properties for
each alert type:
a. Alert Name - the alert display name from rule or monitor that generated the alert
b. Count - how many alerts were created over the period of time by the rule/monitor
c. Severity - indicates the degree of impact based on the issue identified
d. Priority - indicates how quickly to respond in order to resolve the issue identified
e. Monitor / Rule - indicates if the alert was generated by a rule or monitor
f. Monitor / Rule Name - the name of the monitor or rule that generated the alert
8. For each alert type you can select View or Edit settings of this monitor or View or Edit settings of this
rule depending on the alert type selected, View or Override Sources, or Overrides action from the Tasks
pane.
Selecting View or Edit settings of this monitor or View or Edit settings of this rule, will open the properties
dialog of the particular alert type selected.
If you wish to get more information on the different sources which have generated multiple alerts for a specific
alert type, then you can select View or Override Source. This will open a dialog box which display the different
sources which have generated a specific alert along with the count for each source. In this view, you can
understand which source or sources are generating a lot of alerts and from here, you can disable the monitor or
rule or override a specific parameter for that monitored object, or view the overrides already configured for that
workflow.
If you need to configure the override against a different target, you can select Overrides, and target the
configuration change against a all objects of class, a group, objects of another class, specific object of class,
or objects of another class. The override functionality and the View or Edit settings of monitor/rule are
consistent in behavior with the other methods you can apply overrides in the console.
The alert level information and the source level information will provide you more insight on the alerts being
generated in your environment and with the other methods available in Operations Manager to evaluate alert
volume, you can determine where you need to make further changes to improve monitoring and alert accuracy.
Change view settings

The following procedure describes how you can configure the frequency and minimum number of alerts to filter in
the Tune Management Packs view.
3. In the navigation pane, select Tune Management Packs under Management Packs.
4. From the Actions pane, select Identify Management Packs to Tune.
5. In the Identify Management Packs to Tune dialog box, do the following:
a. Specify the date and time range by typing it in manually in the Display alerts from and To fields or use
the Date and Time control to modify the date range.
b. Specify the minimum number alerts generated by workflows in a management pack that you wish to see
by specifying or entering a number.
6. In the Identify Management Packs to Tune dialog box, click OK to save your changes.
Next steps
To understand how to approach to managing the lifecycle of management packs deployed in your
management group, see Management pack lifecycle.
explore the operational data and configuration information in your management group and follow the How
to create reports in Operations Manager to create reports for your operational needs.
How to enable recovery and diagnostic tasks
2 minutes to read
Monitors in System Center - Operations Manager can do more than notify you of problems by sending an alert.
Some monitors also provide diagnostic and recovery tasks to help investigate and resolve those problems.
A task is a script or other executable code that runs either on the computer running the Operations console or on
the server, client, or device that is being managed. Tasks can potentially perform any kind of activity, including
restarting a failed application and deleting files.
Monitors can have two kinds of tasks associated with them: diagnostic tasks that try to discover the cause of a
problem or provide you with additional information to assist with that diagnosis, and recovery tasks that try to fix
the problem.
Diagnostic and recovery tasks can only be created for a specific monitor. A diagnostic or recovery task that you
create for one monitor cannot be shared with or associated with a different monitor; you must recreate the task for
each monitor. In addition, tasks that you create in the Authoring workspace using the Create Task Wizard
cannot be used as a diagnostic or recovery for a monitor.
Some monitors have diagnostic or recovery tasks that are disabled by default. You can enable any of these tasks
that you want the monitor to run. For example, in the following image, you see that some recovery tasks for the
Health Service Heartbeat Failure monitor are not configured to run automatically.
On this tab, you can also add tasks or edit tasks that you have added previously. For more information on how to
add diagnostic and recovery tasks, see Diagnostics and Recoveries in the Author's Guide. Tasks that are configured
by a sealed management pack can only be modified by using overrides.
To enable a diagnostic or recovery task

1. In the Operations console, in the Authoring workspace, right-click a monitor and click Properties.
2. Click the Diagnostic and Recovery tab.
3. On the Diagnostic and Recovery tab, in the Configure diagnostic tasks or Configure recovery tasks
section, ensure the desired task is selected and then click Edit.
4. On the Overrides tab, click Override. You can choose to override this monitor for objects of a specific type
or for all objects within a group. After you choose which group or object type to override, the Override
Properties dialog box opens. For more information about applying an override, see Using Classes and
Groups for Overrides in Operations Manager.
5. In the Override-controlled parameters section, click Enabled and set the override value to True.
6. Either select a management pack from the Select destination management pack list or create a new
unsealed management pack by clicking New. For more information about selecting a destination
management pack, see Creating a Management Pack for Overrides.
7. Click OK. Close the open properties windows.
Next steps
To understand the differences between classes and groups in Operations Manage and how workflows apply
to each, review Using Classes and Groups for Overrides in Operations Manager
How to suspend monitoring temporarily by using
maintenance mode
14 minutes to read
Maintenance mode in Operations Manager enables you to avoid any alerts or errors that might occur when a
monitored object, such as a computer, a SQL database, or distributed application, is taken offline for maintenance.
Maintenance mode suspends the following features:
Rules and monitors
Notifications
Automatic responses
State changes
New alerts
For example, an Exchange mailbox role running on a Windows server will have an Exchange Server service pack
applied. This software update maintenance is expected to take 60 minutes to complete. During this time, the
Mailbox database running on this server will not be available.
In this case, you can put the Exchange Mailbox role and contained components into Maintenance Mode instead of
putting the entire computer into Maintenance Mode. This way you can continue to monitor the other components
running on the server, including the Windows operating system, while maintenance is performed specifically to
the Exchange Server application.
You can either select one or more monitoring objects and place them into maintenance mode on-demand, or you
can define schedules aligned with your service or maintenance windows, and automatically place them into
maintenance mode in the future according to the schedule you choose. With the new scheduling feature, you can:
Schedule maintenance mode at a future time daily, weekly, or monthly.
Choose different classes of entities and groups to put to maintenance as a part of a single schedule.
View all the maintenance mode schedules from a single screen.
Schedule multiple jobs for the same monitored entity.
IMPORTANT
Important Information about configuring and working with the Maintenance Schedule feature:
You can change when a running schedule will end, but the change will only apply to the schedule that is running. If
you want to edit the end time for future runs of that schedule, you must first stop the schedule and then apply your
changes.
The time zone specified for the Windows computer hosting the Management Server role will be applied to the
maintenance schedule.
Changes to accommodate daylight savings time are not automatically applied to maintenance schedules. You must
manually edit the schedule to adjust for daylight savings time.
You can get historical data for when a monitored entity went into maintenance mode by querying the
MaintenanceModeHistory table in the Operations Manager database.
The System Center Operations Manager SDK account must be a member of one of the following SQL Server roles in
order to take advantage of the Maintenance Mode feature:
SQLAgentUserRole
SQLAgentReaderRole
SQLAgentOperatorRole
For more information about setting the SDK action account, see Account Information for Operations Manager
The accounts that are listed under the Operational Database Account profile should have
SQLAgentOperatorRole permission on the MSDB database.
If any accounts that are listed under the Operational Database Account profile do not have access to the
SQLAgentOperatorRole permission on the MSDB database, assign the SQLAgentOperatorRole permission on
the MSDB database to each account under the Operational Database Account profile.
If you do not have any accounts listed under the Operational Database Account profile, then the accounts that
are available under the Default Action Account profile should have the SQLAgentOperatorRole permission on
the MSDB database. This permission is granted automatically during the fresh installation of SCOM 2019.
However, in case of an upgrade to SCOM 2019 from a previous version of SCOM, this permission needs to be
granted manually
To support the scenario of initiating maintenance mode directly from the agent-managed computer, Operations
Manager now supports allowing a system administrator to set the machine in maintenance mode directly from
the computer itself, without needing to perform it from the Operations console. It can be performed with the new
PowerShell cmdlet Start-SCOMAgentMaintenanceMode.
The following section describes how to work with the different options for the on-demand maintenance mode
feature.
On-Demand Maintenance Mode

To put a monitored object into maintenance mode
4. In the Windows Computers pane, right-click the computer that you want to place into maintenance mode,
click Maintenance Mode, and then click Start Maintenance Mode. You can use ctrl+click or shift+click
to select multiple computers to place into maintenance mode.
5. In the Maintenance Mode Settings dialog box, under Apply to, click Selected objects only if the
computer is to be placed into maintenance mode; otherwise, click Selected objects and all their
contained objects.
6. Select Planned if this is a planned event; otherwise, leave it cleared.
7. In the Category list, click the appropriate maintenance category.
8. Under Duration, select and enter the Number of minutes or select and enter the Specific end time, and
then click OK. A maintenance mode icon appears in the Computers pane, in the Maintenance Mode
column for the computer you selected.
NOTE
The minimum value for Number of minutes is 5. The maximum value is 1,051,200 (2 years). To start the
maintenance mode, the maximum wait time is 5 minutes.
To edit maintenance mode settings for a monitored object

4. Right-click the computer in the Windows Computers pane whose settings you want to edit, click
Maintenance Mode, and then click Edit Maintenance Mode settings.
5. In the Maintenance Mode Settings dialog box, edit the settings you want to change, and then click OK.
To stop maintenance mode on a monitored object
4. In the Windows Computers pane, right-click the computer that you want to take out of maintenance
mode, click Maintenance Mode, and then click Stop Maintenance Mode.
5. Do the following in the Maintenance Mode dialog box:
a. If you selected Selected objects and all their contained objects when you placed the computer
into maintenance mode, select Remove contained objects and then click Yes.
b. If you selected Selected objects only, clear Remove contained objects and then click Yes.
6. In the Windows Computers pane, the maintenance mode icon disappears from the Maintenance Mode
column for the computer you selected.
NOTE
Because Operations Manager polls maintenance mode settings only once every 5 minutes, there can be a delay in
an object's scheduled removal from maintenance mode.
Enable from Target System

Maintenance mode can be enabled directly from the monitored Windows computer by a systems administrator
using the PowerShell cmdlet Start-SCOMAgentMaintenanceMode. When a systems administrator or operator
runs this PowerShell cmdlet on the computer, the command logs an event in the Operations Manager event log,
and stores arguments for the maintenance activity such as duration, reason, comment, and information (like the
time when the cmdlet was invoked).
The comment field contains user information, specifically who has invoked maintenance mode. A rule that targets
the agent, runs every 5 minutes to read this registry entry on the agent with a PowerShell script
ReadMaintenanceModeRegEntry.ps1, and then marks this entry as invalid so at next invocation it will not pick
this entry. The write action, which is part of the rule and targets the management server, takes this record and sets
maintenance mode for the agent based on the record read from the registry. The frequency the rule runs can be
overridden to a custom interval.
Enable from Target System
Maintenance mode can be enabled directly from the monitored Windows computer by a server administrator
using the PowerShell cmdlet Start-SCOMAgentMaintenanceMode. When server administrator or operator
runs this PowerShell cmdlet on the computer, the command logs an event, which stores arguments for the
maintenance mode, such as duration, reason, comment, and information like time of invocation of cmdlet.
A rule that targets the agent, reads the event entry on the agent and stores this in Operations Manager database.
There is another rule Microsoft.SystemCenter.Agent.MaintenanceMode.Trigger.Rule, which runs every 4 minutes
by default, and reads this event from the Operations Manager database. It then sets maintenance mode on the
agent, based on the record read from the event. You can override the frequency rule to a custom value.
Start-SCOMAgentMaintenanceMode has the following syntax:
`Start-SCOMAgentMaintenanceMode -Duration <Double (in minutes)> [-Reason <string>] [-Comments <string>]`
NOTE
The minimum duration value accepted is five (5) minutes.
The following reasons are accepted by the cmdlet:

PlannedOther
UnplannedOther
PlannedHardwareMaintenance
UnplannedHardwareMaintenance
PlannedHardwareInstallation
UnplannedHardwareInstallation
PlannedOperatingSystemReconfiguration
UnplannedOperatingSystemReconfiguration
PlannedApplicationMaintenance
UnplannedApplicationMaintenance
ApplicationInstallation
ApplicationUnresponsive
ApplicationUnstable
SecurityIssue
LossOfNetworkConnectivity
Examples:
1. To enable for an interval of five (5) minutes and with a major reason of Planned and minor reason Other
type:
Start-SCOMAgentMaintenanceMode -Duration 5 –Reason PlannedOther
2. To enable for an interval of 10 minutes with no reason, type:
Start-SCOMAgentMaintenanceMode -Duration 10
Perform the following steps to initiate maintenance mode from the target Windows computer.
1. Log onto the computer.
2. On computers running Windows Server 2012 and higher, to run Windows PowerShell as an administrator
from the Start screen, right-click the Windows PowerShell tile, and in the app bar, click Run as
administrator.
3. Change directory to the following path C:\Program Files\Microsoft Monitoring Agent\Agent by
typing cd C:\Program Files\Microsoft Monitoring Agent\Agent .
4. Import the module MaintenanceMode.dll by typing Import-module MaintenanceMode.dll .
5. Type Start-SCOMAgentMaintenanceMode and use the parameters to configure the maintenance mode
request.
NOTE
To confirm that the Maintenance Mode request is successful you can look in the Operations Manager Event Log for an
Event ID 2222 followed by one or more events with Event ID 1215. If Event ID 2222 is present but ID 1215 is missing, this
indicates the maintenance mode request was missed. You will need to re-raise the request.
In order to re-raise the request you will need to remove the record in the registry for maintenance mode using following
command and then re-run the Start-SCOMAgentMaintenanceMode cmdlet:
Set-ItemProperty -Path "HKLM:\software\Microsoft\Microsoft Operations Manager\3.0\MaintenanceMode" -Name
record -Value ""
NOTE
To confirm that maintenance mode request is successful, look in the Operations Manager event log for event ID 2222
followed by an event with event ID 2223. In case event ID 2223 is not available, submit the maintenance mode request
again.
Schedule maintenance mode

The following section describes how to work with the different options available for the maintenance mode
scheduling feature.
Create Maintenance Schedule in the Operations console
The following procedure describes how to create a maintenance schedule for selected monitored objects for a
future date in the Operations console.
3. In the Administration workspace, expand Device Management, and then click Maintenance
Schedules.
4. From the Tasks pane, click Create Maintenance Schedule.
5. In the Create Maintenance Schedule wizard, on the Object Selection page, click Add/Remove
objects... and the Create Group Wizard - Object Selection dialog box appears.
6. In the Create Group Wizard - Object Selection dialog box, perform the following:
a. In the Search for list, the default item Computer is selected. Alternatively, you can select
Computer Group or a specific class such as SQL Server 2012 DB Engine from the drop-down list.
b. Optionally, in the Filter by part of the name box, type all or part of the object name, and then click
Search.
c. In the Available items box, select the desired objects, click Add, and then click OK.
7. On the Object Selection page, click Next.
8. In the Create Maintenance Schedule wizard, on the Schedule page, you can specify the following for
your maintenance schedule:
a. Choose the frequency as to how often you would like it to run. If you select the option Once, the task
will only run one time based on the start date and time selected.
b. Under Duration select the Start Time and for End Time, select the number of minutes or select
and enter the Specific end time.
c. Under Schedule is effective beginning, specify when this schedule is allowed to take effect and if
you require it to no longer be valid after a period of time, click the option The schedule expires on
and select a future expiration date.
NOTE
9. Click Next once you have completed configuring the schedule options.
10. In the Create Maintenance Schedule wizard, on the Details page, specify the following:
a. Create a name for the schedule in the Schedule Name box.
b. Select Planned if this is a planned event; otherwise, leave it cleared.
c. In the Category list, click the appropriate maintenance category.
d. Select Enable Schedule if you want to enable the schedule now, or clear it if you plan on enabling
the schedule later.
11. Click Finish to save your changes.
The new schedule will appear in the list of maintenance schedules and you can edit, disable, or delete a
maintenance schedule from the list. This can be accomplished by selecting the schedule from the list and choosing
the corresponding option from the Tasks pane.
Create maintenance schedule in the Web console

The following procedure describes how to create a maintenance schedule for selected monitored objects for a
future date in the Web console.
2. From the left pane in the Web console, click Maintenance Schedules.
3. From the top of the page, click + Create.
4. In the Create maintenance schedule pane, perform the following:
a. In the Search for classes, the default item Computer is selected. Alternatively, you can select
Computer Group or a specific class such as SQL Server 2012 DB Engine from the drop-down list.
b. Optionally, in the Filter by keyword box, type all or part of the object name, and then press Enter.
c. In the Available objects box, select the desired objects.
5. Expand Schedule and in this section, specify the following for your maintenance schedule:
a. Choose the frequency as to how often you would like it to run. If you select the option Once, the task
will only run one time based on the start date and time selected.
b. Under Duration select the Start Time and for End Time, select the number of minutes or select
and enter the Specific end time.
c. Under Schedule is effective beginning, specify when this schedule is allowed to take effect and if
you require it to no longer be valid after a period of time, click the option The schedule expires on
and select a future expiration date.
NOTE
6. Expand Completion and in this section, specify the following to complete the configuration of your custom
maintenance schedule:
a. Create a name for the schedule in the Schedule Name box.
b. From the Category drop-down list, select the appropriate maintenance category or leave it at the
default of other (Planned).
c. Optionally, in the Comment box, enter a description for the scheduled maintenance task.
d. Select Enable Schedule if you want to enable the schedule now, or clear it if you plan on enabling
the schedule later.
7. Click Finish to save your changes.
The new schedule will appear in the list of maintenance schedules and you can edit, disable, enable, or delete a
maintenance schedule from the list. This can be accomplished by selecting the schedule from the list and choosing
the corresponding option from the menu at the top of the page.
Enable scheduled maintenance mode with SQL Always On

In earlier releases of Operations Manager, maintenance schedules that targeted instances of SQL Server in an
Always On availability group to provide high availability of the Operations Manager databases did not work when
failover to a replica on another SQL Server instance occurred. Operations Manager 2019 includes a fix for this
issue to prevent this behavior and ensures maintenance schedules work in a failover scenario.
Guidelines
As part of fix for this issue, the existing schedules are converted to the new design. This happens
automatically while upgrading to Operations Manager 2019.
Any failures in the above operation are captured in the following database table: [OperationsManager].
[dbo].[MaintenanceModeSchedulesMigrationLogs]
Schedules which fail to get converted to the new design, should be converted manually by executing the
following scripts against the Operations Manager database. EXEC [dbo].
[p_MaintenanceScheduleMigrateSchedule] '' Example: EXEC [dbo].
[p_MaintenanceScheduleMigrateSchedule] '1A6917C6-999C -E811-837B -02155DC77B3F'
To convert all the schedules to the new design, use the following command: Delete [OperationsManager].
[dbo].[MaintenanceModeSchedulesMigrationLogs] EXEC [dbo].
[p_MaintenanceScheduleMigrateExistingSchedules]
NOTE
After you deploy the upgrade, maintenance schedules might be triggered and have a maximum delay of five (5)
minutes. You can configure the maximum delay by overriding the Maintenance Mode rule. The default value five
minutes is to avoid causing a large performance decrease on the system.
Next steps
Create and manage groups
Creating and managing groups
5 minutes to read
In System Center Operations Manager, groups are logical collections of objects, such as Windows-based
computers, hard disks, or instances of Microsoft SQL Server. You create a group by using the Create Group
Wizard. You can explicitly assign membership to a group or you can create rules that will generate a dynamic
group membership.
Some of the purposes for using groups are:
To scope overrides to a specific subset of computers.
To scope alert notifications or product connector subscriptions for a specific set of computers.
To scope user consoles, so the user role only sees the servers they are responsible for.
To scope a set of computers that need to go into a scheduled maintenance mode.
To scope application views only to computers that host a given application.
To create a rollup health state view of an otherwise unrelated set of computers.
To create a set of computers for a report.
Using the Operations console in the Authoring workspace, you can only create instance groups. To create a
computer group, you must use the Authoring console or work directly in the XML of a management pack. The
following image shows the display of groups in the Operations console.
Computer groups only contain computers. Instance groups can contain all object types, such as an instance of a
health service or an instance of a SQL database. Both computer groups and instance groups can contain other
computer and instance groups. Another way to view the difference between the group types is:
An instance group is populated with objects that match your criteria.
A computer group is populated by computers that host objects that match your criteria.
To create a group based on a hosting relationship, such as all computers that are running SQL Server, you must
use the Visual Studio Authoring Extensions for Operations Manager or work directly in the XML of a
management pack.
The most common objects you will place in your groups are Windows Computer objects. The most common
way to dynamically assign computers to the groups is by using a property of the Windows Computer class. For
example, Organizational Unit is a property of the Windows Computer class, so you can create a group that
makes all computers in a specific organizational unit members of the same group. The following image shows the
properties of an object in the Windows Computer class, which you can view in the details pane of the
Monitoring workspace by selecting the Windows Computers state view.
You can assign both explicit and dynamic members in the same group definition, and you can exclude explicit
members. For examples of dynamic group queries and formulas, see Operations Manager Dynamic Group
Examples.
To create a group in Operations Manager

3. Right-click Groups, and then click Create a new Group to start the Create Group Wizard.
4. On the Enter a name and description for the new group page, do the following:
a. Type the Name for the group.
b. Optionally, type the Description for the group. A description of the group membership makes it
easier to select the right group for views, overrides, and so forth.
c. Select a destination management pack from the list, or click New to create a management pack
with the Create a Management Pack Wizard.
d. Click Next.
5. On the Explicit Members - Choose Members from a List page, you can add explicit objects to the
group or click Next to continue to the Dynamic Members configuration. To add explicit group members,
click Add/Remove Objects and then perform the following steps:
a. In the Search for list, select an object type, such as Windows Computer.
Search.
c. In the Available items box, select the desired objects, click Add, and then click Next.
6. On the Dynamic Members - Create a Membership Formula page, you can add a dynamic membership
formula to the group or click Next to continue to the Subgroups page. To add a dynamic membership
formula, click Create/Edit rules and then perform the following steps:
WARNING
This procedure tells you how to create a query for Windows computers based on NetBIOS computer name.
a. In the Query Builder dialog box, leave the default Windows Computer and click Add.
b. In the Property list, select NetBIOS computer name.
c. In the Operator list, select Contains.
d. Set Value to part of the name of the computers you want in the group, such as NY or MKTG.
NOTE
Click Insert to add an Expression or group expressions with OR or AND operators. Repeat the preceding
steps to add additional object types to the rule.
e. Click OK, review the Query formula, and then click Next.
7. On the Choose Optional Subgroups page, either click Next to not add groups to the group, or click
Add/Remove Subgroups to add groups, for example.
a. In the Group Selection dialog box, in Filter by part of name, you can optionally type part or the
all of the group's names, and then click Search.
b. In the Available items text box, select the desired groups, click Add, click OK, and then click Next.
8. On the Excluded Members - Specify Exclude List page, click Finish to not exclude objects from the
group, or click Exclude Objects, and then perform the following steps:
a. In the Object Exclusion dialog box, from the Search for list, select an object type, such as
Windows Computer.
Search.
c. In the Available items text box, select the objects you want to exclude, click Add, click OK, and
then click Finish.
NOTE
It can take approximately one minute to populate the membership of a group.
To view members, state, and diagram of a group

1. In the Authoring workspace, click Groups.
2. In the results pane, click the group you want to view.
3. In the Tasks pane, click:
View Group Members to view a list of all members of the group with the health state of each
member.
View Group State to view a state view of the group.
View Diagram to view a diagram of the group.
Next steps
Running tasks in Operations Manager
2 minutes to read
In the System Center Operations Manager Operations console, the Tasks pane provides links to tasks. A task is a
user-initiated action from the Operations console that is run on an Operations Manager agent or on the computer
where the Operations console is launched from. The tasks that are available depend on the management packs
that are installed. For example, Operations Manager comes with a core set of functionality that provides the ping
task. When you install the SQL Server management pack, it adds SQL -specific tasks, such as a task to start or stop
the SQL Server agent.
NOTE
If the Tasks pane is not displayed, click Tasks on the toolbar to display it.
Click an alert or object to see tasks for that alert or object. Click a task to run the task.
In the example above, if you click the task Display Local Users, you see a Run Task dialog box:
Tasks use the default action account, unless you specify other credentials in this dialog box. Tasks can also be
configured by a management pack author to use a specific Run As profile.
Generally, you should accept the defaults and click Run. You will then see a Task Status window:
In this instance, the task completed successfully. Task Output provides you with the results of the task, in this case
it will return all of the user accounts defined on the server.
Next steps
To stop monitoring of a computer, group of computers or monitored object temporarily during planned
maintenance using a schedule, or to stop monitoring while troubleshooting an issue, see How to Suspend
Groups help categorize, classify or arrange one or more monitored objects to manage targeting of
visualized data, overrides, reports, and more. To learn how to create groups and common uses for groups,
see Creating and Managing Groups.
Operations Manager extends the PowerShell command-line environment and task-based scripting
technology to automate most Operations Manager administrative tasks. See Using Operations Manager
Shell.
Connecting management groups in Operations
Manager
6 minutes to read
Connecting management groups in System Center Operations Manager enables the ability to view and interact
with data from multiple management groups in a single Operations console. The management group in which the
consolidated view is available is called the local management group, and those that contribute their data to the
consolidated view are called the connected management groups. They relate to each other in a hierarchical
fashion, with connected groups in the bottom tier and the local group in the top tier. The connected groups are in a
peer-to-peer relationship with each other. Each connected group has no visibility or interaction with the other
connected groups; the visibility is strictly from the local group into the connected group.
NOTE
Operations Manager does not support communication of data between peer management groups. Only the local to
connected hierarchy configuration is supported. Multiple tiers, where a management group would be both a local group and
a connected group, are not supported.
When you connect management groups, you are not deploying any new servers; rather, you are allowing the local
management group to have access to the alerts and discovery information that is in a connected management
group. In this way, you can view and interact with all the alerts and other monitoring data from multiple
management groups in a single Operations console. In addition, you can run tasks on the monitored computers of
the connected management groups.
Connecting management groups offers these additional services:
Consolidated monitoring and alerting for greater than 6,000 agents
Consolidated monitoring across trust boundaries
IMPORTANT
Both management groups must be running the same build of Operations Manager. For example, both management groups
must be running System Center 2016 - Operations Manager.
In addition to all of the communications channels used in the multiple server, single management group
configuration, connected management groups require communication between the management servers of the
local group and the management servers of the connected group over TCP 5723 and 5724. For a complete list of
ports used by Operations Manager, see Configuring a Firewall for Operations Manager.
Connected management groups support all Operations Manager user roles and makes use of the Operations
Manager Connector Framework to enable bidirectional communication between the connected groups and local
groups.
In this procedure, you create a connection between two management groups. These management groups can be
in the same domain, or they can be in trusted domains. You can connect to management groups that are in
domains that are not trusted, but you cannot view data from those domains until you add an account from the
domain of the local management groups to an Operations Manager role for the connected management group.
To do this, a trust must be established between the domains.
Before you start
1. To connect management groups, you must provide the fully qualified domain name (FQDN ) of a
management server of the connected management group. The management server of the local
management group must be able to resolve this FQDN. If the two management groups do not use the
same Domain Name System (DNS ) service, you must create a secondary DNS zone in the DNS service
that the local management group uses. This secondary DNS zone transfers the DNS information from the
primary DNS zone of the connected management group. The transferred information is essentially a copy
of the DNS information that is available to the management server of the local management group.
2. Add the System Center Data Access service and System Center Management Configuration service
account of the connected management groups to the Operations Manager Administrator role for the
connected management group, or add it to the domain-based Operations Manager Administrator security
group in the connected management group's domain, which has already been added to the Operations
Manager Administrator role.
3. Collect the System Center Data Access service and System Center Management Configuration service
account credentials from the connected management groups. These credentials are needed when you add
the connected management group in the local management group.
4. Identify users in the domain of the local management group that will need access to data from the
connected management groups. They must be added to the appropriate Operations Manager roles in the
connected management group.
To connect management groups

1. Log on to the computer with an account that is a member of the Operations Manager Administrators user
role.
2. In the Operations console that is connected to the destination management group, click Administration.
3. In the Administration workspace, right-click Connected Management Groups, and then click Add
Management Group.
4. In the Add Management Group dialog box, do the following:
a. Type the Management Group name of the management group to be connected.
b. Type the fully qualified domain name (FQDN ) of a Management Server in the desired
management group to be connected.
c. Specify the account that will be used for the initial connection to the connected management group,
either by leaving Use SDK service account selected or selecting Other user account and typing
in the User name, Password, and Domain. The account must be a member of the Operations
Manager Administrators role for the connected management group.
5. Click Add.
To grant access to Connected Management Groups

1. Identify users in the local management group that need access to the connected management groups.
2. Add those users as members to the appropriate user role in the connected management groups.
NOTE
If local and connected management groups are not in the same domain and there is no trust relationship between
the two domains, you will have to create accounts in the connected management group domain for the users in the
local management group domain to use.
3. In the Operations console for the local management group, in the Administration view, expand Security,
and then click User Roles.
4. In the right pane, right-click the user role to which you want to grant connected management group access,
and then click Properties.
5. On the Group Scope tab, select the connected management groups to which you want to grant access to
this user role, and then click OK. A user with both permission and access to at least one connected
management group will see the Show Connected Alerts button in the toolbar of any Alert view in the
Monitoring space.
6. A Log On dialog box appears and prompts the user for credentials (to log on to the connected
management groups). Enter the credentials, and then click OK. Alerts appear from all connected
management groups for which you have access and permission. You can run tasks in the managed
computers of connected management groups.
Next steps
Groups help categorize, classify or arrange one or more monitored objects to manage targeting of
visualized data, overrides, reports, and more. To learn how to create groups and common uses for groups,
see Creating and Managing Groups.
Operations Manager extends the PowerShell command-line environment and task-based scripting
technology to automate most Operations Manager administrative tasks. See Using Operations Manager
Shell .
To learn how to launch common tools or commands from the Operations Manager console to help reduce
your time investigating and diagnosing issues, see Running Tasks in Operations Manager.
Using Operations Manager Shell
2 minutes to read
In System Center Operations Manager, the Operations Manager Shell is installed with the Operations Manager
console; it provides a command-line environment and task-based scripting technology that you can use to
automate many Operations Manager administrative tasks.
The Operations Manager Shell is built on Windows PowerShell. The Operations Manager Shell extends Windows
PowerShell with an additional set of cmdlets, which can either be run directly from the command shell prompt or
called from within a script. Cmdlets can be used individually to perform a specific task, or they can be combined
with other cmdlets to perform complex administrative tasks. Unlike traditional command-line environments that
work by returning text results to the end user or routing ("piping") text to different command-line utilities,
Windows PowerShell manipulates Microsoft .NET Framework objects directly. This provides a more robust and
efficient mechanism for interacting with the system.
To open the Operations Manager Shell, from the Windows start screen, type Operations Manager and select
Operations Manager Shell from the search results. You can also import the Operations Manager module into an
existing Windows PowerShell session by typing the following at the command prompt:
Import-Module -Name OperationsManager
You can access cmdlet help in the Operations Manager Shell by typing Get-Help cmdlet name or view the help
online at Cmdlets in System Center Operations Manager.
To learn more about Windows PowerShell, see Windows PowerShell Getting Started Guide.
Next steps
To learn how to launch common tools or commands from the Operations Manager console to help reduce
your time investigating and diagnosing issues, see Running Tasks in Operations Manager.
How to manage resource pools
4 minutes to read
A Resource Pool is a collection of management servers and/or gateway servers used to distribute work among
themselves and take over work from a failed member. In this section we will cover how to create and modify
resource pools and their membership, as well as properly configure a resource pool dedicated to monitor UNIX
and Linux computers.
To create a resource pool

3. In the navigation pane, click Resource Pools.
4. In the Tasks pane, click Create Resource Pool.
5. In the Create Resource Pool wizard, on the General Properties page, enter a name and, optionally, a
description for the resource pool, and then click Next.
6. On the Pool Membership page, click Add.
7. In the Member Selection window, enter text to filter the search results if desired, and then click Search. If
you click Search without entering anything in the filter field, all available management servers will be
displayed.
8. In Available items, select the servers that you want in the resource pool, click Add, and then click OK.
9. Click Next.
10. On the Summary page, review the settings and then click Create.
11. When the wizard completes, click Close.
Modifying resource pool membership

When you view the resource pools in the Administration workspace, you will see that resource pools that you
create have a manual membership type and resource pools created when Operations Manager was installed have
an automatic membership type, as shown in the following image.
By default, all management servers are members of the resource pools created when Operations Manager is
installed, and any management servers added to the management group are automatically added to the resource
pools that have an automatic membership type. You can remove individual management servers from those
resource pools, however that will change the membership type to manual. If you add a management server to a
management group after the membership type of the resource pools created when Operations Manager was
installed is changed to manual, you must add the management server to the resource pool manually.
NOTE
The membership of the All Management Servers Resource Pool is read-only. To change its membership from automatic to
manual, run the following PowerShell code in the Operations Manager Command Shell:
Get-SCOMResourcePool -DisplayName "All Management Servers Resource Pool" | Set-SCOMResourcePool -
EnableAutomaticMembership 0
To remove a member from an automatic resource pool

3. In the navigation pane, click Resource Pools.
4. In the results pane, click the resource pool that you want to modify.
5. In the Tasks pane, click Manual Membership, and then click Yes in the Manual Membership message.
IMPORTANT
When you click Yes, the membership type of the selected resource pool changes to manual. Even if you make no
changes to the resource pool membership and cancel the properties dialog box, the membership type will remain
manual after this step.
6. On the General Properties page for the resource pool, click Next.
7. On the Pool Membership page, click the management servers that you want to remove from the resource
pool, click Remove, and then click Next.
8. On the Summary page, click Save.
Configure certificates for UNIX and Linux dedicated resource pools

An additional task must be performed in order to configure management servers that are members of a resource
pool dedicated for managing UNIX and Linux computers. Operations Manager uses certificates to authenticate
access to the computers it is managing. When the Discovery Wizard deploys an agent, it retrieves the certificate
from the agent, signs the certificate, deploys the certificate back to the agent, and then restarts the agent.
To configure high availability, each management server in the resource pool must have all the root certificates that
are used to sign the certificates that are deployed to the agents on the UNIX and Linux computers. Otherwise, if a
management server becomes unavailable, the other management servers would not be able to trust the
certificates that were signed by the server that failed. The process for this task is as follows:
1. Export the root certificates from each management server in the resource pool to a file.
2. Import all the exported certificate files into each management server (except for the file that was exported
by that same server).
To configure certificates for high availability
1. Log on to a management server to start the process of exporting certificates.
2. At the command prompt, change the directory to %ProgramFiles%\System Center Operations Manager
2012\Server.
3. Run the following command, specifying a file name of your choosing such as Server3.cert:
scxcertconfig.exe - export <filename>
4. Copy the exported file to a shared directory that is accessible by all the management servers in the resource
pool.
5. Repeat the previous four steps until the shared directory contains all the exported certificate files from each
management server in the resource pool.
6. Log on to a management server to start the process of importing certificates.
7. At the command prompt, change the directory to %ProgramFiles%\System Center Operations Manager
2012\Server.
8. Run the following command for each exported certificate file (except for the file that was exported by the
current management server):
scxcertconfig.exe -import <filename>
NOTE
If you attempt to import the certificate file that was exported by that same management server, the process will fail
with an error message that the object or property already exists.
9. Repeat the previous three steps until all the certificate files have been imported to the applicable
management servers in the resource pool.
10. Delete the certificate files from the shared directory. Although the file contains only the public key of the
certificate, you should still treat it as a security-sensitive file.
Perform this procedure whenever you add a new management server to the resource pool so that high availability
is maintained.
Next steps
For information about deployment considerations for resource pools, see Planning Resource Pool Design
Monitoring the Health of the Management Group
2 minutes to read
System Center Operations Manager introduces a new dashboard view that provides a comprehensive picture of
the health of your management group. The dashboard tries to answer the question, "do I need to do anything?"
The Management Group Health view under the Operations Manager folder, allows you to see at a glance the
health state of all management group functions, such as resource pools, and the management group
infrastructure, such as management servers. It also shows you recent agent health state including gray agents,
agent configuration for agents pending management, and agent versions.
You can display Management Group Health on a SharePoint site by integrating with Operations Manager,
giving all authorized users a useful summary of management group status. For more information, see Using
SharePoint to view Operations Manager data.
Management Group Health automatically refreshes every 15 minutes by default. To manually refresh the view,
right-click the view and click Refresh. It may take some time before the dashboard starts to show data. The agent
data is recalculated every 15 minutes, and not when you refresh the dashboard.
This topic describes the specific information you will see in each cell of the Management Group Health
dashboard view.
Management Group Functions
Management Group Functions shows you the health state of any of the following functions that are installed in
your management group:
Agentless exception monitoring
Audit collection services
System Center Data Access service group
System Center Management service group
Network discovery
Resource pools
Web user interfaces (web console and reporting web site)
You can open Health Explorer, alert view, diagram view, event view, performance view, and state view for any of
the functions listed. To open a different view, right-click the display name for the function, and click Health
Explorer or Navigation.
Management Group Infrastructure
Management Group Infrastructure shows you the health state of any of the following infrastructure features
that are installed in your management group:
Data warehouse database
Management group
Management servers
Gateway servers
Agents
You can open Health Explorer, alert view, diagram view, event view, performance view, and state view for any of
the features listed. To open a different view, right-click the display name for the feature, and click Health Explorer
or Navigation.
Active Alerts
Active Alerts displays all alerts generated by management group components installed in your management
group.
Agent Configuration
In Agent Configuration, you can see how the status of agents in the Pending Management folder in the
Administration workspace. Agents can be pending management for the following reasons:
Manual agent install
Installation in progress
Agent update in progress
Repair in progress
Agent license limit exceeded
Failed agent installation
Agent requires update
Repair failed
Agent Versions
Agent Versions lists the number of agents running each agent version number, including cumulative updates.
Next steps
See How to clear the cacheto understand how to clear the Operations console and agent health service
cache.
How and When to Clear the Cache
2 minutes to read
In System Center Operations Manager, when troubleshooting an issue with the Operations console or with an
agent, you may see recommendations to "clear the cache." For additional information about troubleshooting an
issue with an agent, see Not monitored and gray agents.
To clear the cache

The following table explains how and when to clear the console cache or agent cache.
CACHE HOW TO CLEAR WHEN RESULTS
Operations console Open the Operations Use this method to open Opening the Operations
console with the the Operations console if console with
/clearcache parameter. you experience errors trying /clearcache deletes the
to retrieve data in views, following file:
such as
ObjectNotFoundExceptions, %systemdrive%\Users*usern
or when the cache file grows ame*\AppData\
too large and you want to Local\Microsoft\
reduce its size on disk. Microsoft.EnterpriseManage
ment.Monitoring.Console\
momcache.mdb
Health service on agent- 1. In the Monitoring This should be the final step Clearing the agent cache can
managed computer workspace, expand when troubleshooting issues cause data loss
Operations Manager with the agent, before of monitoring data from
and then expand Agent uninstalling and reinstalling that system.
Details. the agent.
2. Click Agent Health State. 1. Stops the Microsoft
3. In Agent State, select an Monitoring Agent service.
agent. 2. Deletes the health service
4. In the Tasks pane, click store files.
Flush Health Service State 3. Resets the state of the
and Cache. agent, including all rules,
monitors, outgoing data,
and cached
management packs.
4. Starts the Microsoft
Monitoring Agent service.
When the service restarts,

the agent requests
configuration from its
primary assigned
management server.
Note: Because this task
deletes the cached data
in the health service store
files,
including the record of this
task itself,
no task status is reported
on completion of the task.
CACHE HOW TO CLEAR WHEN RESULTS
Health service on 1. In the Monitoring Run this task on a Clearing the agent cache can
management server workspace, expand management server when cause
Operations Manager the management server is data loss of monitoring data
and then expand not functional, a restart has from
Management Server. not fixed the problem, and agents to the management
2. Click Management you have exhausted other server.
Servers State. troubleshooting options.
3. In Management Server 1. Stops the Microsoft
State, select a management Monitoring Agent service.
server. 2. Deletes the health service
4. In the Tasks pane, click store files.
Flush Health Service State 3. Resets the state of the
and Cache. agent, including all rules,
monitors, outgoing data,
and
cached management packs.
4. Starts the Microsoft
Monitoring Agent service.
Note: Because this task
deletes the cached
data in the health service
store files,
including the record of this
task itself,
no task status will be
reported
on completion of the task.
Next steps
To understand how Operations Manager monitors the communication channel between an agent and it's
primary management server to ensure it is responsive and available, see How Heartbeats Work in
Operations Manager.
How to configure Operations Manager to
communicate with SQL Server
8 minutes to read
If after installing System Center Operations Manager, you move the Operations Manager operational or data
warehouse database to a different SQL Server instance, move the databases to a SQL Server Always On
availability group, or reconfigure the SQL Server instance, you need to follow the steps below to reconfigure the
management group to reference the new TCP/IP Port, instance name, or computer name.
How to configure the Operations Manager operational database

1. On each management server run regedit from an elevated Command Prompt, then edit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database Change
DatabaseServerName to computer\<instance> followed by a comma, and then the SQL Server
port number (computer\instance,portNumber) . If you are hosting the database on a SQL Server
cluster, replace computer with the virtual network name of the cluster. If the database is part of a SQL
Always On Availability Group, replace computer\<instance> with the availability group listener name
in the format of <AvalabilityGroupListnerName,portNumber> .
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup Change
DatabaseServerName to computer\<instance> followed by a comma, and then the SQL Server
port number (computer\instance,portNumber) . If you are hosting the database on a SQL Server
Always On Availability Group, replace computer\<instance> with the availability group listener name
2. On each management server, edit the following file:
%ProgramFiles%\System Center 2016\Operations Manager\Server\ConfigService.config for System Center 2016
- Operations Manager, or for current branch
%ProgramFiles%\Microsoft System Center\Operations Manager\Server\ConfigService.config :
Under the tag <Category Name=”Cmdb”> , change the value for ServerName to computer\<instance>
and change the value for PortNumber to the SQL Server port number.
Under the tag <Name=”ConfigStore”> , change the value for ServerName to computer\<instance> and
change the value for PortNumber to the SQL Server port number.
3. On the SQL Server instance hosting the operational database, configure the following:
a. Open SQL Server Management Studio.
b. In the Object Explorer pane, expand Databases, expand the operational database (for example,
OperationsManager), expand Tables, right-click dbo.MT_Microsoft$SystemCenter$ManagementGroup and then
click Edit Top 200 Rows. In the results pane, scroll to the right to the column titled
column.SQLServerName_<GUID> .
c. In the first row, enter computer\<instance> followed by a comma, and then the SQL Server port number
(computer\instance,portNumber) . If you are hosting the database on a SQL Server cluster, replace computer
with the virtual network name of the cluster. If the database is part of a SQL Always On Availability Group,
replace computer\instance with the availability group listener name in the format of
<AvalabilityGroupListnerName,portNumber> .
d. Right-click dbo.MT_Microsoft$SystemCenter$OpsMgrDB$AppMonitoring and then click Edit Top 200 Rows. In
the results pane, scroll to the right to the column titled column.SQLServerName_<GUID> .
e. In the first row, enter computer\<instance> followed by a comma, and then the SQL Server port number
How to configure the Operations Manager Reporting data warehouse

database
1. On each management server run regedit from an elevated Command Prompt, then edit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
Change DataWarehouseDBServerName to computer\<instance> followed by a comma, and then the
SQL Server port number (computer\instance,portNumber) . If you are hosting the database on a SQL Server
Always On Availability Group, replace computer\<instance> with the availability group listener name in the
format of <AvalabilityGroupListnerName,portNumber> .
2. On the new SQL Server instance hosting the Reporting data warehouse database, open SQL Management
Studio.
3. In the Object Explorer pane, expand Databases, expand the operational database (for example,
OperationsManager), expand Tables, right-click dbo.MT_Microsoft$SystemCenter$DataWarehouse , and then
click Edit Top 200 Rows.
4. In the results pane, scroll to the right to the column titled MainDatabaseServerName_<GUID> .
5. In the first row, enter followed by a comma, and then the SQL Server port number
computer\<instance>
6. Right-click dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring , and then click Edit Top 200 Rows.

computer\<instance>
9. Right-click dbo. MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring_Log , and then click Edit Top 200

Rows.
10. In the results pane, scroll to the right to the column titled Post_MainDatabaseServerName_<GUID> .
computer\<instance>
12. Right-click dbo. MT_Microsoft$SystemCenter$DataWarehouse$ , and then click Edit Top 200 Rows.
computer\<instance>
15. Right-click dbo. MT_Microsoft$SystemCenter$DataWarehouse_Log$ , and then click Edit Top 200 Rows.
16. In the results pane, scroll to the right to the column titled Post_MainDatabaseServerName_<GUID> .
computer\<instance>
18. Right-click dbo.MT_Microsoft$SystemCenter$OpsMgrDWWatcher , and then click Edit Top 200 Rows.
computer\<instance>
21. In the Object Explorer pane, expand Databases, expand the data warehouse database (for example,
OperationsManagerDW ), expand Tables, right-click dbo.MemberDatabase , and then click Edit Top 200 Rows.
22. In the results pane, scroll to the right to the column titled column.ServerName .
computer\<instance>
Update Reporting server

Perform the following steps to modify the configuration of Operations Manager reporting server component after
you have updated the configuration of the Reporting data warehouse database.
1. Log on to the computer hosting the Operations Manager Reporting server.
2. Run regedit from an elevated Command Prompt, then edit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting . Change
DWDBInstance to computer\<instance> followed by a comma, and then the SQL Server port number
(computer\instance,portNumber) . If you are hosting the data warehouse database on a SQL Server cluster,
replace computer with the virtual network name of the cluster. If the database is part of a SQL Always On
Availability Group, replace computer\<instance> with the availability group listener name in the format of
3. Click OK.
4. Open a browser and go to the reporting webpage, http://localhost/reports_instancename . If there is no
named instance, go to http://localhost/reports .
5. Click Show Details and then click Data Warehouse Main. Locate Connection string and the line that
reads source=<computer>\<instance>;initial .
6. Change the Connection string to contain the new data warehouse server name. For example,
computer\<instance> followed by a comma, and then the SQL Server port number
replace computer\<instance> with the availability group listener name in the format of
7. Click Apply.
8. Change the connection string for AppMonitoringSource.
9. Click Application monitoring, and then click .NET monitoring.
10. Click AppMonitoringSource.
11. On the AppMonitoringSource page, click Properties and change Connection string to contain the new
data warehouse main data source server name. For example, computer\<instance> followed by a comma,
and then the SQL Server port number (computer\instance,portNumber) . If you are hosting the database on a
SQL Server cluster, replace computer with the virtual network name of the cluster. If the database is part of
a SQL Always On Availability Group, replace computer\<instance> with the availability group listener name
12. Click Apply.
13. Close the browser.
Next steps
See How to move the Operational database to understand the sequence and steps for moving the
Operations Manager operational database to a new SQL Server instance.
See How to move the Reporting data warehouse database to understand the sequence and steps for
moving the Operations Manager Reporting data warehouse database to a new SQL Server instance.
Scheduled Maintenance in Operations Manager
2 minutes to read
This topic details the default schedule for System Center Operations Manager maintenance tasks.
Maintenance Tasks Schedule

By default, System Center Operations Manager performs maintenance tasks daily to maintain optimal
performance of the Operations Manager database and data warehouse database. These maintenance tasks are
defined as system rules in the Operations Manager management pack.
The following table displays the maintenance tasks and the time they are scheduled to run:
TASK DESCRIPTION SCHEDULE
Discovery Data Grooming A rule that deletes aged discovery data Every day at 2 AM
from the Operations Manager database.
Optimize Indexes A rule that executes a daily database Every day at 2:30 AM
maintenance stored procedure name
p_OptimizeIndexes against some of the
tables. This rule cannot be changed
or modified.
Partition and Grooming A rule that runs workflows to partition Every day at 12 AM
and deletes aged data from the
Detect and Fix Object Space A rule that repairs data block corruption Every 30 minutes
Inconsistencies in database schema objects.
Alert Auto Resolve Execute All A rule that automatically resolves active Every day at 4 AM
alerts after a period of time.
Standard Data Warehouse Data Set A rule that calls a number of other Every 60 seconds
maintenance rule stored procedures to aggregate,
optimize, and groom data in the data
warehouse database.
To check the schedules for the grooming jobs

1. Log on to the computer with an account that is a member of the Operations Manager Administrator role.
2. Open the Operations console and in the console, click Authoring from the left-hand pane.
3. Under Authoring, expand Management Pack Objects, and then click Rules.
4. In the Rules pane, change the scope of management pack objects by clicking Scope.
5. In the Scope Management Pack Objects by target(s) dialog box, click Clear All.
6. In Look for, type All Management Servers Resource Pool to locate the target from the System Center
Core Library.
7. Select All Management Servers Resource Pool.
8. In Look for, type Standard Data Set to locate the target and select it. Click OK.
9. In the Rules pane, right-click the specific rule listed in the table earlier, and then click Properties.
10. In the Properties dialog box, click the Configuration tab.
11. Under Data Sources, click View to display the configured schedule for the rule.
12. Click Close twice to close the Properties dialog box.
NOTE
The scheduled times of the grooming jobs cannot be reconfigured by using an override. If you need to change the
schedules of these maintenance tasks, you must first disable them with an override and then create new system rules
that match the configuration of the original rules with new schedules.
Next steps
Manager Reporting data warehouse database and how to modify those settings, please see How to
configure grooming settings for the Operations Manager Reporting data warehouse database.
Manager operational database and how to modify those settings, please see How to configure grooming
settings for the Operations Manager database.
See also Monitoring the Health of the Management Group to understand how you can quickly asses the
functional state of your management group.
How to Move the Reporting Server Role
5 minutes to read
You can move the System Center Operations Manager Reporting server component to a new server, or reinstall
the component on the original server.
During this move, Operations Manager stops storing data in the OperationsManagerDW database until you
complete the Operations Manager reporting server reinstall.
Use the procedures in this article to move the reporting server to a new server and verify the success of the move.
You must back up any custom reports authored outside of Operations Manager, favorites, and schedules which are
stored in the report server database. For more information about the preparation and steps required to move the
SQL Server reporting services installation, see Moving the Report Server Databases to Another Computer (SSRS
Native Mode).
NOTE
Ensure that you follow all steps precisely, as not doing so might result in data corruption.
Migration Overview
The migration process for Reporting Services includes manual and automated steps. The following tasks are part
of a report server migration:
Back up databases and configuration files, such as Web.config if you configured report server to enable FIPS
compliance.
Back up the encryption key.
Install a new instance of SQL Server. If you are using the same hardware, you can install SQL Server side-by-
side with your existing installation if it was one of the supported versions.
Configure the report server.
Install Operations Manager Reporting server component.
Move the report server database from your existing installation to your new SQL Server installation.
Restore settings defined in Web.config to include custom settings enabled in the previous configuration.
Backup data
1. Create a full backup of the data warehouse database. The default name is OperationsManagerDW. Also
create a full backup of the ReportServer and ReportServerTempDB database. For more information, see
Create a Full Database Backup (SQL Server).
2. On the current Operations Manager reporting server, backup the SSRS encryption key. For more information,
see SSRS Encryption Keys - Back Up and Restore Encryption Keys.
3. Back up the report server configuration files. Files to back up include:
Web.config
Uninstall Operations Manager reporting server

1. On the current Operations Manager reporting server, uninstall the Operations Manager reporting server
component as follows:
a. Open Control Panel, and then click Programs and Features.
b. In Programs and Features, select System Center Operations Manager, and then click
Uninstall/Change.
c. In the Operations Manager Setup wizard, click Remove a feature.
d. In the Select features to remove page, select Reporting server, and then click Uninstall. Click Close
when the wizard finishes.
2. On the SQL Server instance hosting the data warehouse database, restore the data warehouse database you
previously backed up. For more information, see Restore a Database Backup (SQL Server Management
Studio).
Install SQL Server Reporting Services

1. If you are installing the Operations Manager reporting server component on a new server, perform a new
install SQL Server Reporting Services.
2. If you are reinstalling the Operations Manager reporting server component on the original server, you must
remove any data that is left from the original installation by doing the following:
a. Copy the ResetSRS.exe tool from the SupportTools folder on the product source media to a local folder.
b. Open a command prompt window using the Run as Administrator option and run the tool as follows:
ResetSRS.exe <SQL Server instance name> . Here, SQL Server instance name is the SQL Server instance that SQL
Reporting Services is installed on, such as Instance1. If SQL Server is using the default instance, enter
MSSQLSERVER.
d. Configure the report server Web service and portal URL, and report server database using the Reporting
Services Configuration tool. For more information, see Configure a Report Server (Reporting Services Native
Mode).
Verify the installation of SQL Report server
If you are reinstalling the Operations Manager reporting server component on the original server, perform the
following steps to confirm SQL Reporting Services is working correctly.
1. Run the Reporting Services Configuration tool and connect to the report server instance you just installed. The
Web Service URL page includes a link to the Report Server Web service. Click the link to verify you can access
the server.
2. Open a browser and type the report server URL in the address bar. The address consists of the server name and
the virtual directory name that you specified for the report server during setup. By default, the report server
virtual directory is named ReportServer. You can use the following URL to verify report server installation:
http:///ReportServer<_instance name>. The URL will be different if you installed the report server as a named
instance.
3. To verify that the web portal is installed and running, open a browser and type the Web Portal URL in the
address bar. The address consists of the server name and the virtual directory name that you specified for the
web portal during setup or in the Web Portal URL page in the Reporting Services Configuration tool. By default,
the web portal virtual directory is Reports. You can use the following URL to verify the web portal installation:
http:///Reports<_instance name>.
Install Operations Manager Reporting server

1. On the new Operations Manager reporting server, install the Operations Manager Reporting server component
as follows:
a. On the Configuration, SQL Server instance for reporting services page, make sure the SQL Server
instance refers to the new SQL Server instance if you are moving reporting to a new server.
b. On the Configuration, Configure Operation Manager accounts page, be sure the Data Reader account is
the same account previously used for the report server.
If you are restoring the original configuration on a new SQL Server reporting services instance, restore the original
ReportServer and ReportServerTempDB databases for SQL Server Reporting services to preserve your custom
reports, favorites, schedules from the original reporting services deployment.
1. Verify the RSExecRole is a database role with the report server database and temporary database.
RSExecRole must have select, insert, update, delete, and reference permissions in the report server
database tables, and execute permissions on the stored procedures.
2. Restore the encryption keys you backed up earlier. For more information, see SSRS Encryption Keys - Back Up
and Restore Encryption Keys.
3. Restore custom settings defined in Web.config enabled in the previous configuration.
4. Restart the Report Server service.
After completing the installation and post-configuration steps, perform the following to confirm Operations
Manager reporting is working correctly.
1. Verify that you can successfully run a report from the Operations console.
2. Ensure that the health state of all Management servers is Healthy.
Next steps
See How to move the Operational database to understand the sequence and steps for moving the
Operations Manager operational database to a new SQL Server instance.
See How to move the Reporting data warehouse database to understand the sequence and steps for moving
the Operations Manager Reporting data warehouse database to a new SQL Server instance.
How to move the Operational database
3 minutes to read
After the initial deployment of System Center Operations Manager, you might need to move the operational
database from one Microsoft SQL Server-based computer to another.
During the move, you need to stop services on your management servers, back up the database, restore the
database, update the registry and configuration file on management servers, update database tables, add new
Logins, and modify User Mapping settings for Logins. For more information, see SQL Server documentation.
NOTE
This procedure can result in data loss if it is not performed correctly and within a reasonable length of time of the failure.
Ensure that you follow all steps precisely, without unnecessary delays between the steps.
Summary of steps
Moving the Operational database
Stop the Operations Manager services
Backup the Operational database on the old SQL Server instance
1. On the original SQL Server instance hosting the operational database, use Microsoft SQL Server
Management Studio to create a full backup of the database. The default name is OperationsManager.
For more information, see How to: Back Up a Database (SQL Server Management Studio).
2. Copy the backup file to a local drive of the new SQL Server instance.
Restore the Operational database on the new SQL Server instance
1. Use Microsoft SQL Server Management Studio to restore the operational database. (In the previous step,
you moved the database backup file to a local drive of the new SQL Server instance.) In this step, you can
change the name of the database and choose the file location.
For more information, see How to: Restore a Database Backup (SQL Server Management Studio).
2. In SQL Server Management Studio, verify that the database is online.
Update the registry and configuration files on the management servers, and Operational database
After moving the Operations Manager operational database to a different SQL Server instance, you will need to
follow the steps below to reconfigure all management servers in the management group to reference the new
computer name and instance. This requires modifying the registry, the configuration service configuration file, and
several tables in the operational database. The steps are detailed in the How to configure Operations Manager to
communicate with SQL Server.
Update security credentials on the new SQL Server instance hosting the operational database
1. On the new SQL Server instance hosting the operational database, open SQL Management Studio.
2. Expand Security, then expand Logins, and add the data writer account name.
3. Under Logins, add the data writer account. For more information, see How to Create a SQL Server Login.
4. Under Logins, add the management server action account.
5. Under Logins, add the Data Access Service (DAS ) user account, using the format "domain\user".
6. For the DAS user account, add the following user mappings:
ConfigService
db_accessadmin
db_datareader
db_datawriter
db_ddladmin
db_securityadmin
sdk_users
sql_dependency_subscriber
7. If an account has not existed before in the SQL Server instance in which you are adding it, the mapping will
be picked up by SID automatically from the restored operational database. If the account has existed in that
SQL Server instance before, you receive an error indicating failure for that login, although the account
appears under Logins. If you are creating a new login, ensure the User Mapping for that log in and
database are set to the same values as the previous login as follows:
LOGIN DATABASE
DW Data Writer - apm_datareader

- apm_datawriter
- db_datareader
- dwsynch_users
Action account - db_datareader

- db_datawriter
- db_ddladmin
- dbmodule_users
DAS/Configuration account - ConfigService

- db_accessadmin
- db_datareader
- db_datawriter
- db_ddladmin
- db_securityadmin
- sdk_users
- sql_dependency_subscriber
NOTE
If the DAS/Configuration account uses the LocalSystem account, specify computer account in the form <domain>
<computername>$.
8. Run the following command on the new SQL Server instance hosting the Operations Manager operational
database.
sp_configure 'show advanced options', 1;

GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
9. Run the following SQL query: SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
If the result of this query was an is_broker_enabled value of 1, skip this step. Otherwise, run the following
SQL queries:
ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER
Start the Operations Manager services

1. On all the management servers in the management group, start the Operations Manager services:
Update Service Principal Name for Kerberos Connections
To update Kerberos authentication with SQL Server, you should review Register a Service Principal Name for
Kerberos Connections in order for management servers to authenticate with the SQL Server using Kerberos
protocol.
Next steps
See How to move the Reporting data warehouse database to understand the sequence and steps for moving
the Operations Manager Reporting data warehouse database to a new SQL Server instance.
How to move the Reporting data warehouse
database
4 minutes to read
After the initial deployment of System Center Operations Manager, you might need to move the Reporting data
warehouse database from one Microsoft SQL Server-based computer to another.
During the move, you need to stop services on your management servers, back up the database, restore the
database, update the registry on management servers, update database tables, add new Logins, and modify User
Mapping settings for Logins. For more information, see SQL Server documentation.
NOTE
This procedure can result in data loss if it is not performed correctly and within a reasonable length of time of the failure.
Ensure that you follow all steps precisely, without unnecessary delays between the steps.
Summary of steps
Moving the Reporting data warehouse database
Stop the Operations Manager services
Backup the Reporting data warehouse database on the old SQL Server instance
1. On the original SQL Server instance hosting the Reporting data warehouse database, use Microsoft SQL
Server Management Studio to create a full backup of the database. The default name is
OperationsManagerDW.
For more information, see How to: Back Up a Database (SQL Server Management Studio).
2. Copy the backup file to a local drive of the new SQL Server instance.
Restore the Reporting data warehouse database on the new SQL Server instance
1. Use Microsoft SQL Server Management Studio to restore the Reporting data warehouse database. (In the
previous step, you moved the database backup file to a local drive of the new SQL Server instance.) In this
step, you can change the name of the database and choose the file location.
For more information, see How to: Restore a Database Backup (SQL Server Management Studio).
2. In SQL Server Management Studio, verify that the database is online.
Update the registry on the management servers and Reporting data warehouse database
After moving the Operations Manager Reporting data warehouse database to a different SQL Server instance,
you will need to follow the steps below to reconfigure all management servers in the management group to
reference the new computer name and instance. This requires modifying the registry, the configuration service
configuration file, and several tables in the operational database. The steps are detailed in the How to configure
Operations Manager to communicate with SQL Server.
Update Reporting server
On the reporting server, you will need to change the connection string to reference the new computer name and
instance of the SQL Server instance hosting the Reporting data warehouse database. The steps are detailed in the
How to configure Operations Manager to communicate with SQL Server.
Update security credentials on the new SQL Server instance hosting the Reporting data warehouse database
1. On the new SQL Server instance hosting the Reporting data warehouse database, open SQL Management
Studio.
2. Expand Security, then expand Logins, and then add the data writer account. For more information, see
How to Create a SQL Server Login.
3. Under Logins, add the data reader account.
4. Under Logins, add the Data Access Service user account, using the form "domain\user".
5. For the Data Access Service (DAS ) user account, add the following user mappings:
db_datareader
OpsMgrReader
apm_datareader
6. If an account has not existed before in the SQL instance in which you are adding it, the mapping will be
picked up by SID automatically from the restored data warehouse database. If the account has existed in
that SQL instance before, you receive an error indicating failure for that login, although the account
appears under Logins. If you are creating a new login, ensure the User Mapping for that login and database
are set to the same values as the previous login as follows:
LOGIN DATABASE
DW Data Writer - db_owner

- OpsMgrWriter
- apm_datareader
- apm_datawriter
DW Data Reader - db_datareader

- OpsMgrReader
- apm_datareader
DAS/Config account - db_datareader

- OpsMgrReader
- apm_datareader
NOTE
If the DAS/Configuration account uses the LocalSystem account, specify computer account in the form <domain>
<computername>$.
Start the Operations Manager services

1. On all the management servers in the management group, start the Operations Manager services:
Update Service Principal Name for Kerberos Connections
To update Kerberos authentication with SQL Server, you should review Register a Service Principal Name for
Kerberos Connections in order for management servers to authenticate with the SQL Server using Kerberos
protocol.
To verify a successful move of the data warehouse database

1. Verify that you can successfully run a report from the console.
2. Ensure that the health state of all management servers in the management group are Healthy. If the health
state of any management server is Critical, open Health Explorer, expand Availability - <server name>, and
then continue to expand until you can navigate to Data Warehouse SQL RS Deployed Management Pack
List Request State. Check the associated events to determine if there is an issue accessing the data
warehouse database.
3. Check operating system events.
a. Open the Event Viewer and navigate to Applications and Services Logs and Operations Manager.
b. In the Operations Manager log, search for events with a Source of Health Service Module and a
Category of Data Warehouse. If the move was successful, event number 31570, 31558, or 31554 should
exist.
c. If there is an issue accessing the data warehouse database, event numbers 31563, 31551, 31569, or
31552 will exist.
4. Check events in Operations Manager:
a. In the Operations console, click Monitoring.
b. In the Monitoring workspace, navigate to Monitoring, Operations Manager, Health Service Module
Events, and then to Performance Data Source Module Events.
c. Search the Performance Data Source Module Events pane for events with a Date and Time that is later
than the move.
d. If there is a problem with the data warehouse database, events which have a Source of Health Service
Module and an Event Number of 10103 should exist.
Next steps
See How to move the Operational database to understand the sequence and steps for moving the Operations
Manager operational database to a new SQL Server instance.
How to configure grooming settings for the
Operations Manager database
2 minutes to read
The grooming process removes unnecessary data from the Operations Manager database in order to maintain
performance by managing its size. You can configure the grooming setting for the following data types:
Resolved alerts
NOTE
Active alerts are never groomed. You must close an alert before it will be groomed.
Event data
Performance data
Task history
Monitoring job data
State change events data
Performance signature
Maintenance mode history
Availability history
Any updates to the grooming settings are applied immediately.
Use the following procedure to specify when specific data types are deleted or groomed from the Operations
Manager database in a management group. The default grooming setting for all data types is data older than 7
days.
To configure database grooming settings for a management group

2. In the navigation pane, expand Administration, and then click Settings.
3. In the Settings pane, right-click Database Grooming, and then click Properties.
4. In the Global Management Group Settings - Database Grooming dialog box, select a data type, and
then click Edit.
5. In the dialog box for the record type, specify Older than days, and then click OK.
6. In the Global Management Group Settings - Database Grooming dialog box, select another data type
to Edit or click OK.
Next steps
To learn more about the default retention period for the different data types stored in the Operations Manager
Reporting data warehouse database and how to modify those settings, please see How to configure grooming
settings for the Operations Manager Reporting data warehouse database.
How to configure grooming settings for the
2 minutes to read
The Reporting data warehouse stores data for a specified length of time, depending on the data (Alert, State,
Event, Aem, or Performance) and the aggregation type (raw data, hourly aggregations, daily aggregations). The
database is set up to delete older data in order to maintain performance by managing its size. Deleting the older
data is called grooming.
The following table highlights the default data types and retention period after initial setup of the data warehouse
database.
Alert Raw 400
Client Monitoring Raw 30
Client Monitoring Daily 400
Events Raw 100
Performance Raw 10
Performance Hourly 400
Performance Daily 400
State Raw 180
State Hourly 400
State Daily 400
Settings for grooming the data warehouse can be changed through Microsoft SQL Server Management Studio.
To change grooming settings in the Reporting data warehouse

1. Log on to the computer with an account that is a member of the SQL Server sysadmin fixed server role.
2. On the Start Page, type SQL Server Management Studio and the program will appear. Click the program
to open SQL Server Management Studio. You might want to right-click the program and pin it to the Start
Page.
3. In the Connect to Server dialog box, in the Server Type list, select Database Engine; in the Server
Name list, select the server and instance for your Reporting data warehouse (for example,
computer\INSTANCE1); in Authentication list, select Windows Authentication; and then click
Connect.
4. In the Object Explorer pane, expand Databases, expand OperationsManagerDW, and then expand
Tables.
5. Right-click dbo.Dataset, and then click Open Table.
6. Locate the dataset for which you want to change the grooming setting in the DatasetDefaultName
column and make note of its GUID in the DatasetId column.
7. In the Object Explorer pane, right-click dbo.StandardDatasetAggregation and then click Open Table.
8. In the DatasetId column, locate the dataset GUID you noted in step 5. Multiple entries of the same GUID
might display.
9. Locate the aggregation type from the list in the AggregationTypeId column by using the following
values:
0 = raw, nonaggregated data
10 = subhourly
20 = hourly
30 = daily
After you have located the dataset and its aggregation type, scroll to the MaxDataAgeDays column, and then
edit the value there to set the grooming interval.
Next steps
To learn more about the default retention period for the different data types stored in the Operations Manager
operational database and how to modify those settings, please see How to configure grooming settings for the

Whats New in Operations Manager 2019

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Whats New in Operations Manager 2019

Загружено:

Авторское право:

Доступные форматы

Contents

Operations Manager documentation

What Operations Manager does

The Operations Manager infrastructure

How objects are discovered and monitored

Communication between agents and management servers

Getting started topics

BUILD NUMBER KB RELEASE DATE DESCRIPTION

7.2.11719.0 September 2016 General Availability release

7.2.11759.0 KB3190029 October 2016 Update Rollup 1

7.2.11822.0 KB3209591 February 2017 Update Rollup 2

7.2.11878.0 KB4016126 May 2017 Update Rollup 3

8.0.10977.0 KB4024941 October 2017 Update Rollup 4 1

Silverlight based Web console

Agent for Nano Server

Operations Manager 2019 release notes

Health Service with Log on type as Service by default

User experience changes in maintenance mode

Support for x64 components

Upgrade to reporting server fails the prerequisites check

OpenSSL 1.1.0 version support

Performance monitoring for VMM server fails with Access denied

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-

Operations Manager 2019 does not support HPUX library

Operations Manager 1807 release notes

Log rotation for Linux agent

Support for SQL Server 2017

Supportability with Internet Explorer Compatibility View

Support for Operations Manager and Service Manager console

Upgrade to Operations Manager version 1807

OpenSSL 1.1.0 version support

Operations Manager 2016 release notes

SharePoint integration with Operations Manager has to be recreated

Web Console might not work due to IIS becoming corrupt

Anomalies in handling tables and bullets in Knowledge Articles

MSI-based installation does not work for Nano agent

Issues with uninstalling an update for Nano agent

Unable to override the path or folder for Nano agent installation

Inconsistencies in push install experience of Nano agent

Inconsistencies in push uninstall experience of Nano agent

ACS is not working for Nano agent

Client-side monitoring (CSM) alerts might stop flowing from the

If after updating System Center Operations Manager server or agent,

Application performance monitoring (APM) for Windows services is not

Namespace values for performance tracking will be ignored

When using sudo elevation with Solaris operating systems, it requires a

Operations Manager Console will stop responding if you attempt to

Telemetry data may be erroneously sent when the "Usage and

Namespace values for performance tracking will be ignored

Operations Manager web console is not compatible with Microsoft

Launching the Operations Manager Web Console may result in a blank

Telemetry for HTML5 dashboards

Edit Company Knowledge

Access Silverlight dashboards in Web Console using a different URL

Attempting to upgrade Reporting server fails prerequisites check

Application Performance Monitoring (APM) agent-component can

In-place upgrade from Operations Manager 2016 will fail if ACS

Error:Found error in 2|Microsoft.ACS.Linux.Universal|7.7.1124.0|Microsoft.ACS.Linux.Universal|| with message:

New features in Operations Manager 2019

Service log on is enabled by default in Operations Manager 2019

Improved experience for HTML5 dashboard

Enhanced experience for alerts raised by monitors

Notifications and subscriptions enhancement

Management server failover support for Linux and UNIX monitoring