I accidentally selected an OU on a MA that contains contacts with duplicate SMTP proxy addresses to users in the destination container. I selected the container in the Source Containers dialog and clicked the 'Remove Container' button. However, when I perform a Full Import and Full Sync, I still get errors for the duplicate contacts ("There is another authoritative object representing the same entity in the metaverse..."). Is there anything else I need to do to ensure this container is not imported and synced? Many thanks in advance, IR8

IRobot, can you confirm if you are talking about an ADMA or an ADAM MA? Also, why have you got users and contacts with the same SMTP addresses? Cheers, MMS_guru

It's the management agent for Active Directory global address list (GAL). We have had IIFP deployment syncing the GAL between domains abc.local and xyz.local for some time now (2 separate organisations). I introduced a one-way GAL sync with a new FIM 2010 deployment to get xyz.local contacts created in a domain we're migrating user accounts and mailboxes to - pqr.local (as the 2 separate organisations are merging). The contacts are being created to provision the GAL for mailboxes migrated to Exchange 2007. However, in the xyz.local MA on new FIM 2010 deployment, I accidentally selected the destination container for xyz.local IIFP MA in the authoritative contacts container list for pqr.local FIM MA. This is why I have users and contacts with the same SMTP addresses. So, I used the 'Remove Container' button to get rid of the this container in the pqr.local FIM MA listing authoritative contacts. However, the scheduled run profiles (Delta Import and Delta Sync) are showing that the MA is still importing/ syncing the removed container. Is there any way to ensure the removed container is not imported/ synced? Many thanks, IR8

Hi There, If you remove the accidently selected container, the objects that were imported should be removed (filtered) and the connection to the MV broken. This should remove the MV objects by the MV deletion rules as I am assuming they only have the one connector from the source system (as the provisioning is erroring out) Thanks B

You mentioned before that you ran a full import and sync. Is that true? Delta imports won't catch change in container list for de-selection. Try running full import(stage only) on MA for which you changed the container list. The full import stats should show many deletes. These should be the objects that are showing errors now. The subsequent sync will clear these out and you shouldn't see these errors anymore. Glenn

Thanks Blain, Glenn for confirming how it should work. Blain - to confirm, there is only one AD GAL MA for the source - and Delta Imports + Delta Syncs are scheduled for this. This is to provision a one-way sync to the destination forest, which has a separate MA with Exports scheduled. Glenn - I ran a Full Import (Stage Only) on the source MA, and Staging Deletes shows 0 (zero) after a successful run. All previous Full Imports I ran after removing the OU also show 0 Staging Deletes. Both show some Filtered Deletions. However the Synchronization Errors for duplicate entities still persist in Full Imports (manual - not scheduled), Delta Imports and Delta Syncs. I can see that the OU is definitely not listed in the Containers list, and is Deselected in the Select Containers dialog. The higher-level OU is listed and selected though - do you think this could be causing the problem? If not, is there anywhere else I can check to ascertain what's causing the problem, or do you think it would be best to just recreate the MA and start again? Thanks again.

Yuu might want to engage PSS for help with this. But removing the OU from the container list and running a full import(stage only) on that MA should have worked. The next full import after de-selecting an OU should show staged deletes for the OU itself and any objects that it contains. I haven't seen this fail myself, the only other thing I can think of is you are getting discovery errors for other objects during import on this same MA. Discovery errors won't allow obsoletion to happen so objects won't be removed properly. However, this is extremely rare for an AD MA, this is typically seen with a text or DB MA.