Guide to Microsoft System Center Management

Pack for SQL Server

Published in December 2019 by Microsoft Corporation.

This guide is based on version 7.0.20.0 of the Management Pack for Microsoft SQL Server.

The Operations Manager team encourages you to provide feedback on the management pack by
sending it to sqlmpsfeedback@microsoft.com.

Copyright
This document is provided "as is". Information and views expressed in this document, including URL
and other Internet website references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real
association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes. You
may modify this document for your internal, reference purposes.

© 2019 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, and Windows Server are trademarks of the Microsoft group
of companies.

All other trademarks are the property of their respective owners.

Table of Contents
Guide to Microsoft System Center Management Pack for SQL Server
Copyright
Table of Contents
Changes History
 Management Pack Scope and Supported Configurations
Notes to Release
SQL Server Configurations and Features
Operating Systems and Platforms
SQL Server Features
SCOM Configurations
Prerequisites
Management Pack Delivery
Disabled Space Monitoring Workflows for SQL on Linux
Monitoring Configuration
Coexistence of SQL Server 2008/2012/2014/2016 MPs and SQL Server MP
How Disabling of Monitoring Works
How to Enable Monitoring of SQL Server 2012/2014/2016 by SQL Server
MP
Monitoring Modes
Configuring Agentless Monitoring Mode
Configuring Mixed Monitoring Mode
SQL Server Agent Alerting Rules: Specifics of Configuration
Configuring SQL Server Monitoring Pool
Disabling Monitoring of Specified SQL Server Versions
Disabling Monitoring of Specified SQL Server Editions
Disabling Monitoring of Specified Databases by Name
Security Configuration of Management Pack
Run As Profiles
Enabling “Allow Log On Locally” Security Policy
Configuring Run As Profiles for Local and Mixed Monitoring Modes
SCOM Action Account is Local Administrator and SA
SCOM Action Account is Local Administrator and Not Have SA Rights
SCOM Action Account is Local System and Not Have SA Rights
Low-Privilege Monitoring
How to Configure Monitoring by Means of Service Security Identifier
How to Configure HealthService Service SID for SQL Server Cluster Instances
How to Configure SCOM SDK Run As Profile
How to Configure Permissions for Always On Workflows when Servers Have
Machine Names Longer than 15 Characters
Configuring Low-Privilege Monitoring
Low-Privilege Agent Monitoring
Low-Privilege Agentless Monitoring
Appendix: Known Issues and Troubleshooting

Changes History
December 2019 - 7.0.20.0 RTM

Including changes made in the prior preview release — v.7.0.18, November 2019.

What's New

Updated MP to support SQL Server 2019 RTM

 Added filter by edition to “Local DB Engine Discovery”
Redesigned DB Space monitoring to improve performance: Enabled by default
monitors and performance rules targeting Database which watch for disk space
consumption by ROWS Filegroups and Logfiles
Redesigned DB Space monitoring: Added two monitors and two performance rules
targeting Database to watch for disk space consumption by In-Memory and
FILESTREAM data
Redesigned DB Space monitoring: Read-only filegroups now count as well
Redesigned DB Space monitoring: Disabled by default all workflows targeting
Filegroups, Files, Logfiles
Redesigned XTP performance counters to make them completely version-agnostic
Added attribute “TCP Port” to “SQL DB Engine Class” and updated “DB Engine
Discovery” to populate the new property
Added summary dashboard for SCOM 2019 Web Console (HTML5)
Added support for cluster nodes with disjoined namespaces
Added sampling to algorithm of monitor “WMI Health State” in order to eliminate false
alerting on cluster SQL Server instances
Updated alert descriptions of monitors “Availability Database,” “Availability Replica,”
and “Availability Group” (generating alerts still disabled by default)
Updated monitor “Product Version Compliance” with versions of most recent public
updates to SQL Server
Disabled by default monitor “Buffer Cache Hit Ratio” and changed its threshold from
0% to 90%
Disabled by default monitor “Page Life Expectancy”
Removed monitors “Availability Database Join State” and “Availability Replica Join
State” as not useful
Updated display strings
Revised columns on DB Engine state views

Bug Fixes

Fixed: monitor “Service Principal Name Configuration Status” raises false alerts because
of case-sensitive comparison
Fixed: “Local DB Engine Discovery” crashes when Windows has Turkish locale
Fixed issue that caused performance degradation in workflows “General Always On
Discovery,” “Database Replica Discovery,” and “Always On System Policy Monitoring”
Fixed: “General Always On Discovery” throws errors on environments with several
Distributed Availability Groups
Fixed monitoring issue in case of Database is replicated by Always On Availability
Group
Fixed empty property bag when Availability Group has cluster type NONE
Fixed wrong target in alerting rule “DB Backup Failed to Complete”
Fixed rule “MSSQL Integration Services on Windows: The package restarted from
checkpoint file” and its alert
Fixed rule “OS Error occurred while performing I/O on pages“ and its alert
Fixed: "DB Disk Write Latency" and "DB Disk Read Latency" monitors and performance
rules get wrong performance metric
Fixed alert description of monitor “WMI Health State”
Management Pack Scope and Supported Configurations
This management pack is version-agnostic, which means that it supports discovery and monitoring
of SQL Server 2012 through 2019 and up, including SQL on Linux with SQL Server 2017 and up.

The management pack discovers and monitors SQL Server right out of the box when there are no
version-specific management packs for SQL Server previously installed. If this management pack is
installed in addition to the version-specific management packs for SQL Server 2008 and 2012, 2014,
2016, see Configuration with old management packs for SQL Server to get more information on
such a configuration.

This section explains what SQL Server features are covered by this management pack, what
configurations are supported, what monitoring features the management pack offers, and what
prerequisites should be met to begin with this management pack.

Notes to Release

Former generation of the management packs for SQL Server 2012, 2014, and 2016
reached the end of support This management pack is virtually a new version of the version-
agnostic management pack for SQL Server 2017 and up, whose last version, 7.0.7.0, was
released in July 2018. All the following versions of the management pack, including the
current one, are for the monitoring of SQL Server 2012, 2014, and 2016 in addition to
previously supported 2017 and up. The former generation of management packs for SQL
Server 2008—2016 reached the end of support with the first public release of the
management pack for SQL Server 2012 and up (April, 2019).

Upgradability issues of path SQL Server 2017+ MP v.7.0.7.0 → any version of the
current management pack This version has a great deal of significant changes in
comparison to the last released version of SQL Server 2017+ MP. Some of these changes are
so severe that lead to upgradability issues, however they all are necessary for this
management pack to provide solid monitoring.

After importing this management pack over the SQL Server 2017+ Management Pack, all
already-discovered instances of SQL Server 2017 will be re-discovered. This will cause SCOM
to “forget” historical data for these instances, which affects reporting.

Management pack for SQL Server 2017+ Integration Services cannot be upgraded and has to
be removed before importing this update. Remove the following management pack (this file
is part of the delivery of SQL Server 2017+ MP): Microsoft SQL Server 2017+ Integration
Services on Windows.

Localization for SQL Server 2017+ MP cannot be imported over the current version of
SQL Server MP

