SCOM 2012: Approve pending agents through PowerShell

If you install your SCOM 2012 agents manually or through a software deployment service like SCCM then you probably have set the approve pending management setting. With this you can decide when the agent is ready to get added to SCOM.

I recently had an agent that was not populating correctly in the pending management view in SCOM. It showed up one time shortly, but when I tried to approve it, I got an error and the system was gone. I even could not see the error correctly because it was directly gone after it appeared. It was really strange, I checked everything (DNS, ports, logs, reinstalled agent), but all looked normal. As if only the approval was missing.

You can check which agents are in pending management with this SQL query (run on OperationsManager database):
select * from agentpendingaction

One thing helped to solve the problem. That was PowerShell.

The cmdlet Get-SCOMPendingManagement provides you all agents which are in pending management and with Approve-SCOMPendingManagement you can approve the agent you need to.

So open the Operations Manager Shell and enter:
Get-SCOMPendingManagement | where {$_.AgentName -eq “ServernameFQDN“} | Approve-SCOMPendingManagement

Read SharePoint lists to use with SCOM or SCORch

In most companies data is spread across different tools / software. SharePoint is one common software to store data. Without a central CMDB you perhaps also have data about servers, server owners, etc. stored in SharePoint. SCOM could use this data to update for example custom fields in alerts
SCORch could process this data for example within an activity. The best way to do that is through PowerShell.

With SharePoint 2010 you have PowerShell cmdlets to grab this data easily. With SharePoint 2007 you can utilize the WebService. I want to focus on this solution.

Use the script from this blog:

If you only need some fields, then you can see the available fields by entering $ | get-member at the end of the script or if you already know which field you want to see, then you can use this format:
If the fieldname contains spaces then replace them with _x0020_.


Fieldname: Management Pack
Powershell: ows_Management_x0020_Pack

So use it like this:

