Tips on using the SharePoint 2010 Management Pack for OpsMgr 2007

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"?>
<Configuration>
<Annotation>
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>

  <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 https://www.bing.com 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.
</Annotation> <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>

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

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

  <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.
</Annotation>
<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" />
</WorkflowCycle>

</Configuration>

Eddy Pacay

The App-V Team blog: https://blogs.technet.com/appv/
The WSUS Support Team blog: https://blogs.technet.com/sus/
The SCMDM Support Team blog: https://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: https://blogs.technet.com/operationsmgr/
The SCVMM Team blog: https://blogs.technet.com/scvmm/
The MED-V Team blog: https://blogs.technet.com/medv/
The DPM Team blog: https://blogs.technet.com/dpm/
The OOB Support Team blog: https://blogs.technet.com/oob/
The Opalis Team blog: https://blogs.technet.com/opalis
The Service Manager Team blog: http: https://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: https://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: https://blogs.technet.com/b/systemcenteressentials

clip_image001 clip_image002