This management pack cannot be localized with the localization packs initially made for SQL
Server 2017+ MP. If you already have SQL Server 2017+ MP (7.0.0.0 or 7.0.7.0) imported and
localized, then you do not need to remove the localization pack before importing this
management pack.

SQL Server Configurations and Features

Operating Systems and Platforms

List of supported operating systems/platforms is as following:

Windows Server 2012

Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Ubuntu 16.04 x64
Red Hat Enterprise Linux 7.3 and 7.4
SUSE Linux Enterprise Server v12 SP2
Docker Engine 1.8+
Azure Kubernetes Service (AKS)

Localized versions of Windows Server are supported by Management Pack.

SQL Server Features

The management pack works with any edition of SQL Server, from Express to Enterprise. Here is the
list of SQL Server features and configurations that the management pack supports (unsupported
features and configurations are also on this list flagged as "Not supported").

SQL Server Database Engine

SQL Server Database, including filegroups, data files, transaction log files, FILESTREAM and
Memory-Optimized Data containers. Different storage options for databases supported:
Local storage (both drive letters and mount points)
Cluster Shared Volumes
SMB Shares
Azure BLOBs
SQL Server Agent and Jobs
SQL Server Memory-Optimized Data (In-Memory OLTP)
SQL Server High Availability Features
Single-domain Availability Groups, including availability replicas and database replicas
Distributed Availability Groups
Failover Clustering
Log Shipping
Replication — Not supported; use dedicated management packs for SQL Server
Replication to monitor this feature.
Mirroring — Not supported
Domain-independent Availability Groups — Not supported
Workgroup Cluster Availability Groups — Not supported
Authentication Mode — both SQL Server Authentication and Windows Authentication are
supported.
Localized versions of SQL Server — Not supported; Management Pack can only work with
the English-language version of SQL Server.

SCOM Configurations
This management pack offers three modes of monitoring: Agent Monitoring, Agentless Monitoring,
and Mixed Monitoring. See Monitoring Modes for more information on each of them. Agent
Monitoring and Mixed Monitoring modes work with SQL on Windows only. Agentless Monitoring
was initially designed to enable monitoring of SQL on Linux but it works with SQL on Windows as
well. The management pack does not require a dedicated management group and can work in
virtual environments. List of supported versions of SCOM is as following:

System Center Operations Manager 2012 R2

System Center Operations Manager 2016
System Center Operations Manager 1801
System Center Operations Manager 1807
System Center Operations Manager 2019

Prerequisites

.NET Framework 4.5+

Installation of .NET Framework 4.5 or newer is required

Management Pack for Windows Server Operating System & Management Pack for
UNIX and Linux Operating Systems

As a best practice, you should import the Windows or Linux Server Management Pack for the
operating system you are using. The management packs monitor aspects of the operating
system that influence the performance of computers running SQL Server, such as disk
capacity, disk performance, memory utilization, network adapter utilization, and processor
performance.

Removal of overrides for “SQL on Windows: Discover Installation Source (seed)”

In case of upgrading the management pack for SQL Server 2017+ to the current one, remove
the overrides set for the “SQL on Windows: Discover Installation Source (seed)” discovery
beforehand because this discovery has Interval (seconds) overridable parameter instead of
Frequency (seconds) one.

“Allow log on locally” security policy for domain monitoring account is enabled

If a domain account is used as the action account for this management pack, make sure to enable
the “Allow log on locally” policy for it. See Enabling “Allow Log On Locally” Security Policy for more
information.

Each agent has the Agent Proxy option enabled

Enable the Agent Proxy option for all agents that will use this management pack to monitor
SQL Server. Agent Proxy setting allows an agent to forward data to the management server
on behalf of another entity and it should be set enabled if agent workflow scenarios discover
any non-hosted objects (the management pack creates a non-hosted object for every SQL
Server instance).

SQL Server Connection Protocols

 For the agent monitoring mode, all three protocols TCP/IP, "Named Pipes", and "Shared
Memory" are supported. Keeping SQL Server Browser running is not a prerequisite for this
monitoring mode. For the agentless monitoring mode, both protocols TCP/IP and "Named
Pipes" are supported. SQL Server Browser should be enabled and running. For the mixed
monitoring mode, only TCP/IP protocol is supported, and keeping SQL Server Browser
running is not a prerequisite for this monitoring mode. See Monitoring Modes for more
information on the monitoring modes provided by this management pack.

Removal of management pack “Microsoft SQL Server 2017+ Integration Services on

Windows” before importing this management pack

Management pack for SQL Server 2017+ Integration Services cannot be upgraded and has to
be removed before importing this management pack. Remove the following management
pack (this file is part of the delivery of SQL Server 2017+ MP): Microsoft SQL Server 2017+
Integration Services on Windows

Author set of privileges on SCOM SDK

This management pack needs the Author set of privileges on the SCOM SDK to be able to
create a management pack and store overrides in it. If the default action account on SCOM
does not have these permissions, make sure to have an account granted with them and map
this account to the Microsoft SQL Server SCOM SDK Run As Profile.

Management Pack Delivery

Management Pack delivers as a download on microsoft.com and is also available on the SCOM
Online Catalog. The download provides the next files:

SQLServerMP.Windows.CTP.msi — set of .MP and .MPB files to start monitoring SQL on

Windows.
SQLServerMP.Linux.CTP.msi — set of .MP and .MPB files to start monitoring SQL on Linux.
SQLServerMPGuide.pdf — this operations guide.
SQLServerDashboardsGuide.pdf — operations guide to SQL MP Dashboards.
SQLServerMPWorkflowList.pdf — complete list of SQL Server MP workflows with descriptions
and parameters.

Management Pack for Microsoft SQL Server includes the following files:

Microsoft.SQLServer.Core.Library.mpb
Microsoft.SQLServer.Core.Views.mp
Microsoft.SQLServer.Core.WebDashboards.mp
Microsoft.SQLServer.IS.Windows.mpb
Microsoft.SQLServer.IS.Windows.Views.mp
Microsoft.SQLServer.Visualization.Library.mpb
Microsoft.SQLServer.Linux.Views.mp
Microsoft.SQLServer.Linux.Discovery.mpb
Microsoft.SQLServer.Linux.Monitoring.mpb
Microsoft.SQLServer.Windows.Views.mpb
Microsoft.SQLServer.Windows.Discovery.mpb
Microsoft.SQLServer.Windows.Monitoring.mpb
Disabled Space Monitoring Workflows for SQL on Linux

The following workflows are disabled because they are not provided with the necessary data by the
SQL Server on Linux. We do not recommend enabling them.

Rules
MSSQL on Linux: DB Memory-Optimized Data Filegroup Free Space Total (MB)
MSSQL on Linux: DB Memory-Optimized Data Filegroup Free Space Total (%)
MSSQL on Linux: DB FILESTREAM Filegroup Free Space Total (%)
MSSQL on Linux: DB FILESTREAM Filegroup Free Space Total (MB)
MSSQL on Linux: DB Filegroup Free Space Total (%)
MSSQL on Linux: DB Filegroup Free Space Total (MB)
MSSQL on Linux: DB Filegroup Allocated Free Space (%)
MSSQL on Linux: DB Filegroup Allocated Free Space (MB)
MSSQL on Linux: DB Free Outer Space (MB)
MSSQL on Linux: DB Allocated Free Space (MB)
MSSQL on Linux: DB Transaction Log Free Space Total (%)
MSSQL on Linux: DB Allocated Space Used (MB)
MSSQL on Linux: DB Free Space Total (%)
MSSQL on Linux: DB Free Space Total (MB)
MSSQL on Linux: DB Allocated Space (MB)
Monitors
DB Free Space Left
DB Space Percentage Change
Transaction Log Free Space (%)
DB FILESTREAM Filegroup Free Space

