Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

Configuring the SharePoint 2013 Management Pack

Configuring the SharePoint 2013 Management Pack

  • Comments 17
  • Likes

 

 

The management pack for SharePoint 2013 (including server and foundation) is available here:

http://www.microsoft.com/en-us/download/details.aspx?id=35590

As of this writing – the version on the download site is 15.0.4425.1000 however the ACTUAL version of the management packs are 15.0.4420.1017.  I have no idea why we don’t make these match up.

 

First – import the MP’s:

As a best practice, also ensure you have imported and configured the Windows Server Operating System, SQL Server, and IIS management packs for your OS versions.  Then – the SharePoint MP’s:

 

image

 

We will assume you have installed SharePoint 2013, and deployed an agent to these servers.  When monitoring a farm, you need to ensure agents are deployed to all farm role computers, including the SQL database servers.

Next – I recommend you perform this step on your management server.  We need to copy the configuration file “microsoft.sharepoint.foundation.library.mp.config” that shipped with the management pack files, to the following location:

C:\Program Files\System Center Management Packs

image

 

This MUST be placed in this specific location.  You might have to create the directory if it does not exist.  If you had previously configured SharePoint 2010 on this same server, you will see your SharePoint 2010 config file present, as seen in the graphic above.

 

Open the microsoft.sharepoint.foundation.library.mp.config file using NotePad, and find the section “<Association Account”

 

<Association Account="SharePoint Discovery/Monitoring Account" Type="Agent">
  <Machine Name="" />
< /Association>

We need to create a RunAs account for the SharePoint 2013 MP to use.  This RunAs account display name MUST match the “Association Account” in the config file.  Here is where we need to have a quick discussion.

The SharePoint 2010 MP’s and config file use the SAME default name of “SharePoint Discovery/Monitoring Account” 

  • If you are NOT monitoring SharePoint 2010, then you can continue and use the default name.  If you ARE monitoring SharePoint 2010 already – then you have two choices. 
  • If your CURRENT SharePoint monitoring RunAs account credential is also a Farm Admin in SharePoint 2013 – you can just use your existing RunAs Account and continue. 
  • If you are monitoring SharePoint 2010 already, and you wish to use a DIFFERENT credential for monitoring SharePoint 2013, then you will need to modify the config file.

Honestly – the config files for SharePoint 2010 and 2013 should not have used the same default name for the RunAs account and the profile.  I’m hoping they change this in future versions because it just makes everything harder to support.

 

At any rate – I was not able to get the 2013 MP to use a unique RunAs account… no matter what I did it was always using the SharePoint 2010 MP’s credential, even when it was not distributed to my SharePoint 2013 servers, which is bizarre.  At this point I’d recommend using the same credential for all Farms if you are trying to monitor SharePoint 2013 and 2010.  I continue to investigate this.

 

Next – I will create a new Run As account – with this EXACT name (unless it already exists)

image

image

image

 

 

Open the RunAs account we just created – and on the distribution tab – add in the servers that are part of the farm, or SQL servers that host farm databases:

image

 

At this point – I need to ensure that my RunAs account credential that I just used is a Farm Admin, and has full access to all SharePoint SQL servers/databases.

 

Next – we need to configure the SharePoint config file for the server names for our SharePoint 2013 and SQL servers.  If you don’t edit the file with specific Farm Server and Database Server names, then SCOM will try and discover SharePoint 2013 on EVERY server in the management group.  It is best to scope this down in advance.  Open the file in NotePad, and under "Association Account” add a “Machine Name=” line for each server in your farm.  For instance, my Farm consists of “shpt2.opsmgr.net” and “db1.opsmgr.net” so my file will look as follows:

 

<Association Account="SharePoint Discovery/Monitoring Account" Type="Agent">
  <Machine Name="shpt2.opsmgr.net" />
  <Machine Name="db1.opsmgr.net" />
< /Association>

Save and close the config file.

