MIM 2016 sync rules become orphaned (broken) after update to


After I upgraded my MIM 2016 test lab to hotfix build I recognized that the MIM portal sync rules became orphaned (broken) when I let them all recreate by setting the password on the MIMService MA again.

Some users also reported that in the following FIM/MIM TechNet Forum post: https://social.technet.microsoft.com/Forums/en-US/e0e6e2db-46e1-4638-bdfb-4436b8f53ae1/mim-portal-sync-rules-have-become-orphaned?forum=ilm2

I already answered there with some points that I found out while debugging the issue.

Like the guy in the forum I also tried to update to the latest hotfix but that does not solve the issue, and it might be possible that you also run into this issue when only applying

The error is like following:

  1. All Management Agents that don’t have sync rules in the portal are re-created fine with no errors.
  2. The Management Agents that have sync rules got deleted but an failed on the re-create with the following error in the MIM request history:
Dispatch Request Failure Source: 'Other'


All sync rules in portal now stating the following:

The referenced Management Agent has been deleted. Please delete this Synchronization Rule, update the external system field or re-import the deleted Management Agent)

So I took a look into the EventLog -> Application and Service Logs -> Forefront Identity Manager Management Agent

Reraised Error 50000, Level 14, State 1, Procedure ReRaiseException, Line 37, Message: Reraised Error 50000, Level 14, State 1, Procedure ReRaiseException, Line 37, Message: Reraised Error 2627, Level 14, State 1, Procedure UpdateResource, Line 224, Message: Violation of PRIMARY KEY constraint 'PK_ObjectValueBoolean'. Cannot insert duplicate key in object 'fim.ObjectValueBoolean'. The duplicate key value is (52, 32, 23807).


Lets take a look it the fim.ObjectValueBoolean table in the FIMService database mentioned in that error:

Note the 3rd value of the duplicate key error, 23807 in the screenshot and my test lab and do the following SQL on the table mentioned above:

SELECT TOP (200) ObjectKey, ObjectTypeKey, AttributeKey, ValueBoolean
FROM fim.ObjectValueBoolean
WHERE (ObjectKey = 23807)


So what are those values and keys shown here?


SELECT TOP 1000 [ObjectKey]
FROM [FIMService].[fim].[Objects]
where ObjectKey = 23807

This gives me only one line of result presenting an ObjectID (a GUID), searching the MIM portal shows me that this is my HR Inbound Sync Rule.

ObjectTypeKey: (2nd value of the duplicate key error)

SELECT TOP 1000 [Key]
FROM [FIMService].[fim].[ObjectTypeInternal]
where [Key] = 32


Of course the type is an SynchronizationRule object.

AttributeKey: (1st value of the duplicate key error)

SELECT TOP 1000 [Key]
FROM [FIMService].[fim].[AttributeInternal]
where ([Key] = 52) or ([Key] = 54) or ([Key] = 64) or ([Key] = 276)


So the issue is related to some of the sync rules Boolean attributes (the 3 ones on the Relationship grouping, and the decision between using EREs or outbound scope filter)

I do not understand why the re-create of the management agents try to update these values as in general only new ma-data objects should be affected.

However, since I’m not an expert in the internals of the MIM database that might be OK or not, but it should work and not trigger an error.

After a little testing (and try an error) I found a partial workaround to get the sync rules back working. Bad thing is that if I trigger the re-create ma-data again by setting the password of the MIMService Management Agent, it get’s broken again, so I still need to wait until there is a fix on that.

So here is my solution to get the sync rules back in an proper state:


Don’t do this directly in your production environment, make backups of your MIMService database, test it in DEV first or make a complete copy of your environment.
I only tested that in my demo lab and it seems all to work properly after applying that solution. I’m not responsible for any damage on your system since directly editing the database is not supported. So still open a case at Microsoft should be the way to go.

Here is what I did:

You remember the output from the following SQL query above ?

SELECT TOP (200) ObjectKey, ObjectTypeKey, AttributeKey, ValueBoolean
FROM fim.ObjectValueBoolean
WHERE (ObjectKey = 23807)

I got the following 4 rows with the Boolean attributes of my sync rule:

ObjectKey, ObjectTypeKey, AttributeKey, ValueBoolean
23807 32 52 False
23807 32 54 True
23807 32 64 False
23807 32 276 True
  • I wrote down the proper TRUE or FALSE values of each row.
  • I deleted the 4 rows in the table
    If I only delete the first line with the 52 mentioned in the 1st value of the error message, the next error will state an issue with the 54, and so on)
  • Open the properties page of the management agent in the Synchronization Service Manager and click OK to start re-create the ma-data again.

The re-create of the management agent is successful now and the sync rules seems to be OK also (not orphaned any more)

  • Do the above SQL query again, and you will see the 4 rows also have re-created but with all ValueBoolean set to False. Just correct this to the values they have before deleting the rows.

That’s it, I did a Full Import and a Full Sync on the MA and also in the MIMService MA and also some Export’s an everything seems to be OK.

If you have multiple sync rules bound to an management agent (like I had for AD) you need to delete the 4 rows for every of the sync rules bound to that management agent before you can successfully re-create the ma-data. Just click OK on the properties of the MA to get the next ObjectKey value (3rd element in the constraint error, 23807 in this sample).


Do not set the password of the MIMService MA again after you will fix your sync rules with the above method or do anything that triggers an ma-data re-create.
If you do do, the sync rules get broken again.
So this is only a temporary solution until Microsoft gets that issues fixed.


Author: Peter Stapf

Senior Consultant Identity and Access

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.