Monitoring Configuration
When either Agent Monitoring or Mixed Monitoring mode is used, the management pack
automatically discovers stand-alone and cluster instances of SQL Server across all managed systems
that run the System Center Operations Manager Agent service. Agentless Monitoring mode
requires manual configuration for each SQL Server instance to be monitored. These three
monitoring modes are described in detail below in this guide. As a rule of thumb, choose Agent
Monitoring mode for SQL Server on Windows and Agentless Monitoring mode for SQL Server on
Linux.

You can customize the management pack by means of overriding the defaults. Your customizations
cannot be stored in the SQL Server MP, so SCOM saves all the overrides in the Default management
pack until you choose another management pack. It is a best practice to store all overrides for a
management pack you want to customize in a dedicated management pack. We recommend to
create at least one management pack named, for example, "Microsoft SQL Server Customizations"
and save all the customizations for the SQL Server MP in it.

Coexistence of SQL Server 2008/2012/2014/2016 MPs and SQL Server MP

The management pack discovers and monitors SQL Server 2012 and up right out of the box when
there are no version-specific management packs for SQL Server 2012, 2014, and/or 2016 previously
installed (the old management packs). In the case when there is any of the old management packs
detected during an import of the version-agnostic management pack, the latter disables the
discovery and monitoring for those SQL Server versions already covered by the old management
packs. It was made to avoid double monitoring.

How Disabling of Monitoring Works

The version-agnostic management pack runs the “MSSQL on Windows: Automatic setup of DB
Engine discovery filter” action rule after importing. The rule does the following actions:

Search for instances of SQL Server 2012, 2014 and 2016 discovered by the old management
packs. If there is at least one instance of any of those SQL Server versions, this version will be
disabled for discovery by the version-agnostic management pack.
Overrides the “MSSQL on Windows: Discover SQL Server Database Engines (Local)” discovery
by filling out the “SQL Server versions to be excluded” parameter with versions to disable and
saves this override in a new management pack called “Microsoft SQLServer overrides.” See
Disabling Monitoring of Specified SQL Server Versions to get more information.
Disables itself and saves this override in the same management pack. Do not remove this
management pack in order to keep this rule disabled.

If the old management packs are imported after importing the version-agnostic management pack,
the monitoring provided by the latter will not be disabled.

How to Enable Monitoring of SQL Server 2012/2014/2016 by SQL Server MP

When you are ready to start off the monitoring of SQL Server 2012/2014/2016 by the version-
agnostic management pack, remove or edit the override for the “MSSQL on Windows: Discover SQL
Server Database Engines (Local)” discovery described in How Disabling of Monitoring Works.
Removal of management pack “Microsoft SQLServer overrides” while still having the old
management packs makes the rule to re-create this management pack, which will disable the SQL
Server MP to discovery for SQL Server 2012/2014/2016.

Monitoring Modes

The management pack offers three monitoring modes:

Agent Monitoring Mode—the monitoring is carried out by the SCOM Agent. This is the
most common kind of monitoring; the old management packs for SQL Server, as well as the
vast majority of all SCOM management packs, provide this kind of monitoring. It supports
SQL on Windows only.

Agentless Monitoring Mode is the monitoring mode that was originally designed to
monitor SQL on Linux, however it supports both SQL on Linux and SQL on Windows. In this
monitoring mode, the management pack's workflows run on management servers and
gateway servers mapped to the SQL Server Monitoring Pool or All Management Servers Pool,
if the first is not configured. This monitoring mode does not provide the automatical
discovery of SQL Server instances and requires all the instances to be manually added to the
monitoring. See Configuring Agentless Monitoring Mode for more information.

Mixed Monitoring Mode is the hybrid of the Agent and Agentless modes. In this
monitoring mode, the management pack places its seed on all computers where there is the
 SCOM Agent and uses this seed to automatically discover all SQL Server on Windows
instances but the entire monitoring is carried out like in Agentless Monitoring mode—from
Management Servers and Gateway Servers that are members of the SQL Server Monitoring
Pool. It supports SQL on Windows only. See Configuring Mixed Monitoring Mode for more
information.

All monitoring modes support both SQL Server and Windows authentication.

As Agentless Monitoring and Mixed Monitoring modes make the management pack workflows run
on management servers, we recommend you not use them without prior test in a non-production
environment to avoid unexpected overload of the servers. Having management servers dedicated
to the monitoring of SQL Server is recommended as well. See Configuring SQL Server Monitoring
Pool for more information.

Configuring Agentless Monitoring Mode

In the Operations Manager console, navigate to Authoring | Management Pack Templates, right-
click Microsoft SQL Server and select Add Monitoring Wizard…

In Monitoring Type window, select Microsoft SQL Server and click the Next button.
In General Properties window, you must provide your template with Name and Description, as
well as Select destination management pack where the template will be stored.
You can also create a new destination management pack by clicking the New… button.
In Service Details window, you should provide the corresponding details about the instances you
want to monitor.
Click the corresponding button to Add Instances for monitoring.
In this window, select a preferable authentication type: SQL or Windows AD credentials. The latter
should be used when the SQL Server instances run on Windows or Linux servers, which are part of
an Active Directory domain.
In this window, you must also select a common Run As Account created in the Operations Manager
with appropriate credentials, or create a new one by clicking the New… button.

In the corresponding window, enter your new Run as Account name and credentials of the SQL
server you want to monitor, and click the OK button.

Then enter the data sources and/or connection strings in the corresponding field. Please, follow the
instructions provided in this window to avoid errors and skip the excessive connection testing.

The data is to be entered in the format provided in the examples below:

172.31.2.133;MachineName="W12BOX-
839";InstanceName="MSSQLSERVER";Platform="Windows"
 172.31.2.133,50626;MachineName="W12BOX-
839";InstanceName="SQLEXPRESS";Platform="Windows"

172.17.5.115;MachineName="ubuntu";InstanceName="MSSQLSERVER";Platform="Linux"

⚠ When adding a Linux-based instance, the connection test fails if an IP address is

specified as a connection string and the authentication type is "Windows AD credentials". In
this case, specify the name of the machine as a connection string.

Click the OK button to submit the entered data.

⚠ Monitoring Template Wizard may show the "An error occurred discovery: A connection
was successfully established with the server, but then an error occurred during the login
process" exception while checking connection. See “A connection was successfully
established with the server, but then an error occurred during the login process” error
appears when adding a new instance to the monitoring by means of the Add Monitoring
Wizard to work this issue out.

When the connection testing is completed, you can view and edit the properties of the added
instance. To do that, select the instance and click the Edit Instance button.
To skip connection testing and enter the data manually, check the corresponding box in this
window. If you do that, the status of your instance will be changed to “Manual”:
In Summary window, you can view your monitoring settings and confirm them by clicking the
Create button.
After that, your monitoring template will be successfully created.

