SCOM 2012 – Maintenance Mode and Orchestrator

Many SCOM admins and users have scripted solutions to help put their machines into maintenance mode in SCOM 2007. There are a ton of great blogs out there on doing this. For SCOM 2012, however, those same scripts will not work. Here’s why:

SCOM 2007 R2:

Brute Force Script:

$class = get-monitoringclass -name:Microsoft.Windows.Computer
$computer = get-monitoringobject -monitoringclass:$class -criteria:”PrincipalName=’scottmusjm1.tpb.lab'”
$start = get-date
$end = $start.addminutes(30)
new-maintenanceWindow -startTime:$start -endTime:$end -monitoringobject:$computer -comment:”Testing”


So, with a short little script we have dropped the health service, the health service watcher, the windows computer object and all contained objects into MM. This was fantastic for doing maintenance activities such as patching. Let’s try the same brute force script in an OM 12 command shell:

Well, at least get-date still works. The PowerShell commandlets for SCOM 2012 have changed. The new commandlets are documented here:

Using the reference, here’s what our script needs to look like to put the windows computer object into MM in OM 12:

$class = get-scomclass -name:’Microsoft.Windows.Computer’
$computer = get-scomclassinstance -class $class | where{$ -eq ‘SCOTTMUSJM2.tpb.lab’}
$start = get-date
$end = $start.addminutes(30)
start-scommaintenancemode -Instance:$computer -EndTime:$end -Comment:”Testing”

It looks like this worked. Notice I had to use a where clause on the get-scomclassinstance commandlet. For some reason in my environment, the commandlet didn’t want to take the both the class and the computer name at the same time. This needs to be investigated further. Either way, let’s take a peek in OM 12:

*UPDATE – this is now works with SP1.  I am not sure exactly when this changed, but in a prior build of OM 12 this was not the case.  This was changed and now the script above does drop the Agent, the Health Service Watcher and the Windows Computer object into MM.



And the contained objects:


Since this works, many admins may stop here.  However, I still believe Orchestrator gives us the best options for controlling MM.

Let’s brute force this just for testing purposes:

Upon running the Runbook:

It even catches the contained objects!

After executing this, all objects have been removed from MM including the health service and the health service watcher.

At this point, you could use orchestrator tied to a CMDB of sorts to manage MM completely on its own. Have you ever had someone accidentally drop your SCOM infrastructure into MM? Going with Orchestrator, you can put exclusions in place to prevent anyone from accidentally hitting your SCOM infrastructure. There are many possibilities. Additionally, if you still need to on demand request MM for a machine, you can always execute the runbook remotely still using PowerShell. The MSDN article for the basic PS code is found here:

Leave a Reply