0
Fixed

Troubleshooting article: AD Sync Changes - More data is available error

Adam van Vliet (Chief Information Security Officer) 6 years ago • updated by anonymous 3 years ago 4

From CSODBB-222, the following exception may occur for the AD Sync Changes operation:

System.DirectoryServices.DirectoryServicesCOMException (0x800700EA): More data is available.
at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
at System.DirectoryServices.SearchResultCollection.get_InnerList()
at System.DirectoryServices.SearchResultCollection.get_Count()
at Unify.Product.EventBroker.ADSyncChangesPlugIn.GetChanges(DirectorySearcher searcher)
at Unify.Product.EventBroker.ADChangesPlugInBase.Check()
at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)

This can be fixed by adding the following configuration to FIM Event Broker:

  <configSections>
    <section name="system.directoryservices" type="System.DirectoryServices.SearchWaitHandler, System.DirectoryServices, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </configSections>
  <system.directoryservices>
    <DirectorySearcher waitForPagedSearchData="true" />
  </system.directoryservices>

Reassigned for confirmation of completion, documentation can be found here

Important note as to the location of the above XML from the linked text:

Resolution

Locate the *.exe.config in the Event Broker services directory, for an x64 installation this will be (by default):

C:\Program Files\UNIFY Solutions\Event Broker\Services\Unify.Service.Event.exe.config

and for an x86 installation this will be (by default):

C:\Program Files\UNIFY Solutions\Event Broker\Services\Unify.Service.Event32.exe.config

Add the following to the *.exe.config of the Event Broker services directory, inside the <configuration> element:

...

Note that this seems to have to be the FIRST CHILD under the <configuration> element - putting it as the last child causes the service to crash on restart.

Confirmed the above - suggestion is that this change should be formalized if (as it appears) has been successful in the past in eliminating this error. Will be checking logs in the coming days to see if this has been effective.