Configuring Mixed Monitoring Mode

Mixed Monitoring is intended for cases when you want to switch the monitoring from the agent to
a SCOM pool. Such monitoring mode is quite similar to Agentless Monitoring, but in this case, you
do not need to configure the connection strings manually. You can enable Mixed Monitoring by the
override.

When you enable Mixed Monitoring, only SQL Server Seed is discovered locally by the SCOM agent.
All other workflows are run from the dedicated management server pool. The details regarding the
SQL Server Monitoring Pool discovery configuration are available in Configuring SQL Server
Monitoring Pool section.

To view the currently used monitoring types in the Operations Manager, go to Database Engines
view, open Personalize View menu and enable Monitoring Type parameter:
Therefore, the complete Database Engines view will look as follows:

To enable Mixed Monitoring Mode, in the Operations Manager console, navigate to Authoring |
Management Pack Objects, select Object Discoveries and find MSSQL: Discover Local SQL
Database Engines on Windows object discovery. Right-click this discovery and select the following
action: Overrides → Override the Object Discovery → For all objects of class: MSSQL on
Windows: Local Discovery Seed.
As a result, the Override Properties window will be displayed. In this window, enable override for
Mixed Monitoring parameter and enter the names of the instances in the Override Value field to
switch them to agentless monitoring. Please note that the names of the instances should be
separated by commas. If you want to add all the instances, enter an asterisk character (*) in the
field. Therefore, all instances (even those with the same names on different servers) will be
monitored on the pool in the mixed mode.

SQL Server Agent Alerting Rules: Specifics of Configuration

Management Pack includes nine alerting rules for SQL Server Agent-related errors. These rules are
enabled by default in Agent Monitoring Mode but disabled in Mixed Monitoring Mode. In
Agentless Monitoring Mode, these rules cannot work (therefore they are not available for SQL on
Linux at all).

MSSQL on Windows: Alert engine stopped due to unrecoverable local eventlog errors
MSSQL on Windows: A SQL job failed to complete successfully
MSSQL on Windows: Job step cannot be run because the subsystem failed to load
MSSQL on Windows: The agent is suspect. No response within last minutes
 MSSQL on Windows: SQL Server Agent could not be started
MSSQL on Windows: SQL Server Agent initiating self-termination
MSSQL on Windows: Step of a job caused an exception in the subsystem
MSSQL on Windows: SQL Server Agent is unable to connect to SQL Server
MSSQL on Windows: Unable to re-open the local eventlog

They are disabled in Mixed Monitoring Mode because, by default, Operations Manager does not
allow to collect events from the event log on remote computers. But overriding these rules by
enabling the “AllowProxying” option makes it possible.

⚠ Note that enabling this option may cause remote code execution. Therefore, this flag is
considered potentially harmful. Unless you make sure that your computer is secure, it is not
recommended to enable the “AllowProxying” option.

Configuring SQL Server Monitoring Pool

The monitoring pool is available for configuration in the Operations Manager console. To configure
the monitoring pool, navigate to Administration | Resource Pools, right-click SQL Server
Monitoring Pool in the list of Resource Pools and check Manual Membership option. Then, select
Properties action.

As a result, the SQL Server Monitoring Pool Properties window will be displayed. In this window,
select the Pool Membership tab. In this tab, click the Add… button to populate the monitoring
pool.
You can configure SQL Server Monitoring Pool manually by adding custom Gateways or
Management Servers.

Disabling Monitoring of Specified SQL Server Versions

You can exclude instances of SQL Server from the monitoring by SQL Server version. Create an
override for the “Versions of SQL Server to be excluded” parameter of the “MSSQL on Windows:
Discover SQL Server Database Engines (Local)” discovery and list versions separating them with
commas. For example, the override “2014,2012” makes the management pack remove all previously
discovered instances of SQL Server 2012 and 2014 and disable further discovery of such instances.
Disabling Monitoring of Specified SQL Server Editions

You can exclude instances of SQL Server from the monitoring by SQL Server edition. Create an
override for the “Editions of SQL Server to be excluded” parameter of the “MSSQL on Windows:
Discover SQL Server Database Engines (Local)” discovery and list editions separating them with
commas. Use the matching table below to figure out what short names of the editions to use in the
parameter.

Short
Covered Editions
Name

Enterprise Edition, Enterprise Edition: Core-based Licensing, Enterprise Evaluation

Enterprise
Edition

Standard Standard Edition, Business Intelligence Edition

Web Web Edition

Developer Developer Edition

Express Express Edition, Express Edition with Advanced Services

Disabling Monitoring of Specified Databases by Name

You can stop discovery and monitoring of databases by specifying their names in the “Exclude list”
property of both discoveries “MSSQL on Windows: Discover SQL Server Databases for a Database
Engine” and “MSSQL on Linux: Discover SQL Server Databases for a Database Engine.” Use commas
to separate database names on the list and asterisks to replace one or more characters. For
example, setting the parameter to dev*,*test*,*stage,dbnotmon causes the monitoring
configuration as in the table below.

DB Name Monitored/Not monitored

dev Not monitored

dev_sales Not monitored

sales_dev Monitored
 DB Name Monitored/Not monitored

test Not monitored

test_sales Not monitored

sales_test Not monitored

stage Not monitored

stage_dev Monitored

dev_stage Not monitored

dbnotmon Not monitored

dbnotmon_sales Monitored

sales_dbnotmon Monitored

If you have * on the list as a database name (e.g., *temp*,*,*dev* or *temp,*), it disables
monitoring of any database.

Security Configuration of Management Pack

This section provides guidance on configuring the security for this management pack.

Run As Profiles

The list of Run As profiles is as follows:

Microsoft SQL Server Discovery Run As Profile – this profile is associated with all discoveries.
Microsoft SQL Server Monitoring Run As Profile – this profile is associated with all monitors
and rules.
Microsoft SQL Server Run As Profile – this profile is associated with all tasks.
Microsoft SQL Server SCOM SDK Run As Profile – this profile is for SQL Server MP workflows
that need access to SCOM SDK.
Microsoft SQL Server SQL Credentials Run As Profile – this profile is for the Agentless
Monitoring Mode only.

⚠ Do not bind any account to profile Microsoft SQL Server SQL Credentials Run As Profile if
you monitor SQL Server in Local or Mixed Monitoring modes. Only a basic action account
can be bound to the profile, do not use a Windows account or non-basic account with this
profile.

When Local Monitoring or Mixed Monitoring mode is used, all discoveries, monitors, and tasks
defined in the SQL Server MP use accounts defined in the “Default Action Account” Run As profile
by default. If the default action account for a given system does not have the necessary permissions
to discover or monitor the instance of SQL Server, then those systems can be bound to more
specific credentials in the “Microsoft SQL Server …” Run As profiles, which do have access.

Enabling “Allow Log On Locally” Security Policy

If a domain account is used as the action account for this management pack, make sure to enable
the “Allow log on locally” policy for it. It is a requirement for SQL Server on Windows and on Linux.
For more information about configuring this security policy setting, see this Docs article Allow Log
On Locally.

Configuring Run As Profiles for Local and Mixed Monitoring Modes

To configure Run As profiles, follow one of the scenarios described below:

SCOM Action Account is Local Administrator and SA

SCOM Default Action Account is mapped to either Local System account, or any Domain User
account, which is placed in the Local Administrators group on the operating system of the
monitored machines. Note that the used account must be granted with SQL System Administrator
rights (hereinafter - SA rights) in the monitored SQL Server instances (Domain User account can be
granted with SA rights by granting SA to BUILTIN\Administrators local group in the SQL Server
security access list). In this case, monitoring of SQL Server instances will work out of the box, except
for some configurations described below. Please follow these steps to ensure that all requirements
are met:

If you store SQL Server databases on an SMB file share, make sure that Default Action
Account has the rights described in the corresponding section of Low-Privilege Agent
Monitoring.
In case when servers hosting Always On Availability Replicas (at least one of them) have the
machine name longer 15 characters, make sure to take steps described in How to Configure
Permissions for Always On Workflows when Servers Have Machine Names Longer than 15
Characters.

SCOM Action Account is Local Administrator and Not Have SA Rights

SCOM Default Action Account is mapped to either Local System account or Domain User account
as in the scenario described above, but SA rights cannot be granted to it, as long as the security
policy prohibits granting SA rights to SCOM Default Action account. If the security policy permits to
grant SA rights to a separate Domain User account, which will be used for launching SQL Server MP
workflows only, perform the following steps:

Create a new Domain User account and add this account to the Local Administrators group
on each monitored server.
Grant SA rights to this account in SQL Server.
Create a new Action account in SCOM and map it to the Domain User account created
above.
Map the new Action account to all SQL Server MP Run As Profiles.
If you store SQL Server databases on an SMB file share, make sure that Default Action
Account has the rights described in the corresponding section of Low-Privilege Agent
Monitoring.

SCOM Action Account is Local System and Not Have SA Rights

⚠ This scenario is for Local Monitoring Mode only.

SCOM Default Action Account is mapped to Local System account, but SA rights cannot be granted
thereto, as long as the security policy prohibits granting Local System with rights to access SQL
Server. You can grant SA or Low Privilege rights to SCOM HealthService using its Service Security
Identifier. For more details, refer to SQL Server uses a service SID to provide service isolation and
How to configure SQL Server 2012 to allow for System Center Advisor monitoring.

Follow the next steps to configure your security configuration with SID:

Configure using a service SID for HealthService as it is described in How to Configure

Monitoring by Means of a Service Security Identifier.
If you have SQL Server Cluster instances, make sure to take the steps described in How to
Configure HealthService Service SID for Monitoring SQL Server Cluster Instances.

Low-Privilege Monitoring

In case you need to grant the minimally required rights to SQL MP workflows, follow the
instructions provided in section Configuring Low-Privilege Monitoring.

How to Configure Monitoring by Means of Service Security Identifier

Below are the steps to configure monitoring via Service SIDs for SQL Server on a Windows Server
instance - was first published by Kevin Holman in his blog. The original article is available here. The
SQL scripts to configure the lowest-privilege access were developed by Brandon Adams.

1. Open Command Prompt as Administrator and run sc sidtype HealthService

unrestricted; then, restart “Health Service”.

2. Run sc showsid HealthService and make sure “STATUS” is active.

3. Open Registry Editor and check that ServiceSidType key equals to 1 at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService.

4. Create the login “NT SERVICE\HealthService” for the HealthService SID on every SQL Server
Instance and grant it with SA rights. If you cannot grant it with the SA rights, then skip this
step and take step 5.

5. Take this step only if you cannot take step “4”. Use the following SQL scripts to set up the
lowest privilege configuration for the account:

USE [master]
SET NOCOUNT ON
/*User account which SCOM will use for access
Default is the Service SID for the HealthService*/
DECLARE @accountname sysname = 'NT SERVICE\HealthService'
-- Create the server role and grant permissions
CREATE SERVER ROLE [SCOM_HealthService]
GRANT VIEW ANY DATABASE TO [SCOM_HealthService];
GRANT ALTER ANY DATABASE TO [SCOM_HealthService];
GRANT VIEW ANY DEFINITION TO [SCOM_HealthService];
GRANT VIEW SERVER STATE TO [SCOM_HealthService]
DECLARE @createLoginCommand nvarchar(200)
SET @createLoginCommand = '
CREATE LOGIN '+ QUOTENAME(@accountname) +
' FROM WINDOWS WITH DEFAULT_DATABASE=[master];'
EXEC(@createLoginCommand);
-- Add the login to the user-defined server role
EXEC sp_addsrvrolemember @loginame = @accountname
, @rolename = 'SCOM_HealthService'
DECLARE @createDatabaseUserAndRole nvarchar(max)
SET @createDatabaseUserAndRole = '';
SELECT @createDatabaseUserAndRole = @createDatabaseUserAndRole + '
USE ' + QUOTENAME(db.name) + ';
CREATE USER ' + QUOTENAME(@accountname) +
' FOR LOGIN ' + QUOTENAME(@accountname) + ';
CREATE ROLE [SCOM_HealthService];
EXEC sp_addrolemember @rolename =
''SCOM_HealthService'', @membername
= '+ QUOTENAME(@accountname) + ''
-- 'ALTER ROLE [SCOM_HealthService] ADD MEMBER '
-- '+ QUOTENAME(@accountname) + ';'
FROM sys.databases db
LEFT JOIN sys.dm_hadr_availability_replica_states hadrstate ON
db.replica_id = hadrstate.replica_id
WHERE db.database_id <> 2
AND db.user_access = 0
AND db.state = 0
AND db.is_read_only = 0
AND (hadrstate.role = 1 or hadrstate.role is null);
EXEC(@createDatabaseUserAndRole)
GO
USE [master];
GRANT EXECUTE ON sys.xp_readerrorlog
TO [SCOM_HealthService]
USE [msdb];
GRANT SELECT on [dbo].[sysjobschedules]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[sysschedules]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[sysjobs_view]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[log_shipping_primary_databases]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[log_shipping_secondary_databases]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[log_shipping_monitor_history_detail]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[log_shipping_monitor_secondary]
TO [SCOM_HealthService];
GRANT SELECT on [dbo].[log_shipping_monitor_primary]
TO [SCOM_HealthService];
GRANT EXECUTE on [dbo].[sp_help_job]
 TO [SCOM_HealthService];
GRANT EXECUTE on [dbo].[sp_help_jobactivity]
TO [SCOM_HealthService];
EXEC sp_addrolemember @rolename='PolicyAdministratorRole'
, @membername='SCOM_HealthService';
EXEC sp_addrolemember @rolename='SQLAgentReaderRole'
, @membername='SCOM_HealthService';

6. In order to run SQL Server MP tasks, such as “Set database Offline”, “Set database Online”,
and “Set database to Emergency state,” grant HealthService SID account with permission
ALTER ANY DATABASE.

USE [master]
GRANT ALTER ANY DATABASE TO [SCOM_HealthService];

