Summary

SharePoint monitoring in SCOM has a unique configuration that is often overlooked or implemented incorrectly. This post contains a pair of SCOM management packs intended to simplify the configuration of SharePoint monitoring.

Introduction

System Center Operations Manager has been a first-class tool for monitoring an on-premises SharePoint environment for over a decade, as official management packs have been created and supported by Microsoft for SharePoint monitoring. Ever since the SharePoint 2007 management pack, the initial configuration of SharePoint monitoring has relied upon a helper task ran from within the SCOM console after the management packs were imported. The helper task was designed to make initial configuration and discovery of SharePoint components easy, and there have been several blog posts walking users through the configuration process (such as this post from Kevin Holman about SharePoint 2013). Despite that, it remains a frequent pain point in the configuration procedure, resulting in countless blog posts about the various problems encountered with it, reasons why it might not run properly or at all, and more. (I can personally attest that I’ve spent far more time wrestling with the task than is reasonable for something intended to be “helpful”.) One of the main reasons why it causes problems is that method for configuring SharePoint monitoring is so very different from the procedure for configuring any other management pack, and the documentation isn’t accurate for SCOM environments with multiple management servers.

To that end, I’ve created a set of management packs designed to simplify the configuration process for SharePoint monitoring. Right now, I have management packs for SharePoint 2010 and SharePoint 2013, and as soon as the 2016 management packs are fully released, I’ll create an equivalent management pack for that version. Regardless of the version, the management packs function the same way and are designed to bring the initial SharePoint monitoring configuration methods in line with the procedures used to configure other management packs, while accommodating the quirks of the SharePoint discovery process. This post is intended to introduce those management packs and provide instructions for implementation.

The Native Way

To understand how these management packs work, it’s best to first understand what the SharePoint management pack’s helper task does, so we’ll start there. The helper task is designed to facilitate three functions:

1. Enable the initial SharePoint discoveries for specific computers (either explicitly listed or defined via regular expression)
2. Configure the SharePoint run as profiles to use the SharePoint monitoring account, and configure the SharePoint monitoring account’s distribution to ensure all computers for which the discoveries were enabled can use the SharePoint monitoring credentials
3. Set sync time overrides on SharePoint discoveries to accelerate the discovery process

That is useful in theory, but the execution has always been lacking. Instead of the SCOM admin being able to import the management packs and then configure them entirely via the SCOM console, the task requires the admin to:

1. In SCOM, configure the run-as account
2. In SCOM, import the management packs
3. In a text editor, configure the configuration file (either explicitly listing all servers to discover SharePoint on or figuring out how regular expressions work)
4. Copy the config file to the same location on every SCOM management server, probably creating the necessary folder in the first place and hoping that no one changes any one instance of the configuration file
5. Restart the SCOM services on all management servers to ensure the helper task’s related script will be present and the task could actually run
6. In SCOM, run the task and hope you don’t get any errors

Then, if ever any servers needed to be added or removed, the admin would have to update the configuration file, re-copy it to all servers, restart all the services again, and then re-run the configuration task.

In short, it results in a giant pain in the backside.

Combine that with the fact that this procedure is grossly different from the configuration of any other management pack, and it’s not hard to realize why most SCOM admins either don’t configure it properly or give up on it entirely.

The Simpler Way

These custom management packs I’ve created help simplify the process, return all of the configuration steps back to the SCOM console, and make it easier to make changes in the future, all while aligning with the standard SCOM procedure for configuring management packs. This is accomplished by removing the configuration file and the helper task from the equation entirely, instead relying on an instance group and a pre-defined set of overrides to achieve two of the helper task’s functions and leaving the third up to the SCOM admin.

First, let’s talk about the SharePoint discoveries and the aforementioned SCOM group. The primary role of the configuration file is to list out the computers upon which SharePoint should be discovered, either explicitly or via a regular expression. This is the exact same function that a manually-populated SCOM instance group is designed to perform, while also providing a wider range of dynamic membership conditions, while keeping the configuration in the SCOM console instead of an unrelated text file. To that end, I’ve created a group titled “Windows Computers with SharePoint Discovery ENABLED”. Instead of filling out the text file, after importing the management packs, the SCOM admin only needs to go into the Groups view and populate this group with Windows Computer instances via whichever method best suits their situation. Overrides are already configured which target this group and enable discovery of SharePoint components on the computer instances within the group. If ever new computers need to be added to SharePoint monitoring, it’s as easy as adding them to the group. Same for removing servers from SharePoint monitoring – just remove them from the group. The configuration of the group can even be assigned to the SharePoint monitoring team via User Role scoping, allowing them to manage SharePoint monitoring themselves without having to share administrative access to SCOM.

The second function the helper task performs is to set sync time overrides to ensure that the SharePoint discoveries occur immediately after implementation. These management packs take a slightly different path than the helper task here – the benefit of the helper task is that, no matter when you run it, all of SharePoint should be discovered within 2 hours of running the task. Since I have no way of knowing when an admin will import the management packs, I’ve instead configured overrides within the management pack with sync times based around noon. Using this management pack, the SharePoint discoveries will all start running in an appropriate order between 12:00 noon and 1:00 PM (based on the time zone of the management server). So long as these management packs are imported in the morning, SharePoint should be fully discovered by 2:00 PM. If the management packs are imported later in the day, then discovery might not complete until the next day. I don’t see this as a negative, though, because having core discovery workflows only run once or twice per day is a standard configuration across many management packs, meaning this change just makes the SharePoint management packs behave more like any other management pack. If you do want to hasten the process, though, all that is needed is to manually update the existing overrides, which can be easily accessed in the Overrides view in the Authoring workspace.

The final function the helper task performs is the configuration of the SharePoint run as account’s distribution and mapping to the SharePoint monitoring run as profiles. In every other management pack under the sun, this is a manual task as part of the security configuration of the management pack. The helper task, when it works, is handy in that it automates the process, but the average SCOM admin is more than capable to do this step themselves. In fact, even with the task, sometimes the run as profile configuration still needs some manual attention.

These custom management packs do not perform any automation around run as account and profile configuration at this time; instead, this task is returned to the SCOM administrator. After adding Windows Computer instances to the discovery group, the SCOM admin will want to also update the SharePoint run as account’s distribution to allow the necessary servers access to the credentials, and will need to update the SharePoint run as profiles to leverage the run as account. I may create a custom workflow for this and add it to the management packs in the future, but for now, this is left to the admin. In my opinion, given that the admin configuration of the account security is standard in other management packs, I don’t see this as a detriment, but I am open to feedback.

Summary and Download

I’ve used these custom management packs with several clients now and they have drastically reduced the headaches of configuring SharePoint monitoring. I have found that bringing all the configuration into the SCOM console and aligning it with the standard management pack configuration procedure has decreased the time it takes to configure SharePoint monitoring and has gotten results the the various SharePoint teams faster and more consistently. The SharePoint teams still need to make sure the credentials being used have the appropriate access to SharePoint and its resources, but with that being true, SharePoint monitoring configuration is not the pain it has been in the past when I use these management packs.

You can download the management packs for SharePoint 2010 and 2013 from the following links. Once the 2016 management pack becomes officially released, I’ll create a version for it and either update this post or create a new one. If you have any questions at all, shoot us an email and we’ll update this accordingly.

Click here to download the SharePoint 2010 Discovery Overrides management pack

Click here to download the SharePoint 2013 Discovery Overrides management pack