Configure SCOM agent from PowerShell

Configure SCOM agent from PowerShell
Configure SCOM agent from PowerShell


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 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!


Configure SCOM agent from PowerShell

GitHub Download

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


Use the PowerShell script to:

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‘.




Kevin Holman’s blog for VB commands

Using the agent scripting objects on a SCOM 2012 agent

The agent configuration objects in MSDN


Install SCOM agent MSI via command line

MECM application for SCOM agent MSI
MECM application for SCOM agent MSI
Shout out to AT and Aris for his help with this!


Install SCOM agent MSI via command line and roll into a ‘SCOM agent’ MECM application package.

Why an application/package?  Many times, servers are built, and the IT Enterprise doesn’t find out device is NOT monitored until it’s involved in an outage.  Proceed to add to your Configuration management tool will provide a consistent configuration to avoid the ‘NOT monitored’ configuration.


While there are a few options to build out a MCM/MEM/MECM/SCCM application/package to install the SCOM agent on managed windows machines.  In August, I posted Neal’s updates to install/configure the SCOM agent.  Neal’s scenario works great for a new environment, and it’s simple PowerShell.  Also, if Neal’s scenario with PowerShell is NOT your preference, try the batch file below.  Another key point, the script has logic for multiple forests and SCOM gateways (to connect said forests).  Basically test the command line script, then roll into a MCM/MEM/MECM/SCCM application/package.  Have the SCOM agent added to task sequence which consequently includes the SCOM agent in the default build.



Install SCOM agent command line script

First – NOTE each line has no hidden line feed/carriage returns

Second – go through the variables before testing

Variables to review/replace:

##SCOMManagementGroup##      # SCOM Management group, seen in SCOM console on top left corner

SCOMManagementServer##     # SCOM management Server in primary domain
##SCOMManagementServerGW##     # SCOM first gateway
##SCOMManagementServerGW2##     # Second gateway
##Domain## as forest FQDN
##Domain2## as forest FQDN

Determine domain –

‘systeminfo | findstr /i /c:”domain” | findstr /i /c:”##Domain##”

Example Lab output

C:\> systeminfo | findstr /i /c:”domain” | findstr /i /c:”testlab”


Third – Find/Replace ##hashtagged## variables and test away!

@echo off


REM This script command line is for NEW installs of the agent (nothing prior)
REM Replace ##SCOMManagementGroup## SCOM Management group, seen in SCOM console on top left corner

ECHO Installing SCOM 2019 Windows Agent…

echo Determining domain….

REM Determine if machine is in DMZ….

systeminfo | findstr /i /c:”domain” | findstr /i /c:”DMZ” && (

echo Machine found to be in DMZ…installing for that enclave and management server: ##Domain2##”




GOTO Logging)

REM Determine if machine is on domain….

systeminfo | findstr /i /c:”domain” | findstr /i /c:”##Domain##” && (

echo Machine found to be in ##Domain##…installing for that enclave and management server: ##Domain##




GOTO Logging)

REM Neither DMZ or domain joined found above…look for alternate domain(s)

REM These all share this same management server: FOREST2.FQDN and Gateway server



ECHO Installing SCOM 2019 Windows Agent Completed…>> C:\Windows\Logs\SCOM2019Agent.log

time /t >> C:\Windows\Logs\SCOM2019Agent.log

date /t >> C:\Windows\Logs\SCOM2019Agent.log


Lastly enjoy!   In summary, I hope the ‘Install SCOM agent MSI via  command line’ script helps get the agent deployed faster, and more consistent!

Improving SCOM Monitor reset logic

Faster - Improving SCOM Monitor reset logic
Faster – Improving SCOM Monitor reset logic


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.



Improving SCOM monitor reset logic

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!

PowerShell code

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)


PowerShell code snippet

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



# 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




Reset monitor PowerShell screenshot

Download from GitHub

SCOM Reset PowerShell
SCOM Reset PowerShell


Example PowerShell on HealthService resets

NOTE debug logic enabled

Found 0 unhealthy monitors for class Microsoft.SystemCenter.HealthServicesGroup
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 + '



Building on Scott’s idea – (retired links)
Original post
TechNet gallery download
Alternate link