7. The login “NT AUTHORITY\SYSTEM” needs to be present as a SQL login, and must not be set
to “Disabled” status, also “NT AUTHORITY\SYSTEM” login must be present and enabled for
Cluster Nodes and Always On.

How to Configure HealthService Service SID for SQL Server Cluster Instances

To configure HealthService Service SID for the monitoring of SQL Server Failover Cluster, take the
following steps at each cluster node.

1. Launch mmc.exe and add the following two snap-ins:

Component Services
WMI Control (for local computer)

2. Expand Component Services, right-click My Computer, click Properties and go Security

tab.

3. Click button Edit Limits in section Launch and Activation Permissions.

4. In Launch and Activation Permission, allow the following permissions for the “NT
SERVICE\HealthService” account:

Remote Launch
Remote Activation
5. Go to snap-in WMI Control and call its properties, go to Security tab, select namespace
Root\CIMV2 and click button Security.

6. Allow the following permissions for the “NT SERVICE\HealthService” account:

Enable Account
Remote Enable
 7. Click button Advanced.

8. In Permissions Entry for CIMV2, select the “HealthService” account and click Edit, make sure
Applies to is set to This namespace only, and enable the following permissions:

Enable Account
Remote Enable

How to Configure SCOM SDK Run As Profile

This management pack needs the Author set of privileges on the SCOM SDK to be able to create a
management pack and store overrides in it. If the default action account on SCOM does not have
these permissions, make sure to have an account granted with them and map this account to the
Microsoft SQL Server SCOM SDK Run As Profile.

How to Configure Permissions for Always On Workflows when Servers Have Machine
Names Longer than 15 Characters

Please note that regardless of the used account (Local System or a Domain User account) and the
method of rights granting, you should make sure that the account has the permissions listed below.
The process of obtaining permissions is described below as a case when Local System account is
used for monitoring.

Example: You have three replicas in your Availability Group, which are hosted on the following
computers: comp1, comp2 and comp3. At that, comp1 hosts the primary replica. In this case, you
should configure security settings for comp1 on comp2 and comp3 computers.

Note: If comp2 would host primary replica (after failover), other computers should also have
configured WMI security for this computer. In general, you have to make sure that Local System
account of each node, which can act as Primary one, have WMI permissions for the other nodes of
the current Availability Group. The same is true for the Domain Action Account used for monitoring.
Therefore, below are the steps to configure security for configurations with Local System account
(please note that in the provided instruction it is considered that SQLAON-020 computer hosts the
primary replica).

1. Launch mmc.exe and add two Snap-Ins:

Component Services
WMI Control (for local computer)

2. Expand Component Services, right-click My Computer, click Properties, go to COM Security

tab, and click button Edit Limits button in section Launch and Activation Permissions.

3. In form Launch and Activation Permission, allow the following permissions for the remote
machine’s account:

Remote Launch
Remote Activation
4. Go to WMI Control snap-In and open its properties, go to tab Security, select namespace
Root\CIMV2, and click button Security.

5. Alow the following permissions for the target computer:

Enable Account
Remote Enable
 6. Click button Advanced, select the target account and click button Edit.

7. Make sure that parameter Applies to is set to This namespace only and enable the following
permissions:

Enable Account
Remote Enable

Steps above should be taken on each replica participating in the target Availability Group.
Configuring Low-Privilege Monitoring

This section describes how to configure the Management Pack for low-privilege access. All
workflows (discoveries, rules, monitors, and actions) in this management pack are bound to Run As
profiles described in Run As Profiles. To enable low-privilege monitoring, appropriate permissions
should be granted to Run As accounts and these accounts should be bound to respective Run As
profiles. Subsections below describe how to grant permissions at both Operating System and SQL
Server level for all monitoring modes.

Low-Privilege Agent Monitoring

To configure low-privilege environments for local agent monitoring, perform the steps described
below.

In Active Directory

In Active Directory, create three domain users that will be commonly used for low-
privilege access to all target SQL Server instances:

SQLTaskAction
SQLDiscovery
SQLMonitor

Create a domain group named SQLMPLowPriv and add the following domain users:

SQLDiscovery
SQLMonitor

Grant SQLMPLowPriv with a special permission: Read-only Domain Controllers – “Read

Permission”

On Agents

Grant accounts SQLTaskAction and SQLMPLowPriv with the Read permission on

HKLM:\Software\Microsoft\Microsoft SQL Server registry path.

Add domain users SQLTaskAction and SQLMonitor to “EventLogReaders” local group.

Configure the “Allow log on locally” local security policy setting to allow the
SQLTaskAction domain user and SQLMPLowPriv domain group users to log on locally.

Grant “Execute Methods”, “Enable Account”, “Remote Enable”, “Read Security”

permissions to SQLTaskAction and SQLMPLowPriv for these WMI namespaces:

root
root\cimv2
root\default
root\Microsoft\SqlServer\ComputerManagement11 (if exists)
root\Microsoft\SqlServer\ComputerManagement12 (if exists)
root\Microsoft\SqlServer\ComputerManagement13 (if exists)
root\Microsoft\SqlServer\ComputerManagement14 (if exists)
root\Microsoft\SqlServer\ComputerManagement15 (if exists)
 Grant SQLMPLowPriv with the Read permission on HKLM:\Software\Microsoft\Microsoft
SQL Server\[InstanceID]\MSSQLServer\Parameters registry path on each monitored
instance.

Additional steps for cluster SQL Server instances

Take steps above for each node in a cluster.

Grant SQLMPLowPriv and SQLTaskAction with “Remote Launch” and “Remote

Activation” DCOM permissions using DCOMCNFG. Please note that both defaults and
limits should be adjusted.

Allow Windows Remote Management through the Windows Firewall.

Grant “Full Control” access for the cluster to the SQLMPLowPriv using Failover Cluster
Manager.

Grant “Execute Methods”, “Enable Account”, “Remote Enable”, “Read Security”

permissions to SQLTaskAction and SQLMPLowPriv for WMI namespace root\MSCluster.

On SQL Server instances

Open SQL Server Management Studio and connect to the instance of SQL Server
Database Engine.

In SQL Server Management Studio, for each instance of SQL Server Database Engine
running on a monitored server, create a login for both SQLMPLowPriv and
SQLTaskAction.

Create SQLMPLowPriv and SQLTaskAction users in each user database, master, msdb,
and model. Link SQLMPLowPriv users to SQLMPLowPriv login and SQLTaskAction users
to SQLTaskAction login.

--This script is an example of the creation new users

-- in database msdb. Make sure to execute such a script
-- for every database on each SQL instance.
use msdb
go
CREATE USER [SQLMPLowPriv] FOR LOGIN [SQLMPLowPriv]
CREATE USER [SQLTaskAction] FOR LOGIN [SQLTaskAction]

Grant SQLMPLowPriv with the following permissions:

use master
go
GRANT VIEW server state to [SQLMPLowPriv]
GRANT VIEW any definition to [SQLMPLowPriv]
GRANT VIEW any database to [SQLMPLowPriv]
GRANT EXECUTE ON xp_readerrorlog TO [SQLMPLowPriv]

use msdb
go
grant EXECUTE ON msdb.dbo.sp_help_job to [SQLMPLowPriv]
 grant EXECUTE ON msdb.dbo.sp_help_jobactivity to [SQLMPLowPriv]
