SNOW prerequisites
Update incident script and begin testing.
$ServiceNowURL=”https://##SERVICENOWURL##/api/now/table/em_event”
Operational monitoring tools including System Center, Azure Monitor

Thank you Aris for reaching out with questions on these new vulnerabilities!
New OMI vulnerabilities for SCOM/Log Analytics Agents posted. The vulnerabilities apply to OMI component on non-windows servers with SCOM2019, SCOM2022, or Log Analytics agents. The vulnerabilities apply to non-windows server operating systems. See hotfix details below to resolve.
CVE-2024-21134 https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-21334
The vulnerability exists due to a use-after-free error in the Open Management Infrastructure (OMI). A remote attacker can execute arbitrary code on the target system.
CVE-2024-21330 https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-21330
The vulnerability exists due to application does not properly impose security restrictions in the Open Management Infrastructure (OMI), which leads to security restrictions bypass and privilege escalation.
2019 https://www.microsoft.com/en-us/download/details.aspx?id=58208
2022 https://www.microsoft.com/en-in/download/details.aspx?id=104213
Leverage Holman’s Monitoring UNIX quick start guide(s) if you need a ‘how to’ or refresher to update your SCOM management groups with the latest packs, and how to update the agent on non-windows/UNIX servers.
SCOM2022 https://kevinholman.com/2022/12/12/monitoring-unix-linux-with-scom-2022/
SCOM2016,2019 https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/
SCOM2019 https://kevinholman.com/2020/07/23/scom-2019-security-account-matrix/

Use the Tangible SCOM management pack to monitor logins and ProV application registration issues. First, the management pack configures Seed class discovery. Second, the pack includes rules/monitors for Tangible ProV software. Third, rules and monitors for 2802 ‘Could not validate product key’ and 4402 ‘Could not validate the contents of user logon request context: AS-REQ contains an invalid or unknown username type’ events. Fourth, the service monitor, which uses Kevin Holman’s fragment library for service recovery scripts/rules. Fifth, scheduled and on-demand daily reports for audit and record keeping purposes. Lastly, alert cleanup logic, to reduce admin burden and overhead.
Reference the Tangible vendor’s website – Tangible ProV application website
NOTE: This may not apply for everyone, as the ProV application ‘Auto-provisions Active Directory user accounts for visitors or new employees whenever they want to work from one of your PCs.’
The Daily report piece of the pack makes things easier answering ‘what happened in the last 24-72 hours’ question. Gathers open/closed insights and organizes alerts.

Open ProV alerts = 13Since last report run:#———————–Total ProV alerts = 23Auto-closed monitors = 22Auto-closed rules = 0Total automation closures:#—————————Auto-closed monitors = 262Auto-closed rules = 0# Unhealthy Tangible ProV service alert details#==============================================NetbiosComputerName TimeRaised RepeatCount Name ——————- ———- ———– —- DC01 8/11/2023 5:18:14 AM 0 Tangible ProV ProVService…
All in all, the daily report utilizes get and set-SCOMAlert to accomodate large enterprise environments.
$OpenAlerts = get-scomalert -ResolutionState (0..254) -Name “Tangible ProV ProVService Service*”
$OpenAlerts = $OpenAlerts | ? { $_.TimeRaised -ge $Time }
# $OpenAlerts.count
# Closed alerts
$ClosedAlerts = get-scomalert -ResolutionState 255 -Name “Tangible ProV ProVService Service*” | ? { $_.TimeRaised -ge $Time }
# $ClosedAlerts.count
GitHub https://github.com/theKevinJustin/TangibleProV
Download here

Ever have a need to configure a SCOM agent outside the SCOM Console GUI using SCOM.Management pack? Tyson’s ‘SCOM Helper PowerShell module’ on monitoringguys.com may assist if you can update PowerShell and SnapIn’s. If Tyson’s solution may not be an applicable solution in a locked down environment, the blog is a PowerShell script to manage agent configuration.
A shout out to Aris for his watchful eye testing and playing with this!
GitHub Download https://github.com/theKevinJustin/SCOMAgentInstallApplication/
First, let’s begin the conversation. Leverage the PowerShell script to configure SCOM/MOM agent per domain(s). Whether DMZ forest(s), or multiple forests with SCOM gateways, the script will enable configuration management. Alternatively, add script as a compliance check to the Configuration Management tool, or as a post install step to configure SCOM Agent (MomAgent.MSI) via application or package. Third, utilize the PowerShell script where agent upgrade is a pre-req to resolve ‘a really old SCOM agent version’. Lastly, the script also tests network connectivity, and verifies if configuration is requested/loaded.
It all starts with this object from the command:
$SCOMAgent = New-Object -ComObject AgentConfigManager.MgmtSvcCfg
Clean up extraneous management groups
Determine domain
Check network connectivity via test-netconnection
Reset healthservice to expedite agent configuration
Because Kevin Holman blogged this almost 10 years ago in VB, and I’m pretty rusty in VB these days. Check out Kevin’s blog titled ‘Using the agent scripting objects on a SCOM 2012 agent‘.
Download https://github.com/theKevinJustin/SCOMAgentInstallApplication/
Kevin Holman’s blog for VB commands
The agent configuration objects in MSDN http://msdn.microsoft.com/en-us/library/hh328967.aspx

My thanks to Aris Somatis for his deep dive reviewing the packs with me, particularly new use cases. The PowerShell below builds on Scott Murr’s initial TechNet published logic from years back. Consequently, the reset logic provides a ‘manual intervention required’ alerting/monitoring system.
Calling the reset method has been a game changer for my customers – including operators, system and application owners!
Scott’s reset logic, from SCOM2012, helped administrators reset unhealthy monitors where alerts may have been closed. Because Scott leveraged the ResetMonitoringState method, the community gained a way to keep true health. Additionally, many administrators and engineers built custom management packs to provide solutions. Second, the addendum packs blog brought in more options – best practices, lessons from the field (and customers), and health model accurate alerting for what was really broken in the environment. Third, addressing ‘gaps’ or ‘blind spots’ from product teams. As a result of NEW monitoring, the packs may include: rules/monitors, datasource/writeAction (DS/WA) workflows, recovery tasks and automation, count logic monitors, overrides, discoveries, and groups. Thirdly, to take monitoring to the next level. To top that off, with very little/NO cost compared to competitors!
Aris’s Age use case takes this even further. Using monitor age allows further analysis to dial down ‘monitor reset’ to object is X days old. Comparatively, the 24-72 hour setup default is used in the addendums, so Age provides a second option. Third option can rely on SCOM’s built-in cleanup, but that’s typically 14-30 days. Overall, flexibility is a good thing.
# Specify age variable for your environment
$Age = [DateTime](Get-Date).AddDays(-7)
First, the reset logic can pivot on the age requirement. Then, adjust the Age variable per requirements. Third, figure out which method applies to gather a unique list of classes, whether by partial string(s), or by management pack name(s).
Set age variable (how long ‘OLD’ monitors might be stale and need reset)
# Example sets $Age variable to 7 days ago (-7)
$Age = [DateTime](Get-Date).AddDays(-7)
Unpack two different ways to gather classes for monitors to reset
# When common string name exists in all classes
Example DFS/FileServices packs all have one of the three strings:
# DFS pack naming
$DFSClasses = @(Get-SCOMClass -Name “*FileServices*”; Get-SCOMClass -Name “*FileServer*”; Get-SCOMClass -Name “*DFS*” )
$DFSClass = $DFSClasses | sort -property Name -uniq
# Debug
$DFSClass.Count
# Get AD classes – Microsoft.Windows.Server.AD.2016.Discovery, Microsoft.Windows.Server.AD.Library
$ADLibrary = Get-SCOMManagementPack -name “Microsoft.Windows.Server.AD.Class.Library”
#get-scomclass -ManagementPack $ADLibrary
$ADMonitoring = Get-SCOMManagementPack -name “Microsoft.Windows.Server.AD.2016.Monitoring”
#get-scomclass -ManagementPack $ADMonitoring | fl DisplayName,Name,ID
$ADDiscovery = Get-SCOMManagementPack -name Microsoft.Windows.Server.AD.2016.Discovery
#get-scomclass -ManagementPack $ADDiscovery | fl DisplayName,Name,ID
# ADDS pack naming
$ADDSClasses = @(Get-SCOMClass -ManagementPack $ADLibrary; Get-SCOMClass -ManagementPack $ADDiscovery; )
# NOTE Excluded AD Monitoring pack as NO classes existed
$ADDSClass = $ADDSClasses | sort -property Name -uniq
# Debug count of unique classes
$ADDSClass.Count
Download from GitHub https://github.com/theKevinJustin/SCOMMonitorReset

NOTE debug logic enabled
0 Found 0 unhealthy monitors for class Microsoft.SystemCenter.HealthServicesGroup 1 Found 1 unhealthy monitors for class Microsoft.SystemCenter.HealthServiceWatcher Resetting Health State on ' + Microsoft.SystemCenter.HealthServiceWatcher:Microsoft.SystemCenter.AgentWatchersGroup;5e0 4f804-8b71-6eb6-0101-dcbb58022498 + ' Guid ---- 0218d239-3d37-f9b1-75d2-6d52c2c7c0c1