+1
Completed
Preferred DC list for AD agents
The native AD MA for the FIM Sync service has long had an optional configuration section for preferred DCs, so that administrators can nominate an ordered list of preferred DCs to connect to for imports/exports. When this is used with Event Broker, especially in forests where there are delays in AD replication between DCs, the result can be that Event Broker detects a change before it is replicated to the DC from which FIM is connecting. This generally results in a missed change.
A feature to configure the AD agent exactly in line with that in the corresponding AD MA is suggested here.
Customer support service by UserEcho
Thanks Bob, it's on our backlog (VSTS), it just never got prioritised. Could you explain how it'd work in a little more detail? Are we talking about the AD check changes operation? What is the trigger for attempting the operation on a different connection? An exception, a timeout, not finding a change?
Thanks.
Yes the AD check changes operation is the one Adam. As with FIM, the trigger is a failed connection on either error or timeout - not finding a change should count as a success. The reason this came up is because @CSODBB the list of preferred DCs had remained misconfigured for a long time after several DCs were decommissioned. See attached
I just remembered that uSNChanged isn't replicated, so this won't work nicely for AD Changes operation. We could have it store different values, but then it'd always trigger a change if any of the servers can't be connected to. AD Sync changes should work as I believe the mechanism is replicated.
Yes that's correct about the replication issue - this would be for the AD Sync changes mechanism I always use wherever I can now. However this will STILL be of benefit in AD Changes operation too ... simply aligning the FIM AD MA with Event Broker will mean both FIM and Event Broker are reading the same uSNChanged value 99/100. And if Event Broker fails to connect and flicks to the second in the list, so should FIM right?
Thanks, I'll update the details on the issue and increase the priority.
Just adding that now for QBE this problem is very real, and such a feature would drastically improve the solution IMHO.
Consider the listen operation on fail:
Other related exceptions written to the EvB logs: