Bugs
Object reference not set to an instance of an object error when attempting to retrieve schema
When trying to retrieve schema, MIM throws error below.
Log Name: Application Source: FIMSynchronizationService Date: 30/05/2017 8:44:54 AM Event ID: 6801 Task Category: Server Level: Error Keywords: Classic User: N/A Computer: dc1devfim01.dev.apra.gov.au Description: The extensible extension returned an unsupported error. The stack trace is: "Unify.Product.IdentityBroker.LdapOperationException: Object reference not set to an instance of an object. at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request) at Unify.Product.IdentityBroker.LdapConnection.GetSchema(String schemaDn) at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext() at System.Linq.Enumerable.Aggregate[TSource](IEnumerable`1 source, Func`3 func) at Unify.Product.IdentityBroker.LdapConnectionProxy.get_LdapSchema() at Unify.Product.IdentityBroker.LdapConnectionProxy.get_Schema() at Unify.Product.IdentityBroker.UnifyLdapConnectorTypeProxy.GetSchema(KeyedCollection`2 configParameters) at Unify.Product.IdentityBroker.UnifyLdapConnector.GetSchema(KeyedCollection`2 configParameters) Forefront Identity Manager 4.4.1459.0"Error in logs is as follows:
20170529,22:44:53,UNIFY Identity Broker,Security engine,Information,"Require an LDAP access level Request to require LDAP access level Read completed successfully.",Verbose 20170529,22:44:53,UNIFY Identity Broker,LDAP engine,Error,"Handling of LDAP schema request. Handling of LDAP schema request from user mim on connection 127.0.0.1:65135 for the server schema failed with error ""Ob ject reference not set to an instance of an object."". Duration: 00:00:00.",Normal 20170529,22:44:53,UNIFY Identity Broker,LDAP Engine,Error,"An error occurred on client from 127.0.0.1:65135. More detail s: Internal Server Error #11: System.NullReferenceException: Object reference not set to an instance of an object. at Unify.Product.IdentityBroker.SearchRequestHandlerBase.HandleRequest(IRfcLdapMessage message, CancellationToken tok en, Action`1 postAction) at Unify.Product.IdentityBroker.RequestHandlerAuditingDecorator.HandleRequest(IRfcLdapMessage message, CancellationTo ken token, Action`1 postAction) at Unify.Product.IdentityBroker.LDAPRequestHandlerSecurityDecorator.HandleRequest(IRfcLdapMessage message, Cancellati onToken token, Action`1 postAction) at Unify.Product.IdentityBroker.LDAPConnection.<RespondToMessageAsync>d__33.MoveNext()",Normal 20170529,22:44:53,UNIFY Identity Broker,LDAP engine,Information,"Handling of LDAP unbind request. Handling of LDAP unbind request received on connection mim to connect as user 127.0.0.1:65135 started.",Verbose 20170529,22:44:53,UNIFY Identity Broker,Security engine,Information,"Require an LDAP access level
Answer
Hi Matt,
Is this the same issue as http://voice.unifysolutions.net/topics/2988-unable-to-retrieve-schema/? Did you recently change the container name for an adapter? If so, please remember to clear the entity context and the orphaned container should delete itself after a few minutes.
Very possibly. I did search for this error using the method previously described, but nothing was returned in voice.
When are we going to get a fix for this, so the product cleans up after itself?
I did have an extra container in there but after removing it, I now have a 1:1 match of containers to adapters and the error is still occurring.
Hi Matt,
As I said, the solution will clean up after itself if you clear the adapter context. There should be a warning on the dashboard that the context should be cleared after changing the container name for an adapter. The improved error reporting will be included in future releases.
Is the error you are receiving now definitely the same error as before, or is it different? If it's the same, could you please try dropping in the final patch from the previous issue (attached here for your convenience Unify.IdentityBroker.LDAP.Engine.dll) and reply with the latest error.
Found 1 rename has not been done by comparing xml with db contents.
$SQLServer = "mimsqldev"
$SQLDBName = "Unify.IdentityBroker"
$SqlQuery = "SELECT [DistinguishedName] FROM [Container]"
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Data Source=$SQLServer;Initial Catalog=$SQLDBName;Integrated Security = True;"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$DataSet.Tables[0]
DistinguishedName
-----------------
DC=IdentityBroker
OU=AurionEmployees,DC=IdentityBroker
OU=Contacts,DC=IdentityBroker
OU=EmployeeOrganisations,DC=IdentityBroker
OU=ScheduleUser,DC=IdentityBroker
OU=SecurityUsers,DC=IdentityBroker
OU=SPOrganisations,DC=IdentityBroker
OU=SPUsers,DC=IdentityBroker
containerName="AurionEmployees"
containerName="Contacts"
containerName="AurionOrganisations"
containerName="ScheduleUser"
containerName="SecurityUsers"
containerName="SPOrganisations"
containerName="SPUsers"
Can't you just invalidate the contents of the adapter upon renaming the adapter? There was no alert or warning on my screen like the one you described.
The best way to handle it would be to warn that changing the adapter container name will delete the contents of adapter & perform the operation after the user clicks 'OK'.
Hi Matt,
Thanks for the feedback, I agree that the product could handle this more gracefully, and we'll take it into consideration.
For your immediate issue, you should be able to resolve this by removing the container corresponding to the previous container name and re-populating the adapter entity context.
Customer support service by UserEcho
Hi Matt,
Thanks for the feedback, I agree that the product could handle this more gracefully, and we'll take it into consideration.
For your immediate issue, you should be able to resolve this by removing the container corresponding to the previous container name and re-populating the adapter entity context.