AD Integration Considerations
As we all know, SCOM is integrated into Active Directory, which means we have many more features available to us. Not only does this offer some security related features, like User Roles, and Run As Accounts and Profiles, but also how we configure Agents.
I wanted to take a moment to discuss some considerations before you decide to jump onto the AD Integration bandwagon, because although AD Integration does have it's place, there are a couple drawbacks and pitfalls that come into play when using this feature. Consider these points before you decide to use AD Integration. It might save you a lot of work in the long run, or you might find that AD Integration isn’t right for you.
Why do you want to use AD Integration?
The answer to this question is often times, “because I need a mechanism to assign Primary and Failover Management Servers”. That’s a fine answer, but there are other, more flexible and forgiving ways to assign Primary and Failover lists. AD Integration does add another component (moving part) to a critical piece of your implementation, and can be tricky to configure correctly. LDAP queries used for agent assignment rules in SCOM aren’t extremely flexible, like you might see in other tools. In fact, these queries can become quite complex and sometimes unreliable, especially if your naming convention is less than perfect.
One drawback to AD Integration is that it isn’t very forgiving. If you happen to make a mistake in your LDAP queries, you might find yourself in a big “fixup” project which would include removing Management Group configuration from Agents that were accidentally included in your LDAP queries. This is because AD Integration not only configures Primary and Failover Management Servers for the Agent, it will also configure a new Management Group for an Agent. This is synonymous to running the MSI package and configuring a new Management Group, or pushing a new Agent to a computer using the Discovery Wizard. The only way to fix this (or remove an undesired management group) is to modify the Agent installation by running the MSI package.
This drawback is actually one good reason why a customer should consider AD Integration. Because AD Integration can install a Management Group on an Agent, customers can “bake” the Agent package into their server images. When the server comes online for the first time with a pristine Agent installation, it queries Active Directory and is configured automatically to report to Management Group X, and also receives it’s Primary and Failover Management Servers.
If you plan to include the SCOM Agent in your server images, then AD Integration can play a key role in that process. If you do not plan to include the SCOM Agent in your server images, consider using other methods to assign Primary and Failover lists. We can assign Primary Management Server from the Administration space in the console. If you want to assign a Failover list for your Agents, Command Shell can handle that with no problem. Doing this through Command Shell is my preferred method, because it’s very flexible and forgiving.
Check Active Directory before implementing AD Integration
AD Integration leverages Active Directory by assigning permissions to certain objects. When an Agent starts up, it checks Active Directory. If it can READ these AD Integration objects in Active Directory, the Agent understands this as instructions to configure itself with that particular Management Group, and also with any Primary and Failover Management Servers participating in AD Integration. The RMS controls the writing of objects and permissions to these containers.
Think about this for a minute. If your forcing inheritance for Everyone to READ all objects at the root level in Active Directory, this will severely affect and essentially break your AD Integration functionality. If your company does explicitly force inheritance throughout the entire directory with Everyone having READ permissions (not uncommon), you must block this inheritance on the top-level AD Integration container and all child objects (this is the OperationsManager container). If you don’t do this, AD Integration will not work as designed and you will not have reliable and consistent Primary and Failover assignment for any Agents. On top of that, if you happen to have more than one Management Group, all Agents in both Management Groups will be multi-homed as well. I’ve seen this happen with more than one customer, and this causes a lot of havoc and creates a lot of cleanup work. This is part of the “unforgiving” quality of AD Integration that I mentioned earlier.
Monitoring Exchange Servers?
Exchange Server is highly dependent on Active Directory. When Exchange Server is installed, some changes are made to the directory that enable the Exchange organization to read all objects from Active Directory. This puts us in a similar situation as noted above, and will break AD Integration for Exchange Servers!
Either remove these explicit read permissions on the OperationsManager containers for Exchange Servers in your directory, or DO NOT use AD Integration for Exchange Servers.
In summary
I’m not trying to sway anyone away from using AD Integration. The message here is to be careful if you do plan to use it, and make sure you have done your homework and planned well before implementing.