locked
OpsMgrLatency CN gets auto created in Domain NOT Configuration RRS feed

  • Question

  • Hi

     

    I am configuring AD Replication Monitoring and have been following the AD MP Guide. However, I noticed that I wasn't receiving any preformance overview data or any data under Replication Monitroing so I reconfigured it all again. What I found was that the OpsMgrLAtency CN was cretaed in (as viewed in Adsiedit) under the Domain not under Configuration as it describes in the AD MP Guide. So I deleted it and reconfigured the Monitoring only to see each DC recreate the CN under the domain again. Is this normal and the Guide is a typo?

    Also will I knwo have to wait 24 hours for Replication monitoring to show up? My client side monitoring seems fine.

     

     

    Sunday, May 2, 2010 10:17 PM

Answers

  • The guide is wrong.  :-(

    The domain partition is correct, and the object will be created there automatically for each DC if they have rights, upon first run of the script.

    The configuration container is used, IF this setting is enabled in the replication monitoring script parameters, via overrides.

    Ignore the guide for this section... unfortunately you will never get it working using the guide.

    Basically - if your domain controllers are running as local system default agent action account, in most cases you will not need to ever set up any replication monitoring run-as accounts.... as local system on a DC has all the rights necessary.  (in most cases).

    Next - if you override ANYTHING on ANY replication monitoring rules, you MSUT set the override the same for ALL rules which share this script datasource.  THis is not documented unfortunately... but you can find the correct information here:

    http://blogs.technet.com/jimmyharper/archive/2009/05/20/configuring-or-disabling-replication-monitoring-in-the-active-directory-management-pack.aspx

    You must set this on 14 rules.... for each OS.  It is a pain the first time, luckily you dont have to make changes to this very often.... if ever.

     

    Now - for getting performance data to show up - this is a different story.... this is collected by setting up sources and targets in groups, and the guide is pretty good here.  Just start by setting up one source and one target and see if you can get some data from those... and remember it isnt designed to collect this data from all DC's as that would be a massive flood of data every 2 minutes. 

     

    • Proposed as answer by LTHPETER Wednesday, May 5, 2010 1:52 PM
    • Marked as answer by Vivian Xing Friday, May 7, 2010 5:53 AM
    Wednesday, May 5, 2010 10:41 AM

All replies

  • Are you able to get it to work once you make the changes you described?
    Microsoft Corporation
    Monday, May 3, 2010 3:25 PM
  • Hello!

    If you followed the latest guide, you probably missed one important piece of information:
    http://social.technet.microsoft.com/Forums/en-US/operationsmanagermgmtpacks/thread/2b28b299-155b-45b0-af48-d3181fe65e99

    However, one thing that puzzles me from the older documentation is the sentence under "AD MP Account"; "This account is not needed if you are using the Action Account for ADMP operations". What is meant by "Action Account", local system?

    Are your agents (HealthService.exe) running as local system on the DC:s?
    Are you running R2?
    Have you configured a "Run As Account" for the "AD MP Account"-Run As Profile and put it in "Operations Manager Administrators"-user role, and distributed it to all DC:s and presumably also to all "AD Client Monitoring"-agents? I have myself not tested this yet, I´m awaiting some kind of clarification from PS, but this how I guess it should be done from reading the old docs, but it seems to fertilize the environment with domain admin permissions.

    I´ve also asked a similar question that you did here:
    http://social.technet.microsoft.com/Forums/en-US/operationsmanagermgmtpacks/thread/7e8a9b44-aab8-4fda-b1a1-c31a3ae1aa12

    Let´s hope somebody can shed some light on this.

    /Peter

    Wednesday, May 5, 2010 7:00 AM
  • The guide is wrong.  :-(

    The domain partition is correct, and the object will be created there automatically for each DC if they have rights, upon first run of the script.

    The configuration container is used, IF this setting is enabled in the replication monitoring script parameters, via overrides.

    Ignore the guide for this section... unfortunately you will never get it working using the guide.

    Basically - if your domain controllers are running as local system default agent action account, in most cases you will not need to ever set up any replication monitoring run-as accounts.... as local system on a DC has all the rights necessary.  (in most cases).

    Next - if you override ANYTHING on ANY replication monitoring rules, you MSUT set the override the same for ALL rules which share this script datasource.  THis is not documented unfortunately... but you can find the correct information here:

    http://blogs.technet.com/jimmyharper/archive/2009/05/20/configuring-or-disabling-replication-monitoring-in-the-active-directory-management-pack.aspx

    You must set this on 14 rules.... for each OS.  It is a pain the first time, luckily you dont have to make changes to this very often.... if ever.

     

    Now - for getting performance data to show up - this is a different story.... this is collected by setting up sources and targets in groups, and the guide is pretty good here.  Just start by setting up one source and one target and see if you can get some data from those... and remember it isnt designed to collect this data from all DC's as that would be a massive flood of data every 2 minutes. 

     

    • Proposed as answer by LTHPETER Wednesday, May 5, 2010 1:52 PM
    • Marked as answer by Vivian Xing Friday, May 7, 2010 5:53 AM
    Wednesday, May 5, 2010 10:41 AM
  • Thursday, May 13, 2010 3:40 AM
  • Kevin,

    Can you provide more information around how to configure the rules below?  There seems to be a lot of uncertainty around whether you configure this for replication from one dc to it's partner or for convergence (One side of the AD to the other).  Also do you set each of the below rules differently as their names would indicate?  for instance if it takes 45 minutes on avg for a change to get from one side of AD to the other would you set the Rule for Avg to 45, the Max to 60 and the Min to 30 for example?  Also how should you configure the 1st rule below in this scenario.  Obviously I'm using an example that these rules are supposed to be configured for convergence and not partner to partner.  The MP guide refers to convergence so I'm assuming that is correct, but I've had SCOM MVP's tell me otherwise.

    AD Replication Performance Collection - Metric Replication Latency
    AD Replication Performance Collection - Metric Replication Latency:Minimum
    AD Replication Performance Collection - Metric Replication Latency:Maximum
    AD Replication Performance Collection - Metric Replication Latency:Average

    Thank you


    Marc Schmieder
    Tuesday, June 8, 2010 1:58 PM
  • Kevin,

    Can you provide more information around how to configure the rules below?  There seems to be a lot of uncertainty around whether you configure this for replication from one dc to it's partner or for convergence (One side of the AD to the other).  Also do you set each of the below rules differently as their names would indicate?  for instance if it takes 45 minutes on avg for a change to get from one side of AD to the other would you set the Rule for Avg to 45, the Max to 60 and the Min to 30 for example?  Also how should you configure the 1st rule below in this scenario.  Obviously I'm using an example that these rules are supposed to be configured for convergence and not partner to partner.  The MP guide refers to convergence so I'm assuming that is correct, but I've had SCOM MVP's tell me otherwise.

    AD Replication Performance Collection - Metric Replication Latency
    AD Replication Performance Collection - Metric Replication Latency:Minimum
    AD Replication Performance Collection - Metric Replication Latency:Maximum
    AD Replication Performance Collection - Metric Replication Latency:Average

    Thank you


    Marc Schmieder


    Marc - you should ignore the guide - and follow Jimmy's blog I linked above.

    The blog is quite clear for the most part.

    When you have multiple workflows that use the same script datasource (14 workflows in this case) and you need to configure ANY override - the override must be placed on ALL workflows, and must be IDENTICAL for ALL workflows.  The primary reason for this is that if you dont - you will break cookdown.

    So - in summary - if you need to change ANYTHING about AD replication via overrides:

    Set the same identical override on all 14 rules.  No exceptions.

     

    For the AD performance collection specifically - the guide is correct - but this is a different issue.  This is an optional step for reporting.  In this case - follow the guide and create the groups and populate them as stated.

    Tuesday, June 8, 2010 2:53 PM
  • Thank you for responding Kevin.  I've re-read Jimmy's blog again (100th time ;^ ) ) and there are still some aspects I'm not grasping completely.  

    He mentions the following in the post's remarks:  (My questions are in-line in BOLD)

    "You'll need to take the largest latency and set that for all of them. (Does he mean all DC's in the forest or all DC's in a particular site? He was answering a quesiton about slow replication Alerts from one site)  Unfortunately, we don't have a way to set latency for replication FROM a specific DC.  Now, if replication TO a specific DC (FROM all other DCs) is different than others, you can set a high intersite latency threshold for just that DC." (This second piece seems to answer my first question, true?  So to sum up, you set the intersite replication threshold on all 14 rules to the time it takes objects to replicate across AD for most DC's and if you have a few sites that are extraordinarily slow you can increase the threshold explictly for them via additional overrides on all 14 Rules?  Am I understanding this correctly?

    Thank you again

     


    Marc Schmieder
    Friday, June 11, 2010 1:12 PM
  • "You'll need to take the largest latency and set that for all of them. (Does he mean all DC's in the forest or all DC's in a particular site? He was answering a quesiton about slow replication Alerts from one site)  

    (KH) Typically - we set this for "All Objects of Class" which means all domain controllers of that type... which would translate to your statement as "All DC's in the forest".

    Unfortunately, we don't have a way to set latency for replication FROM a specific DC.  Now, if replication TO a specific DC (FROM all other DCs) is different than others, you can set a high intersite latency threshold for just that DC." (This second piece seems to answer my first question, true?  So to sum up, you set the intersite replication threshold on all 14 rules to the time it takes objects to replicate across AD for most DC's and if you have a few sites that are extraordinarily slow you can increase the threshold explictly for them via additional overrides on all 14 Rules?  Am I understanding this correctly?

    (KH) Bingo.  :-) 

    Typically we will set the override for intersit replication across the board (All objects of class) on all 14 rules, to the WORST replication capability of the slowest DC to replicate, or, we will set it to our SLA for AD replication of that exists.  However, if this is too long due to a handful of slower DC's... then you can have different settings for different DC's... the critical thing is to make sure that if you use a custom setting for a single DC, that you make the same change for that DC on all 14 rules to not break cookdown.

    Friday, June 11, 2010 2:35 PM
  • Awesome Kevin thanks!
    Marc Schmieder
    Friday, June 11, 2010 7:25 PM
  • Hi Kevin

    I already created the container in the configuration partition (as per MP documentation) assume I can just go ahead and delete this ? and just leave the automatically created in containers in the domain partition etc ?

    thanks

    Tuesday, September 21, 2010 2:20 PM
  • Hi Kevin

    I already created the container in the configuration partition (as per MP documentation) assume I can just go ahead and delete this ? and just leave the automatically created in containers in the domain partition etc ?

    thanks


    Correct - provided your rules are not set to use it.  If they are - you will know because you will get an alert about not being able to write to it.  No worries either way.
    Tuesday, September 21, 2010 4:49 PM
  • Thanks Kevin for clarifying.
    Tuesday, September 21, 2010 10:21 PM