Active Directory (AD) Integration: When to use it and when NOT to use it and how to get rid of EventID 11463…
This posting is provided "AS IS" with no warranties, and confers no rights.
Bumped into an interesting issue some time ago but I forgot to blog about it. I was a bit too busy I guess.
At a customers site all SCOM R2 Agents were pushed from the Console. So the Agents got their configuration directly during the installation. So no need to use ADI here. And yet, ADI was in place and fully functional. At least, that is what the customer thought to be.
Normally it is like this:
SCOM Agents are pushed from the Console:
ADI will not be used, so no need to configure it.
SCOM Agents are not pushed but manually installed:
ADI can be used, but when the Agents are manually installed the configuration can be done manually as well.
SCOM Agents are not pushed but are part of a server image or pushed by a mechanism like SCCM:
Now ADI comes into play and must be configured properly.
So this customer had all the Agents pushed from the Console and ADI in place. And configuring ADI is something which needs to be done thoroughly and wisely. Otherwise a faulty SCP (Service Connection Point) is in place.
But here all was well. SCP was correctly configured even though it was never utilized. So all was just fine. Until one day a Forest was removed and the related Gateway Server as well.
ADI was neatly reconfigured so the changes were properly reflected in SCOM R2. But now errors kept popping up in the Console and in the OpsMgr event log of the RMS:
And:
Event Type: Error
Event Source: Health Service Modules
Event Category: None
Event ID: 11463
Date: xxxxxx
Time: xxxxxx
User: N/A
Computer: xxxxxxx
Description:
OperationsManager container doesnt exist in domain xxxxx.com or the Run As Account associated with the AD based agent assignment rule does not have access to the container. Please run MomADAdmin before configuring agent assignment rules and make sure the associated Run As Account is the member of the Operations Manager Administrator role.
Workflow name: CleanerOf_xxxxxx
Instance name: xxxxx
Instance ID: {724CA3B7-7D52-DD21-9E55-C2202C650EDF}
Management group: xxxxxxx
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Also EventID 11701 (Error calling ADsOpenObject in LDAP probe module) is logged:
Even though the SCOM R2 Console does not Alert upon it, this nagging Event must be taken care off as well.
But no where in the SCOM R2 Console was anything to be found about it. No more ADI was in place for the old (removed) Forest nor did the related RunAs Profile (Active Directory Based Agent Assignment Account) contain anything about this Forest. With the tool MomADAdmin was the related SCP neatly removed as well, so nothing wrong there.
Now it was time to take a further look into SCOM R2. So I exported the Default MP, made a safe copy of it and stored in a safe place. I opened the export file (not the safe copy!) in XML Notepad and searched for the entry as stated in the Workflow name, found in the description of EventID 11463:
I removed the whole Rule which takes care of EventID 11463.
Now it is time for step 2 which takes care of EventID 11701.
I searched for the entry ldap in the Default MP (be sure it matches the description in EventID 11701). At TypeID I found the entry ldap but just removing this rule is not enough: so I went to the ID of this Rule and copied it.
The whole Rule was removed and then I searched for the ID of this rule, this is what I found:
Removed the DisplayString as well.
Saved the Default MP. Imported the MP, restarted the Health Service on the RMS and the errors didn’t come back anymore.
