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

How do I turn off UAC with group policy?

Go away UAC! Nobody likes you! When I do leave it enabled most of the time I do end up feeling like poor PC in this Mac commercial. Mac has issued a salutation cancel or allow

Well not really, I dress much nicer than PC. But in my humble opinion, until UAC capability is beefed up so administrators can whitelist process names for automatic elevation, there are plenty of cases where it needs to be turned off when weighed against legacy application and OS manageability requirements.

If you want to disable it, the best method is group policy. Here’s how you do it. Hope this helps someone.

Getting RID of duplicate objects!

A while ago, after a failed attempt to P2V a domain controller an environment I was working with was getting the following error messages when trying to delete and create AD objects.  Before we delve in, let me explain why the P2V of the DC was even done. The VMware KB outlining the best practices in regards to virtualizing domain controllers, clearly states  and I quote “VMware does not recommend converting a Windows NT domain controller if at all possible.” The reason that the attempt to virtualize the DC without standing up a fresh VM was legacy unsupported unwarrantied SSO and Biometric software that was installed and could not be modified or reinstalled on a new server. During the P2V the server was rolled back to the physical DC after the virtual one came up, because the SSO software wasn’t functioning after the migration. Let’s look at the error messages that presented afterwards. Error messages when creating user objects:

Windows cannot set the password for <Objectname> because: The requested object has a non-unique identifier and cannot be retrieved.

Windows cannot remove the newly created object automatically.  Remove it manually or contact your system administrator

Event ID 16646 The computed account identifier is not valid because it is out of the range of the current account-identifier pool belonging to this domain controller. The computed RID value is %1. Try invalidating the account identifier pool owned by this domain controller. This will make the domain controller acquire a fresh account identifier pool.

The first thing I ran was a dcdiag /V, and headed to the section highlighting the RIDmanager test. RIDs are variable length numbers that are assigned to new objects at the time of creation which helps ensure that a unique SID is created for each new object. The RID Master role is responsible for doling out pools of 500 unique RIDs to domain controllers, so that they each can create objects with unique SIDs.  RID pools are distributed by the RID Master, which is one of the FSMO (Flexible Single Master Operations) roles.

Here is a sample output of of the RidManager test when running dcdiag /V:

Starting test: RidManager
* Available RID Pool for the Domain is 61103 to 1073741823
* is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 51103 to 51602
* rIDPreviousAllocationPool is 51103 to 51602
* rIDNextRID: 51103
……………………. DC1 passed test RidManager

The bolded underlined sections show which pool is allocated, which pool was previously allocated. At first glance with the diagnostics, it appeared that all the RID pools were properly assigned unique pools of 500. Examining the event logs and finding the event ID 16646 SAMMSG_INVALID_RID was the give away. This was caused by what is called USN rollback, which microsoft has a great article on called “How to detect and recover from USN rollback“. One of the potential root causes is you guessed it, reverting to an old snapshot of a DC.

We ended up fixing the problem by running the vbscript iRIDPool.vbs included in this technet article on each of the affected DCs. The script invalidates the RID pool currently assigned to the DC and forces it to get a new one the next time an object needs to be created. Once the RID pools were invalidated, we attempted to create a new user from each of the DCs. The first create attempt failed and forced the DC to get a new RID pool. As a result, the second attempt was successful. Also, subsequent dcdiags revealed that the pools had been updated and were now using assigning from new RID pools.

The moral of the story is don’t P2V domain controllers, but if there is no way around it pay very close attention to VMware’s and Microsoft’s recommendations for the process.