How to Configure System Center Operations Manager (SCOM) Agent on Windows Server 2012 R2
System Center Operations Manager (SCOM) 2012 R2 provides enterprise-grade monitoring for Windows Server 2012 R2 environments. The SCOM agent, installed on each managed server, collects health state data, performance counters, event log entries, and application-specific metrics, then transmits them to the SCOM Management Server for centralised analysis, alerting, and reporting. SCOM uses Management Packs to define what to monitor and how to respond, allowing out-of-the-box monitoring for Windows OS, IIS, SQL Server, Active Directory, and hundreds of other technologies. This guide covers agent deployment, configuration, management pack application, and alert configuration.
Prerequisites
A SCOM 2012 R2 Management Server must be deployed and reachable from the target Windows Server 2012 R2 machine. The target server must be a member of a domain or have a trust relationship with the domain hosting the SCOM Management Server. Firewall rules must permit TCP port 5723 from the agent to the Management Server. The agent installation account requires local administrator privileges on the target. Sufficient disk space (approximately 200 MB) must be available for the agent binaries and data cache.
Step 1: Deploy the SCOM Agent via Push Installation
The easiest deployment method is push installation from the SCOM Operations Console. Open the Operations Console, navigate to Administration → Device Management → Agent Managed, and right-click to select Discovery Wizard.
In the Computer and Device Management Wizard, select Windows Computers, then Advanced Discovery. Specify the target server by hostname or IP address range. Provide domain credentials with local administrator rights on the target servers. The wizard will scan the target, detect the OS version, and offer to install the agent.
Select the Management Server the agent should report to and click Install. The Operations Console pushes the agent MSI to the target server over SMB, installs it silently, and registers the agent with the Management Server.
Step 2: Deploy the SCOM Agent Manually
For servers that cannot be reached via the push method (due to firewall restrictions or workgroup membership), install the agent manually. Locate the agent installer on the SCOM Management Server:
\SCOMManagementServerOperationsManagerSetupMediaAMD64MOMAgent.msi
Transfer the MSI to the target server and install using the following command (replace values with your environment details):
msiexec.exe /i MOMAgent.msi /qn /l*v C:LogsMOMAgentInstall.log ^
MANAGEMENT_GROUP=YOURDOMAINSCOM ^
MANAGEMENT_SERVER_DNS=SCOMMS01.yourdomain.com ^
MANAGEMENT_SERVER_PORT=5723 ^
ACCEPTLICENSETERMS=yes
For a PowerShell-driven deployment:
$msiArgs = @(
"/i", "\FileShareSCOMMOMAgent.msi",
"/qn",
"/l*v", "C:LogsMOMAgentInstall.log",
"MANAGEMENT_GROUP=YOURDOMAINSCOM",
"MANAGEMENT_SERVER_DNS=SCOMMS01.yourdomain.com",
"MANAGEMENT_SERVER_PORT=5723",
"ACCEPTLICENSETERMS=yes"
)
Start-Process -FilePath "msiexec.exe" -ArgumentList $msiArgs -Wait -PassThru
Step 3: Approve the Agent in the Operations Console
After manual installation, the agent appears in the SCOM Operations Console under Administration → Pending Management. Right-click the pending agent and select Approve. Select the Management Server it should be assigned to and click OK. The agent will be approved and begin submitting health state data within a few minutes.
Verify the agent is communicating correctly by checking Administration → Agent Managed. The heartbeat status should show as green. If the agent shows as grey (not monitored) or red (critical), check connectivity on port 5723 and review the Operations Manager event log on the agent server.
Step 4: Configure the SCOM Agent Service
The SCOM agent runs as the Microsoft Monitoring Agent service (HealthService). Verify it is running and configured for automatic startup:
Get-Service -Name "HealthService" | Select-Object Name, Status, StartType
Set-Service -Name "HealthService" -StartupType Automatic
Start-Service -Name "HealthService"
The agent service account can be configured to run as Local System (default) or as a specific domain account with least-privilege access. For monitoring that requires domain credentials (such as Active Directory monitoring), configure the Run As account in the SCOM Operations Console under Administration → Run As Configuration → Accounts.
Check the agent’s operational health status from the SCOM side:
# Run on Management Server using SCOM PowerShell module
Import-Module OperationsManager
$agent = Get-SCOMAgent -Name "WS2012R2-SERVER01.yourdomain.com"
$agent | Select-Object Name, HealthState, LastModified, ManagementGroupName
Step 5: Apply Management Packs
Management Packs define the monitoring rules, discoveries, views, and alerts for specific workloads. Apply the Windows Server 2012 R2 Operating System Management Pack from the SCOM Management Server:
Import-Module OperationsManager
$mpFile = "C:ManagementPacksMicrosoft.Windows.Server.2012.R2.mp"
Import-SCOMManagementPack -ManagementPackFile $mpFile
Common Management Packs for a Windows Server 2012 R2 environment include: Microsoft Windows Server 2012 R2 OS, Microsoft SQL Server, Microsoft IIS, Microsoft Windows Active Directory, and Microsoft Windows DNS Server. Download management packs from the Microsoft Download Center or the SCOM catalog within the Operations Console under Administration → Management Packs → Import Management Packs.
Step 6: Configure Alert Notifications
Configure SCOM to send email alerts when critical health state changes occur. In the Operations Console, navigate to Administration → Notifications → Subscriptions. Create a new notification subscription:
Set the Criteria to filter by alert severity (Critical and Warning), class (Windows Computer), and resolution state (New). On the Subscribers page, add the notification channel (email address). Create a notification channel first under Administration → Notifications → Channels if one does not exist.
Configure the SMTP notification channel via PowerShell:
Add-SCOMNotificationChannel -Name "EmailSMTP" -DisplayName "Email SMTP" -Description "Email via SMTP" `
-Subject "SCOM Alert: {0}" -Body "Alert: {0}`nDescription: {1}`nSeverity: {2}`nComputer: {3}" `
-Address "[email protected]" -From "[email protected]" `
-PrimarySmtpServerAddress "smtp.yourdomain.com" -PrimarySmtpServerPort 25 `
-Type Email
Step 7: Monitor Agent Health and Tune
SCOM agents can be verbose by default. Review and tune alert thresholds to reduce noise. Common tuning actions include:
Overriding noisy rules that generate false positives in your environment. For example, the default Logical Disk Free Space Critical alert triggers at 5% free space. Adjust this threshold via Overrides:
$rule = Get-SCOMRule -Name "Logical Disk % Free Space Low"
$override = New-Object Microsoft.EnterpriseManagement.Configuration.ManagementPackRulePropertyOverride
$override.Property = "Threshold"
$override.Value = "3"
Monitor the agent’s own data cache and queue health on the managed server. Review the Operations Manager event log for Agent health events:
Get-WinEvent -LogName "Operations Manager" -MaxEvents 50 | Where-Object {$_.LevelDisplayName -in "Error","Warning"} | Select-Object TimeCreated, LevelDisplayName, Message | Format-List
Step 8: Verify End-to-End Monitoring
Confirm that the agent is sending data to SCOM by generating a test alert. Force a heartbeat failure test by temporarily stopping the agent service, confirming SCOM generates a heartbeat failure alert, then restarting the service to confirm recovery:
Stop-Service HealthService
# Wait 5 minutes - SCOM should generate a heartbeat failure alert
Start-Service HealthService
Summary
The SCOM 2012 R2 agent transforms Windows Server 2012 R2 into a fully instrumented monitored node within your enterprise monitoring infrastructure. Proper agent deployment, Management Pack application, alert subscription configuration, and threshold tuning are essential for making SCOM a reliable operational tool rather than a source of alert fatigue. Regular maintenance of agent versions, management pack updates, and periodic review of alert subscription rules ensures continued monitoring effectiveness as your environment evolves.