The System Center Operations Manager Support Team Blog

This is the OpsMgr 2007 blog for the Microsoft support team. If you were looking for the SCOM 2007 or MOM 2005 blog then you are in the right place.

Tips on using the SharePoint 2010 Management Pack for OpsMgr 2007

Tips on using the SharePoint 2010 Management Pack for OpsMgr 2007

  • Comments 18
  • Likes

InformationHi, Eddy Pacay here, and I wanted to share a couple notes on using the SharePoint 2010 Management Pack for System Center Operations Manager 2007 (SCOM 2007).

The SharePoint 2010 MP Guide does not say anything specific on how to set this up around multiple SharePoint (SPS) farms when each SharePoint farm is installed with a different installation account. 

First off, the initial discovery appears to need the FarmAdmin installation account in order to discover more than one SharePoint Farm.  The following permissions are needed to get this working correctly:

  • local admin on all SP2010 Front End and Application servers
  • local admin on all SQL boxes that host SharePoint 2010 Databases
  • dbo for the actual SharePoint databases
  • full farm admin rights within SharePoint 2010

There is currently isn’t a lot of documentation stating what the minimum requirements are to setup a low privilege account but this should get you started in the right direction:.

1) The SharePointMP.Config file resides on the Root Management Server (RMS), not the Management Server (MS). If the RMS is clustered then the SharePointMP.Config file must be on both nodes.

2) Create a SCOM RunAs account for each SPS farm, or each unique SPS farm installation account when the SPS Farm was installed.

3) Update the SharePointMP.Config file to include account entries per the RunAs accounts created.  See the contoso example below.

4) Run the SPS config task; return in 24 hours.  Due to discovery layers, synch times and frequencies, it can take 12-24 hours for all farms to be discovered which is to be expected.

5) After running the SPS config task you can verify that the RunAs account successfully logged on by reviewing the local SCOM log on the SPS server and looking for informational event ID 7026.  This should verify a successful account logon.  conversely, if the logon fails you’ll probably see error event ID 7000 for a failed logon.

Sample SharePointMP.Config

Note that in the SharePoint.config file, there is a section titled Associations.  This is the section that needs to be modified for multiple farm support.  See the section in brown below:

<?xml version="1.0" encoding="utf-8"?>
    This is the configuration file for the admin task in Microsoft SharePoint Foundation 2010 Management Pack.
    To run the task, save this file on the Root Management Server machine under %ProgramFiles%\System Center Management Packs

  <Annotation Element="Association">
   Association element specifies account association. You can have 0, 1, or many Association elements.

    - The Account attribute specifies what RunAs account to be associated. The account must exist before running the admin task.
      RunAs account can be created in the Administration pane of the Operations Console.

    - The Type attribute may have one of two values: "Agent" and "ManagementServer". "Agent" indicates that the account applies to
      agent managed machines. "ManagementServer" indciates that the account applies to management servers.

    - Each Machine node serves as a machine filter. Machine that matches any filter will be associated with the account in the profile.

    - The Name attribute of Machine node holds a regular expression value on full machine name. Go to and search for
      "Regex Tutorial" to learn more about regular expression. If you leave the Name attribute empty, all of machines (agent managed or
      management server depending on the type) match.

   - For "Agent" type, discovery proxy is also enabled on the matched machines so that farm level discoveries can work correctly.
  <Association Account="Contoso - SharePoint Farm administrator 1" Type="Agent">
    <Machine Name="Contoso1" />
    <Machine Name="Contoso2" />
    <Machine Name="Contoso3" />
    <Machine Name="Contoso4" />
    <Machine Name="Contoso5" />
    <Machine Name="Contoso6" />

  <Association Account="Contoso - SharePoint Farm Administrator 2" Type="Agent">
    <Machine Name="constosrv1" />
    <Machine Name="constosrv2" />
    <Machine Name="constosrv3" />

  <Association Account="Contoso - SharePoint 2010 Farm Administrator7" Type="Agent">
    <Machine Name="constosrv4" />
    <Machine Name="constosrv5" />
    <Machine Name="constosrv6" />

  <Annotation Element="WorkflowCycle">
    WorkflowCycle element specifies the schedule of list workflows. You can have 0, 1, or many WorkflowCycle elements. But if you
    have multiple WorkflowCycle elements, you should avoid listing the same workflow in different WorkflowCycle elements.

    - The BaseStartTime attribute can have value in the form of "HH:mm" or integer. "HH:mm" format works as the start time alignment based on which
    the cycle repeats. Integer format functions as setting the alignment start time to be the current time plus that many seconds. Be aware that
    if you set integer value, every time you rerun the admin task, the cycle start time is recalculated.

    - The Length attribute specifies the length (in seconds) of each cycle.

    - The Spacing attribute specifies the spacing time (in seconds) between one workflow's timeout time and the next workflow's start time.
    For example, SPFarm.Discovery has timeout 300 and base start time at "14:00". If the Spacing is 60, the base start time of SPService.Discovery
    is set to 14:00 + Ceiling[(300 + 60) / 60] = 14:06. If you set negative Spacing, workflows may overlap and cause performance and out of memory problems.

    - The WorkflowTimeout attribute (optional) if defined applies to each workflow in the cycle unless being overridden in the Script node. If not set, current timeout values are respected.

    - The Id attribute of Workflow node is a list of the discovery/monitor Id(s) separated by ';' (for the workflow).

    - The MP attribute (optional) of Workflow node is for workflow not defined in the Microsoft SharePoint Foundation 2010 MP.

    - The Type attribute of Workflow node indicates the workflow type. Only "Discovery" and "Monitor" are supported.

    - The Times attribute of Workflow node specifies how many times the workflow needs to run within a cycle. If you set it to 0 or negative, the workflow is disabled.

    - The Timeout attribute (optional) of Workflow node if defined overrides the timeout of the workflow.
  <WorkflowCycle BaseStartTime="+300" Length="28800" Spacing="60">
    <Workflow Id="WSSInstallation.Discovery" Type="Discovery" Times="1" />
    <Workflow Id="SPFarm.Discovery" Type="Discovery" Times="1" />
    <Workflow Id="SPService.Discovery" Type="Discovery" Times="4" />
    <Workflow Id="SPSharedService.Discovery" Type="Discovery" Times="4" />
    <Workflow Id="SPHARule.Discovery" Type="Discovery" Times="1" />
    <Workflow Id="SPHARuleMonitor.Availability;SPHARuleMonitor.Security;SPHARuleMonitor.Performance;SPHARuleMonitor.Configuration;SPHARuleMonitor.Custom" Type="Monitor" Times="8" />
    <Workflow Id="SPHARuleMonitor.SPServer.Availability;SPHARuleMonitor.SPServer.Security;SPHARuleMonitor.SPServer.Performance;SPHARuleMonitor.SPServer.Configuration;SPHARuleMonitor.SPServer.Custom" Type="Monitor" Times="8" />


