The following shows a search result which incorrectly returns all org unit records where none of the inspected results actually matched the search criteria:

***Searching...
ldap_search_s(ld, "OU=orgUnits,DC=IdentityBroker", 2, "(hierarchy=50002000)", attrList,  0, &msg)
Matched DNs: OU=orgUnits,DC=IdentityBroker
Getting 1000 entries:
Dn: CN=50022695,OU=orgUnits,DC=IdentityBroker


costCentre: 0000045240; 
costCentreGroup: CCCA; 
costCentreID: d567d5b9d344523618fc25cc2efe70e7; 
costCentreIDRef: CN=0000045240,CN=CCCA,OU=costCentres,DC=IdentityBroker; 
costCentreText: International Climate Law; 
createTimestamp: 30/11/2019 1:36:03 PM AUS Eastern Daylight Time; 
distinguishedName: CN=50022695,OU=orgUnits,DC=IdentityBroker; 
entryUUID: 08e5d654-d8a2-4b41-a516-00bd457a93b9; 
EXTOBJID: 50022695; 
hashDN: 60451482495227d7d95601c180bcceac; 
hierarchy (7): 50000100; 50000500; 50022601; 50022677; 50022687; 50022692; 50022695; 
hierarchyRef (7): CN=50000100,OU=orgUnits,DC=IdentityBroker; CN=50000500,OU=orgUnits,DC=IdentityBroker; CN=50022601,OU=orgUnits,DC=IdentityBroker; CN=50022677,OU=orgUnits,DC=IdentityBroker; CN=50022687,OU=orgUnits,DC=IdentityBroker; CN=50022692,OU=orgUnits,DC=IdentityBroker; CN=50022695,OU=orgUnits,DC=IdentityBroker; 
longText: International Climate Law Section; 
modifyTimestamp: 2/12/2019 10:23:42 PM AUS Eastern Daylight Time; 
objectClass: orgUnit; 
objectEndDate: 99991231000000.000Z; 
objectID: 50022695; 
objectStartDate: 20071203000000.000Z; 
OBJECTTYPE: O; 
orgLevel: 7; 
orgLevelName: Section; 
OU: orgUnits; 
parentOrgID: 50022692; 
parentOrgIDRef: CN=50022692,OU=orgUnits,DC=IdentityBroker; 
PLANSTAT: 1; 
PLANVERS: 01; 
shortText: DCC ID; 
status: Active; 
subschemaSubentry: CN=orgUnits,cn=schema; 

Using the new version of the Aderant Expert connector I'm seeing this error.  This is the first time I've attempted an export with the new connector.  The configuration is a migration of the old version of the connector, talking to a database which is a copy of the one used by the old version of the connector.

UNIFYBroker v5.3.2 Revision #0
Aderant Expert Connector 5.3.1.1
Chris21 Connector 5.3.0.0

Could you please assist in working out what's wrong?

When running a FULL IMPORT on an IdB5.3.2 implentation I am getting data returned from only 2 of the 7 configured partitions - yet data is clearly visible for each of them via LDP, making me suspect an issue with the Broker for MIM component.  I have tried deleting and recreating run profiles, refreshing schema, reloading interfaces, and even creating a new instance of the MA - but still the same result.

There are no exceptions being logged for the full import (currently in VERBOSE mode).  As an example

• The AREA adapter correctly returns 11 records, including the root container node (although the Total Entities count incorrectly shows as 0 on the Import job counter)
• The COMPANIES adapter returns 1 record, being the container node only - despite all objects appearing correctly via LDAP.EXE.

Can I please have some urgent assistance to determine the root cause?

Hi Guys,

Couldn't find an existing ticket or knowledge ticket about this so I though I would start one.

In the past I have design schedules and exclusion groups around the idea that you could not import from an adapter and do an import on the relative connector at the same time as it would cause sluggishness within Broker. Additionally, reading from an adapter while UNIFYBroker is committing changes will also cause some sort of locking (whether it locks up entirely or whether it just take long while doing so).

So I was hoping you could tell me about how UNIFYBroker handles concurrency. More specifically what operations it can do at the same time. Eg:

• Can you import from two connectors at the same time (both if its a one to one adapter relationship or a many to one)?
• Can you import from the an adapter while an import is being run on the respective connector
• Can you do a import all and a delta import at the same time without anything locking up (not that I do this, but it happens from time to time)?

If you can let me know of any operations that couldn't be run at the same time that would be great, as it would be good to define a concrete way to schedule UNIFYBroker operations.

Thanks

