Troubleshooting SharePoint Server 2013 MP

Bumped into this issue at a customers location.

The SharePoint Server 2013 MP was imported and – as stated in the related MP guide – properly configured. But no matter what, nothing was discovered so nothing was monitored:

Which was a bit frustrating. So time to investigate. And – when possible – to solve the issue.

The investigation
When the Configure SharePoint Management Pack Task is run, an output will be generated within a couple of minutes, telling you exactly when certain Discoveries will be run.

And:

When I looked in the OpsMgr eventlog of those SharePoint servers, EventID 0, Source Operations Manager was logged with this description: ‘Cannot identify which SharePoint farm this server is associated with. Check the management pack guide for troubleshooting information.’

The cause
So apparently the Discoveries were fired on the SharePoint 2013 Servers, but they didn’t get very far. No Discovery = No Monitoring. Period. Time to find out why the Discoveries failed.

Soon I found this posting of much respected SCOM Guru Tim McFadden. Even though this posting is about the SAME issue with SharePoint 2010, it has many resemblances. However, there is ONE crucial difference.

In the SharePoint 2010 case the culprit was Windows Management Framework 3.0. Which isn’t really required for SharePoint 2010. So a simple removal as described in the same posting by Tim solves the issue and makes it work.

But when looking at the requirements for SharePoint Server 2013 there is the REQUIREMENT for Windows Management Framework 3.0:

So removing it won’t do. Even worse, it will most certainly break some of the functionality of SharePoint Server 2013! So that’s not the way to go!!!

None the less, the behavior is exactly the same. When trying to run SharePoint 2013 Management Shell, this error is what I got (also the same error for the account being used by the SharePoint 2013 MP): The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

How it was solved
It even got more sillier. When I went to speak with one of the super system administrators about this issue, he logged on to one of the SharePoint Server 2013 boxes, and started the SharePoint 2013 Management Shell without any issues at all! No error message! It just started!

Even though it looked like erratic behavior it showed Windows Management Framework 3.0 wasn’t the culprit here. Otherwise this system administrator would have seen the same error. So something else was at play here.

And when found, it would solve this issue. Comparing the properties of the SharePoint 2013 Management Shell between his account and mine, didn’t show any differences. So adding the switch –v2 (or –version 2 for that matter) as stated in many postings on the internet (like this one), won’t do. Also it will generate an error since SharePoint 2013 requires a higher version of PowerShell. Downgrading it will result in another failure…

Also the path variables were checked. And they matched as well. So somehow somewhere I wasn’t allowed to load that SharePoint Server 2013 PS extension. Time to zoom in on that.

BINGO!
Now I found this posting of Koen Vosters, all about the issues I bumped into. As he describes in the same posting: ‘…You have someone who has the rights to run powershell add your user as SP Shell Admin…’. In this case the system administrator who runs the SharePoint 2013 Management Shell without any issues at all.

When he run the command giving my account and the SCOM account the permissions to run SharePoint 2013 Management Shell this is what happened when I tried to run it:

Yeah! It works!!! The same for the SCOM account used by the SharePoint Server 2013 MP! Awesome!

SharePoint is being monitored now
Time to run the Configure SharePoint Management Pack Task again. And within 30 minutes the results came in:

Afterwards all the views in this MP got populated WITH a health status! Awesome!