The directory name is invalid SharePoint 2010 Management Pack on SCOM 2012

I was recently on a project to configure SCOM 2012, and ran into some interesting hurdles with the SharePoint 2010 management pack on SCOM 2012.

We downloaded the latest SharePoint 2010 management pack from the online catalog and followed the documentation to the letter, of course it was for SCOM 2007, so I took the documentation with a grain of salt. I would later find out that the correct document to follow for configuring the SharePoint Management Pack on SCOM is actually here: http://support.microsoft.com/kb/2690744. The SharePoint management pack for SCOM 2007 was version 14.0.4744.1000. It was this error that started my troubleshooting:

Configure SharePoint Management Pack Failed

Failed to create process due to error ‘0x8007010b : The directory name is invalid.’, this workflow will be unloaded.

The short version with this error is that you need to use an updated management pack that isn’t currently publically available from Microsoft, I gleaned this from the above article titled Configuring the Sharepoint 2010 Management Pack in scenario 5. I wasn’t receiving the exact error described there, but it was darn close enough for a call to Microsoft to at least try this new management pack; especially because I couldn’t find that AdminTask.ps1 script file anywhere on the entire server. The new management pack that I imported was delivered to me in a zip file and only contained the MP named Microsoft.SharePoint.Foundation.2010.SCOM2012.mp.

As a note of hindsight, before importing this new management pack, I would recommend completely removing the Sharepoint 2010 management packs for SCOM 2007, because I ended up having to do that later as a part of troubleshooting the configuration process.

Now this process below isn’t exactly what happened in the scenario I was working on, but the next time I have to deploy this management pack this is exactly what I’m going to do to prepare the environment. 

1. Create an new active directory account to be used as the monitoring/discovery account specific to SharePoint only.
   1. Make sure to set this account to be distributed to all computers or be prepared to turn off the distributed credential alarm, as this account is used to discover and monitor SharePoint servers, and if it’s not distributed the discovery will fail and alert critical (if defaults are configured) on all servers making it a really loud day if you subscribe to all critical alerts.
2. You need to add this AD account as a local administrator of every app, web and server involved in the SharePoint farm.
3. This account must have db_owner privileges on every database that is involved with the SharePoint setup, either content or configuration.
4. This account must be added to the farm administrators role within the SharePoint Central Administration Site
5. Import the Microsoft.Sharepoint.Foundation.2010.SCOM2012.mp. management pack.  
6. Once the management pack is imported, the account, the account created earlier must be added to the “SharePoint Discovery/Monitoring Account” runas profile.
7. The SharepointMP.config file must be properly modified and placed on the Management Server
   1. You can find this config file after installing the “Sharepoint Microsoft SharePoint 2010 Products OpsMgr 2007 MP en-us.msi” and browsing under the install directory for it.
   2. You should ONLY modify this config file make new lines at or after line 22 of this document, where you should enter the short names of the web and application servers in the sharepoint farm. The association account should NOT be the display name of the account, it should be the runas group that was automatically created when the MP was imported.
   3. You should place this modified file AND the .mp file under the directory %ProgramFiles%\System Center Management Packs on the RMS emulator role management server. The reason I did this on the RMS emulator was because this is the recommendation in the 2007 MP guidelines, I have no proof that it needs or doesn’t need to be on that one, it just seemed logical. The documentation also doesn’t say that the MP file needs to be in that directory, but Microsoft had me copy it there when troubleshooting, so I’ll make sure to do that in the future.
   4. 
8. Finally, once you have all this groundwork laid you can go to the administration node of the SharePoint 2010 management Pack and look at the tasks pane. If you have the new 2012 management pack imported, you’ll notice that there’s a new task available called “Configure Sharepoint Management Pack (2012)”. Run this task, and if you’ve done the above it “should” work.

Bonus information about my experience:

* The first time we ran the new task 2012 configuration task we were not successful. After removing the old management packs and ensuring proper permissions were in place the task ran successfully, and the discovery and monitoring were successfully carried out. Also, I had changed the name of the association account in the SharepointMP.config in line 21 to the display name of the Sharepoint action account, which is incorrect. Leave that dang line alone in this config and simply add the account to the runas profile that is created on import.

* We ended up adding the discovery/monitoring account as a sysadmin on the database as well as a part of troubleshooting, but we did that before we realized that the discovery/monitoring account was missing admin rights on the Sharepoint application server, so it is not likely required that the discovery/monitoring account requires sysadmin privileges.

* Microsoft recommended we restart the management servers after importing the MP and running the configure task to aid with the discovery process.

* If you notice that the SQL monitors within the Sharepoint 2010 management pack are not monitored, this is because the exact same monitors are already covered by the SQL management pack. To enable the ones in the Sharepoint MP you would need to disable the SQL management pack on those servers first.