Just to follow up on this................this situation is essentially a reverse-join scenario; objects already exist in the portal but then objects from another directory, such as AD, attempt to re-provision to portal. Because of uniqueness constraints that Steve mentioned, which include ObjectSID and AccountName, you get these errors and you are essentially stuck like this until you can get the objects to join. While you can use the account joiner to manually join them, I typically would not recommend using this tool, as most of the problems that are fixed by this can be fixed more efficiently in other ways.

 

If this is happening for many objects, this could have been caused by deleteing the connector spaces for MAs and then running syncs, etc....I would typically try this first if you have many objects in this state - Turn off the sync rule provisioning in Tools->Options, verify that objects in portal are actually projected into MV. If they are not, go ahead and do so. Because the sync rule provisioning has been turned off, this will also prevent the sync-rule-provisioning errors that state objects already exist. Once objects are in the MV, they presumably will have attribute values populated such as AccountName that are unique and that can be used in inbound sync rules for joins for the other MAs, like AD. So after projectin objects from portal using import and sync on FIM MA, run sync on AD MA, this should join objects from AD CS to objects in MV. Assuming that you see the expected amount of joins, you can then turn sync rule provisioning back on.

 

There are other ways to handle reverse join scenarios, but this method is quite easy to implement and if this only happens as an accident from deleting the CS, they it is good idea. If you have design where this might happen often with individual objects, you might look at the reverse-join document in the Design Concepts collection, http://www.microsoft.com/downloads/en/details.aspx?familyid=40A52201-A297-4C35-82E9-F0B4CA05DAEB&displaylang=en.

 

 

• Marked as answer by Markus VilcinskasMicrosoft employee, Owner Saturday, December 25, 2010 3:42 PM

This isn't so much a question as something others might like to be aware of...

When you install the FIM Portal and configure metaverse->FIM user sync, supposing you use an account of which your FIM metaverse is already aware, the sync service will be unable to export your account to the FIM MA with an uniqueness constraint violation.  This is because merely setting up the portal and service cause your AccountName, SID, etc., to be populated in the database.

This will express itself as a "failed-creation-via-web-services" with error detail thusly:

Fault Reason: The request message contains errors that prevent processing the request.

Fault Details: <RepresentationFailures xmlns="http://schemas.microsoft.com/2006/11/ResourceManagement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><AttributeRepresentationFailure><AttributeType>ObjectSID</AttributeType><AttributeValue></AttributeValue><FailureMessage>The specified attribute value must be unique for this Resource Type.</FailureMessage><AttributeFailureCode>ValueViolatesUniqueness</AttributeFailureCode></AttributeRepresentationFailure></RepresentationFailures>

My solution was to search (cautiously) the FIMService database to figure out the conflicting account's anchor value:

select ObjectID from fim.Objects with(nolock) where ObjectKey =(select ObjectKey from fim.DomainAndAccountName with(nolock) where DomainAndAccountName = 'mydomain\my.user')

This returns a GUID you can use in the FIM Sync Service admin interface to search the FIM MA by DN/anchor and disconnect.  Now you have a user disconnector in the FIM MA, so head over to the joiner tab, and link it up.

I keep wondering if I've done something wrong in the FIM setup to arrive at this situation, but it's happened in several clean installs following the documented guidelines.

--Steve

Just to follow up on this................this situation is essentially a reverse-join scenario; objects already exist in the portal but then objects from another directory, such as AD, attempt to re-provision to portal. Because of uniqueness constraints that Steve mentioned, which include ObjectSID and AccountName, you get these errors and you are essentially stuck like this until you can get the objects to join. While you can use the account joiner to manually join them, I typically would not recommend using this tool, as most of the problems that are fixed by this can be fixed more efficiently in other ways.

 

