Event Broker 2.2 uses uSNChanged which is not replicated between DCs. When the preferred Domain Controller was changed recently, Event Broker retained the uSNChanged from its previous DC, as a result it has not been able to detect changes properly.
I logged into Event Broker,
Active Directory -> Incoming -> Highlight Run Profile Active Directory.Delta Import and Delta Synchronization, On Failure=Fail
Click Edit check operation
Select Reset Highest Committed, and click Go
Click OK
Click Save
Active Directory -> Incoming -> Highlight Commit AD Changes Plugin, On Failure=Fail
Click Edit check operation
Select Reset Highest Committed, and click Go
Click OK
Click Save
This should reset uSNChanged for new DC. This issue is not present in EvB 3 as it uses a different mechanism for tracking changes.
Hi Pat, Bob advised me to do the tasks documented in the issue. It didn't appear to work however. Perhaps I didn't do it correctly. Do you have this fix documented anywhere? Bob mentioned a PDF, but didnt know the location.
Our v2.2 documentation is located here. I can't find any reference to this problem, did Bob indicated it's a fairly well known issue? Adam has suggested to me it might be worth looking at the current uSNChanged value stored in the database - it should reset after the "Reset Highest Committed" command be updated after the next commit operation.
Also, EvB3 still uses this mechanism as well, it just has a second, alternate option (with its own 'downsides').
Updated the AD Changes Plugin in EvB so that it only detects changes in users and groups as that is the only objects that FIM runs syncs against. Also, the plugin now points to same DC as the AD MA, Reset the highest committed so that USNChanges are inline with the new DC and ran a Full import on the AD MA to ensure no changes have been missed.
I would expect to see a delta imports and syncs on the AD MA at very regular intervals during normal operations as changes will occur to users and groups during normal operations.
I also can't find any documentation for it, and given that the Path field seems to cover the same thing I suspect it's probably not even used. Do you know how it came to be in your config in the first place?
Regarding multiples, I can't imagine either would support it.
That's as (un)helpful as I can be until Matt Clark comes back from leave unfortunately.
Bugs
Event Broker 2.2 uses uSNChanged which is not replicated between DCs. When the preferred Domain Controller was changed recently, Event Broker retained the uSNChanged from its previous DC, as a result it has not been able to detect changes properly.
I logged into Event Broker,
Active Directory -> Incoming -> Highlight Run Profile Active Directory.Delta Import and Delta Synchronization, On Failure=Fail
Click Edit check operation
Select Reset Highest Committed, and click Go
Click OK
Click Save
Active Directory -> Incoming -> Highlight Commit AD Changes Plugin, On Failure=Fail
Click Edit check operation
Select Reset Highest Committed, and click Go
Click OK
Click Save
This should reset uSNChanged for new DC. This issue is not present in EvB 3 as it uses a different mechanism for tracking changes.
Found issue still occurring. ran through reset procedure again.
Hi Pat, Bob advised me to do the tasks documented in the issue. It didn't appear to work however. Perhaps I didn't do it correctly. Do you have this fix documented anywhere? Bob mentioned a PDF, but didnt know the location.
Hi Matthew,
Our v2.2 documentation is located here. I can't find any reference to this problem, did Bob indicated it's a fairly well known issue? Adam has suggested to me it might be worth looking at the current uSNChanged value stored in the database - it should reset after the "Reset Highest Committed" command be updated after the next commit operation.
Also, EvB3 still uses this mechanism as well, it just has a second, alternate option (with its own 'downsides').
Updated the AD Changes Plugin in EvB so that it only detects changes in users and groups as that is the only objects that FIM runs syncs against. Also, the plugin now points to same DC as the AD MA, Reset the highest committed so that USNChanges are inline with the new DC and ran a Full import on the AD MA to ensure no changes have been missed.
I would expect to see a delta imports and syncs on the AD MA at very regular intervals during normal operations as changes will occur to users and groups during normal operations.
Hi Patrick,
Is OUName a valid node in the EvB2 configuration? It is not mentioned in the EvB configuration docs.
If it is valid can it contain multiple values?
I also can't find any documentation for it, and given that the Path field seems to cover the same thing I suspect it's probably not even used. Do you know how it came to be in your config in the first place?
Regarding multiples, I can't imagine either would support it.
That's as (un)helpful as I can be until Matt Clark comes back from leave unfortunately.
Installed EvB 3.