Something to be aware of when monitoring SharePoint, especially if you upgraded your environment from SCOM 2007 to SCOM 2012, is that you might find that your previously discovered SharePoint servers suddenly return to being Unidentified.
What appears to be missing from the SharePoint Management pack configuration guide is that in a SCOM 2012 deployment the SharePointMP.Config file needs to be present in the same location on all management servers. What seems to happen is that if the management server that executes the workflows for the configuration task does not have the config file, then the workflows undiscover the SharePoint servers, which makes them come up as unidentified again. This is due to the task being executed against the “All Management Servers” resource pool.
A symptom of the above is that when running the configuration task you find that you get this error:
Failed to create process due to error ‘0x8007010b : The directory name is invalid.’, this workflow will be unloaded
Note: This applies to monitoring SharePoint 2010 and 2013
Something that was brought to my attention by a colleague of mine the other day. When running the Most Common Alerts report in SCOM 2012, if you select more then 15 for your top N alerts then the report renders with multiple blue, red and green blocks. I then tested on my SCOM 2012 environment and discovered the same situation.
We logged a support call to MS on this one and they were able to replicate the issue in their lab environments. They have since provided us with a fixed version of the report which has been amended to render better for higher amounts of alerts.
In order to update the report follow these steps:
1. Browse to the report server manager http://server/reports
2. Open Microsoft.SystemCenter.DataWarehouse.Report.Library
3. On the drop down menu next to the report Microsoft.SystemCenter.DataWarehouse.Report.MostCommonAlerts select download and make a backup of this report
4. Then click on upload File
5. Browse to the updated .rdl file
6. Select “Overwrite items if it exists” and then click OK
7. Refresh the Reporting Pane in the SCOM console and run the report
A colleague of mine came across a situation where SCOM performance reports were not working due to corrupt performance counters on a particular server. This situation can be easily resolved by rebuilding the performance counters using the lengthly procedure outlined at http://support.microsoft.com/kb/300956/en-us
In PerfDataSource, could not resolve counter LogicalDisk, Free Megabytes, C:. Module will be unloaded.
One or more workflows were affected by this.
The short version:
On the affected server open an elevated command prompt
Navigate to c:\windows\system32
Type lodctr /R and press enter
Shortly you should see the following message:
Info: Successfully rebuilt performance counter setting from system backup store.