If this is happening for many objects, this could have been caused by deleteing the connector spaces for MAs and then running syncs, etc....I would typically try this first if you have many objects in this state - Turn off the sync rule provisioning in Tools->Options, verify that objects in portal are actually projected into MV. If they are not, go ahead and do so. Because the sync rule provisioning has been turned off, this will also prevent the sync-rule-provisioning errors that state objects already exist. Once objects are in the MV, they presumably will have attribute values populated such as AccountName that are unique and that can be used in inbound sync rules for joins for the other MAs, like AD. So after projectin objects from portal using import and sync on FIM MA, run sync on AD MA, this should join objects from AD CS to objects in MV. Assuming that you see the expected amount of joins, you can then turn sync rule provisioning back on.

 

There are other ways to handle reverse join scenarios, but this method is quite easy to implement and if this only happens as an accident from deleting the CS, they it is good idea. If you have design where this might happen often with individual objects, you might look at the reverse-join document in the Design Concepts collection, http://www.microsoft.com/downloads/en/details.aspx?familyid=40A52201-A297-4C35-82E9-F0B4CA05DAEB&displaylang=en.

 

 

Hmm... is there any sort of default join rule associated with the FIM MA?  A related issue is when objects get disconnected from the FIM MA but not deleted (i.e., the objects' type lacks an explicit deletion rule, and only the FIM MA connector is keeping them alive), project into the MV again via another MA, and now you have duplicate keys again.  AFAIK there is no way to configure join rules on the FIM MA... the only solution I know is painstaking deletion of objects through the FIM portal.

--Steve

Steve,

 

You are correct, you cannot change default join rules for FIM MA in current iteration of product. The current rules as I understand them are for MVObjectID and CSObjectID. That's why when this situation occurs, it is often necessary to have FIM MA project objects in MV so that other MAs can join. There is no way for the AD MA to project and then have the FIM MA join unless the previous CSObject or MVObjectID values are preserved in AD or a different MA and then added to the MV before attempting sync on the FIM MA.

 

Also, my undestanding is that inability to configure specific join rules on FIM MA is known issue and is being looked at to be changed in future version of product.

Steve, you might want to take a look at FIM Admin Accound ObjectSID is deleted by FIMMA Sync Rule - ADMA is not doing its job.
Basically, the AD DS accounts used by FIM should not be part of your synchronization implementation.
To protect them from being synchronized, you should put them into an OU that is outside your configured container filter.

Cheers,
Markus 

 

Just to follow up on this................this situation is essentially a reverse-join scenario; objects already exist in the portal but then objects from another directory, such as AD, attempt to re-provision to portal. Because of uniqueness constraints that Steve mentioned, which include ObjectSID and AccountName, you get these errors and you are essentially stuck like this until you can get the objects to join. While you can use the account joiner to manually join them, I typically would not recommend using this tool, as most of the problems that are fixed by this can be fixed more efficiently in other ways.

 

If this is happening for many objects, this could have been caused by deleteing the connector spaces for MAs and then running syncs, etc....I would typically try this first if you have many objects in this state - Turn off the sync rule provisioning in Tools->Options, verify that objects in portal are actually projected into MV. If they are not, go ahead and do so. Because the sync rule provisioning has been turned off, this will also prevent the sync-rule-provisioning errors that state objects already exist. Once objects are in the MV, they presumably will have attribute values populated such as AccountName that are unique and that can be used in inbound sync rules for joins for the other MAs, like AD. So after projectin objects from portal using import and sync on FIM MA, run sync on AD MA, this should join objects from AD CS to objects in MV. Assuming that you see the expected amount of joins, you can then turn sync rule provisioning back on.

 

There are other ways to handle reverse join scenarios, but this method is quite easy to implement and if this only happens as an accident from deleting the CS, they it is good idea. If you have design where this might happen often with individual objects, you might look at the reverse-join document in the Design Concepts collection, http://www.microsoft.com/downloads/en/details.aspx?familyid=40A52201-A297-4C35-82E9-F0B4CA05DAEB&displaylang=en.

 

 

Really saved my day :D

Dear Sir,

I am facing some issue is FIM 2010 while exporting user from another AD environment. Please tell me the feasible time for you so that i can communicate with you on it.

Regards,

Shakeel Shahid.