Hello,

When we original setup FIM 2010 R2 we only had one domain (AD1). Our original  inbound sync rule has a relationship criteria based on MetaverseObject:accountName = ConnectedSystemObject:sAMAccountName. 

After a few months we added a second domain (AD2), which has a inbound sync rule based on MetaverseObject:ObjectSID = ConnectedSystemObject:ObjectSID.

Each end user has an account in both domains and the same username is used. Our problem occures when a user is pulled into FIM from AD2 first then the same username is added from AD1. Since AD1's relationship is based on accountName, it tries to join with the AD2 object which has the same username.

I believe a solution would be to add a second relationship criteria to AD1 which would be :ObjectSID = ConnectedSystemObject:ObjectSID

Does this sound like a possible solution? what happens to all the exisitng objects if i add a second relationship to an existing inbound rule?

Any information is appreciated.

thanks,

Josh

A second relationship criteria will not work, but you have 2 options. Either replace the relationship with another attribute, say objectSID, DN, or something specific to this domain only. Or, maybe it a compound relationship, say; sAMAccountName+domainName.

Thanks Nosh,

Both are great ideas. What happens to the existing objects when I change the inbound SR? I'm assuming during the next Run all objects would be updated. Is there any negative side effects to changing an existing SR?

thanks again

Josh

Current objects will be updated, if they are not joined. The obes who are joined already will not be effected. There are no Negative effects as long as you ensure the attributes you choose to join on are unique in both domains. sAMAccountName+domainName is 100% safe.

Thanks again Nosh.

So it is as simple as changing the current relationship critera from

MetaverseObject:accountName = ConnectedSystemObject:sAMAccountName

to

MetaverseObject:accountName = ConnectedSystemObject:sAMAccountName+domainName?

I'm assuming that if I run my regular Automated Run profile (Delta Import, Delta Sync, Export), that the changes will be applied to all AD1 objects in the metaverse.

or would it be better to run a  full import, full Sync, export and delta import.

thanks,

Josh

• Edited by Jgonsalves 11 hours 50 minutes ago

You will need a full sync the first time, most likely, depending on how the data looks like now. It does not hurt anyways, so go for a full sync.  No Full Import necessary, you only need a full sync.

So, here is a little more explanation of this.

In Portal Rules, you cannot have a compound relationship criteria. It is an OR, which is same as having one or the other. 

So, you would have to do this in Classical Rules.  Which means you set this view to NULL as here,

And create the join Rule in FIM Sync client as below.

Thanks again Nosh.

So it is as simple as changing the current relationship critera from

MetaverseObject:accountName = ConnectedSystemObject:sAMAccountName

to

MetaverseObject:accountName = ConnectedSystemObject:sAMAccountName+domainName?

I'm assuming that if I run my regular Automated Run profile (Delta Import, Delta Sync, Export), that the changes will be applied to all AD1 objects in the metaverse.

or would it be better to run a  full import, full Sync, export and delta import.

thanks,

Josh

• Edited by Jgonsalves Tuesday, August 25, 2015 7:30 PM

Hi Nosh,

I'm wondering why I can not simply modify the relationship criteria? So simply switch it from accountName to Object Sid.

thanks for all your help

J

You can.

Also, be aware that the relationship criteria is important only if you have users in AD and FIM and you need to join them, otherwise, this is not relevant.