Why does an Outbound Sync Rule ask you to configure a relationship criteria? The book says that the relationship criteria is used by an OSR during the inbound sync phase: http://technet.microsoft.com/en-us/library/ff608273(WS.10).aspx However, my testing isn't showing that to be the case. If I have an OSR with a relationship creiteria set, I do not see a join occuring based on that criteria. I do see the join occur if I have the same relationship criteria set on an inbound sync rule. The sync rule is present in the MV and at least one of my MV objects has the ERE for it. I have also tested the case where the CS object is joined to the MV but the relationship criteria is no longer valid. In this case, the outboud attribute flow from the OSR still takes place. So - back to my original question: Why does an OSR have a relationship critera? My testing shows that it is not used. -JeremyJeremy Palenchar

If not for the relationship, what would trigger an external account to be provisioned or deprovisioned? If the account names are different, how would you key on the correct account?Alex Trusler Systems Engineer

Thanks for the response Alex, I would think that we would provision an account if the number of connectors in the target system = 0. Are you suggesting that the relationship criteria determines if an object gets provisioned? If so, what is the logic in the following cases: 1 - connectors = 0 but there is an object in the CS that matches the relationship criteria 2 - connectors = 1 and the connected object does not match the relationship criteria If the relationship criteria for an OSR controls provisioning, why doesn't the book say so? Why does it mention its use "during the inbound sync phase"? -JeremyJeremy Palenchar

I have to admit that I struggled with this wednesday as well. It wasn't my FIM deployment and I'm just there to do other stuff. But still I looked into it for a bit. Situation: There's a FIM MA and an AD MA. Some security groups already exist in AD. In the Portal there's an OSR with provisioning enabled and relationship criteria: accountName = sAMAccountName. No ISR's. Now I would expect the provisioning logic to find&join the existing groups in the AD CS (when creating groups with an already existant name), but that was clearly not the case. I was getting "provisioning exceptions: dn already exists blabla". When I turned off provisioning in the synchronization service manager options the errors went a way but no joins occured. So I'm really wondering how you can cover this with FIM. Relationship Criteria on ISR won't be of any use as the object isn't projected in the MV due to the above provisiong error. So that's a bit of chicken/egg.http://setspn.blogspot.com

Thomas, there is no forward join in FIM. In other words, the relationship criteria in an OSR has no associated outbound activity - it is an inbound setting in an outbound synchronization rule. If you need to "sync up" existing objects, the way you did this (switching provisioning off), is the right way to handle this. Jeremy, if the feature doesn't show the designed behavior, you should contact PSS. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Markus, Are you suggesting that a relationship criteria is meaningless in a sync rule that is Outbound only (as I was finding in my testing)? Therefore it is only meaningful in a sync rule that is inbound or both inbound and outbound? If so, then I think I will take your suggestion and open a case with PSS so that relationship criteria is no longer a mandatory configuration for a sync rule that is outbound only. -JeremyJeremy Palenchar

Please do so and open a case. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I have noticed the same behavior as Jeremy. I had several Outbound-only Synch Rules defined within the FIM Portal...because they should only be exporting data in the form of updates/adds to the connected system. However, no joins were occurring to existing objects in those connected systems unless I changed the Synch Rules as Inbound and Outbound. Is this the intended behavior? If so, what are my options? I suppose they are: 1) change the outbound synch rules to outbound and inbound. 2) Use join rules on the actual MA within Synchronization Service Manager. Please advise...

You should avoid using non-declarative synchronization rule. They only exist for down-level compatibility. Especially, in the case of this scenario, you really don't need them. You could change the synchronization rule to in- and outbound. Personally, I would create a separate inbound synchronization rule. However, this is just a personal preference because I think that a configuration is easier to read and if necessary to troubleshoot this way. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Great...thanks, Marcus. That was the info I was looking for. Appreciate it...

One last question on this topic...what if I need to be able to try multiple join conditions in order to join objects between the MV and CS? The relationship criteria only allow you to set multiple conditions that are ANDed together...correct? In "classic" join rules, you can OR join conditions. So, is the recommendation to use non-declarative join rules on the MA in that case?

Jeremy, Although this is an old thread I thought I might add my 2 cents worth. I beleive the Relationship criteria on an outbound sync rule is used by the Expected State Detection (ESD) feature of FIM 2010. From my understanding you can have an out bound sync rule which is not part of a provisioning policy (Sync Rule + MPR + Set). Also known as an operational outbound sync rule. This rule would only consist of existence test based attributes to determine a DRE. Technically these attributes (existence test attributes) are actually applied on the inbound sync anyway. for more info see http://technet.microsoft.com/en-us/library/ff608269(WS.10).aspx Hope this helps Phil

Markus, When you say create an inbound sync rule are you saying create an inbound sync rule with attribute flows of the fields you need. For example i'm using extensionAttribute10 in AD to join with a metaverse attribute 'bannerID'. After reading this I think I understand why I keep getting DN already exist errors in ADDS. However, should I now have an inbound rules setup to bring that vlue in from ADDS if it already exists?