Hi, We are experiencing an issue with an AD user account move as follows: - for testing we have 2 main "location" attributes (FIM Portal is authoritative for this attribute) - also we have 3 "employeeType" attributes (FIM Portal is authoritative for this attribute) - the entire OU structure already exists in AD: - /staff/location1/adatum/com - /staff/location2/adatum/com - /contractor/location1/adatum/com - /contractor/location2/adatum/com - /student/location1/adatum/com - /student/location2/adatum/com In the AD sync rule, we have defined 2 x DN attribute flows, one initial, the other one not initial. The rule looks like this: "CN='accountname', OU='employeeType', OU='location', DC=adatum, DC=com" => dn The new user account is initially provisioned correctly in the correct OU (based on location & employeeType attributes). if we just change the "location" attribute in the Portal, the AD User is moved to the correct OU as expected. here is the problem: if we just change the "employeeType" attribute - the AD user account is NOT moved to the correct OU. Why does it work on the "location" attribute and not the sub-OU and "employeeType" attribute? regards, SK

I can't think of an obivous reasion. But I would: Check that the employeeType attribute is modified in the MetaVerse upon modification in the Portal Run a full sync preview after you did a delta import on the FIM MA (when changing the employeeType attribute) Tripple check the ERE is attached to the user you are testing with http://setspn.blogspot.com

go to the sync service manager -- search the metaverse -- select one of the objects that should move open its conenctors tab open the fim ma connector and run preview -- is the employeetype flowing into the metaverse? Is it updating the DN. Remember that sync rules are accessing attributes in the metaverse not the FIM database, so if employeetype isn't flowing into the metaverse then the sync rule won't calculate the new dn. Does the preview indicate that the dn flow is not applied, not precedent? If so then is there another sync rule?David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

go to the sync service manager -- search the metaverse -- select one of the objects that should move open its conenctors tab open the fim ma connector and run preview -- is the employeetype flowing into the metaverse? Is it updating the DN. Remember that sync rules are accessing attributes in the metaverse not the FIM database, so if employeetype isn't flowing into the metaverse then the sync rule won't calculate the new dn. Does the preview indicate that the dn flow is not applied, not precedent? If so then is there another sync rule?David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

Thank, I just redid the entire OU structure and Sync Rules in my lab environment and it works as expected. There is one difference between my lab and the company test environment: - in my lab I have 1 Sync Rule; irresepective of 'employeeType' - in the (non working) test environment I have 3 Sync Rules (Staff, student and contractor). Each Sync rule has got exactly same attribute flows - just kept them separate in case I ever wanted to flow different attributes for the different Sets (Staff, student and contractor). Could the fact that I have 3 AD provisioning Sync Rules have anything to do with it not working?

Thank, I just redid the entire OU structure and Sync Rules in my lab environment and it works as expected. There is one difference between my lab and the company test environment: - in my lab I have 1 Sync Rule; irresepective of 'employeeType' - in the (non working) test environment I have 3 Sync Rules (Staff, student and contractor). Each Sync rule has got exactly same attribute flows - just kept them separate in case I ever wanted to flow different attributes for the different Sets (Staff, student and contractor). Could the fact that I have 3 AD provisioning Sync Rules have anything to do with it not working?

Yup, If you got 3 'provisioning' SR, which rougly flow the same attributes, but have a different "permanent' DN flow, you'll have to make sure if the employeeType changes, this triggers the removal of the "old" employeeType SR and adds the "current" employeeType SR. This can be done with Transitioning MPR's and WF's. Having multiple SR's on a object which flow to the same attribute can have undesired (or no) effects... Do you understand where I'm going with this? or do I need to elaborate? Regards, Thomashttp://setspn.blogspot.com

Yup, If you got 3 'provisioning' SR, which rougly flow the same attributes, but have a different "permanent' DN flow, you'll have to make sure if the employeeType changes, this triggers the removal of the "old" employeeType SR and adds the "current" employeeType SR. This can be done with Transitioning MPR's and WF's. Having multiple SR's on a object which flow to the same attribute can have undesired (or no) effects... Do you understand where I'm going with this? or do I need to elaborate? Regards, Thomashttp://setspn.blogspot.com

yes I understand. Here is an example for one 'employeeType': - 'Contractor Set' - 'Contractor Sync Rule' - 'Add Contractor User Workflow' linked to the 'Contractor Sync Rule' - 'Add Contractor MPR' linked to the 'Contractor set' (transition in); linked to the 'Add Contractor User Workflow' This process is repeated for the other 'employeeType'. I might just rework everything so its a bit simpler - as it might be an unnecessary complication of MPRs, workflows, etc What do you think?

yes I understand. Here is an example for one 'employeeType': - 'Contractor Set' - 'Contractor Sync Rule' - 'Add Contractor User Workflow' linked to the 'Contractor Sync Rule' - 'Add Contractor MPR' linked to the 'Contractor set' (transition in); linked to the 'Add Contractor User Workflow' This process is repeated for the other 'employeeType'. I might just rework everything so its a bit simpler - as it might be an unnecessary complication of MPRs, workflows, etc What do you think?

