Hi, 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:
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.
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 http://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>
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
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.
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"
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
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 opsmgrunleashed.wordpress.com/.../opsmgr-r2-by-example-the-sharepoint-mp
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.
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