Foreach ($listitem in $
$line = $listitem.ows_title, $listitem.ows_Management_x0020_Pack
# this example writes a log file, but you can also use the data in another way
# => see the link to the blog to update custom fields.
out-file -FilePath c:\list.log -InputObject $line -Append

Sample Agent Maintenance Mode 2012 MP

Attention! New version of this MP is available. See blog:

Every Operations Manager administrator will hit the maintenance mode problem some times. It is not always useful to only have the option setting the maintenance mode through the console or with the minimum of Operator role permissions – as it is defined in OpsManager.

So with 2007 we implemented a agent based maintenance mode solution (provided by our Microsoft consultant Jens Morawietz – thanks for that!). So every user, which logs on to a server will see a splash screen which enables the user to set the maintenance mode directly on the machine without the need of the console and without permissions in Operations Manager. One additional request was: being able to set the maintenance mode through script for using in scheduled tasks. One example is a regular offline backup which brings a service down and where no alerts should be created. So the solution also offers a Visual Basic script, that can be added to those tasks.

With the upgrade to Operations Manager 2012 we had to change the solution a bit (use SCOM 2012 cmdlets, changed to PowerShell, etc.). So I post the 2012 solution here.

Base functionality:

1. The maintenance mode splash screen (or the TriggerOM12MM.Instance.Event.vbs script) writes an event into the OperationsManager event log
2. A rule on the agent checks if this event occurs and creates an informational alert. (part of Sample.Agent.MaintenanceMode.MP)
3. A second rule on the agent checks if this event occurs and triggers a PowerShell write action on the assigned management server to start the maintenance mode. (part of Sample.Agent.MaintenanceMode.MP)


1 a. The maintenance mode splash screen

The script behind this splash screen is written in PowerShell. So each agent, which should use this functionality needs PowerShell 2.0 and the OpsManager shell installed (links!).

The user sets the duration, reason and a enters a comment. Then the user can decide if only maintenance mode should be set or also a shutdown or reboot of the machine should be initiated. If a shutdown or reboot should be started, then the script waits 60 seconds to give the workflow time setting the maintenance mode first.
As soon as the user hits enter (that initializes maintenance mode only) or one of the buttons, an informational event is written to the Operations Manager event log.

This window indicates, that the log entry was created:

Then the script waits up to 5 minutes and checks if there are new events with the id 1215 in the OpsManager event log which indicate that the agent started maintenance mode.

The script will show this window, if the server is set into maintenance successfully:

Or it will show this window, if the maintenance mode was not started within the 5 minutes wait time:

You need to distribute this splash screen separately to the management pack to all agents, that should use this functionality. We have used SCCM for that. You will find a folder called MM in the Zip file which is linked to my post on System Center Central (see bottom). Copy this to the agents C:\ drive and copy the contained OpsMgrmm Shortcut to the Desktop of all users or to the Startup folder in the Start Menu of all users.

I also recommend to change add your company logo to the folder and call it “logo.gif” and enter a correct email address to contact the Operations Manager administrators in the OpsMgrMM.ps1 line 264:

$objContact.Text =“Please contact for assistance.”

The shortcut starts the PowerShell script in a hidden shell with the execution policy “Remotesigned”. So you do not need to change the default execution policy.

1 b. The TriggerOM12MM.Instance.Event.vbs script

The script is also located in the C:\MM folder. It also writes the same event log entry as the Maintenance mode splash screen. The difference is, that you can also specify a class and an instance to be set into maintenance mode.

cscript TriggerOM12MM.INstance.Event.vbs <maintenance mode duration in mins> <comment for maintenance> <class> <instance>

cscript.exe TriggerOM12MM.Instance.Event.vbs 15 “Monthly server reboot.” “Microsoft.Windows.Server.2003.LogicalDisk” “C:”

If you want to set the a complete class with all instances into maintenance, then change it like this:
cscript.exe TriggerOM12MM.Instance.Event.vbs 15 “Monthly server reboot.” “Microsoft.Windows.Server.2003.LogicalDisk” “”

If you want to set the whole server into maintenance, then change it like this:
cscript.exe TriggerOM12MM.Instance.Event.vbs 15 “Monthly server reboot.” “” “”

The script waits 3 min and then ends. So the server has time to go through the workflow and set the maintenance mode.

If you have a regular task, that stops a resource then add the call of this script at the beginning of your command line and then go on with your steps.

Now we have to move to the Sample.Agent.MaintenanceMode.MP

Import this Mp into your Operations Manager 2012 environment. The management pack will create two rules and a Run as Profile.

Sample – Event Log Entry Triggers Alert Rule
Sample – Event Log Entry triggers Maintenance Mode Rule
=> Both rules are targetted to “Microsoft.Windows.OperatingSystem”, so they will run on all Windows computers.

Run as Profile:
Sample Operations Manager Administrator Run As Profile
=> Assign a Operations Manager administrator user to this profile!

2.  Sample – Event Log Entry Triggers Alert Rule

This rule checks for the event 997 in the Operations Manager event log on the agent and creates an informational alert.

Name: Sample Maintenance Mode 2012 – Maintenance Mode was Triggered On The Agent
Source:    Microsoft Windows Server 2008 R2 Standard
Full Path Name:    Servername\Microsoft Windows Server 2008 R2 Standard
Alert Rule:    Sample – Event Log Entry Triggers Alert Rule
Created:    8/2/2012 5:52:55 AM
Alert Description:
The maintenance mode was triggered on: Microsoft Windows Server 2008 R2 Standard . Event Description: TriggerOM12MM.Instance.vbs 1.1 : Start;15;PlannedOther;;;Test:domain\username;8/2/2012 5:52:55 AM.

3. Sample – Event Log Entry triggers Maintenance Mode Rule

This rule checks for the event 997 in the Operations Manager event log on the agent and starts a write action on the asigned management server.

<WriteAction ID=”WA” TypeID=”Sample.Agent.MaintenanceMode.EventlogEntryTriggersMM.WriteAction” Target=”SC!Microsoft.SystemCenter.ManagementServer”>

This write action is based on a PowerShell 2.0 script, so the management server also needs PowerShell 2.0 installed.

The write action itself uses the defined run as profile (Sample Operations Manager Administrator Run As Profile), where a user with Operations Manager administrator permissions needs to be assigned to. Otherwise the write action will not work!

<WriteActionModuleType ID=”Sample.Agent.MaintenanceMode.EventlogEntryTriggersMM.WriteAction” Accessibility=”Internal” RunAs=”Sample.Agent.MaintenanceMode.OpsMgrAdmin.RunAsProfile” Batching=”false”>

The write action will set the maintenance mode depending on how the event description looks like.

TriggerOM12MM.Instance.vbs 1.1 : Start;15;PlannedOther;;;Test:domain\username;8/2/2012 5:52:55 AM
<Will be ignored>;<Duration>;<Class>;<Instance>;<Comment>;<Will be ignored>

Here you can download the Zip file:

OpsMgr 2012: Powershell Cmdlet Get-MonitoringPropertyValue removed – but how to get these values now?

Some OpsManager 2007 cmdlets have been removed in OpsManager 2012. But what if you used those in your scripts?
You will need to replace them.

One example is the cmdlet get-monitoringpropertyvalue. Where you can read values OpsManager has stored in a property.

Here is a script that shows how this value can be read within SCOM 2012:

$computername = “”
$class = get-scomclass -Displayname “Classname”
$agent = get-scomclassinstance -class $class | where {$_.Displayname -like $computername}
$prop = $agent.getmonitoringproperties() | where {$_.Displayname -like ‘Propertyname’}

General Operations Manager 2012 upgrade tipps

Here are some general tipps if you upgrade or plan to upgrade from Operations Manager 2007 to 2012.

  1. Supported configuration
    If you recognize that your servers do not meet the required supported configurations, then do not upgrade windows. I would recommend to build a new machine and move the role to the new server.
  2. Operations Manager 2007 PowerShell snapin
    If you have PowerShell scripts running in your management packs, that utilize the Operations Manager 2007 snapin, then check that the snapin is still available on the upgraded servers.
    Open Powershell and enter get-pssnapin -registered. If you see the following lines then you can use the OM2007 cmdlets.
    Name: Microsoft.EnterpriseManagement.OperationsManager.Client
    PSVersion: 1.0
    Description: Microsoft Operations Manager Shell Snapin
    Otherwise you will need to register the snapin (also possible on management servers!).
    You will need to copy the files from a om 2007 server with the operations manager shell installed.
    You can follow this blog:
    You will get more time to update your scripts and management packs if you can use the old snapin in the meantime.
  3. AD Integration
    If you use AD integration in your environment then check your agents after the upgrade! I saw some strange behaviour.
    Agents that are multi-homed lost their AD integration setting. The manual added management group entry was still in there but the AD integration checkbox was empty.
    Servers with the operating system Windows Server 2003 SP2 could not read the SCP entries anymore, so we had to switch them to manual configs.  The error looked like this:
    Event ID 2000
    Source: HealthService
    Description: The Management Group failed to start. The error message is: The environment is incorrect (0x8007000A). A previous message with more detail have been logged.
    There was no previous message. Microsoft had no reason for that.
  4. Agent Error: Management Group cannot be saved

    I had this error (the management group configuration could not be saved) on one machine when I entered the management group information manually and clicked on apply. The solution was easy: Reinstall the agent. It looked like that the upgrade was not really successful.
    If that does not help try to delete the following registry keys and restart the healthservice.
    HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\[MG name]
    HKLM\System\CurrentControlSet\Services\HealthService\Parameters\Management Groups\[MG name]
  5. Fix Bug: