Troubleshooting Sync-rule-flow-provisioning-failed: An Object with DN Already Exists in Management Agent

Troubleshooting Sync-rule-flow-provisioning-failed: An Object with DN Already Exists in Management Agent

The objective of the FIM synchronization service is to manage the distributed identity data in your external systems according to the configuration of your synchronization rules.



For a complete overview of how the FIM synchronization service works and how to configure it, see Understanding Data Synchronization with External Systems.
The activities of the FIM synchronization service are initiated by run profile. During the run of a synchronization run profile, the Synchronization Service Manager user interface might report errors codes such as “sync-rule-flow-provisioning-failed”.

The following illustration shows an example for this:

To troubleshoot the error, you need to first gather more details about the nature of the error by reviewing the associated call stack trace information. Clicking the error code opens the Connector Space Object Properties dialog. This dialog has a Stack Trace button to display the call stack information.  The objective of this article is to provide more details about common call stack trace details of a synchronization run and troubleshooting steps to resolve them.

Symptoms

The call stack information of a synchronization error might indicate that an object with a specific DN already exists in the connector space of a management agent.
The following illustration shows an example for this:

 

Cause

When you configure a synchronization rule in the FIM portal, at a minimum, you must configure an attribute flow mapping to set the DN of a newly provisioned object. In FIM, the DN of connector space objects must be unique. If your synchronization rule causes the synchronization engine to provision a new connector that has the same value for the DN attribute as an already existing connector space object, an exception is raised.

Resolution

To fix this issue, you need to determine what the reason for this conflict is.

The most common reasons are:

  1. Incomplete joins
  2. Incorrect DN calculation method

Incomplete joins - the objective of the initialization phase is to join related identity data parts. This is why you should disable provisioning in your initial synchronization runs.

To fix an incomplete join problem in your environment, you should:

  1. Disable provisioning.
  2. Run synchronization on the Fabrikam FIMMA to bring Britta Simon into the metaverse.
  3. Run synchronization on the Fabrikam ADDSMA to join Britta Simon with the related object in the metaverse.
  4. Enable provisioning. 

Incorrect DN calculation method - your logic to calculate the value of your DN attribute must result in a unique value. In this case, you need to develop a better method to calculate a unique DN attribute value.


See Also

 

note Note
To provide feedback about this article, create a post on the FIM TechNet Forum.
Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Comments
  • Carsten Siemens edited Revision 7. Comment: Added tags: en-US, has TOC, has See Also

  • Ed Price - MSFT edited Revision 2. Comment: TOC

  • David W. Henderson edited Revision 5. Comment: In some cases, if an admin goes ahead and creates the account out of band prior to FIM provisioning it, you get the same problem for a isolated account. How do you resolve these cases?

Page 1 of 1 (3 items)
Wikis - Comment List
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Carsten Siemens edited Revision 7. Comment: Added tags: en-US, has TOC, has See Also

  • Ed Price - MSFT edited Revision 2. Comment: TOC

  • David W. Henderson edited Revision 5. Comment: In some cases, if an admin goes ahead and creates the account out of band prior to FIM provisioning it, you get the same problem for a isolated account. How do you resolve these cases?

Page 1 of 1 (3 items)