Active Directory Changes operation return False

This is the ADDS where user being modified, in the container OU=Users,OU=AHG,OU=chris21,OU=Lab,DC=FIM,DC=UNS,DC=COM which is below the OU=Lab,DC=FIM,DC=UNS,DC=COM container.

I know you're busy with the tree stuff but can you take a look at this when you get a chance.

Shane,

I appreciate all the effort you've gone in to testing Event Broker like this, as well as the information you've provided here. Two things to check:

• Is the operation returning false the only thing in the logs?
• What is the change in Active Directory that has been made that you are expecting? For example, if you have deleted objects I believe you may also need to add a tombstone filter if you're using the AD Changes operation.

Hi Matthew,

The log I provided are the one that is relevant to ADDS Agent and Op List. There is no error or warning log in the Event Broker.

The change that I made was modifying the "DisplayName" value.

Regards,

Shane L

Pass back to Matthew with response.

Shane,

I've attempted to replicate this problem as best I can, but have been unsuccessful. I did the following:

• Added a new operation list with an AD Changes, run profile, and AD Commit operation
• Pointed the AD Changes operation at a local OU
• Update a few display names
• Each change was successfully picked up by the operation as it happened
• Created a new OU inside the target OU of the operation
• Created a new user in the OU
• Event Broker detected the change and ran the import
• Updated user information
• Change successfully detected

As such, I have been unable to reproduce the issue using seemingly the exact same scenario.

A few other things to check:

• The primary DC is the target and has not changed - targeting different DCs can produce different results with this mechanism of checking for changes
• Check the USN change attribute of the AD instance, to see if changing the display name is incrementing this value (if not, there is no change to detect). You could also try updating any other field and seeing if the change is detected
• Verify the account used in your AD Agent has sufficient permission to access the AD instance

I'd be available to arrange a LiveMeeting to have a closer look and try to work out what is happening. Let me know when you would be available to discuss this

Hi Matthew,

Now is most timely, since I have just boot up the VM.

I'll send out the invite in a tick.

Thanks!

During Live Meeting session with Matthew we did the following tests and observation:

• Confirm that the AD Changes Check Operation's filter is set as "(objectCategory=*)"
• Making changes to a few user and fields and observed the that uSNChanged number did increase
• The AD Check Operation still returning "False".

We then clear out the AD Changes Check Operation Filter by setting it to blank (empty). The default filter is generated as "(&(objectClass=user)(objectCategory=person))".

• After this change the AD Changes Check Operation return "True", as expected when there is a change in AD.
• Further manually modified this filter to "(objectCategory=*)" also return "True" when there is a change in AD.

We are not certain why clearing the Filter seem to resolve this issue.
Matthew suggest that may have something to do with when I am uninstalling the older version of Event Broker v3.0.0.1 and install the new version v3.0.0.2 it picked up the old settings which may caused this issue.

Matthew, mentioned that he may need to investigate the upgrade scenario further to see whether this is an upgrade related issue.

Thanks Matthew for your help.

As an addendum to Shane's comment above:

• The usnChanged attribute for users was successfully being updated following changes, but changes anywhere inside the OU (whether in a lower level OU or in the root OU) were not being picked up
• Clearing the LDAP filter and attempting to detect changes ran successfully
• The operation list was also manually executed at some stage in testing changes
• On the issue of upgrade, it may be that Event Broker was still looking at either an old, or no longer existent, value for the latest USN changed value. The internal stored values collection used by Event Broker may or may not have been cleared, and this may have prevented the operation from refreshing following an update, possibly until the operation list was manually instigated

A few more checks remain to try to replicate the issue, otherwise we'll have to wait and see if it occurs elsewhere:

• Uninstalling/reinstalling Event Broker and seeing if pre-configured Active Directory operations execute following this
• Removing the stored values collection and observing Event Broker behaviour
• Checking for any potential changes between Alpha 2 and Beta 1 that may have had any effect

I have been unable to reproduce this error given a number of attempts.

Clearing the internal stored values collection did not prevent Event Broker from operating. Reinstalling the Event Broker service also did not prevent operation from occurring, and from changes being detected.

Issues with EB-293 prevented the Active Directory operations from functioning correctly in the alpha releases, and such this work was incorporated into Beta 1 (3.0.0.2). This may have been a contributor, but I could not find any configuration changes that would have prevented older configuration from functioning correctly.

Marked as resolved as I am unable to reproduce this behaviour, and have had Active Directory operations functioning correctly in multiple environments using the AD Changes operation. Please reopen or recreate the issue if this behaviour reoccurs.

I agreed with the decision. Thus closing this issue.

I currently have this issue with an ADAM instance which the operation was working against succeeded. Investigating

After quite some investigation between myself and Tony, we found that the issues we were experiencing were due to either:

• An incorrect or incomplete LDAP filter
• An incorrect organizational unit specified
• Surprisingly, insufficient access to the Active Directory instance, which resulted in no objects being returned as opposed to error messages stating there were authentication issues (we used the Domain Administrator when attempting to connect to an ADAM instance within the domain, rather than the ADAM administrator). Debugging revealed this is a limitation of the DirectorySearcher, resulting in the searcher either timing out or returning no objects.

The documentation has been suitably updated with a troubleshooting article and each of the operations (Active Directory Changes and Active Directory Sync Changes) have also been updated appropriately.

Tony, please confirm if these documentation updates will suitably address potential issues clients may experience.

Revised documentation confirmed as representative of encountered problems and respective solution.