none
Join not attempted before Projection by FIM MA Sync to disconnectors in AD Connector space. Projection fails with pre-existing CS error.

    Question

  • Scenario: Users are added to a SQL table first and are provisioned correctly to FIM Portal & AD. Some users are initially added to AD directly and subsequently imported & synced from SQL MA - with the intention that during FIM MA sync process they will join with metaverse. To facilitate the join there is accountName=SAMAccountname Relationship Criteria for sync rule declaration in the FIM Portal. The issue seems to be that this criteria does not Join resulting in hundreds of AD accounts remaining in normal disconnector mode. The FIM MA Sync generates error: "Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: An object with DN "CN=xxxx,OU=xxxx,DC=xxxx" already exists in management agent "AD MA"." 

    The recommended method to turn off Synchronization Rule Provisioning and run sync cycles (for all & specifically AD MA) at http://social.technet.microsoft.com/Forums/en-US/36db6716-87c8-499a-b20d-35a96ecf56d8/join-rule-not-working also does not work.

    The process that has worked  for the disconnectors to connect up is to enable the Join property for AD MA in the Sync Console accountName=SAMAccountname. This is sub-optimal as this workaround makes the Join common to multiple provisioned ADs. It would be preferable to have the FIM Portal Sync Rule relationship handle the relationships for individual domains.

    Deployment: FIM2010 R2 with SP1 and latest hotfix.
    • Edited by B Sunny Tuesday, September 24, 2013 6:23 PM
    Tuesday, September 24, 2013 6:21 PM

Answers

  • you do not need to create join rules for all AD domains (in other words no need to do this per AD domain). You just need to have at least one or more (in some order) that can be used by objects in any AD domain.

    you could use:

    * sAMAccountName, but that must be unique within the AD forest

    * userPrincipalName, assuming the attribute does have an explicit value

    * mail address

    * combination of 2 or more attributes


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    • Marked as answer by B Sunny Friday, October 11, 2013 11:16 PM
    Friday, October 11, 2013 10:27 PM

All replies

  • you would need to implement so called reverse joins. More info is available through the following link:

    http://technet.microsoft.com/en-us/library/cc720646%28v=ws.10%29.aspx

    by the way... it is a best practice to ALWAYS have join rules configured in every MA, although not actively used in day-to-day operations. The reason for that is that during initial load OR disaster recovery you need to have those join rules. So, be smart, think about those and implement them. When needed they are already there.


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Saturday, October 05, 2013 7:28 PM
  • Thanks Jorge,

    The situation I describe falls neither under initial load or DR. However, I think you make a good generic recommendation. Could you advise how multiple AD domains can be configured for separate join criteria and would this affect the sync performance.  

    Friday, October 11, 2013 6:39 PM
  • you do not need to create join rules for all AD domains (in other words no need to do this per AD domain). You just need to have at least one or more (in some order) that can be used by objects in any AD domain.

    you could use:

    * sAMAccountName, but that must be unique within the AD forest

    * userPrincipalName, assuming the attribute does have an explicit value

    * mail address

    * combination of 2 or more attributes


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    • Marked as answer by B Sunny Friday, October 11, 2013 11:16 PM
    Friday, October 11, 2013 10:27 PM
  • Thanks Jorge!

    B Sunny

    Friday, October 11, 2013 11:16 PM