In the monitoring view – Expand Microsoft SharePoint > Administration and select the “Microsoft SharePoint Farm Group”

In the Tasks pane – run the task “Configure SharePoint Management Pack”

*** Note – if the task fails – or throws an error – try running it again a few times, or closing and opening the SCOM console – and running it again.  If it continues to fail – investigate and ensure you have the config file on your management server, and you are running the console on the management server when calling the task.

 

You should see output similar to this:

Output
Load configuration file Microsoft.SharePoint.Foundation.Library.mp.config
Configure Microsoft.SharePoint.Foundation.Library version 15.0.4420.1017
Create override management pack Microsoft.SharePoint.Foundation.Library.Override
Account SharePoint Discovery/Monitoring Account is associated to DB1.opsmgr.net for Microsoft.SharePoint.AdminAccount
Account SharePoint Discovery/Monitoring Account is associated to SHPT2.opsmgr.net for Microsoft.SharePoint.AdminAccount
Allow DB1.opsmgr.net as a proxy
Allow SHPT2.opsmgr.net as a proxy
Create 'Enabled' property override with value true for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Create 'SyncTime' configuration override with value 18:43 for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Create 'IntervalSeconds' configuration override with value 28800 for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Microsoft.SharePoint.2013.WSSInstallation.Discovery does not have configuration TimeoutSeconds
Create 'SyncTime' configuration override with value 18:45 for Microsoft.SharePoint.2013.SPFarm.Discovery
Create 'SyncTime' configuration override with value 18:51 for Microsoft.SharePoint.2013.SPService.Discovery
Create 'SyncTime' configuration override with value 18:57 for Microsoft.SharePoint.2013.SPSharedService.Discovery
Create 'SyncTime' configuration override with value 19:03 for Microsoft.SharePoint.2013.SPHARule.Discovery
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Availability
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Security
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Performance
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Configuration
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Custom
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Availability
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Security
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Performance
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Configuration
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Custom
SharePoint management pack configuration completed successfully

 

This task is really a “discovery helper”.  It will create the necessary RunAs profile associations to the RunAs account for each server, and it will enable agent proxy for each server, and will create some overrides to space out all the discoveries so they run in order, and can discover all Farm components as quickly as possible.   From the time you run the task, to full Farm, Role, Server, and Service discovery, should be around 40 minutes.

 

After 40 minutes – check in the console and see if your Farm, Servers, and Services have all been discovered.  If not – check in the “Unidentified machines view”.  If your farm servers show up there, it is likely a permissions issue with your RunAs account, either on the Farm servers or on the SQL server.  On the SharePoint servers, make sure this account can log in and execute the SharePoint command shell without errors. 

 

 

Some good troubleshooting blogs on this topic:

http://thoughtsonopsmgr.blogspot.com/2013/04/sharepoint-server-2013-mp-useful-links.html

http://thoughtsonopsmgr.blogspot.nl/2013/04/troubleshooting-sharepoint-server-2013.html

http://thoughtsonopsmgr.blogspot.nl/2013/04/sharepoint-server-2013-mp-configure.html

 

 

 

Known issues:

There is a bug in the MP’s report deployment – you will see an alert about

Data Warehouse failed to deploy reports for a management pack to SQL Reporting Services Server. 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 'edf9e0b9-65aa-df29-6729-d16f0005e820'. Failed to deploy linked report 'Microsoft.SharePoint.Server_Performance_Report'. Failed to convert management pack element reference '$MPElement[Name="Microsoft.SharePoint.Foundation.2013.Responsetime"]$' to guid. Check if MP element referenced exists in the MP. An object of class ManagementPackElement with ID 75668869-f88c-31f3-d081-409da1f06f0f was not found.
One or more workflows were affected by this.
Workflow name: Microsoft.SystemCenter.DataWarehouse.Deployment.Report

See:  http://thoughtsonopsmgr.blogspot.com/2013/05/bug-alert-sharepoint-server-2013-mp.html

