Can't put random servers in Maintenance Mode - SCOM 2022

Hi Sean,

the key part of the stack trace is the inner exception:

System.InvalidOperationException: The monitoring object is already in maintenance mode.

The “client has been disconnected, please call ManagementGroup.Reconnect()” text is just what the console shows when the SDK call fails, but the real reason is that OpsMgr believes the target object is already in maintenance mode.

Because maintenance mode in SCOM is per object, not per “server”, it is very easy to have a situation where a related object is in MM while the Windows Computer view looks normal. I would go through these steps:

1. Check MM status for all related objects

Pick one of the affected servers and, in the SCOM 2022 management group where you see the issue, run something like:

Import-Module OperationsManager
$serverName = "SRV01"   # replace with one of your problem servers
 
$classNames = @(
    "Microsoft.Windows.Computer",
    "Microsoft.SystemCenter.HealthService",
    "Microsoft.SystemCenter.HealthServiceWatcher"
)
 
foreach ($className in $classNames) {
    $class = Get-SCOMClass -Name $className
    $instances = Get-SCOMClassInstance -Class $class | Where-Object {
        $_.DisplayName -eq $serverName -or $_.Path -like "*$serverName*"
    }
 
    foreach ($inst in $instances) {
        "`n== $($className) : $($inst.DisplayName) =="
        Get-SCOMMaintenanceMode -Instance $inst |
            Select-Object DisplayName, StartTime, ScheduledEndTime, Reason, Comment |
            Format-Table -AutoSize
    }
}
 
Get-SCOMMaintenanceMode | Where-Object { $_.DisplayName -match $serverName } |
    Select-Object DisplayName, StartTime, ScheduledEndTime, Reason, Comment |
    Format-Table -AutoSize

This shows whether any of the related objects (computer, HealthService, watcher, etc.) are actually in MM for that machine, even if the standard “Windows Computers” view suggests otherwise.

If you find any entries, end them:

Get-SCOMMaintenanceMode | Where-Object { $_.DisplayName -match $serverName } |
    Set-SCOMMaintenanceMode -EndTime (Get-Date) -Comment "Cleanup for $serverName"

2. Check for scheduled maintenance that targets these servers

See if there is any active maintenance schedule still targeting those machines:

Get-SCOMMaintenanceSchedule | Where-Object {
    $_.Targets -match $serverName
} | Select-Object Name, Enabled, IsActive, NextRuntime, Targets | Format-List

If you find any suspicious/stuck schedules, you can stop them with:

Get-SCOMMaintenanceSchedule | Where-Object {
    $_.Targets -match $serverName
} | Stop-SCOMMaintenanceSchedule

Misconfigured schedules are a common source of “object is already in maintenance mode” behaviour.

3. Test maintenance mode from PowerShell

Next, bypass the console and try starting maintenance mode via PowerShell:

$instance = Get-SCOMClassInstance -DisplayName $serverName
Start-SCOMMaintenanceMode -Instance $instance `
    -Reason PlannedOther `
    -Comment "Test MM from PowerShell" `
    -Duration (New-TimeSpan -Minutes 30)

• If you get the same error here, you know the issue is purely on the server/DB side (schedules, stale MM entries, or automation).
• If PowerShell works but the console still throws the error, then it is more of a console or SDK channel problem.

In that case:

1. Make sure your console user is in the Operations Manager Administrators role.
2. Clear the local console cache (%LOCALAPPDATA%\Microsoft\System Center\Operations Manager\Console) and reopen the console.
3. Check the Operations Manager event log on the management server for any errors at the time you click OK in the Maintenance Mode dialog.

4. Check for custom maintenance mode automation

Finally, check whether production has any custom or third-party maintenance mode solution that dev does not – for example:

• SCCM integration that triggers SCOM maint mode,
• SCOMAgentHelper / agent-side MM modules,
• Cookdown / gateway-based maintenance packs, etc.

Those can put a subset of servers into MM under specific classes or with long durations, which would explain why dev can maint-mode them cleanly, but prod believes the objects are already in maintenance.

If you run through those steps for one of the affected servers you should be able to see where SCOM thinks maintenance mode is already active and either clean up the existing entries or fix the schedule/automation that is setting them.

Best Regards

Stoyan Chalakov

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."