I noticed after Update 1, there are now two MPRs with the same DisplayName (Users can create registration objects for themselves). However, these are two seperate objects because both have different uids. Also, one applies to Create and Modify and the other only applies to Create. In the SyncPolicy.ps1 script (http://technet.microsoft.com/en-us/library/ff400283(WS.10).aspx), the following comment is around MPR join criteria: # === Policy configuration === # Sets, MPRs, Workflow Definitions, and so on. are best identified by DisplayName # DisplayName is set as the default join criteria and applied to all object # types not listed here. So, is there a way to to change the join rules for Join-FIMConfig to use another attribute other than the default DisplayName for MPRs? Or is this just an error with the update or could the DisplayName no longer be unique in future updates? fyi - The workaround we used is just changing the DisplayName of one of the MPRs, but we feel this is not a good long term approach. Thanks, Bryan

Taken offline through PSS. For others, please refer to IMT 27077 when contacting PSSThe FIM Password Reset Blog http://blogs.technet.com/aho/

I also came upon this issue. I am/was currently in progress about writing a blogpost about this. I renamed one of those MPR's as a workaround. But I guess a more decent/ MS advised solution would be nice. http://setspn.blogspot.com

the RelNote will be updated. stay tuned basically the two new MPRs are meant to replace the old one

Any updates on this? I've just been enabling the one flagged as "Create, Modify" and leaving the other one disabled.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

you are supposed to use the 2 splited MPR instead of the combined one with "Create + Modify" i haven't got an ETA to update the relnote yet. Sorry about thatThe FIM Password Reset Blog http://blogs.technet.com/aho/

relnote has been updated http://support.microsoft.com/kb/978864The FIM Password Reset Blog http://blogs.technet.com/aho/

relnote has been updated http://support.microsoft.com/kb/978864 The FIM Password Reset Blog http://blogs.technet.com/aho/ Thanks Anthony. I ran into this last week. Looking at the article I am still a bit confused how this solves the problem. Follwoing these instructions will not fix the issue if you have NOT modified the MPR. To accomodate this bug I have to update this MPR on the source and target systems when using DisplaName in my join rules. Not an optimal tact but I would at least like to the article reflect this correctly. Thanks Paul Update 1 adds two new Management Policy Rules (MPRs). The new MPRs are: “Users can create registration objects for themselves” (Action Type: Create) “Users can modify registration objects for themselves” (Action Type: Modify) These new MPRs are intended to replace the “Users can create registration objects for themselves” (Action Type: Create, Modify) MPR. If you have modified the old “Users can create registration objects for themselves” (Action Type: Create, Modify) MPR, you will need to apply those modifications to the new MPRs before you delete the old MPR. To do this, follow these steps: In the FIM Portal, click Management Policy Rules. Filter the list of MPRs by searching for the term “registration objects.” If you have modified the old “Users can create registration objects for themselves” (Action Type: Create, Modify) MPR, modify the two new MPRs accordingly. Delete the old “Users can create registration objects for themselves” (Action Type: Create, Modify) MPR.