Share via

Support-Tip: (AADCONNECT): 0x80230307 (The dimage indicates an add operation, but the image already exists

  • Article

Hey all,

Tim Macaulay here again to share some an interesting issue that I recently worked.

PRODUCTS INVOLVED

  • Microsoft Azure AD Connect 1.1.524.0
    • Number of Connectors: 2
NOTE: Please note, that there is a later build of Microsoft Azure AD Connect available for download in 1.1.649.0. You can download that build here: https://www.microsoft.com/en-us/download/details.aspx?id=51495

 

PROBLEM SCENARIO DESCRIPTION

  • In this scenario, we were experiencing any new Contact Object that was provisioned through the Azure AD Connect Sync System was failing to provision and dumping the below exception on the Synchronization Error Tab.
NOTE: Please note, that I will cover some additional information here, but that the key to the issue is the "but the image already exists"

EXCEPTION

Unable to persist entry.

An error occurred, ..\ObjectNamespace.cpp(636), code 80230307,

BAIL: MMS(19636): ..\tripleholo.cpp(10253): 0x80230307 (The dimage indicates an add operation, but the image already exists.)

BAIL: MMS(19636): ..\tripleholo.cpp(1886): 0x80230307 (The dimage indicates an add operation, but the image already exists.)

BAIL: MMS(19636): ..\tower.cpp(1678): 0x80230307 (The dimage indicates an add operation, but the image already exists.)

BAIL: MMS(19636): ..\tower.cpp(10789): 0x80230307 (The dimage indicates an add operation, but the image already exists.)

<delta operation="add" dn="CN={ AAD CS GUID TO THE CS OBJECT }">

 

TROUBLESHOOTING ITEMS

  • Searched for the problem object in the Metaverse (Metaverse Search Tab) as well as the Target (Azure AD) Connector Space (Search Connector Space). In both cases, we were not able to locate the object to prove a duplicate.
  • We utilized the Preview Feature and found that the Contact object did in fact complete the synchronization (Full or Delta Synchronization Radio buttons checked) all the way through and even provided the Export Attribute Flow information; however, still received the exception indicating a duplicate.
    • On the Export Attribute Flow Tab of the Preview under the Connector Updates section, we reviewed the synchronization rules and discovered that we had a customized outbound synchronization rule for the AAD Connector.
  • In the Synchronization Rules Editor window, we reviewed two Outbound Synchronization Rules.
    • First, the Out to AAD - Contact Join Synchronization Rule, which is the Outbound Provisioning Synchronization Rule for Contact Objects.       This Synchronization Rule, was enabled, which means that we would fire this Synchronization Rule during Provisioning. This can be confirmed on the Export Attribute Flow Tab in the Preview Window where the Synchronization Rules are located.
    • Then reviewed the custom Outbound Synchronization Rule.       This rule was a Provisioning Synchronization Rule. On the Transformations Tab, we discovered that there is a Transformation for the DN (DistinguishedName). This was identical to the Out to AAD - Contact Join Synchronization Rule.

 

NOTE: A Provisioning Synchronization Rule is the Synchronization Rule that creates the object. If it is an Inbound Provisioning Synchronization Rule, then the Azure AD Connect Sync is creating the Metaverse Object. If it is an Outbound Provisioning Synchronization Rule, then the Azure AD Connect Sync is creating the Target Connector Space Object.

 

NOTE:

CAUSE

  • The reason that the exception was occurring, is because the Azure AD Connect Sync Solution contained two Outbound Provisioning Synchronization Rules that were both Enabled with the identical Scoping Filters and the identical Transformation for the DN. This was attempting to create two Target Azure AD Connector Space Objects.       This failed with the Exception documented above.

TEMPORARY RESOLUTION

  • To temporarily resolve the immediate issue, you can disable the Custom Outbound Provisioning Synchronization Rule. From there, you will need to make the determination if you need the Custom Synchronization Rule for Outbound Provisioning. If you do, you will need to investigate an avenue to update the Custom Synchronization Rule so that you adhere to the Business Rule that you are attempting to fix.

 

CUSTOM SYNC RULE SUGGESTIONS IF YOU NEED TO KEEP IT

If you do need to keep the Custom Synchronization Rule to adhere to a Business need, then here are some possible thoughts to help move you forward.

  1. Rather than using a Provisioning Synchronization Rule, make the custom rule a Join Rule. This will allow the Provisioning Synchronization Rule to create the object and then the Join Rule will fire based on the Scoping Filter. Now, you may need to play with the Synchronization Rule Precedence to ensure that the Custom Synchronization Rule fires when you need it to fire.
NOTE: A Provisioning Synchronization Rule is the Synchronization Rule that creates the object. If it is an Inbound Provisioning Synchronization Rule, then the Azure AD Connect Sync is creating the Metaverse Object. If it is an Outbound Provisioning Synchronization Rule, then the Azure AD Connect Sync is creating the Target Connector Space Object.

 

NOTE: A Joining Synchronization Rule is the Synchronization Rule that joins to an existing object. If it is an Inbound Join Synchronization Rule, then the Azure AD Connect Sync will attempt to join to an existing Metaverse Object. If it is an Outbound Join Synchronization Rule, then the Azure AD Connect Sync will attempt to join to an existing Target Connector Space Object.

 

 

 

 

 

KEYWORD SEARCH: Iamsupport aadconnect image already exists