grant SELECT ON sysjobs_view to [SQLMPLowPriv]
grant SELECT ON sysschedules to [SQLMPLowPriv]
grant SELECT ON sysjobschedules to [SQLMPLowPriv]
grant SELECT ON log_shipping_monitor_history_detail
to [SQLMPLowPriv]
grant SELECT ON log_shipping_monitor_secondary
to [SQLMPLowPriv]
grant SELECT ON log_shipping_secondary_databases
to [SQLMPLowPriv]
grant SELECT ON log_shipping_monitor_primary
to [SQLMPLowPriv]
grant SELECT ON log_shipping_primary_databases
to [SQLMPLowPriv]

For msdb database: add user SQLMPLowPriv to database roles SQLAgentReaderRole

and PolicyAdministratorRole.

use msdb
go
ALTER ROLE [SQLAgentReaderRole] ADD MEMBER [SQLMPLowPriv]
ALTER ROLE [PolicyAdministratorRole] ADD MEMBER [SQLMPLowPriv]

On SMB Shares

Grant share permissions by opening share properties dialog for the share, which hosts
SQL Server data files or SQL Server transaction log files.
Grant Read permissions to SQLMPLowPriv.
Grant NTFS permissions by opening the properties dialog for the shared folder and
navigate to the “Security” tab.
Grant Read permissions to SQLMPLowPriv.

Optional steps for tasks on Agents

Some optional System Center Operations Manager tasks require a higher privilege on an
agent machine and/or database to allow the task execution.

You should execute the following provisioning steps on the agent machine or the database
only if you want to allow the System Center Operations Manager console operator to take
remedial actions on that target.

If the task is related to starting or stopping an NT service (such as DB Engine Service,

SQL Server Agent service, SQL Full Text Search Service, ntegration Services): on the
agent machine, grant the SQLTaskAction user permission to start or stop an NT service
This involves setting a ervice’s security descriptor. For more information, see Sc sdset.

Read the existing privileges for a given service (using sc sdshow) and then grant
additional privileges to the SQLTaskAction user for that server.

For example, suppose the results of the sdshow command for SQL Server service are as
follows:
 D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:
(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

In this case, the following command line grants sufficient access to SQLTaskAction for
starting and stopping the SQL Server service (please replace colored strings with
appropriate values and keep everything on a single line of text).

sc sdset SQLServerServiceName D:(A;;GRRPWP;;;SID for SQLTaskAction)

(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:
(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

In SQL Server Management Studio, add SQLTaskAction to db_owner database role for
each database if the task is related to performing database checks:

“Check Catalog (DBCC)”

“Check Database (DBCC)”
“Check Disk (DBCC)” (invokes DBCC CHECKALLOC)

USE msdb
GO
ALTER ROLE [db_owner] ADD MEMBER [SQLTaskAction]

Grant the ALTER ANY DATABASE privilege to SQLTaskAction login to run the task if the
task is related to changing the database state:

“Set Database Offline”

“Set Database Emergency State”
“Set Database Online”

USE master
GO
GRANT ALTER ANY DATABASE TO [SQLTaskAction]

On System Center Operations Manager

Import the SQL Server Management Pack if it has not been imported.

Create an SQLTaskAction, SQLDiscovery and SQLMonitor Run As accounts with

“Windows” account type. For more information about creation of a Run As account,
see How to Create Run As Account in Operations Manager 2012. For more information
about various Run As Account types, see Managing Run As Accounts and Profiles in
Operations Manager 2012.

On the System Center Operations Manager console, configure the Run As profiles as
follows:

Set the “Microsoft SQL Server Task Run As Profile” Run As profile to use the
SQLTaskAction Run As account.
 Set the “Microsoft SQL Server Discovery Run As Profile” Run As profile to use
the SQLDiscovery Run As account.
Set the “Microsoft SQL Server Monitoring Run As Profile” Run As profile to use
the SQLMonitor Run As account.

Low-Privilege Agentless Monitoring

To configure Low-Privilege Agentless Monitoring, perform the steps described below.

The steps below are suitable for SQL Server on both platforms: Windows and Linux.

On SQL Instance

Open SQL Server Management Studio and connect to the instance of SQL Server
Database Engine.

In SQL Server Management Studio, for each instance of SQL Server Database Engine
running on a monitored server, create an SQL login for monitoring and grant the
following permissions:

use msdb
go
GRANT VIEW server state to [SQLMPLowPriv]
GRANT VIEW any definition to [SQLMPLowPriv]
GRANT VIEW any database to [SQLMPLowPriv]
GO
ALTER ROLE [db_datareader] ADD MEMBER [SQLMPLowPriv]
GRANT EXECUTE ON xp_readerrorlog to [SQLMPLowPriv]
GO

Create a user in each user database, master, msdb, and model. Link created users to
login SQLMPLowPriv.

--This script is an example of the creation new users

-- in database msdb. Make sure to execute such a script
-- for every database on each SQL instance.
use msdb
go
CREATE USER [SQLMPLowPriv] FOR LOGIN [SQLMPLowPriv]

For msdb database, grant the user with the following permissions:

use msdb
go
GRANT EXECUTE ON msdb.dbo.sp_help_job to [SQLMPLowPriv]
GRANT EXECUTE ON msdb.dbo.sp_help_jobactivity to [SQLMPLowPriv]
GRANT SELECT ON sysjobs_view to [SQLMPLowPriv]
GRANT SELECT ON sysschedules to [SQLMPLowPriv]
GRANT SELECT ON sysjobschedules to [SQLMPLowPriv]
GRANT SELECT ON log_shipping_monitor_history_detail
to [SQLMPLowPriv]
GRANT SELECT ON log_shipping_monitor_secondary
 to [SQLMPLowPriv]
GRANT SELECT ON log_shipping_secondary_databases
to [SQLMPLowPriv]
GRANT SELECT ON log_shipping_monitor_primary
to [SQLMPLowPriv]
GRANT SELECT ON log_shipping_primary_databases
to [SQLMPLowPriv]

Some optional System Center Operations Manager tasks require a higher privilege on
an agent machine and/or database to allow the task execution.

You should execute the following provisioning steps on the database only if you want
to allow the System Center Operations Manager console operator to take remedial
actions on that target.

In SQL Server Management Studio, add SQL Login SQLMPLowPriv to db_owner

database role for each database if the task is related to performing database
checks:

“Check Catalog (DBCC)”

“Check Database (DBCC)”
“Check Disk (DBCC)” (invokes DBCC CHECKALLOC)

use [yourdatabase]
go
ALTER ROLE [db_owner] ADD MEMBER [SQLMPLowPriv]
go

Grant the ALTER ANY DATABASE privilege to SQL Login SQLMPLowPriv to

performing database tasks:

“Set Database Online”

“Set Database Offline”
“Set Database to Emergency State”

use master
go
GRANT ALTER ANY DATABASE to [SQLMPLowPriv]

For msdb database: add the SQLMPLowPriv user to the SQLAgentReaderRole and
PolicyAdministratorRole database roles:

use [msdb]
go
ALTER ROLE [PolicyAdministratorRole]
ADD MEMBER [SQLMPLowPriv]
go
use [msdb]
go
ALTER ROLE [SQLAgentReaderRole]
 ADD MEMBER [SQLMPLowPriv]
go

Appendix: Known Issues and Troubleshooting

Seed discovery of a deleted platform pack may be still working on the pool nodes

Issue: An error may occur when an operating system pack was deleted, but its seed discovery is still
working on the pool nodes.

Resolution: Upon deletion of an operating system pack, delete the corresponding seed discovery
manually.

“Database Status” monitor is constantly changing its status

Issue: If “Auto Close” parameter for the database is set to “True", “Database Status” monitor is
constantly changing its status from “Healthy” to “Recovering/Restoring” and vice versa according to
the timeout set in the override parameters.

Resolution: In view of the monitoring operation specifics, no resolution is required.

Enabling of “Auto Close” database parameter blocks collection of the performance

metrics

Issue: If “Auto Close” parameter for a database is set to “True", performance rules targeting
Database return empty values for this particular database.

Resolution: Set “Auto Close” database parameter back to “False”.

If a machine containing a monitored agentless instance is not available, multiple

errors occur in the watcher node event log

Issue: If a machine containing a monitored agentless instance is not available, multiple SQL Server
Monitoring MP Windows and SQL Server Discovery MP Windows errors occur in the watcher node
event log. The errors will keep coming until the machine is available.

Resolution: No resolution available.

Some issues may occur upon installation of the management pack

Issue: The log reader may begin scanning the whole log of the SQL Server, which may lead to
triggering of all alerts found. At that, the RepeatCount property may contain an excess number of
events.

Resolution: No resolution available.

Double quotes in a database name may cause database console tasks failures

Issue: Database console tasks take database names enclosed in double quotes as one of their
arguments. A database name may contain any symbol including double quotes. If it does, the
console tasks for this database will not work.
Resolution: No resolution.

Odd behavior of the monitors’ operational states

Issue: If the resource pool contains more than one management server, the operational states of all
the monitors will be changing according to the failover settings of the resource pool.

Resolution: No resolution.

SQL Server on Docker: multiple errors occur after a reboot of the Docker

Issue: Multiple errors occur after a reboot of the SQL Server on Docker because Docker-ID
(MachineName) is changed after the reboot.

Resolution: In SCOM, go to the monitoring template properties, open Service Details tab and click
“Retry Connection”.

Extended discovery intervals

Issue: In case of using a resource pool with several watcher nodes, the discovery intervals may be
significantly extended.

Resolution: No resolution.

None of the event rules works on localized SQL DB Engines

Issue: None of the event rules works on localized SQL DB Engines. In the current implementation,
these rules work with the English version only.

Resolution: No resolution.

Console tasks for Availability Group objects with names containing double-quote
character do not work

Issue: Double-quota character may not be used in names of Availability Group and Databases in
the Availability Group (for Always On). Therefore, console tasks for objects with such names do not
work.

Resolution: No resolution.

Connection fails when an IP address is specified as a connection string for a Linux-

based instance

Issue: When adding a Linux-based instance (“Add Instances” step of the Add Monitoring Wizard),
the connection test fails if IP address is specified as a connection string and the authentication type
is "Windows AD credentials".

Resolution: Specify the name of the machine as a connection string and use the correct
authentication type.

SCOM issue: Configuration Service may frozen after Management Pack re-installation

Issue: Configuration Service may frozen after Management Pack re-installation.

Resolution: No resolution.

“Out of memory” errors are received in the Operations Manager

Issue: “Out of memory” errors are regularly received in the Operations Manager while the server
has plenty of memory.

Resolution: Isolate the SQL Server WMI provider and increase the UploadTimeout.

To isolate the provider in its own host, run the script below in an elevated PowerShell session:

$a =
[WMI]'Root\Microsoft\SqlServer\ComputerManagement14:__Win32Provider.name="M
SSQL_ManagementProvider"'
$a.HostingModel = "NetworkServiceHost:SQL"
$a.put()

To revert the changes, run this script.

$a =
[WMI]'Root\Microsoft\SqlServer\ComputerManagement14:__Win32Provider.name="M
SSQL_ManagementProvider"'
$a.HostingModel = "NetworkServiceHost"
$a.put()*

To increase the unload timeout to 30 minutes, follow these steps:

Open WBEMTEST.
Click the “Connect” button.
In the “Namespace”, enter Root\Microsoft\SqlServer\ComputerManagement14, and then click
the “Connect” button.
Click the “Query” button.
Enter select * from __win32provider where name = 'MSSQL_ManagementProvider',
then click the “Apply” button.
Double-click the resulting row.
Double-click the “UnloadTimeout” value.
Select “Not NULL” level, enter 00000000003000.000000:000, and then click the “Save
Property” button.
Click the “Save Object” button.
Click the “Close” button.

Errors occur in workflows related to Memory-Optimized Data databases

Issue: The following errors occur in workflows related to Memory-Optimized Data for databases
with the “AutoClose” parameter set to “True”:
"Database is being recovered. Waiting until recovery is finished."

Resolution: No resolution.

“Custom user policy” discovery discovers system databases

Issue: The discovery may discover custom SQL Server policies for system databases (such as
“master”, “msdb” etc.) and custom ones. In fact, a custom user policy can be performed only
databases created by the user.

Resolution: No resolution.

SCOM issue: Sometimes SCOM console may show an exception in "Database

Engines" state view if the selected instance is in the process of undiscovery

Issue: Sometimes SCOM console may show an "object reference not set" exception in "Database
Engines" state view if the selected instance is in the process of undiscovery*.*

Resolution: No resolution.

“A connection was successfully established with the server, but then an error
occurred during the login process” error appears when adding a new instance to the
monitoring by means of the Add Monitoring Wizard

Issue: Sometimes, when you are finishing to add a new instance to the monitoring with the Add
Monitoring Wizard, an error message may show up: “An error occurred discovery: A connection was
successfully established with the server, but then an error occurred during the login process.” Most
likely, this error indicates that the resource pool “SQL Server MP Monitoring Pool” has not been
discovered yet.

Resolution: Decrease the intervals for both "MSSQL: Generic Monitoring Pool Watcher Discovery"
and "Discover All Management Servers Pool Watcher" discoveries to force them to run right away,
then restore the previous value.

“CPU Utilization” performance rule may show values greater than 100

Issue: Sometimes “CPU Utilization” performance rule may show values greater than 100. This occurs
due to a known issue in the sys.dm_os_ring_buffers dynamic management view which is used by the
rule to get the utilization value.

Resolution: No resolution.

A “Job Failed” error appears when adding a new SQL Server instance to monitoring
with “Add Monitoring Wizard”

Issue: On the last step of the Wizard, when clicking “Create”, an error message appears that states
“Job Failed.” This most likely indicates that you name the monitoring template with one of the
following names: SystemCenter, Windows, System, SQLCorelib.

Resolution: Do not use any of the mentioned words as a monitoring template name.

SQL Server instances have not been discovered after importing the management
pack and configuring it, and no alerts have been raised

Issue: This may indicate that you have bound a non-basic action account to the SQL
Credentials run as profile.

Resolution: Configure the SQL Server MP Run As Profiles in appliance with Security Configuration.