Eddy Pacay

The App-V Team blog:
The WSUS Support Team blog:
The SCMDM Support Team blog:
The ConfigMgr Support Team blog:
The SCOM 2007 Support Team blog:
The SCVMM Team blog:
The MED-V Team blog:
The DPM Team blog:
The OOB Support Team blog:
The Opalis Team blog:
The Service Manager Team blog: http:
The AVIcode Team blog: http:
The System Center Essentials Team blog: http:

clip_image001 clip_image002

  • Good Post!

    The MP is working but I cannot get the Config and Content DB monitoring working. Everytime I get "Data Source could not be initialized" (also with imported SQL MP). Has anybody experienced the same issue?

  • The computer name is required to be in simple format like contoso1 or i have to give the FQDN in the Config file.

    nothing is getting discovered.

  • Quick question.  I took the odd step of reading the MP guide for this MP a couple of weeks ago, and I seem to recall it clearly stating you can only monitor one SharePoint farm per management group.  That seems to contradict your statements here.  What gives?

  • To follow up on my last post, it looks like you CAN support more than one farm, but we do NOT recommend it:

    The SharePoint foundation MP guide states in the FAQ section:

    • How many farms can I monitor from one set of Operations Manager 2007 servers?

    We recommend having one set of Operations Manager 2007 servers monitor only one SharePoint farm.

    I don't work with SharePoint but do work with OpsMgr.  I don't know the difference betweeen SharePoint Foundation and SharePoint, but I think SharePoint depends on Foundation? I could be wrong.

  • @ Andy

    I have found one other case where this was resolved by creating an OLEDB data source for the DB connectivity, the Provider string was copied out and and an override for the monitor was created to change the the conection string using the provider string to match.

    Example: "Provider=SQLOLEDB;Server=contoso2\enterprise;Database=sharepoint_config;Integrated Security=SSPI"

  • @Nalin

    I have often used the short name (netbios) to get them to work. However, depending on the envrionment you may have to use FQDN depending on your DNS scheme and the security in the network where you would be prevented from using netbios across forests/domains

  • @Andres

    Same here, I work mainly with OpsMgr not with SharePoint or SharePoint Foundation. The recommendation is made based on the capacity of the MG to be able to monitor multiple farms due to SharePoint monitoring can be expensive to an MG depending on the design of the MG. Same would go for Exhange 2007/2010 and Active Directory since the MP's need to be highly tuned to reduce noise. Here is a link that I have used to help with that before

    The recommendation is based on load, not necessarily based on design principles. although it can be said that it could depend on the environment variables wheter it would be a problem.

  • Hi

    We have sharepoint 2010 MP in our SCOM environment. All the sharepoint servers are discovered and listed under agent mangend. But  some of the servers doesn't get listed in monitoring tab , under sharepoint server view. Any help here...

  • Having same issue - sharepoint servers not being monitored, agent is installed and healthy.  Only 1 shpt front end is showing up,  all the others are not.

  • Hope this thread isn't dead.  It's been very informative!  Just to be clear, so long as permissions are correct, you should list a SP farm's app, web and SQL servers in each Associations section to cover discovery/monitoring of the entire farm?

    Thanks very much!

  • Still unclear why would SCOM need sp_install account. There's only one per farm. Can it not be just farm Admin account?

  • How do I exclude a sharepoint server from being discovered as a SP svr?

  • You could create a group with the servers you wish to "NOT Monitor" and override the "Discovery for SharePoint Foundation Installed Machine", setting it to False.

  • I have followed various articles and forums, I can't get this to work. Keeps failing to associate account.

  • @Simon  Make sure the RunAS account is named EXACTLY what is listed in the SharePointMP.Config

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment