I do not take credit for this fix, I am going to copy and paste it verbatim from another forum post.
Ugh, this one was a pain-in-the-ass to figure out, but I did, so I thought I would share. The other day, I had to add a custom resource type to the portal — computer and contact types to be specific. After I did all tedeious work of expanding the schema, granting permissions to the synchronization engine to control them, added their types to the synchronization filter, defined the synchronization rules, blah, blah blah; when I attempted to export them from my ADMA into my FIMMA, I was getting the following error:
Microsoft.ResourceManagement: Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other —>
System.Data.SqlClient.SqlException: Reraised Error 50000, Level 16, State 1, Procedure ReRaiseException, Line 31,
Message: Reraised Error 50000, Level 16, State 1, Procedure ReRaiseException, Line 31, Message: Reraised Error 547,
Level 16, State 1, Procedure UpdateResource, Line 462, Message: The INSERT statement conflicted with the
FOREIGN KEY constraint “FK_ObjectValueReference_BindingInternal”. The conflict occurred in database “FIMService”, table “fim.BindingInternal”.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader()
at Microsoft.ResourceManagement.Data.DataAccess.ProcessRequest(RequestType request)
— End of inner exception stack trace —
at Microsoft.ResourceManagement.Utilities.ExceptionManager.ThrowException(Exception exception)
at Microsoft.ResourceManagement.Data.Exception.DataAccessExceptionManager.ThrowException(SqlException innerException)
at Microsoft.ResourceManagement.Data.DataAccess.ProcessRequest(RequestType request)
at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ProcessInputRequest(RequestType request)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction(RequestType request)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction[ResponseBodyType](RequestType request)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request, Guid requestIdentifier, Object redispatchSingleInstanceKey, Boolean isRedispatch)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request)
at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Create(Message request)
If you are reading this, likely you are having this problem too and likely it is because in defining the schema of the custom resource type, you included a binding to the Domain attribute. Well, after conferring with the product group, it turns out that whenever you create or update a binding of a resource to a Domain attribute, you must also create a second binding for the DomainConfiguration attribute to that resource type as well. *Woof* Nice for them to make that obvious…
Anyway, the short of it is: whenever you create (or update) a binding to the Domain attribute, you must also create a DomainConfiguration binding. After doing so, refresh the schema of the FIMMA in the sync engine, run a full import, sync, and export, and celebrate that this nut has been cracked… freeing you up for the next one.
If you are reading this, likely you are having this problem too and likely it is because in defining the schema of the custom resource type, you included a binding to the Domain attribute. Well, after conferring with the product group, it turns out that whenever you create or update a binding of a resource to a Domain attribute, you must also create a second binding for the DomainConfiguration attribute to that resource type as well. *Woof* Nice for them to make that obvious…
https://docs.microsoft.com/en-us/archive/blogs/karchworld_identity/a-note-when-creating-a-custom-resource-types-that-has-a-domain-attribute-binding
Anyway, the short of it is: whenever you create (or update) a binding to the Domain attribute, you must also create a DomainConfiguration binding. After doing so, refresh the schema of the FIMMA in the sync engine, run a full import, sync, and export, and celebrate that this nut has been cracked… freeing you up for the next one.
https://web.archive.org/web/20200422225723/https://docs.microsoft.com/en-us/archive/blogs/karchworld_identity/a-note-when-creating-a-custom-resource-types-that-has-a-domain-attribute-binding