Link to home
Start Free TrialLog in
Avatar of alexr54
alexr54Flag for United States of America

asked on

SCOM 2007 R2 AD MP, Replication monitoring denied!

For the life of me i can not figure this out.

I have SCOM 2007 r2, which is monitoring AD replication across forests. On the local forest where the RMS sits, the AD MP makes the container needed and works fine, now on the other forest, i created ad accounts with domain admin rights on each domain in the forest, and from those made run as accounts in SCOM.

What can i do go get this working across forests? Sorry if my desription is breif and not very well oriented, i am in a bit of a rush and very frustrsted.

If any better information can help, please let me know and i will provide all i can.

thanks


Avatar of Rich Weissler
Rich Weissler

Double check distribution of the Run As Account?
  (In SCOM, Administration Section, Run As Configuration, Accounts.
   Select the account you created in the other domain, and select properties... and the last tab is Distribution... if you are using the 'more secure' setting... you might have to specify which servers to distribute the credentials.)

And I don't use my SCOM across forest or domain boundaries, so I'm looking at the Profiles area, right below Accounts, and confirming that it where I'd configure which account to use for different groups of servers.  I'm sure you already have all that set-up.
Avatar of alexr54

ASKER

I will try to be a bit more specific.

This is my domain structure:
Forest1
domain1
domain2
__________
Forest2
domain1
domain2

SCOM is installed on a server on domain1 in forest1. SCOM agents are deployed to all domains in all forests.

The error i am seeing is:
AD Replication Monitoring : encountered a permissions error.
The script failed to create the OpsMgrLatencyMonitors container in the naming context 'DC=ForestDnsZones,DC=forest2,DC=com' because access was denied. Alter the permissions for this naming context so that the script can add this container, or change the parameters for this script to stop monitoring this naming context.

I see OpsMgrLatencyMonitors container in all domains and in forest1, it has not populated in forest2.
Also in the OpsMgrLatencyMonitors container in forest2's domain1 and domain2, there are no objects created. While in forest1'd domains there are.

Avatar of alexr54

ASKER

Double check distribution of the Run As Account?
  (In SCOM, Administration Section, Run As Configuration, Accounts.
   Select the account you created in the other domain, and select properties... and the last tab is Distribution... if you are using the 'more secure' setting... you might have to specify which servers to distribute the credentials.)
.

I do not think this applies to my issue.
Okay, if you've already correctly configured the run-as accounts...

... I assume there is already a two-way transitive trust between the forests?
... confirm that the action account in the second forest has permission to create the OpsMgrLatencyMonitor containers.  (If you don't want to grant the account Enterprise Admin permissions in that forest, page 36 of the management pack documentation has manual instructions for creating the necessary objects.)
Avatar of alexr54

ASKER

This is the first time i am doing such a deployment of SCOM 2007 R2. So for me to say i am sure i did all the RUN-AS accounts correctly, i would be lying.

I made the Run As accounts and whichever domain the server is on, i made sure to add this server to the explicitly allowed section in the Run AS user profile for that domain.

The containers are made automatically on both forests, in the container lies sub containers of all DC server names in that forest. On forest 2 nothing is being populated within the containers, (no user or computer accounts), just empty containers.

As far as the Run As users go, i made all of them 'More Secure', this is the only way forest 2 will not use the wrong account for auth.
What do you mean the action acount? See this is really what confuses me... The AD MP Action account? The Run As Profiles for AD are all set to local account.
I need to stop banging my head.. this is driving me insane!

Thank for your help on this!
Avatar of alexr54

ASKER

As far as the trusts go, the security team has confirmed that there is a 2 way trust between these forests. One forest is on a 2008 domain the other is on a 2003 if that makes any difference.

The 2003 domain is forest 2. I have numerous MP's going across domains beyond the AD MP. The AD MP is the only troublesome one when it comes to access.
ASKER CERTIFIED SOLUTION
Avatar of Rich Weissler
Rich Weissler

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of alexr54

ASKER

Is there a way to see which account is failing? So i know what account the AD MP is trying to use for auth for AD monitoring?

The errors are so generic, it only makes this more confusing.
I'm not in front of a system now... but I'd look at the event viewer on your DCs in the other Forest.  If your environment looks like mine, the security event log is huge and it'll be challenging to find any entries in there -- but there is a separate Operations Manager log.  (It'll be broken out separately in Windows 2008, under an Applications category.)

(Unfortunately I don't ever remember seeing a helpful log in the System Center directory under Program Files.  :-( )
Avatar of alexr54

ASKER

I did notice on one of the DC's an error number 67 in the logs. I am not in front of it right now either. Not until tomorrow AM.

That log again, is generic. Just states what I already know, access was denied for replication monitoring from SCOM. No user ID.. nothing...

If i could somehow tell which Run As user SCOM is attempting to authenticate with, then i can troubleshoot the issue better. Now knowing what each Run As account or each Run As profile is doing exactly is a mess.
Avatar of alexr54

ASKER

anything?
Obviously what account it should be using is what would be pushed to it as the AD MP Action account as part of the More Secure setting.  The only way I know to double check what it's actually using is to correlate the time on the events that appear in the SCOM logs for the failed event against the security log.