Ah, there you go. So if you change someone to another employeeType, the other MPR will fire and the "other" SR will be added. However because you got two ERE (for both types) on the User, the Sync Engine doesnt know which DN to flow... So: You put everything in one SR flow OR You modify your WF's to remove both other employeeType SR before adding the tobe employeeType SR. This way you can freely move users from one type to another, they'll always have the correct SR attached. Say "contractor" WF: Remove student SR Remove staff SR Add contractor SR Say "student" WF: Remove staff SR Remove contractor SR Add Student SR http://setspn.blogspot.com

Ah, there you go. So if you change someone to another employeeType, the other MPR will fire and the "other" SR will be added. However because you got two ERE (for both types) on the User, the Sync Engine doesnt know which DN to flow... So: You put everything in one SR flow OR You modify your WF's to remove both other employeeType SR before adding the tobe employeeType SR. This way you can freely move users from one type to another, they'll always have the correct SR attached. Say "contractor" WF: Remove student SR Remove staff SR Add contractor SR Say "student" WF: Remove staff SR Remove contractor SR Add Student SR http://setspn.blogspot.com

Thomas - that makes complete sense. Will revert back to the forum once resolved - thank you again !

Thomas - that makes complete sense. Will revert back to the forum once resolved - thank you again !

Ah, there you go. So if you change someone to another employeeType, the other MPR will fire and the "other" SR will be added. However because you got two ERE (for both types) on the User, the Sync Engine doesnt know which DN to flow... So: You put everything in one SR flow OR You modify your WF's to remove both other employeeType SR before adding the tobe employeeType SR. This way you can freely move users from one type to another, they'll always have the correct SR attached. Say "contractor" WF: Remove student SR Remove staff SR Add contractor SR Say "student" WF: Remove staff SR Remove contractor SR Add Student SR http://setspn.blogspot.com I usually do the opposite of this and simply control it with precedence on the sync rules. Keeping people in each SR they're entitled to (if you can have multi-role people) makes deprovisioning easier too.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Ah, there you go. So if you change someone to another employeeType, the other MPR will fire and the "other" SR will be added. However because you got two ERE (for both types) on the User, the Sync Engine doesnt know which DN to flow... So: You put everything in one SR flow OR You modify your WF's to remove both other employeeType SR before adding the tobe employeeType SR. This way you can freely move users from one type to another, they'll always have the correct SR attached. Say "contractor" WF: Remove student SR Remove staff SR Add contractor SR Say "student" WF: Remove staff SR Remove contractor SR Add Student SR http://setspn.blogspot.com I usually do the opposite of this and simply control it with precedence on the sync rules. Keeping people in each SR they're entitled to (if you can have multi-role people) makes deprovisioning easier too.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

I think it depends on whether a user can simultaneously be staff and student. If they can then precedence is definitely the way to go (what Brian said). If they can't you could do add and remove sync rules (what Thomas said). If however the flows are really similar with just different OU then you could put it all in one sync rule and use the expression builder to sort them into the different OUs.David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

I think it depends on whether a user can simultaneously be staff and student. If they can then precedence is definitely the way to go (what Brian said). If they can't you could do add and remove sync rules (what Thomas said). If however the flows are really similar with just different OU then you could put it all in one sync rule and use the expression builder to sort them into the different OUs.David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

Hi, No, a user can only ever be one 'employeeType'. I thought of creating one Sync Rule - however, one set of users need to get a live@edu account so their attribute flow will therefore be slightly different. Just wanted to confirm one thing in the above example - how do we actually remove a SR as you recommend above? "Say "student" WF: Remove staff SR Remove contractor SR Add Student SR " thank you

Hi, No, a user can only ever be one 'employeeType'. I thought of creating one Sync Rule - however, one set of users need to get a live@edu account so their attribute flow will therefore be slightly different. Just wanted to confirm one thing in the above example - how do we actually remove a SR as you recommend above? "Say "student" WF: Remove staff SR Remove contractor SR Add Student SR " thank you

Just wanted to confirm one thing in the above example - how do we actually remove a SR as you recommend above? "Say "student" WF: Remove staff SR Remove contractor SR Add Student SR " thank you When you add a Sync Rule activity to a workflow, there will be Add and Remove options - you'll want to pick the Remove one.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Just wanted to confirm one thing in the above example - how do we actually remove a SR as you recommend above? "Say "student" WF: Remove staff SR Remove contractor SR Add Student SR " thank you When you add a Sync Rule activity to a workflow, there will be Add and Remove options - you'll want to pick the Remove one.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Got it...so essentially when users 'transition out' of a set, then I can select this 'remove' option, yes?

Got it...so essentially when users 'transition out' of a set, then I can select this 'remove' option, yes?

Got it...thank you!

Ah, there you go. So if you change someone to another employeeType, the other MPR will fire and the "other" SR will be added. However because you got two ERE (for both types) on the User, the Sync Engine doesnt know which DN to flow... So: You put everything in one SR flow OR You modify your WF's to remove both other employeeType SR before adding the tobe employeeType SR. This way you can freely move users from one type to another, they'll always have the correct SR attached. Say "contractor" WF: Remove student SR Remove staff SR Add contractor SR Say "student" WF: Remove staff SR Remove contractor SR Add Student SR http://setspn.blogspot.com Hi, just tried this method - but now FIM deletes the AD user account, and creates a new one in the new OU location - instead of doing a 'move' operation. How do we get FIM to move the user instead?

Hi, well, I couldnt get it to work with multiple Sync Rules (without FIM deleting and creating a brand new user). So I rewrote all the logic and placed it in a single Sync Rule. Now everything works fine. Thank you