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: 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

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 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. image
  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.

SCOM 2012 Powershell Script to Backup Unsealed Management Packs

Sure there’s plenty out there already. But my does it out of the box. Run it from wherever on the management server and it will create a folder called C:\UnsealedBackup\<date> and dump the unsealed management packs in there. Nice and neat, run it every day after you eat your Wheaties. Or just schedule it with Task Scheduler. But either way, Wheaties are tasty.

# Written by J. Clarke to automated the backup of unsealed management packs.
# Version 1.0
Import-Module OperationsManager
$Date = Get-Date -Format “yyyy-MM-dd”
$TodaysFolder = “C:\UnsealedBackup\” + $Date
New-Item $TodaysFolder -type directory -force
Get-SCOMManagementPack | where {$_.Sealed -eq $false} | export-SCOMmanagementpack -path $TodaysFolder

SCOM 2012 AD integration not populating in AD

So I’ve got a little SCOM 2012 lab. One DC, two database servers, four management servers, one Exchange 2010 and one soon to be SharePoint 2010 server.

The summary of what I was experiencing was that when I configured AD integration using the wizard in the SCOM console, nothing was populated into AD even an hour later, and no manually installed agents are automatically assigned as a result, even after properly using the Mom AD Admin EXE to prepare active directory.

The end result was the client can’t find a policy in AD as shown below.

Event 2011: The Health Service did not find any policy in Active Directory


In active directory users and computers, none of my management servers were populating underneath the Operations Management \ Mario, and each of them should have their own corresponding containers and AD groups if all is working properly.


I tried several things with no luck:

  1. Verifying I had properly run the MOMADAdmin.exe with the proper switches: MOMADAdmin.exe <ManagementGroupName> <MOMAdminSecurityGroup> < RunAsAccount> <Domain>
  2. Completely loosening permissions on the OperationsManager container and child objects (Sidebar: NEVER EVER DO THIS, read this article to see why)
  3. Selecting a different runas account and profile ensure full domain admin rights
  4. Restarting client agents, servers and DCs
  5. Verified my LDAP inclusion query was valid by using Active Directory Users and Computers advanced search
  6. Telling my laptop “You look fat compared to the new macbooks” to hurt its feelings.

None of the above worked. After letting it bake overnight, a call with Microsoft the following morning and a refresh of ADUC indeed verified that you should plan on waiting at least 24 hours for that to be updated in AD with 2012, a change from 1 hour since 2007. When I came in the next morning, everything was working as shown below. You can look for the operations manager event 11470 on the management servers to verify successful publishing to AD.


Here are some good articles on AD integration with SCOM as a bonus. Hooray for bonuses!

AD Integration Considerations– My quick summary of this article is: don’t use AD integration unless you’re really sure you need to. Why not just use the command line if you’re going to bake it into your base images? Really the only time you need this is if you have multiple separate management groups in the same large domain.

Integrating Active Directory and Operations Manager

Understanding How AD Integration Works with OpsMgr 2007