We are running SCOM 2012 SP1 and 2016 dual-homed with AD MP Version 6.0.8321.0 for Server 2008 and above, and version 10.0.0.0 for 2016. Receiving “AD Replication is occurring slowly” alerts for 3 of our DC’s (92 total), repeat count increases by 3-4 every 1-2 minutes. All three are running Windows 2012 R2 Standard, AD, DNS, and Are GC’s. Followed this article to increase max latency to 60 (from 15) for the environment:
https://blogs.technet.microsoft.com/jimmyharper/2009/05/20/configuring-or-disabling-replication-monitoring-in-the-active-directory-management-pack/
Found the pattern of AD Object attribute adminDescription in OpsMgrLatencyMonitors for each of these DC’s had not updated as does the rest of the environment. This was checked on the three DC’s local copy of the directory. For instance, DC03 and DC04 from the same site, same subnet, one updates adminDescription, one does not. It seems the part of the script which is supposed to update this Object in AD every 6th run (according to the above referenced article) is not doing so. DC03 updates ok, DC04 does not . Both agents are running as Local System, both are dual-homed, running agent v 8.0.10918.0., both in a healthy state. Alerting DC’s alert in both 2012 SP1 and 2016 environments.
Is there a way to 1) assure that the AD replication scripts are running,and if not, why, 2) If the script is running, why is it not updating the attribute adminDescription? and, 3) How do I figure out which DC object in the local directory copy is triggering the slow replication during the running of the script?
Peter C
Hi Peter,
Has the OOMADs components being install on the DC’s too. There are some things that don’t run properly on DC’s without it.
http://www.systemcenterrocks.com/2016/05/manually-install-oomads-on-domain.html
Richard
you will also find that this is an issue in mixed environments. Primarily as it depends where the agent looks for oomads being installed which is different depending on whether it is installed in C:\Program Files\System Center Operations Manager or C:\Program Files\Microsoft Monitoring Agent. I have witnessed this occurring in an environment recently where it is mixed 2007 R2 and 2016. All upgraded agents have this issue in 2007 but not in 2016 alerting.
Richard, thank you for your response. Yes, the OOMAD components are installed on all the DC agents.
Updates: Microsoft Premier has now been engaged. I worked with one of the DC’s particularly that was not updating the AD object record. After removing dual-home, resetting the Agent, and even deleting the AD object under OpsMgrLatencyMonitors, problem still persisted. The object was never recreated by the agent, as described should be the case. As a (next-to) last resort, I removed the agent and all remnants in SCOM to this agent, and of SCOM on the DC. Rebooted the DC, waited 24 hours, and rediscovered the agent. After about 45 minutes, the AD object was recreated, and alerts stopped for this agent. Problem solved.
As the last, last resort, I engaged MS to address this issue on the remaining DC’s, and to figure out what happened / root cause, as well as to address some other issues with PS scripts failing. They (MS) also pointed me to the jimmy harper blog (above) about these scripts… and found a Holman blog entry that said that ANY override must be the same across ALL of the monitors for it to be effective:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/2a0e5a2b-a3d9-42d4-8474-9f690007caa0/opsmgrlatency-cn-gets-auto-created-in-domain-not-configuration?forum=operationsmanagermgmtpacks
(This was written in 2010 - I haven’t checked the guide to see if it has been fixed).
These 14 monitors have now been uniformly altered with a max expected latency of 60 (minutes), and a frequency of 1800 (seconds); and three of the noisiest and duplicate PS scripts have been disabled. We now have significantly less noise, but the original symptom is still there. Now Giving it 24 hours to churn, and will re-address tomorrow. Trying to avoid total - nuke of the agents (as was done on DC #1), hoping to find and understand the actual issue behind the alerts. Will report how it goes, and what MS says may be the underlying issue.