There are lot of articles over Internet how to enable AD Integration for SCOM 2007 R2 but so far I haven’t found any on how to disable AD Integration. For the last couple of weeks I was faced with such task and it is not so easy as certain steps have to be followed.
The reason we had to disable AD Integration is because it was not working. Probably some rights were inherited from the root of the domain to the OperationsManager OU which led to agents being confused to which Management Server they have to connect. Because of this and various other reasons it was decided AD Integration to be disabled.
With the introduction of SCOM 2012 where RMS role is removed AD Integrations becomes more irrelevant because agents can leverage that high-availability of SCOM 2012 environment. Also it is much more easier to manage your agents trough SCOM directly. Because of these reasons I think before migrating to SCOM 2012 it is good idea to disable AD Integration if you have this feature enabled in your SCOM environment.
The steps bellow apply to SCOM 2007 R2 but as they are general steps they can also apply to 2012 also:
- As all agents are installed with AD Integration configuration they have to be reinstalled. It is best first to run uninstall command and completely remove the agent (uninstallation commands here). After complete removal of the agent it can be installed with new configuration (installation commands here). Do not forget to apply agent CU to the version your SCOM environment is. You can execute these task on all servers manually or create task sequence in SCCM and advertise it. If you have servers with System Center Service Manager roles in your environment it is best to exclude them from the collection to which you will advertise the task sequence as you know SCOM and SCSM share the same architecture. Agents on SCSM servers can be reinstalled manually. As you have SCSM service on these service not all registry keys related to SCOM agent are removed. Because of that before reinstalling the agent you have to change the value of REG DWORD key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\ConnectorManager\EnableADIntegration from 1 to 0:
After you change that key you can reinstall the SCOM agent on the server.
2. When all your agents have the new configuration the OperationsManager OU can be removed by executing the following command “MoMADAdmin.exe -d MANAGEMENT_GROU_NAME DOMAIN_NAME”. This will delete all objects under OperationsManager OU, the OU itself have to deleted manually.
3. When there is no OU any more, LDAP rules for agent distribution can also be deleted in SCOM console.
Note: If you have any agents left with the old configuration for AD Integration you probably will receive health service errors from these agents.
Now that you are in manual agent management you can take some steps to make distribution of agents among the management servers (if you have more than one) more automatic:
- First you need to make all agents remotely manageable (if all are in the same domain as SCOM), You can find how and more about this approach here.
- After all or almost of your agents are remotely manageable you can distribute them equally between two or more management servers with PowerShell script. You can find such script here.
- And finally if you want to make point 1 and 2 automatic and be applied to new agents you can create Scheduled Task in SQL Server Management Studio to run the query every day and Windows Task on the RMS server to run the script every day.
Note: Keep in mind that the solution provided for SCOM agent load balancing does not apply to all environments.
Cloud Administrator in Azure World 
Hi, Yes, AD Intergartion gets messed up when we start installing Agents on Exchange 2010 Servers.There is a fix from Microsoft for that. Once we followed their recomendations , it was fixed for us.
Also ,would like to mention that Resource Pools are NOT used for monitoring instances from Windows Agents : You cannot assign Windows agents to a resource pool, agents still communicate primary with a management server (primary/secondary set via Agent UI, PowerShell or AD integration) and not a resource pool. In other words, resource pools do not replace Active Directory integration in OM 2012.Resource Pools was introduced mainly for Unix & Network devices.
This has been verified with the Product Team.
Hi Mathew,
Thank your for the information. I think we have Exchange 2010 server in the environment but I do not know if this is the same case. May be it is. If there is such issue I think it should be described in the Technet Library or knowledge base article. All I found is this link http://blogs.technet.com/b/jonathanalmquist/archive/2010/06/14/ad-integration-considerations.aspx but the information is insufficient to me and we basically followed the guidelines – we removed AD Integration :).
About the resource pools you are completely right and thank you very much for correcting me. I will correct the article also. What i wanted to say that with the removal of RMS role we now have high-availability out of the box and agents leverage that high availability.
Thank you very much for the corrections once again.
Hi Stan, The AD integration issue is documented in KB 2592561.Maybe this was the issue n your Infra 🙂
Symptom
AD integration breaks after installing Exchange 2010 Management pack. The moment Exchange 2010 MP is installed on a server running SCOM Agent, AD integration gets broken for that Agent. The memberships in Primary and secondary groups are all showing up correctly, but just that Agent reads everything in AD and tries to connect to all the Management servers including RMS (where RMS is not even configured with AD integration)
Cause
The reason why this is happening is because when a box is installed with Exchange 2010, the machine account gets added to the following three additional Domain groups that are created.
· Exchange Trusted Subsystem (read and special)
· Exchange Servers (only special)
· Exchange Windows Permissions (only special)
And these three groups have permissions in the Domain level itself. So, it gets inherited in “OperationsManager” and subsequent Management Group containers / SCP’s. When Agent has health service running under “local system”, and when it starts up, it is able to read everything in AD under the OperationsManager container.
Hi Matthew,
Is this issue occurs only for agents that are installed on Exchange 2010 servers or to all agents in the environment.
The funny thing is that I was reading this article a couple of weeks ago but only part of it to fix some particular issue. And the task of configuring Exchange MP was never given to me 🙂
Hi Stan, The Issue was noticed & brought to our attention only on Exchange Servers. So, I cannot confirm if it was noticed on all Agents.
Hi Mathew,
We had the issue with all agents. All servers had the error in OperatiosManager event log that they see multiple servers as management servers. Probably there were some permissions that were inherited from the root OU that was causing that. I’ve tried to remove authenticated users permissions for OperationsManager OU but that didn’t helped also. I guess if we involved Microsoft Support the issue would be resolved but we just didn’t have the time to do that and honestly I prefer not to use AD Integration.
I have two management groups (07 and 2012) with ADI enabled and agents dual homed reporting into both. I am ready to decommision my 07 mgmt group and would like to stop agent from trying to communicate into that group. What is the sanctioned way (or best way) to do this? I guess momadadmin.exe -d is not the answer. Perhaps I just manually delete the container with my 07 mgmt group name that houses the SCPs? Once that is done I will delete the agent assignment rules and consider it a done deal. Would you agree?
Agree but expect alerts on your SCOM 07 as the server knows about these agents. You have to decommission also your SCOM 07 server.
Is there an easy way to disable ADI temporarily with very quick rollback? Maybe renaming the Managment Group OU created in AD under OperationsManager. I want to disable ADI but want to make sure the change will not break the existing environment. I think most of my agents are pushed from the console and should be Manual and not using ADI. End goal is to have ADI disabled but i really want a fast rollback.
Thanks
Mike
Hi,
I would not suggest to mess with AD directly. Even if your agents are pushed from the console that does not mean they are not using ADI. Make your test environment and try it there. If you will disable ADI you just need to do it from the console and momadadmin and the quick way back is to create it again .
Thanks for the reply Stanislav,
I might build a lab on a different domain and run some tests.
Thanks again 🙂
Stanislav,
If reg key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\ConnectorManager\EnableADIntegration is set to 1. so Enabled; this vaule indicates that ADI is enabled for this agent but does it automatically mean the agent is using ADI?
I found another reg key: UseActiveDirectory with a vaule of 0. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Managment Group\SCOM_MG_Name\UseActiveDirectory. If i’m reading this right the agent is enabled to use ADI but the installed agent is not using ADI and is a manual install.
Sorry to keep buging you with this i just wanted to make sure the agents are not using ADI before i turn it off.
Thanks again 🙂
Mike
Yes even if the agent is enabled for ADI that doesn’t mean it will use AD to find Management Server and Group. It will use ADI only if you have configured it trough SCOM and in AD.
No problem you are not bugging me.
Hi Stanislav,
Keith made the comment “I guess momadadmin.exe -d is not the answer. Perhaps I just manually delete the container with my 07 mgmt group name that houses the SCPs? Once that is done I will delete the agent assignment rules and consider it a done deal”
I’m just wondering why momadadmin.exe -d is not the answer and manually deleting the container is a better option. I have just moved all my agents to SCOM 2012R2 and I’m ready to disable ADI pointing to the old SCOM 2007 MG. The migration was done manually by uninstalling 2007 and then pushing 2012R2 agent. The agents do show the old MG in the Microsoft Monitoring Agent properties as Assignment: AD but only because the ADI is configured for the old MG. In SCOM 2007 all the agents are in Pending Management. I just want to disable the ADI and not use this feature in SCOM 2012R2. Should i use the MOMADADMIN or just simply delete the container and remove the query?
Thanks,
Mike
Hi Mike,
I would use momadadmin.exe -d as this is the tool Microsoft created for these situations but deleting manually will not cause harm also since you’ve already migrated all your agents.