locked
OpsMgrLatencyMonitors and the ADMP RRS feed

  • Question

  • Can't seem to find a solid answer on replication monitor settings for the ADMP version 6.0.6542. I followed the instructions in the guide, but still receiving script errors saying access denied when trying to create DC objects in the opsmgrlatencymonitors container.       Here's our config:  

    - We have a legacy AD forest where SCOM resides. 
    - We recently added a brand new 2008 DC only forest and have forest trusts with the legacy forest.
    - I want to monitor AD replication in the new 2008 forest, so I created a new replication monitoring account in the new forest, as well as a runas profile for this account, and assigned it to all the new 2008 DC's.    Additionally, all of the new DC's have proxy security settings. 
    - This is not a domain admin account, so I granted this account access "full control" access to the opsmgrlatencymonitors container in the default naming context, and selected "All child objects".   However, I get access denied script errors on each DC.   
    - I'm also getting access denied script errors accessing a opsmgrlatencymonitors  in the Forestdnszones partition, but no such container exists in this partition.  

    So My questions are as follows:
    - Should the AD MP account run as a credentialed account, or as built-in system?      The MP guide says credentials, but many forum postings say to use system.
    - In which naming contexts should the opsmgrlatencymonitors container exist?       default,  forestdnszones, and domaindnszones?  
    - Do I need to be an enterprise admin to initially create these containers, and should I even have to create them manually, or should they be getting created by the SCOM agent?   

    Thanks,
    Scott...

    Friday, December 18, 2009 8:28 PM

Answers

  • I got approval to temporarily add our AD MP account to the enterprise admins group.   Once I did this, several DC's were reporting errors creating the opsmgrlatecymonitors container because it already existed.    So I think the problem may have been that this container was manually created.    I used adsiedit to remove the container from default naming context and this allowed the fully-priveleged agent to initially create, and then populate the container with dc-specific subfolders.        Once it was created, we adjusted the security permissions on the top-level latency container to allow full control to the MP runas account, and then removed the account from the enterprise admins group.      So a couple lessons here:

    - If you decide to use a credentialed runas account (as the MP guide suggests), then temporarily add the account to the enterprise admins group to allow it to create all the structure necessary.  
    - Then selectively add an individual ACL to the latency container object for the runas account, and make sure you grant the right to modify all child objects and not just the top-level latency container. 
    - Note that this container gets created in three differenct naming contexts - default,  forestdnszones, and domaindnszones.   So you must modify permissions in all three container objects using ADSIEdit.  

    Tuesday, December 29, 2009 4:52 PM

All replies

  • Hi,
    I try to use local system as action account on domain controllers, that normally works fine, as it is the dc computer account then running all testa. I dont create that container either, it is automatically created.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Friday, December 18, 2009 9:52 PM
  • do you have a forest trust between the 2 forest you have? if you don't not everything will work, but i am still figuring out what does and what doesn't :)
    did you install oomads?
    Rob Korving
    http://jama00.wordpress.com/
    Monday, December 21, 2009 4:27 PM
  • Hi Rob,
    Yes we have a forest trust and it's working.      I did not manually try to install ooamds because it's supposed to be installed automatically (i.e the MP guide makes no mention of having to install this manually).     This is one of my problems with this pack, specifically in a 2008 environment - not enough clarity on what has to be configured manually and what is supposed to be automatic.

    The base agent on these boxes IS using the built-in system account, however,  per the MP guide, we setup a special account for replication monitoring.      I'm sure it would be easier if I just made this AD MP account a domain admin, but unfortunately I can't for security reasons.  

    Please let me know if you have any additional recommendations. 
    Monday, December 21, 2009 9:57 PM
  • I got approval to temporarily add our AD MP account to the enterprise admins group.   Once I did this, several DC's were reporting errors creating the opsmgrlatecymonitors container because it already existed.    So I think the problem may have been that this container was manually created.    I used adsiedit to remove the container from default naming context and this allowed the fully-priveleged agent to initially create, and then populate the container with dc-specific subfolders.        Once it was created, we adjusted the security permissions on the top-level latency container to allow full control to the MP runas account, and then removed the account from the enterprise admins group.      So a couple lessons here:

    - If you decide to use a credentialed runas account (as the MP guide suggests), then temporarily add the account to the enterprise admins group to allow it to create all the structure necessary.  
    - Then selectively add an individual ACL to the latency container object for the runas account, and make sure you grant the right to modify all child objects and not just the top-level latency container. 
    - Note that this container gets created in three differenct naming contexts - default,  forestdnszones, and domaindnszones.   So you must modify permissions in all three container objects using ADSIEdit.  

    Tuesday, December 29, 2009 4:52 PM