Comments
  • Hi,

    thanks for this information. This is very helpfull.. Any recomendations when I want to discover multiple farms over different domains using different Farm Administrator accounts.

    Should I add the servers one by one to

    <Association Account="SharePoint Discovery/Monitoring Account" Type="Agent">

     <Machine Name="shpt2.opsmgr.net" />

     <Machine Name="db1.opsmgr.net" />

    < /Association>

    or is there a way to work with Groups?

    Thnxs

    Thomas

  • Hi Kevin,

    Thanks for another great post! Is there a simpler way to create a custom alert notification/subscription for all SharePoint 2013 related alerts to route to my SharePoint Support group?  My current Subscription Criteria Conditions are:  Raised by any instance of a specific class (which I have selected ALL classes from the Microsoft SharePoint Server Core Library and Microsoft Sharepoint Foundation Core Library MP) and of a specific severity (Warning or Critical), and with specific resolution state (New (0)).  Is there a single SharePoint class that would include all SharePoint alerts?  Too bad I can't just specify the names of the SharePoint 2013 MPs (Foundation and Server) for criteria.

    Thanks,

    Huy

  • What a nightmare of a MP this is... Is it really necessary for all these configuration tasks? The folks responsible for designing/writing this MP should really find a better way. Implementing this MP causes confusions and frustration for a lot of customers.

  • Hi Kevin,

    there is another error that will be generated after importing this MP (error will no longer be shown if the MP is deleted):

    Event ID 26319:

    An exception was thrown while processing GetObjectsByIdentifiers for session ID uuid:d820ce18-a60c-4c97-bd58-a39464b675b0;id=499.

    Exception message: The creator of this fault did not specify a Reason.

    Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException]: The creator of this fault did not specify a Reason.

    (Fault Detail is equal to Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user domain\DataWarehouseReader does not have sufficient permission to perform the operation.).

    You can ignore this error because everything is working fine. This error is based on the descripted error:

    Event ID 31567:

    Alert Description:

    Data Warehouse failed to deploy reports for a management pack to SQL Reporting Services...

    BR

    Dominik

  • Any updated on when the report deployment bug will be fixed?

  • Reporting Deployment Bug now fixed in version 15.0.4557.1000 of the Management Pack.

  • Hi , I have questtaion about more farm . Can I add more credentional to anothern farm ?

    thanx

  • Thanks for the good blog post, Kevin. Seems odd that you wouldn't be able to configure seperate account "At this point I’d recommend using the same credential for all Farms if you are trying to monitor SharePoint 2013 and 2010. I continue to investigate this." Any new info on that?

  • Same question, we can have many account for many farm in many domains?
    Thank you.

  • Since our SharePoint 2013 farm was upgraded to SP1 the SCOM management pack is not functional. All the farm machines are in the Unidentified Machines container. Any ideas?

  • I added specific Sharepoint servers and DB's into the config file hoping it would only target/discovery SharePoint on those specific servers. However, it is discovering SharePoint installations on other agent managed machines.

    I was thinking of overriding the discovery in the SharePoint MP to exclude those server objects. Is there a specific discovery I could use...or a combination of a few?

  • While I see the MP indicates for SCOM 2007 and higher any experience deploying it on SCOM 2012 SP1? Is the install process the same

  • Well the Management Pack deployment guide only indicates 2007 not 2012. 1. Set up System Center Operation Manager 2007 R2 servers. Follow the Operations Manager 2007 R2 Deployment Guide

  • Hi Kevin, you've mentioned that - C:\Program Files\System Center Management Packs This MUST be placed in this specific location.
    For windows server 64bit, if it exist in C:\Program Files (x86)\System Center Management Packs, we still need to change it to C:\Program Files\System Center Management Packs??

  • In addition, it shows "To run the task, save this file on the Root Management Server machine under %ProgramFiles%\System Center Management Packs"
    My SCOM actually installed at E drive. Is that okay?

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