Microsoft
SCOM – Tips & Tricks
This document is designed to support Microsoft SCOM users, architects,
and administrators in their daily work with SCOM. The tips compiled here are
gathered from community experts, SCOM-focused blogs, Microsoft’s official
documentation, and the knowledge we at NiCE have gained over many years. Where
applicable, we have included references for additional resources.
1. Rename the Default
Management Pack
2. Always Use Dedicated
Override Management Packs
3. Disable Monitors by Default After Importing MPs
4. Tune Discovery Intervals
Carefully
5. Optimize Performance
Data Collection
6. Prefer Agent-Based Over
Agentless Monitoring
7. Implement Management
Pack Version Control and Backups
9. Use Service-Centric
Monitoring
10. Design Alerts With an
Owner and Action
12. Use the SCOM Health
Check / Assessment
13. Separate Test,
Acceptance, and Production
15. Use Naming Conventions
Consistently
16. Reduce Alert Noise
Before Adding More Monitoring
17. Review and Clean
Overrides Regularly
18. Document Why Overrides
Exist
19. Integrate SCOM With
ITSM or Dashboards
20. Treat SCOM as a Living
System
21. Avoid Using the
“Management Servers Resource Pool” for Everything
22. Tune Heartbeat and
Health Service Alerts
23. Use Maintenance Mode
Correctly (and Automatically)
24. Scope Views and
Dashboards by Group
25. Use Dynamic Groups
Instead of Static Groups
26. Clean Up Decommissioned
Objects Regularly
27. Understand and Respect
Cookdown
28. Limit Event Log
Collection
29. Use Overrides Instead
of Editing MPs
30. Document Custom
Monitoring Decisions
31. Regularly Review Alert
Volume Trends
32. Separate Operator and
Admin Views
34. Treat Overrides as
Technical Debt
35. Align Monitoring With
SLAs
36. Use Scheduled Reports
Sparingly
37. Don’t Over-Monitor
“Green” Systems
38. Validate Monitoring
After Patching
39. Regularly Review Run As
Accounts
40. Periodically Revalidate
the Original Monitoring Goals
41. Don’t Treat SCOM Alerts
as Tickets
42. Suppress Duplicate or
Cascading Alerts
43. Review and Prune
Disabled Monitors
44. Use Health Explorer for
Root Cause Analysis
45. Understand Monitor
Reset Behavior
46. Avoid Overusing
PowerShell Script Monitors
47. Validate Permissions
After Security Hardening
48. Don’t Ignore Warning
Alerts
49. Review Data Retention
Settings Regularly
50. Validate MP
Compatibility Before Upgrades
51. Avoid Monitoring
Everything “Just in Case”
52. Regularly Test Alert
Notifications
53. Use Severity Levels
Consistently
54. Keep Management Packs
Up to Date
55. Don’t Ignore Console
Performance
56. Validate Group
Membership Logic
57. Avoid “Set and Forget”
Monitoring
58. Use Custom Views
Sparingly
59. Align SCOM Ownership
Clearly
60. Measure SCOM Success by
Outcomes, Not Alerts
61. Automate
Agent Maintenance Mode via PowerShell
62. Use
Scripts to Manage Proxy-Enabled Agents
63. Populate
Custom Attributes via PowerShell
64. Use
“Script in Script” for Complex Linux Monitoring
65. Monitor
Robocopy and Other Logs Using NiCE MP
66.
Understand How SCOM Encrypts Data
67. Script
Maintenance Mode Based on SCCM Collections
68. Create
Custom Dynamic Groups Based on Registry Keys
69. Always
Review Update Rollup Fix Lists Before Applying
70. Apply
Hotfixes Separately When Microsoft Releases UR Add-Ons
71. Fix
Linux Agent Upgrade Failures Caused by Apache
72. Extend
Monitoring with SQL Custom Query-Based Monitors
73. Use the
SCOM Reporting Series to Unlock the Data Warehouse
74. Report
on Availability Using State Views Instead of Alerts
75. Treat
SCOM Updates as an Observability Improvement, Not Just Patching
76. Use
Community SCOM Blogs as an Early Warning System
77. Audit
Management Pack Changes with Change Tracking
78. Use Easy
Tune to Reduce Alert Noise Quickly
79. Place
Agents into Maintenance Mode from the Agent Computer
80. Migrate
Overrides When Upgrading SCOM
81.
Visualize Override Sprawl with Power BI Sankey Diagrams
82. Use Bi‑Directional
Integration with ITSM Tools
83. Restart
the Agent After Removing a Logical Disk or Filesystem
84. Always
Install Linux/AIX Agents Using the -enable-opsmgr Flag
85. Resolve
Multiple Critical Event Log Entries (ID 17178) After Agent Restart
86. Fix
“SCOM Agent Failed During SSH Discovery. Exit Code: 1”
87. Test SCOM Connectivity and Dependencies Early
88. Configure Your Firewall Correctly
89. Fix SSL Certificate Problems on Linux/UNIX Agents
90. Use Proven UNIX/Linux Troubleshooting Techniques
91. Clean Up the SCOM Database Using
Remove-SCOMDisabledClassInstance
92. Avoid Special Characters in SCOM Service Account
Passwords
References Per Tip Where Applicable
Level:
Intermediate (Admin)
Versions: All (SCOM 2012+)
Why:
The Default Management Pack is intended only for temporary testing and should
never be used for permanent overrides or custom monitors in production. Saving
overrides there is a long-standing bad practice that leads to clutter, hidden
dependencies, and painful cleanup later. Many administrators unintentionally
store overrides in the Default MP simply because it is preselected in the
console, which over time turns it into an unmanageable dumping ground.
How:
In the SCOM console, go to Administration → Management Packs,
locate Default Management Pack, and rename its Display Name (it
is unsealed, so renaming is supported) to something like “DO NOT USE –
Default MP”. From that point forward, always create or select a dedicated
unsealed MP for overrides or custom monitoring, ideally aligned to the sealed
MP or workload being customized.
When & Where:
This should be done immediately after deploying a new SCOM management group or
as an early cleanup task in existing environments [ds.squaredup.com]. It is
especially valuable in environments with multiple admins or consultants, as the
renamed MP acts as a persistent visual safeguard against accidental misuse.
Level:
Intermediate (Admin)
Versions: All
Why:
Mixing overrides for multiple sealed MPs into a single override MP creates
tight coupling and makes troubleshooting, exporting, or migrating
configurations extremely difficult. Microsoft best practice is to isolate
overrides per workload or per sealed MP to keep changes traceable and portable.
How:
When creating overrides, always select “New Management Pack” and name it
clearly (e.g., Overrides – Windows Server MP). Maintain a consistent
naming convention so that override MPs can be easily identified, backed up, and
migrated between environments.
When & Where:
This practice should be enforced whenever new MPs are introduced or tuned. It
is critical in environments with separate test, acceptance, and production
management groups where overrides must be promoted cleanly between tiers.
Level:
Intermediate (Admin)
Versions: All
Why:
Most vendor MPs are designed to be broadly applicable, not
environment-specific. Enabling everything immediately often results in alert
storms, noise, and operator fatigue. This causes teams to distrust SCOM alerts
altogether.
How:
After importing a new MP, create overrides to disable all non-critical monitors
and rules. Then selectively enable only those monitors that are meaningful for
your environment, applications, and support model.
When & Where:
This approach should be applied immediately after importing any new MP,
especially infrastructure MPs (Windows, SQL, IIS). It is most effective in
large environments where alert noise quickly becomes unmanageable.
Level: Advanced
(Admin)
Versions: All
Why:
Discovery workflows are among the most expensive operations in SCOM. Running
them too frequently consumes unnecessary CPU, memory, and network resources on
agents and management servers, especially when the discovered objects rarely
change.
How:
Review discovery rules in each MP and increase their interval (for example,
from hourly to daily) unless rapid rediscovery is explicitly required. Override
discovery intervals rather than modifying sealed MPs.
When & Where:
This tuning should be done after the initial discovery phase of a new
deployment and revisited during performance optimization exercises, especially
in large or highly virtualized environments.
Level: Advanced
(Admin)
Versions: All
Why:
Unoptimized performance collection can dramatically increase Operations DB and
Data Warehouse size while providing little operational value. Excessive data
also slows reports and increases SQL maintenance overhead.
How:
Use optimized collection settings, reduce sample frequency, and disable
unnecessary performance counters. Only collect metrics that are actually used
for alerting, dashboards, or capacity planning.
When & Where:
Apply this tuning once baseline monitoring is established and during periodic
database growth reviews. It is particularly important in environments with long
data retention requirements.
Level:
Intermediate (Admin)
Versions: All
Why:
Agentless monitoring relies heavily on remote calls from management servers,
which does not scale well and creates blind spots. Agent-based monitoring
provides better performance, reliability, and richer monitoring data.
How:
Deploy the SCOM agent wherever possible and reserve agentless monitoring only
for corner cases such as network devices or systems where agents are explicitly
unsupported.
When & Where:
This decision should be made during initial design and revisited when
onboarding new platforms. It is especially relevant in large Windows server environments.
Level:
Intermediate (Admin)
Versions: All
Why:
Unsealed MPs contain critical configuration knowledge. Without backups or
versioning, accidental deletions or bad overrides can be difficult or
impossible to reverse.
How:
Regularly export unsealed MPs and store them in source control or a secure
repository. Automate exports using PowerShell where possible.
When & Where:
This should be implemented as part of operational governance and reviewed after
any major tuning or MP changes.
Level:
Intermediate (Admin)
Versions: All
Why:
SCOM infrastructure components (management servers, gateways, SQL databases)
are themselves critical services. If they degrade, monitoring quality suffers
silently.
How:
Ensure the SCOM internal MPs are enabled and tuned. Monitor health of
management servers, workflows, and database performance just like any other
production workload.
When & Where:
This should be enabled in every environment and reviewed after upgrades or
topology changes.
Level:
Intermediate (Operator/Admin)
Versions: 2012+
Why:
Operators care about service health, not individual components. Without service
views, alerts lack context and troubleshooting takes longer.
How:
Create distributed applications or service maps that represent real business
services and include all dependent components.
When & Where:
Best applied once core infrastructure monitoring is stable and for
customer-facing or business-critical applications.
Level:
Intermediate (Operator)
Versions: All
Why:
Alerts without a clear owner or action lead to alert fatigue. Every alert
should answer: Who reacts? and What should they do?.
How:
Review each alert and ensure it has meaningful descriptions, severity, and
resolution steps. Document resolution steps using the company knowledge tab and
store in a dedicated unsealed knowledge MP for each sealed Management pack.
Disable alerts that do not require action.
When & Where:
This should be an ongoing operational task and part of regular alert hygiene
reviews.
Level:
Intermediate (Admin)
Versions: All
Why:
Without proper grooming, SCOM databases grow excessively, impacting performance
and maintenance windows.
How:
Review and adjust grooming settings for alerts, events, and performance data
according to business and compliance requirements.
When & Where:
Configured early in deployment and reviewed quarterly or after major monitoring
scope changes.
Level:
Intermediate (Admin)
Versions: 2016+
Why:
Configuration drift and legacy settings accumulate over time. Microsoft’s SCOM
assessment identifies risks and misconfigurations early.
How:
Run the SCOM Assessment via Microsoft Services Hub and apply recommendations
selectively.
When & Where:
Ideal before upgrades, during performance issues, or as part of annual health
reviews.
Level: Advanced
(Admin)
Versions: All
Why:
Testing MP changes directly in production increases risk and instability. A
tiered approach reduces outages caused by bad overrides.
How:
Maintain separate SCOM environments or management groups and promote MPs
through them using exports.
When & Where:
Critical in regulated or large enterprise environments.
Level: Advanced
(Admin)
Versions: All
Why:
Poorly written custom MPs can severely impact performance and stability if
cookdown and best practices are ignored.
How:
Follow Microsoft MP authoring guidelines and reuse existing modules where
possible.
When & Where:
Only when vendor MPs are insufficient and internal knowledge is strong.
Level: Beginner /
Intermediate
Versions: All
Why:
Inconsistent naming makes long-term management and troubleshooting harder.
How:
Apply clear, consistent naming to MPs, overrides, groups, and views.
When & Where:
From day one and enforced through documentation.
Level:
Intermediate
Versions: All
Why:
Adding monitoring on top of noisy alerts amplifies problems rather than solving
them.
How:
Stabilize existing alerts first, then expand coverage.
When & Where:
Before onboarding new workloads.
Level:
Intermediate (Admin)
Versions: All
Why:
Obsolete overrides remain long after systems are decommissioned.
How:
Audit override MPs and remove unused management packs and their override MPs.
When & Where:
During quarterly or annual maintenance.
Level:
Intermediate
Versions: All
Why:
Overrides without context are confusing years later.
How:
Use MP descriptions or external documentation to explain intent, author and
date.
When & Where:
Whenever an override is created.
Level: Advanced
Versions: All
Why:
Standalone monitoring limits operational value.
How:
Integrate with ticketing systems and visualization tools like dashboards.
When & Where:
Once monitoring is stable and trusted.
Level: All
Versions: All
Why:
SCOM degrades if left unattended.
How:
Continuously review MPs, alerts, and performance.
When & Where:
Always — SCOM requires active stewardship.
Level: Advanced (Admin)
Versions: 2012+
Why:
By default, many workflows target the All Management Servers Resource Pool,
which can cause unnecessary load on every management server. This reduces
scalability and can introduce instability when a single workflow misbehaves.
How:
Create dedicated resource pools for specific workloads (e.g., network
monitoring, Unix/Linux monitoring, or third-party MPs) and explicitly target
workflows to those pools.
When
& Where:
Apply this in medium to large environments, especially when onboarding MPs that
rely heavily on SDK or PowerShell workflows. Review pool usage whenever
performance issues arise.
Level: Intermediate (Admin /
Operator)
Versions: All
Why:
Heartbeat failure alerts are important, but overly aggressive thresholds can
generate false positives during patching, reboots, or network hiccups, creating
unnecessary noise.
How:
Adjust heartbeat thresholds and timeouts via overrides so that alerts reflect
real outages rather than expected maintenance events.
When
& Where:
Tune these settings early in deployment and revisit whenever patching
strategies or maintenance windows change.
Level: Beginner / Intermediate
Versions: All
Why:
Failing to place systems into maintenance mode leads to false alerts and skewed
SLA reporting. Manual maintenance mode is also frequently forgotten.
How:
Use scheduled maintenance mode for patch windows and integrate automation
(PowerShell or orchestration tools) to start and stop maintenance
automatically.
When
& Where:
Essential in environments with regular patching, deployments, or infrastructure
automation.
Level: Intermediate (Operator)
Versions: All
Why:
Global views showing “everything” overwhelm operators and make it harder to
focus on what they own or support.
How:
Create dynamic groups (e.g., by application, environment, or support team) and
scope views, dashboards, and alerts to those groups.
When
& Where:
Most useful in NOC or operations teams where responsibilities are clearly
segmented.
Level: Intermediate (Admin)
Versions: All
Why:
Static groups require constant manual updates and quickly become inaccurate as
environments change.
How:
Create dynamic groups based on discovery attributes such as OS version, naming
conventions, or installed software.
When
& Where:
Apply this everywhere groups are used — for views, overrides, maintenance mode,
and reporting.
Level: Intermediate (Admin)
Versions: All
Why:
Decommissioned servers can linger in SCOM, creating stale alerts and
unnecessary database growth.
How:
Enable and tune grooming settings and periodically review deleted object
retention in both the Operations DB and Data Warehouse.
When
& Where:
Perform during regular maintenance cycles or after large decommissioning
projects.
Level: Advanced (Admin / MP
Author)
Versions: All
Why:
Ignoring cookdown principles leads to duplicate workflows running on every
agent, significantly impacting performance.
How:
Design workflows so that data is collected once and shared across multiple
monitors or rules using optimized modules.
When
& Where:
Critical when authoring custom MPs or troubleshooting unexplained agent CPU
usage.
Level: Advanced (Admin)
Versions: All
Why:
Collecting large volumes of event logs increases database size and often
provides little actionable value.
How:
Disable unnecessary event collection rules and focus only on events that
trigger alerts or reports.
When
& Where:
Review after importing infrastructure MPs and during database growth
investigations.
Level: Beginner / Intermediate
Versions: All
Why:
Editing sealed MPs breaks upgrade paths and introduces unsupported
configurations.
How:
Always apply changes via overrides stored in unsealed MPs rather than modifying
vendor MPs directly.
When
& Where:
This rule applies universally — especially during troubleshooting when quick
fixes are tempting.
Level: Intermediate
Versions: All
Why:
Years later, no one remembers why a monitor was disabled or a threshold
changed, leading to confusion and rework.
How:
Use MP descriptions, naming conventions, or external documentation to explain
why changes were made by whom and when.
When
& Where:
Whenever creating custom rules, monitors, or overrides.
Level: Intermediate (Operator /
Admin)
Versions: All
Why:
Gradual alert creep often goes unnoticed until alert fatigue becomes severe.
How:
Analyze alert trends over time and identify monitors responsible for repeated
noise.
When
& Where:
Monthly or quarterly operational reviews.
Level: Beginner / Intermediate
Versions: All
Why:
Operators need clarity and simplicity, while admins need depth and diagnostics.
Mixing both leads to confusion.
How:
Create role-specific views and dashboards tailored to operators versus
administrators.
When
& Where:
In environments with dedicated NOC or first-line support teams.
Level: Intermediate
Versions: All
Why:
Monitoring components that teams cannot act upon adds noise without value.
How:
Disable alerts for components outside your control and redirect responsibility
clearly to other teams.
When
& Where:
During alert tuning and service ownership reviews.
Level: Advanced (Admin)
Versions: All
Why:
Every override adds complexity. Over time, excessive overrides make
environments fragile and harder to upgrade.
How:
Periodically reassess overrides and remove those that are no longer required.
When
& Where:
Before upgrades and during annual cleanups.
Level: Intermediate (Admin /
Operator)
Versions: 2012+
Why:
If alerts don’t align with SLAs, teams spend time on low-impact issues while
missing critical service breaches.
How:
Map monitoring thresholds and alert severity to SLA definitions.
When
& Where:
During service onboarding and SLA reviews.
Level: Beginner / Intermediate
Versions: All
Why:
Unnecessary scheduled reports consume resources and are often ignored by
recipients.
How:
Review report subscriptions regularly and eliminate unused or redundant
reports.
When
& Where:
Quarterly reporting reviews.
Level: Intermediate
Versions: All
Why:
Healthy systems don’t need excessive scrutiny. Over-monitoring wastes resources
and attention.
How:
Focus deep monitoring on unstable or business-critical systems.
When
& Where:
After establishing baseline stability.
Level: Intermediate
Versions: All
Why:
Patches and upgrades can break discoveries, scripts, or permissions silently.
How:
Spot-check monitoring health after patch cycles.
When
& Where:
After monthly patching or application upgrades.
Level: Advanced (Admin)
Versions: All
Why:
Expired or overprivileged Run As accounts are common sources of monitoring
failures and security risk.
How:
Audit Run As accounts for scope, permissions, and password expiry.
When
& Where:
During security reviews and after credential changes.
Level: All
Versions: All
Why:
Over time, monitoring drifts away from original business goals as environments
evolve.
How:
Revisit why SCOM exists in your organization and adjust monitoring accordingly.
When
& Where:
Annually, or after major organizational or platform changes.
Level: Beginner / Intermediate
Versions: All
Why:
SCOM alerts indicate symptoms, not root causes. Treating every alert as a
ticket often leads to duplicate work, slow resolution, and frustrated operators.
Alerts should inform decisions, not automatically create workload.
How:
Define which alerts warrant ticket creation and which are informational or
aggregated. Use alert suppression or correlation where appropriate before
integrating with ITSM tools.
When
& Where:
This is critical when integrating SCOM with service desks. Apply during alert
design and periodically review integration rules.
Level: Intermediate (Admin)
Versions: All
Why:
One failure can trigger dozens of downstream alerts, obscuring the root cause
and overwhelming operators.
How:
Use alert suppression, dependency monitoring, and distributed applications to
ensure only the root cause alerts are raised.
When
& Where:
Apply after service modeling is in place and during alert noise reduction
initiatives.
Level: Intermediate (Admin)
Versions: All
Why:
Disabled monitors accumulate over time and obscure what is actually
being monitored, increasing cognitive load during troubleshooting.
How:
Periodically review disabled rules and monitors and remove those that are no
longer relevant rather than simply leaving them disabled.
When
& Where:
During quarterly cleanup or pre-upgrade reviews.
Level: Beginner / Intermediate
(Operator)
Versions: All
Why:
Many operators jump straight to alerts without understanding health rollup
logic. Health Explorer provides valuable insight into which monitors are
contributing to an unhealthy state.
How:
Train operators to open Health Explorer from alerts and review monitor state
changes rather than focusing only on alert text.
When
& Where:
Daily operational use, especially for complex or service-based alerts.
Level: Intermediate (Admin)
Versions: All
Why:
Some monitors do not automatically reset, leading to lingering unhealthy states
even after issues are resolved.
How:
Review monitor reset logic (manual vs automatic) and adjust where appropriate,
especially for state-based monitors.
When
& Where:
When troubleshooting alerts that appear “stuck” or after MP imports.
Level: Advanced (Admin / MP
Author)
Versions: All
Why:
PowerShell scripts are powerful but resource-intensive. Excessive or poorly
optimized scripts can cause agent performance issues.
How:
Use native modules and workflows wherever possible. If PowerShell is required,
optimize scripts and ensure proper cookdown.
When
& Where:
When authoring custom MPs or reviewing agent CPU spikes.
Level: Intermediate (Admin)
Versions: All
Why:
Security hardening and GPO changes often break monitoring by restricting agent
or Run As permissions.
How:
After security changes, validate discoveries, scripts, and Run As profiles to
ensure monitoring still functions.
When
& Where:
After security audits, hardening projects, or domain policy changes.
Level: Beginner / Intermediate
Versions: All
Why:
Warning alerts often indicate early signs of degradation. Ignoring them leads
to critical outages that could have been prevented.
How:
Ensure warning alerts are meaningful and reviewed, even if they don’t trigger
immediate action.
When
& Where:
In proactive operations models and SLA-driven environments.
Level: Intermediate (Admin)
Versions: All
Why:
Default retention settings may not align with compliance, reporting, or
capacity planning needs and can cause unnecessary database growth.
How:
Adjust Operations DB and DW retention based on business requirements, not
defaults.
When
& Where:
During capacity planning and compliance reviews.
Level: Advanced (Admin)
Versions: All
Why:
Some older MPs are not compatible with newer SCOM versions and can cause
instability after upgrades.
How:
Review MP compatibility matrices and update or remove unsupported MPs before
upgrading SCOM.
When
& Where:
Mandatory step in any SCOM upgrade project.
Level: Beginner / Intermediate
Versions: All
Why:
Monitoring without purpose creates noise and wastes resources. Monitoring
should always have a clear objective..
How:
Define monitoring goals first, then enable only what supports those goals.
When
& Where:
During initial design and whenever scope expands.
Level: Beginner / Intermediate
Versions: All
Why:
Notification channels break silently due to credential, SMTP, or integration
changes
How:
Periodically test email, webhook, or ticket notifications using test alerts.
When
& Where:
Monthly or after infrastructure changes.
Level: Beginner / Intermediate
Versions: All
Why:
Inconsistent severity usage makes it impossible to prioritize incidents
effectively.
How:
Define clear criteria for Information, Warning, and Critical alerts and enforce
them across MPs.
When
& Where:
During alert design and operational onboarding.
Level: Intermediate (Admin)
Versions: All
Why:
Outdated MPs may contain bugs, inefficient workflows, or missing coverage.
How:
Regularly review vendor and Microsoft MP updates and apply them after testing.
When
& Where:
Quarterly reviews or before platform upgrades.
Level: Intermediate (Admin)
Versions: All
Why:
Slow console performance often indicates underlying SQL or workflow issues and
impacts operator productivity.
How:
Monitor console responsiveness and investigate database, network, or MP-related
causes.
When
& Where:
When operators report slowness or after scale increases.
Level: Intermediate (Admin)
Versions: All
Why:
Incorrect dynamic group logic leads to missing alerts or incorrect scoping.
How:
Periodically review group membership and discovery rules to ensure accuracy.
When
& Where:
After naming convention changes or discovery modifications.
Level: All
Versions: All
Why:
Environments evolve, but monitoring often doesn’t. This leads to blind spots
and obsolete alerts.
How:
Schedule regular monitoring reviews aligned with infrastructure and application
lifecycle changes.
When
& Where:
Ongoing operational practice.
Level: Beginner / Intermediate
Versions: All
Why:
Too many custom views overwhelm users and dilute value.
How:
Create only views that answer specific operational questions.
When
& Where:
During console customization and operator onboarding.
Level: Intermediate (Admin /
Management)
Versions: All
Why:
Unclear ownership leads to neglected tuning, slow upgrades, and monitoring
decay.
How:
Define clear technical and operational ownership for SCOM.
When
& Where:
At program inception and reviewed annually.
Level: All
Versions: All
Why:
The goal of SCOM is service stability and faster resolution—not high alert
counts.
How:
Track outcomes such as reduced MTTR, improved uptime, and fewer surprise
outages.
When
& Where:
In operational reporting and management reviews.
Level: Intermediate (Operator / Admin)
Versions:
SCOM 2016+
Why:
Manually placing agents into maintenance mode is error-prone and easy to forget
during patching windows. Starting with SCOM 2016, you can programmatically
schedule maintenance, which reduces false alerts and missed maintenance
periods. Stefan Roth explains that SCOM 2016 added cmdlets to script this,
giving automation flexibility beyond the GUI.
How:
Use the Start-SCOMAgentMaintenanceMode
PowerShell cmdlet (introduced in SCOM 2016) to place agents into maintenance
mode directly, including scheduling for future windows — for example from
automation tools or deployment scripts.
When & Where:
Apply this where patching is frequent or orchestrated (e.g., monthly updates).
It’s especially useful when integrating maintenance mode into broader CI/CD or
configuration workflows in hybrid infrastructures.
Level: Intermediate (Admin)
Versions: All
Why:
Some management packs or monitoring scenarios require SCOM agents to be
proxy-enabled. Manually checking hundreds of agents is inefficient and prone to
oversight. Stefan Roth’s short PowerShell script quickly identifies
proxy-enabled agents at scale, improving operational hygiene.
How:
On a management server, run a PowerShell query against SCOM to list agents with
the proxy setting enabled. Use this in regular audits or onboarding automation.
When & Where:
Great to use during onboarding of new agents or when troubleshooting MP
behavior that depends on proxy settings (e.g., network device monitoring).
Level: Advanced (Admin / MP Author)
Versions: All
Why:
Dynamic groups and targeted overrides often depend on class attributes that
aren’t discovered by default. For servers in DMZs or with custom configuration
data, registry-based discoveries may not be practical. PowerShell can be used
to populate class attributes dynamically, enabling powerful grouping and
targeting.
How:
Write a PowerShell script that updates SCOM class instance attributes using the
Operations Manager SDK. Use these attributes for dynamic groups, views, and
override targeting.
When & Where:
Useful when dynamic group logic goes beyond built-in discovery, especially for
environments
Level:
Advanced (Admin / Cross-Platform)
Versions:
2012+ (All Linux monitoring capable versions)
Why:
SCOM’s built-in Linux monitor only supports single commands (“one-liner”). For
real world monitoring logic that involves multiple steps or custom scripts,
Stefan Roth demonstrates how a “script in script” technique lets you call
complex logic — overcoming the one–liner limitation.
How:
Wrap your logic in a shell script that calls other scripts and returns a
numeric or mapped state to SCOM. Then configure a two-state monitor to execute
that script and translate results into health states.
When &
Where:
Critical for environments with Linux workloads where robust, multi-step
condition checks are required (e.g., log processing, multi-component checks).
Level: Intermediate (Admin)
Versions: All
Why:
Many administrators need to monitor application or service logs (e.g., Robocopy
job logs) that aren’t covered by built-in MPs. Stefan Roth shows a practical
example of using the NiCE Log
File Library Management Pack to detect and alert on log
contents.
How:
Import the NiCE Log File Library MP, then configure log file monitoring rules
to watch for specific events or patterns (e.g., errors in log files) and
generate alerts.
When & Where:
Useful when native MPs don’t natively capture the logs you need — common for
custom services or periodic tasks (like Robocopy).
Level:
Intermediate (Admin / Security)
Versions: All
Why:
Security-minded administrators need a clear understanding of how monitoring
data and Run As credentials are encrypted. Stefan Roth explains SCOM’s internal
encryption mechanics — not just what is encrypted, but why it
matters for security compliance and troubleshooting.
How:
Review SCOM’s encryption model (database, inter-server communications, RunAs
secrets). Validate that your environment meets compliance requirements and
ensure encryption keys and secrets are rotated or backed up appropriately.
When &
Where:
Ideal during security hardening, external audits, or when implementing strict
SOC/SECOPS compliance rules on the monitoring stack.
Level: Intermediate (Admin / Automation)
Versions: All
Why:
SCOM maintenance mode improves alert accuracy during planned patching. Stefan
Roth provides a script that ties maintenance mode scheduling to SCCM
collections so that when SCCM pushes updates and reboots, SCOM automatically
places those same systems into maintenance mode, reducing noise and manual
steps.
How:
Use a WMI connection to the SCCM server to retrieve target collection members
and then schedule maintenance mode for those systems via script.
When & Where:
Use this when SCCM/MECM is your primary patching tool and you want synchronized
SCOM maintenance mode with minimal manual intervention.
Level: Advanced (Admin / MP Author)
Versions: All
Why:
Static groups are brittle. Stefan Roth demonstrates how you can create dynamic
groups based on registry key values, which allows highly flexible scoping for
overrides, dashboards, and alerting based on runtime system properties.
How:
Use the Visual Studio Authoring Extensions (VSAE) to extend the Windows
Computer class with a custom attribute based on registry keys and then use that
attribute as a dynamic group membership rule.
When & Where:
Apply this when you need grouping granularity that isn’t supported by default
discovery criteria — e.g., grouping by configuration states or custom installed
software versions.
Skill level: Intermediate (Admin)
SCOM versions:
2016, 2019, 2022, 2025
Why:
SCOM Update Rollups (URs) often contain fixes that silently resolve
long-standing issues such as agent failures, console crashes, SDK instability,
or security gaps. Administrators frequently apply URs without fully
understanding what problems they solve — or worse, delay URs unnecessarily due
to fear of change. Reviewing UR fix lists helps justify updates and prevents
running into already-fixed issues.
How:
Before installing a UR, review the published fix list and known issues.
Identify fixes that apply to your environment (agents, Linux monitoring, SQL,
console). Validate prerequisites and follow the documented installation order
for management servers, gateways, agents, and consoles.
When & Where:
Do this as part of every SCOM maintenance cycle. Especially important in large
or business-critical environments where update justification is required.
Skill level: Intermediate (Admin)
SCOM versions:
2022+
Why:
Some SCOM URs are later followed by standalone
hotfixes that address newly discovered or critical issues.
These fixes are not always included in the next UR and may be required
immediately. Missing them can leave environments unstable even after a UR
update.
How:
Monitor official and trusted community sources for post-UR hotfix
announcements. Validate whether the hotfix applies to your environment and
install it according to Microsoft guidance, often without needing to wait for
the next UR.
When & Where:
Use this approach when experiencing unexplained issues after a UR or when
Microsoft explicitly recommends a hotfix for your scenario.
Skill level: Intermediate (Admin)
SCOM versions:
2016+
Why:
SCOM Linux agent upgrades can fail when Apache is installed on the monitored
system due to dependency or package conflicts. Failed upgrades leave agents
outdated, unsupported, or partially functional — often without clear error
messages. This as a repeatable and solvable issue.
How:
Identify Linux systems running Apache where agent upgrades fail. Adjust package
dependencies as documented, then re-run the agent upgrade. Validate agent
health after installation using SCOM cross-platform views.
When & Where:
Apply this during Linux agent upgrade campaigns or when troubleshooting
stubborn agent version mismatches.
Skill level: Advanced (Admin / Author)
SCOM versions:
All
Why:
Out-of-the-box SQL MPs focus on infrastructure health, not business or
application logic. Many critical KPIs exist only as SQL query results. Custom
SQL query-based monitors allow SCOM to alert on application-specific data,
thresholds, or business rules.
How:
Create SQL queries that return numeric or state-based results and integrate
them into SCOM as custom monitors or rules. Define thresholds carefully to
avoid alert noise.
When & Where:
Use this when application owners request monitoring that standard MPs cannot
deliver, or when SLAs depend on database-level conditions.
Skill level: Beginner–Intermediate (Operator / Admin)
SCOM versions:
All
Why:
Many SCOM environments underuse reporting, relying only on real-time alerts.
The Data Warehouse contains valuable historical data for trend analysis, SLA
reporting, and capacity planning.
How:
Access built-in SSRS reports, understand state vs. performance data, and
schedule recurring reports for stakeholders. Use reports to identify long-term
issues rather than reacting only to alerts.
When & Where:
Ideal for monthly service reviews, SLA validation, and long-term infrastructure
planning.
Skill level: Intermediate (Operator / Admin)
SCOM versions:
All
Why:
Alerts alone do not accurately reflect availability. They may be closed,
suppressed, or overridden. State views provide a more accurate representation
of system health over time. Reporting directly from state views improves
accuracy.
How:
Use state-based reports from the Data Warehouse instead of alert-based reports.
Filter by class, group, or monitor to reflect real availability.
When & Where:
Use this approach for management reporting, audits, and SLA documentation.
Skill level: Intermediate (Admin)
SCOM versions:
2019+
Why:
SCOM URs often include improvements to monitoring quality, performance, and
scalability — not just bug fixes. Viewing updates only as “maintenance” leads
to missed value.
How:
Review UR release notes with a monitoring mindset: look for improvements in
alert accuracy, agent stability, Linux monitoring, and performance counters.
Communicate benefits to stakeholders.
When & Where:
During planning phases for upgrades or when justifying change windows to
management.
Skill level: Beginner–Intermediate
SCOM versions:
All
Why:
Microsoft documentation often lags behind real-world issues. Community blogs and
forums like https://www.reddit.com/r/scom/ frequently publish fixes, workarounds, and insights before official
guidance is updated. Leveraging these sources reduces downtime and
troubleshooting time.
How:
Follow trusted SCOM-focused blogs and review posts after each UR release.
Cross-reference issues you see in your environment with community findings.
When & Where:
Especially valuable immediately after updates, during unexplained issues, or
when troubleshooting rare edge cases.
Skill level: Intermediate (Admin)
SCOM versions:
2019 UR2
Why:
Before SCOM 2019 UR2, there was no built‑in way to see who
changed MPs or overrides. Tracking such changes is critical for accountability,
troubleshooting, and audit compliance — particularly in environments with
multiple administrators. Update Rollup 2 introduced reports that show
management pack installs, modifications, and override changes along with user
context.
How:
Open the Reporting
workspace in the SCOM console. Under the Microsoft
Generic Report Library, find reports for Management Pack History, Management
Pack Objects, and Overrides Tracking. Use filters like date, username, and MP name to dissect changes.
When & Where:
Run these reports after governance reviews, before major production changes,
and as part of security audits. They are especially valuable in environments
undergoing frequent tuning.
Skill level: Intermediate (Admin / Operator)
SCOM versions:
All (2012+) but most useful in 2016+ environments
Why:
Manual overrides are time‑consuming and inconsistent. The Easy Tune
utility provides community‑driven best practice tuning packs — from
minimal discovery to full alerting. It speeds tuning, reduces noise, and avoids
override sprawl.
How:
Download the Easy Tune management pack. In the SCOM console, choose the MP
workload (e.g., SQL Server), select a tuning level (Discovery Only, Essential,
Balanced, Full), and apply. Easy Tune auto‑creates all necessary
overrides based on your chosen level.
When & Where:
Apply Easy Tune early in a deployment to prevent unnecessary alerts. Revisit
tuning whenever new MPs are imported or alert noise increases.
Skill level: Intermediate (Operator / Admin)
SCOM versions:
2016 and later
Why:
Traditionally, maintenance mode was initiated from the SCOM console. SCOM 2016
introduced the ability to trigger maintenance
mode on an agent directly via
PowerShell. This helps reduce friction and makes it easier for local operators
to silence alerts during planned work.
How:
Ensure the Agent Initiated Maintenance
Mode Rule is enabled via override. Then, on the monitored
machine, import the SCOM PowerShell module and run:
Start-SCOMAgentMaintenanceMode –Duration
Verify via Event
Viewer (Event ID 2222) and in the SCOM console.
When & Where:
Use this when planned maintenance happens at the OS or application level and
central console access isn’t convenient. Ideal for field technicians or
distributed environments.
Skill level: Advanced (Admin)
SCOM versions:
All upgrades (e.g., 2019 → 2022)
Why:
When upgrading a management group, override settings are often scattered across
many MPs — sometimes even in the default MP. Capturing and migrating them
manually is error prone. Cookdown highlights the benefits of tools like Easy
Tune that can capture effective
overrides and help reapply
them in the new environment.
How:
Export all override MPs from the old environment. Use Easy Tune PRO or similar
tooling to capture effective tuning (even if scattered across many override MPs),
and tailor it to the target environment before importing into the upgraded
group.
When & Where:
Plan this step as part of every SCOM upgrading project — between exporting MPs
from the old group and importing them into the new.
Skill level: Intermediate (Admin / Analyst)
SCOM versions:
All
Why:
As SCOM environments grow, override sprawl becomes hard to reason about —
especially when overrides span multiple MPs. Cookdown provides a downloadable
Power BI Sankey diagram that visualizes override scope and relationships,
helping admins identify tuning hotspots and unnecessary overrides.
How:
Download the Power BI Sankey template. Connect it to your SCOM Data Warehouse.
Use filters to focus on a specific MP, group, or object. Analyze how overrides
flow from MPs to targets to identify optimization opportunities.
When & Where:
Use this during quarterly reviews, governance sessions, or before major tuning
campaigns. Great for environments with many custom overrides.
Skill level: Intermediate (Admin / Operator)
SCOM versions:
All
Why:
Many organizations use ITSM tools (ServiceNow, Cherwell, etc.) to manage
incidents. Cookdown’s Connection Center enables bi‑directional synchronization —
alerts become incidents, and incident state (resolve/close) flows back into
SCOM, automatically resolving or resetting alerts. This improves SLA compliance
and reduces manual coordination.
How:
Configure Connection Center to integrate SCOM with your ITSM of choice. Select
inbound/outbound sync options, define alert filters, and map incident fields.
Once enabled, closing an incident in ITSM can automatically close or reset
monitors in SCOM.
When & Where:
Best implemented when SCOM is part of an enterprise ticketing process, reducing
alert‑to‑ticket friction and keeping SCOM as the single source of truth across toolchains.
Skill level: Intermediate (Admin)
SCOM versions:
All
Why:
When a logical disk or filesystem is removed from a server, the SCOM agent may
continue to reference it. This can cause stale monitoring objects or alerts to
persist in the console. Restarting the agent ensures that the management server
receives an accurate, updated inventory.
How:
Restart the Linux/AIX agent on the Linux/AIX
system after removing a logical disk / filesystem on a AIX/Linux system.
When & Where:
Use this whenever a logical disk or filesystem is removed from a monitored
system and you notice that the object still appears in SCOM alerts or
discoveries. This is particularly important in dynamic storage environments.
-enable-opsmgr FlagSkill level: Intermediate (Admin)
SCOM versions:
All
Why:
Manual installation of Linux or AIX agents without the -enable-opsmgr flag will fail to properly register with the
management group. This flag ensures that the agent is enabled for Operations
Manager communication and can participate in discovery and monitoring.
How:
When performing a manual installation of a Linux/AIX agent, use the following
command syntax:
-install
-enable-opsmgr
Follow the official
documentation for additional parameters such as management server configuration
and agent proxy settings.
When & Where:
Previously, Linux/AIX agents could be installed without this flag, but this is
no longer supported. Always apply this flag during initial agent installation,
particularly in environments with multiple Unix/Linux systems.
Skill level: Intermediate (Admin)
SCOM versions:
All
Why:
If the Operations Manager agent on a server is restarted while a monitored Unix
agent is down, multiple critical event log entries (ID 17178) may be generated
in the SCOM event log. This is a known one-time event and does not indicate an
ongoing issue.
How:
Once the Unix/Linux agent comes back online, the entries are automatically
reconciled. No further remediation is typically required. Optionally, review
the HealthService logs to ensure no persistent errors remain.
When & Where:
This is observed after restarting Windows agents while remote Unix/Linux agents
are temporarily unavailable. Typical event log entries may look like:
LogFile Monitoring fails for
·
DB2MP_AdmLogFile : system.lab.de
·
DB2 Instance: db2instance
·
RuleID: NiCE.DB2.X.Alert.AdmLog.Monitoring.BackupInProgress
Skill level: Intermediate (Admin)
SCOM versions:
All
Why:
SSH discovery failures with exit code 1 often occur when the root user’s
default shell is set to /usr/bin/csh. The csh shell does not support the $? variable, which is required for SCOM’s discovery command pipeline. This
prevents the agent from completing discovery of Unix/Linux systems.
How:
Change the default shell for the root user to /usr/bin/sh
After this change,
rerun the SSH discovery. The agent should now successfully discover all
objects.
When & Where:
Use this tip when SSH discovery fails for Unix/Linux systems with exit code 1
and standard error indicating “Variable syntax.” Common in environments where
csh is the default shell for root.
Reference:
Internal operational knowledge / SCOM SSH discovery best practices
Skill level: Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
Many SCOM issues don’t originate in SCOM itself, but in external dependencies
such as DNS, firewalls, certificates, or SQL permissions.
Tip:
Before deploying agents or management packs, make sure you validate:
·
DNS
forward and reverse lookups
·
Port
connectivity (TCP 5723, SQL ports, gateway ports)
·
Certificate
trust chains
·
Service
account permissions
·
Account Distribution Security
settings (use the “More secure” option)
·
Credential distribution to all
computers and resource pools that require them
Catching these
dependencies early helps avoid long and frustrating troubleshooting sessions
later on.
Skill level:
Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
Firewalls are essential for security, but incorrect rules can break agent
communication, discovery, or monitoring.
How:
Review and open only the ports required for SCOM management servers, agents,
gateways, and SQL communication.
Tip:
Always validate after upgrades or topology changes—SCOM port requirements may
shift with new versions.
Skill level:
Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
Some Linux agents generate certificates containing only the short hostname,
while SCOM uses the FQDN when validating certificates.
Symptoms:
·
Certificate validation fails
·
Deployment or discovery errors
·
“Signed certificate verification – operation
was not successful”
How:
·
Rename the Linux server so the hostname aligns
with the FQDN
·
Regenerate the OpenSSL certificate on the Linux
agent using the fully qualified domain name
Skill level: Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
UNIX and Linux monitoring can be one of the more challenging areas in SCOM due
to certificates, sudoers files, agent logs, and timeout behaviors.
Tip:
Bookmark and use Blake Drumm’s comprehensive troubleshooting guide:
https://blakedrumm.com/blog/scom-unix-linux-troubleshooting-tips/
Covers:
·
Certificate
trust
·
Log
locations
·
Elevation
issues
·
Common
error patterns
·
Discovery
problems
This guide saves
hours when diagnosing tricky agent behavior.
Skill level: Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
Over time, disabled discoveries leave behind unused class instances. These can
inflate the operational DB and affect performance.
How:
Use the PowerShell cmdlet:
Remove-SCOMDisabledClassInstance
It removes class
instances associated with disabled discoveries and helps maintain a clean
database.
Tip:
Run during maintenance windows on large environments.
Skill level: Intermediate to Advanced (Admin)
SCOM versions:
All
Why:
SCOM interprets
quotes and some symbols incorrectly during validation, causing “wrong
credentials” errors even when the password is correct.
How:
SCOM (especially
during setup and Linux agent onboarding) may fail authentication if the
passwords for service accounts contain certain special characters.
Do NOT use in SCOM
passwords:
$
&
?
#
@
"
'
Fix:
Use strong passwords without those characters.
1. Rename the Default Management Pack
https://kevinholman.com/2011/02/15/renaming-your-default-management-pack/
https://ds.squaredup.com/blog/20-operations-manager-tips-in-20-minutes/
2. Always Use Dedicated Override MPs
https://learn.microsoft.com/troubleshoot/system-center/scom/best-practices-configure-overrides
3. Disable Monitors by Default After Importing MPs
https://ds.squaredup.com/blog/20-operations-manager-tips-in-20-minutes/
https://www.nice.de/2025/09/30/reducing-alert-fatigue-in-microsoft-scom/
4. Tune Discovery Intervals Carefully
https://janscman.wordpress.com/2012/11/19/optimizing-your-management-packs-performance/
5. Optimize Performance Data Collection
https://janscman.wordpress.com/2012/11/19/optimizing-your-management-packs-performance/
6. Prefer Agent-Based Monitoring
https://learn.microsoft.com/system-center/scom/manage-agentless-monitoring
https://www.nice.de/wp-content/uploads/2023/11/Microsoft-SCOM-Compendium-by-NiCE-2023Q4.pdf
7. Implement MP Version Control and Backups
https://kevinholman.com/2017/07/07/scom-2012-and-2016-unsealed-mp-backup/
8. Monitor SCOM with SCOM
https://techcommunity.microsoft.com/t5/system-center-blog/system-center-operations-manager-assessment/ba-p/351679
https://learn.microsoft.com/services-hub/unified/health/getting-started-scom
9. Use Service-Centric Monitoring
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
10. Design Alerts with an Owner and Action
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
11. Use the SCOM Health Check / Assessment
https://techcommunity.microsoft.com/t5/system-center-blog/system-center-operations-manager-assessment/ba-p/351679
https://learn.microsoft.com/services-hub/unified/health/getting-started-scom
15. Use Naming Conventions Consistently
https://cireson.com/blog/scsm-management-pack-naming-best-practice/
16. Reduce Alert Noise Before Adding Monitoring
https://www.nice.de/2025/09/30/reducing-alert-fatigue-in-microsoft-scom/
19. Integrate SCOM with ITSM or Dashboards
https://squaredup.com/features/
20. Treat SCOM as a Living System
https://www.nice.de/wp-content/uploads/2023/11/Microsoft-SCOM-Compendium-by-NiCE-2023Q4.pdf
28. Limit Event Log
Collection
https://www.nice.de/wp-content/uploads/2023/11/Microsoft-SCOM-Compendium-by-NiCE-2023Q4.pdf
29. Use Overrides Instead of
Editing MPs
https://learn.microsoft.com/system-center/scom/manage-mp-lifecycle#tune-and-customize
33. Monitor What You Can Fix
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
37. Don’t Over-Monitor
“Green” Systems
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
40. Revalidate Original
Monitoring Goals
https://www.nice.de/wp-content/uploads/2023/11/Microsoft-SCOM-Compendium-by-NiCE-2023Q4.pdf
41. Don’t Treat Alerts as
Tickets
https://www.nice.de/2025/09/30/reducing-alert-fatigue-in-microsoft-scom/
48. Don’t Ignore Warning
Alerts
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
51. Avoid Monitoring “Just
in Case”
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
53. Use Severity Levels
Consistently
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
57. Avoid “Set and Forget”
Monitoring
https://www.nice.de/wp-content/uploads/2023/11/Microsoft-SCOM-Compendium-by-NiCE-2023Q4.pdf
59. Align SCOM Ownership
Clearly
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
60. Measure Success by
Outcomes
https://www.nice.de/2026/01/16/microsoft-scom-cheat-sheet/
61. Automate Agent
Maintenance Mode via PowerShell
https://www.stefanroth.net/2017/11/26/scom-2016-start-scomagentmaintenancemode-powershell-way/
62. Use Scripts to Manage
Proxy-Enabled Agents
https://www.stefanroth.net/2012/07/24/scom-2012-find-proxy-enabled-agents-quickly/
63. Populate Custom
Attributes via PowerShell
https://www.stefanroth.net/2014/05/04/scom-populate-attributes-through-powershell/
64. Use “Script in Script” for Complex Linux Monitoring
https://www.stefanroth.net/2012/10/21/scom-2012-linux-two-state-monitor-with-script-in-script/
65. Monitor Robocopy and
Other Logs Using NiCE MP
https://www.stefanroth.net/2014/02/24/scom-2012-nice-log-file-library-mp-monitoring-robocopy-log-file/
66. Understand How SCOM Encrypts Data
https://www.stefanroth.net/2016/03/02/scom-how-data-is-encrypted/
68. Create Custom Dynamic
Groups Based on Registry Keys
https://www.stefanroth.net/2013/11/11/scom-vsae-custom-dynamic-computer-groups-based-on-server-registry-keys/
67. Script Maintenance Mode Based on SCCM Collections
69. Always Review Update
Rollup Fix Lists Before Applying
https://blog.topqore.com/scom-2022-ur3-hotfix-kb5071859-whats-fixed-why-it-matters-and-how-to-check/
70. Apply Hotfixes
Separately When Microsoft Releases UR Add Ons
https://blog.topqore.com/scom-2022-ur3-hotfix-kb5071859-whats-fixed-why-it-matters-and-how-to-check/
71. Fix Linux Agent Upgrade
Failures Caused by Apache
https://blog.topqore.com/how-to-fix-scom-linux-agent-upgrade-failures-when-apache-installed/
72. Extend Monitoring with
SQL Custom Query Based Monitors
https://blog.topqore.com/extend-your-observability-with-sql-custom-query-based-monitors/
73. Use the SCOM Reporting
Series to Unlock the Data Warehouse
https://blog.topqore.com/scom-reporting-series-home/
74. Report on Availability
Using State Views Instead of Alerts
https://blog.topqore.com/scom-reporting-series-reporting-from-a-state-view/
75. Treat SCOM Updates as an
Observability Improvement, Not Just Patching
https://blog.topqore.com/scom-2025-update-rollup-1-full-list-of-fixes-and-improvements/
76. Use Community SCOM Blogs
as an Early Warning System
https://blog.topqore.com/
77.
Audit Management Pack Changes with Change Tracking
https://www.cookdown.com/blog/a-quick-look-into-the-change-tracking-of-management-packs-in-scom
78.
Use Easy Tune to Reduce Alert Noise Quickly
https://www.cookdown.com/blog/introducing-easy-tune-the-new-way-to-tune-scom
79. Place Agents into
Maintenance Mode from the Agent Computer
https://www.cookdown.com/blog/enabling-scom-maintenance-mode-from-a-monitored-computer
80.
Migrate Overrides When Upgrading SCOM
https://www.cookdown.com/blog/alert-tuning-for-your-upgraded-scom-environment
81.
Visualize Override Sprawl with Power BI Sankey Diagrams
https://www.cookdown.com/blog/powerbi-sankey-diagrams-for-visualizing-overrides
82.
Use Bi‑Directional Integration with ITSM Tools
https://www.cookdown.com/blog/bi-directional-integration-for-scom-amp-your-itsm-tools
88. Configure Your Firewall Correctly
https://learn.microsoft.com/en-us/system-center/scom/plan-security-config-firewall?view=sc-om-2025
89. Fix SSL Certificate Problems on
Linux/UNIX Agents
https://www.stefanroth.net/2014/02/03/scom-linux-agent-deployment-signed-certificate-verification-operation-was-not-successful/
90.
Use Proven UNIX/Linux Troubleshooting Techniques
https://blakedrumm.com/blog/scom-unix-linux-troubleshooting-tips/
91. Clean Up the SCOM Database Using
Remove-SCOMDisabledClassInstance
https://learn.microsoft.com/en-us/powershell/module/operationsmanager/remove-scomdisabledclassinstance?view=systemcenter-ps-2025
https://janscman.wordpress.com
https://techcommunity.microsoft.com
https://www.reddit.com/r/scom/