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

Problems with the shared data source OperationalDataBaseMain on SQL 2008 R2 SSRS.

If you imported the community management pack SCC Health Check Reports ( then you probably also experience an issue when you upgrade your Operations Manager SSRS environment to SQL 2008 R2 Sp1 as a preparation for the Operations Manager 2012 upgrade. The SCC Health Check Reports management pack connects to the OperationsManager database through the shared data source “OperationalDataBaseMain”. With SQL 2005 all settings described in the above link worked.
After moving our SCOM reporting to a new Windows 2008 R2 SP1 server with SSRS 2008 R2 Sp1 the following event log entry appeared on the management server which was contacted from the reporting server:

ID 31567:

Failed to deploy reporting component to the SQL Server Reporting Services server. The operation will be retried.
Exception ‘DeploymentException’: Failed to deploy reports for management pack with version dependent id ‘3865f46b-54a4-464e-aa7c-2762b5b42856’. Failed to deploy report ‘SCC.HealthCheck.Reports.V2.OM.Misc.ManagementPacks’. AdjustDataSources: Exception <ErrorCode xmlns=””>rsInvalidParameter</ErrorCode><HttpStatus xmlns=””>400</HttpStatus><Message xmlns=””>The value of parameter ‘DataSources’ is not valid.</Message><HelpLink xmlns=””>;EvtSrc=Microsoft.ReportingServices.Diagnostics.Utilities.ErrorStrings&amp;EvtID=rsInvalidParameter&amp;ProdName=Microsoft%20SQL%20Server%20Reporting%20Services&amp;ProdVer=10.50.1617.0</HelpLink><ProductName xmlns=””>Microsoft SQL Server Reporting Services</ProductName><ProductVersion xmlns=””>10.50.1617.0</ProductVersion><ProductLocaleId xmlns=””>127</ProductLocaleId><OperatingSystem xmlns=””>OsIndependent</OperatingSystem><CountryLocaleId xmlns=””>1033</CountryLocaleId><MoreInformation xmlns=””><Source>ReportingServicesLibrary</Source><Message msrs:ErrorCode=”rsInvalidParameter” msrs:HelpLink=”;EvtSrc=Microsoft.ReportingServices.Diagnostics.Utilities.ErrorStrings&amp;EvtID=rsInvalidParameter&amp;ProdName=Microsoft%20SQL%20Server%20Reporting%20Services&amp;ProdVer=10.50.1617.0&#8243; xmlns:msrs=””>The value of parameter ‘DataSources’ is not valid.</Message></MoreInformation><Warnings xmlns=”; /> 

In the event you can see that it has problems with a report that connects to the OperationsManager database. This error will effect all reports that use this shared data source so also custom reports.

If you run the report then you get the failure “rsInvalidDataSourceReference“. 

I found the blog from Marnix and followed his procedure, but that did not help.

Afterwards I tried other things and found this solution:
It looks like a missing link to the correct data source in the ReportServer database (add screenshot and link).

  1. Logon to the Operations Manager SQL server and give the data reader account data_reader permissions on the OperationsManager database.
  2. Open up http://reportservername/reports and change the settings to “credentials are not required” for the data source OperationalDataBaseMain:
    Test the data source and click Apply.
  3. Open up the details view in the SCC Health Check Reports folder and change the data source of the report that caused the event to the shared OperationalDataBaseMain data source.
  4. Do that for all failed reports which use this data source.

The problem behind that is that the link to the data source is missing.

You can check that in SQL Server Management Studio. Run this query:

SELECT Name, Link, ItemID FROM [ReportServer].[dbo].[DataSource] where name like ‘operational%’

If the Link field is empty, then the report will not work. After manually updating the data source in SSRS the link entry should be filled and all other missing reports should be deployed correctly.

Gray agents in Operations Manager 2012

One small but really nice thing I realized in Operations Manager 2012 is that the sorting got optimized. Specially when you want to see, which agents are grayed out.

In Operations Manager 2007 the state views did not update correctly. So if you sorted by health state in the Windows computers view, then the grayed out agents were somewhere in the view but not at the top.

In Operations Manager 2012 if you sort by health state in the Windows computers view then the system shows you all unmonitored or grayed out agents at the top. So you do not need to search for them anymore.

Isn’t that great?!

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: