As you said, repl topology... The issue stemmed from a dc in a remote colo sometimes getting provisioning or lookup requests. Exacerbating this was the network topology sometimes causing aborts which actually gave it away.
The mechanism to query for available ldap enabled dc's was adjusted to use the site name of interest for the srv record lookup and it's been running well for a few days. Often implementers do hardcode a single DC but that's adding a point of failure making the implementations fragile, if I can avoid I always try. Thanks, jlc From: [email protected] [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Thursday, April 17, 2014 8:28 PM To: [email protected] Subject: [NTSysADM] RE: Searching for an account attribute in a multi-site environment Sorry for the delay in responding, but in general, you want to target a SINGLE DC in a given domain for these types of creations/updates/queries. If you can't do that, you need to have knowledge of the site replication topologies. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Joseph L. Casale Sent: Monday, April 7, 2014 9:09 PM To: '[email protected]' Subject: [NTSysADM] Searching for an account attribute in a multi-site environment I have a situation in a multi-site environment where I am needing to perform some logic against an account depending on the value (if any) of the targetAddress attr. I am seeing some potential issues in corner cases where either an ldap query for the account object itself returns object not found when it was just created, or the account is found but the targetAddress attr is blank when it was populated on another dc. What metrics can I use to quantify expected delays for these two scenarios in a given environment and given the cases, how have others dealt with this in large environments? Thanks, jlc
