Active Directory Integration (ADI) Notes From The Field

Bumped into some Active Directory Integration (ADI) issues at a customers location some time ago. These issues resulted in non-functional SCOM Agents when the primary SCOM Management Server broke down, simply because the SCOM Agents couldn’t fail over to the secondary SCOM Management Server.

And of course were all these Windows servers production critical, so monitoring of those very same Windows servers was key.

After some investigation it turned out ADI wasn’t in place at all, it only seemed like it. And because the primary Management Server never failed before, the customer never noticed it. Until the primary Management Server became corrupted and went offline for many days. Now their most business critical servers became unmonitored simply because ADI was only partially in place causing the Windows servers being unable to fail over to the secondary SCOM Management Server.

Since ADI isn’t magic at all but requires some serious attention in order to get it up and running AND some mistakes seem to be common, I have decided to write this posting. There is much to share so let’s start.

First of all, what’s ADI and why use it?
ADI is a mechanism which uses Active Directory as a location to store configuration information for SCOM Agents which aren’t ‘pushed’ from the SCOM Console. ADI uses a Service Connection Point (SCP) which stores the information like the name of the SCOM Management Group, the primary SCOM Management Server and the failover Management Server.

For a more detailed description how ADI works read this posting written by Steve Rachui. Even though the posting is based on SCOM 2007 R2, it’s still valid for OM12 (SP1). Satya Vel also wrote a good posting about ADI, to be found here. Together these postings share a good deal of information about ADI so no need for me to repeat it here .

Common ADI Mistake 01
Only the MomADadmin.exe tool is run. But this tool is only ONE step of the whole process of configuring ADI in a proper manner. Actually, configuring ADI doesn’t start by running this tool, nor does it end with running this tool. So RTFM is key here, as described in detail in Steve Rachui’s previous mentioned blog posting.

Common ADI Mistake 02
For a whole configuration of ADI additional steps in the SCOM Console are required as well, so don’t forget them:

It might sound like: ‘Doh! I knew that already!’ but you would be surprised how many times I have seen people forgetting this step.

Common ADI Mistake 03
AD isn’t checked for the presence of the ADI container after the tool MomADadmin.exe is run. Even though this is a simple process (Check Yourself Before You Wreck Yourself). Simply open ADUC and check for the presence of the ADI container, named OperationsManager. Don’t forget to enable the Advanced Features (View > Advanced Features) or the ADI container will never be shown…

Common ADI Mistake 04
Misconfiguring the SCOM Agent. Suppose you run Citrix servers, based on a ‘golden’ image and these servers are spawned every morning brand new. The golden image contains a SCOM Agent, manually installed. So far so good since this kind of servers are really good ADI customers.

But when installing the SCOM Agent, please make the right choice when entering the Management Group Configuration screen.

This is the WRONG choice when manually installing a SCOM Agent which must use ADI:
Selecting the option Specify Management Group information:

As a result a SCOM Agent installed like this will use the information provided by the user instead using ADI and without any further configuration, FAIL to failover to a secondary SCOM Management Server when the primary SCOM Management Server becomes unavailable.

This is the CORRECT choice when installing a SCOM Agent which must ADI:
Deselecting the option Specify Management Group information:

As a result the SCOM Agent will connect with the Active Directory SCP in order to get all the required information, thus this SCOM Agent will use ADI. Mind you, the option Use Management Group information from Active Directory will stay greyed out. This is normal! Simply click Next and the SCOM Agent will be installed with the ADI option enabled.

Common ADI Mistake 05
ADI isn’t tested! This is really too bad since NEVER EVER ASSUME, ALWAYS ASK & TEST! This prevents a lot of unwanted and unnecessary situations.

So when you think ADI is in place and fully configured, SIMPLY test it. Spawn a server with the SCOM Agent configured with ADI and look what it does. Does it connect to AD in order to obtain a configuration?

Do you EventID 2019 happening in the OpsMgr eventlog?

And how about EventID 20062 (telling ADI is enabled)?

And does the SCOM Agent really work? Does is get a health status in SCOM? Are the MPs received and processed?

Another thing to test: Failover. When the primary Management Server goes offline, does the SCOM Agent failover to the secondary SCOM Management Server?

Of course, test this outside production hours but TEST it none the less. This way you’re sure the SCOM Agent is ADI enabled AND ADI works as intended.