We use MIIS for passowrd sync btw AD adn SQLDB.

we have provisioning error in some user.

Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "XXXXXX" already exists in management agent "SQL_MA".
   at Microsoft.MetadirectoryServices.Impl.CSEntryImpl.CommitNewConnector()
   at Microsoft.MetadirectoryServices.GALSync.MVSynchronizer.XXXXProvision(MVEntry mventry)
   at Microsoft.MetadirectoryServices.GALSync.MVSynchronizer.Provision(MVEntry mventry)

I found that user CS object in AD_MA.

If I simulate sync, it says in provisioning summary in SQL_MA connector add , failed duplicate object.

I confirmed that user exists in AD_MA,SQL_MA , but does not exist in MV.

In my guess, AD_MA try to project and provision but same object already exists in SQL_MA and sync fail.

How could I solve that safely ?

The error message appears to be stating the problem pretty clearly: You are trying to provision an object that already exists. Two things to check:

1. Is the anchor you defined in SQL_MA really unique for all records?
2. Is your join rule set up correctly? If it were, FIM should not try to provision the object again, but rather recognize it and join it to an existing object.

Thank you.

1. yes, samaccount name is set for anchor and primary key.

2. join and projection rule is set for AD_MA correctly .

Q1 If provision fail (AD_MA),  projection also fail ?

Because there is no MV object for that user.

Q2 If we project that user by joiner, only one user are affected ? I am worry about negative side effect.

You write that your join and projection rule set is correct for AD_MA - what about projection and join rules for the SQL_MA?

As to your questions:

Q1: I'm not really sure here, but that's the way I always understood it works: FIM Sync Engine only needs an MV entry for objects that exist in at least two Connector Spaces, so it only creates the MV Entry once the entry in the second CS is provisioned.

Q2: No, all users will (potentially) be affected, and that's just what you want: if there's are potential match between the AD record and the SQL record, you do not want a new CS entry provisioned (as that will cause your error). Instead, you want a join to take place and for that you will need a join rule. This will not affect your current connectors though.

What appears to have happened in your case is that object "XXXXXX" was at some point provisioned to the SQL CS, but then became disconnected. If you have a join rule, it will connect again (unless it's an explicit disconnector). If you don't have a join rule, the sync engine will try to re-provision, which leads to the error you're getting.

Thank you.

SQL_MA has only join rule, no projection rule.

In the joiner tab , I found projection button and I thought it might be possible to projection one disconnector object to metaverse by that button. How about that ?

>Q2: No, all users will (potentially) be affected, and that's just what you want: if there's are potential match between the AD record and the SQL record, you do not want a new CS entry provisioned (as that will cause your error). Instead, you want a join to take place and for that you will need a join rule. This will not affect your current connectors though.

The Joiner tab is for manually connecting a connector space object to a metaverse object. Since you don't have a metaverse object yet, I'm not sure this would work. I assume there's no harm in trying though.

At any rate, I would review not only the presence, but the actual configuration of the SQL MA's join rule. How is it configured?

Thank you.

Join rule of SQLMA is simple.

Just join sameaccount name column of SQLMA and samaccountname of ADMA directly.