When I changed the case of an OU name in an adapter from OrgUnits to orgUnits, the data returned subsequently over the LDAP interface was not adjusted accordingly.  I believe I tried each of the following without success (but you may want to prove this for yourself):

1. restarting the IdB service
2. deleting the adapter and reloading it
3. deleting the connector and adapter data and reloading them both

Eventually I had to go into the Broker SQL table (container names I think it was), locate the offending record, and update it there.

After my recent experience with upgrading Identity Broker there are a couple of nice-to-haves in the installer that would make things easier. In both cases either a warning or a log would be helpful. Admittedly, both problems could be solved by stringent documentation however the scattered nature of documentation on sharepoint and having to find one line mentions in a host of project documentation is a challenge for professional services I believe so some checks and balances in the installer itself would alleviate the problem.

1. A notification that there are non-standard assembly redirects in the unify.service.connect.exe.config and which ones are non standard. (The only way to know now is through trial-and-error or rely on documentation.)

2. A notification of all .dlls that are found that are patches from previous installs. (the only way to find now is to uninstall rendering in place upgrade risky or relying on documentation.) This one is relevant to both UNIFYBroker and UNIFYNow.

Using the Broker Microsoft Dynamics CRM v5.2.0.1, Infrastructure are seeing some intermittent errors. The error shows in MIM and when checking the IdB logs the content of the error is the same as what shows in IdB. It's not that big a problem. It only occurs occurs on export and the pending export that fails remains a pending export and is processed ten minutes later and the error isn't rethrown on the second export. It seems to be some type of network connection problem but there aren't a lot of settings to configure it in the CRM Agent. Just the address and account and they're both correct. The full error is pasted below.

System.InvalidOperationException: Metadata contains a reference that cannot be resolved: 'https://dynamicscrm.internal.dotars.gov.au/DAMS//XRMServices/2011/Organization.svc?wsdl&sdkversion=8.2'. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Description.MetadataExchangeClient.MetadataLocationRetriever.DownloadMetadata(TimeoutHelper timeoutHelper)
at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper)
--- End of inner exception stack trace ---
at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper)
at System.ServiceModel.Description.MetadataExchangeClient.ResolveNext(ResolveCallState resolveCallState)
at System.ServiceModel.Description.MetadataExchangeClient.GetMetadata(MetadataRetriever retriever)
at Microsoft.Xrm.Sdk.Client.ServiceMetadataUtility.RetrieveServiceEndpointMetadata(Type contractType, Uri serviceUri, Boolean checkForSecondary)
at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1..ctor(Uri serviceUri, Boolean checkForSecondary)
at Microsoft.Xrm.Sdk.Client.OrganizationServiceConfiguration..ctor(Uri serviceUri, Boolean enableProxyTypes, Assembly assembly)
at Microsoft.Xrm.Sdk.Client.ServiceConfigurationFactory.CreateConfiguration[TService](Uri serviceUri, Boolean enableProxyTypes, Assembly assembly)
at Unify.Product.IdentityBroker.OrganizationServiceCommunicator.GetOrganizationService(IAddressCommunicatorInformation communicatorInformation)
at Unify.Product.IdentityBroker.OrganizationServiceCommunicator.<>c__DisplayClass1_0.<.ctor>b__0()
at Unify.Product.IdentityBroker.AddressCommunicatorBase`2.get_Service()
at Unify.Product.IdentityBroker.DynamicsCrmAgent.GetAttributeMetadata(String objectName, EntityFilters schemaRetrieveEntityFilters)
at Unify.Product.IdentityBroker.DynamicsCrmAgent.RetrieveSpecialFieldTypes(String objectName)
at Unify.Product.IdentityBroker.DynamicsCrmObjectConnector.GetSpecialFieldTypesInformation(IDynamicsCrmAgent`2 agent)
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at Unify.Product.IdentityBroker.DynamicsCrmObjectConnector.UpdateEntities(IEnumerable`1 entities, IEnumerable`1 originalEntities, ISaveEntityResults`2 results)
at Unify.Product.IdentityBroker.AuditUpdatingConnectorDecorator.UpdateEntities(IEnumerable`1 entities, IEnumerable`1 originalEntities, ISaveEntityResults`2 results)
at Unify.Product.IdentityBroker.EventNotifierUpdatingConnectorDecorator.UpdateEntities(IEnumerable`1 entities, IEnumerable`1 originalEntities, ISaveEntityResults`2 results)

Any clues on the resolution of this intermittent issue? We haven't done diagnostic logging because it's in production and the error is intermittent so making huge logs is undesirable. I googled a bit and it looks like there are lines of code to set the TLS version to 1.2 which has resolved the same error in different contexts for other people. But you guys don't hardcode the authentication with web services right? So maybe the bindings should be updated? Still it doesn't make much sense that it fails sometimes and works sometimes. Makes me think the service is the problem rather than broker.

The UNIFYBroker logo and label is not resizing correctly in IE.

Hello,

Recently updating UNIFYBroker from 5.0.4 to 5.3.2 and am now receiving this below error in the IdB logs.

I am also having issue updating the IdB maangement agents after the update. FIM is able to successfully retrieve the interfaces but when I click ok on the Connectivity Tab it give me the following error:

FIM also produces the following error in the log:

The extensible extension returned an unsupported error.
The stack trace is:

"Unify.Product.IdentityBroker.LdapOperationException: The server forcefully terminated the connection with the following reason: Internal Server Error #11: Unify.Product.IdentityBroker.UnifyLDAPException: Could not retrieve a valid last change number.
at Unify.Product.IdentityBroker.RootDSEGenerator.GetLastChangeNumber()
at Unify.Product.IdentityBroker.RootDSEGenerator.AddLastChangeNumber(IDictionary`2 resultAttributes)
at Unify.Product.IdentityBroker.RootDSEGenerator.BuildRootDseEntry(HashSet`1 attributes)
at Unify.Product.IdentityBroker.RootDSERequestHandler.HandleRequest(IRfcLdapMessage message, CancellationToken token, Action`1 postAction)
at Unify.Product.IdentityBroker.RequestHandlerAuditingDecorator.HandleRequest(IRfcLdapMessage message, CancellationToken token, Action`1 postAction)
at Unify.Product.IdentityBroker.LDAPConnection.d__35.MoveNext() - Result Code: Other ---> Unify.Product.IdentityBroker.LdapServerException: The server forcefully terminated the connection with the following reason: Internal Server Error #11: Unify.Product.IdentityBroker.UnifyLDAPException: Could not retrieve a valid last change number.
at Unify.Product.IdentityBroker.RootDSEGenerator.GetLastChangeNumber()
at Unify.Product.IdentityBroker.RootDSEGenerator.AddLastChangeNumber(IDictionary`2 resultAttributes)
at Unify.Product.IdentityBroker.RootDSEGenerator.BuildRootDseEntry(HashSet`1 attributes)
at Unify.Product.IdentityBroker.RootDSERequestHandler.HandleRequest(IRfcLdapMessage message, CancellationToken token, Action`1 postAction)
at Unify.Product.IdentityBroker.RequestHandlerAuditingDecorator.HandleRequest(IRfcLdapMessage message, CancellationToken token, Action`1 postAction)
at Unify.Product.IdentityBroker.LDAPConnection.d__35.MoveNext() - Result Code: Other
at Unify.Product.IdentityBroker.LdapConnection.GetMessage(Int32 messageId)
at Unify.Product.IdentityBroker.SearchRequest.Send(Func`2 send, Func`2 recv)
at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)
--- End of inner exception stack trace ---
at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)
at Unify.Product.IdentityBroker.LdapConnectionProxy.<.ctor>b__3_0()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at Unify.Product.IdentityBroker.LdapConnectionProxy.<>c__DisplayClass3_0.<.ctor>b__2()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at Unify.Product.IdentityBroker.LdapConnectionProxy.get_LdapSchema()
at Unify.Product.IdentityBroker.LdapConnectionProxy.get_Schema()
at Unify.Product.IdentityBroker.UnifyLdapConnectorTypeProxy.GetSchema(KeyedCollection`2 configParameters)
Forefront Identity Manager 4.1.3646.0"

Thanks

Hi Guys,

I've noticed with that latest version of UNIFYBroker v5.3 above that the Entity Search is slow for large partitions (both connectors and adapters that are usually around 300k-400k entities and about 20 or so attributes each record).

I am aware that some changes have been made to the entity search in recent versions and have raised tickets before about timeout that occur in some cases. I have noticed this occurring in both IIS and self hosted versions. The workaround for this currently is to increase the timeout value, but even when this is increase for larger connectors you can be waiting for 15~20 minutes or longer for the entity search to load. In previous versions of Broker (5.0) the old entity search would load the entities with 5~10 seconds.

So I'm proposing that the search doesn't necessarily need to be reverted but investigated as to why it take so long and to see if it can be improved. Let me know if you need any information on this, I'm happy to provide any information on environments this is currently affecting.

Thanks