I’m currently writing a guide on how to transition a FIM configuration from a lab to an acceptance environment. The great part is that MS already has some nice work on this and has the PowerShell scripts ready for download. The step by step guide (and scripts) can be found at Technet: FIM 2010: Configuration Migration Deployment Steps

One of the steps allows you to sync the exported config of the lab environment with that of the acceptance environment: syncpolicy.ps1

And then things went wrong (a copy paste):

PS C:\FIM\Migration Scripts> .\SyncPolicy.ps1
Loading production file  C:\FIM\Migration Scripts\ProductionPolicy.xml .
Loaded file  C:\FIM\Migration Scripts\ProductionPolicy.xml . 760  objects loaded.
Loading pilot file  C:\FIM\Migration Scripts\PilotPolicy.xml .
Loaded file  C:\FIM\Migration Scripts\PilotPolicy.xml . 801  objects loaded.

Executing join between pilot and production.

Join-FIMConfig : Two objects with the same AnchorAttributeValue were detected. A requirement for using this migration tool is that AnchorAttributeValue is unique with an Object Type.
AnchorAttributeNames = DisplayName
AnchorAttributeValues = Displayname
ObjectType = ManagementPolicyRule
ObjectID 1 = urn:uuid:1aaf99c7-e7d8-42c0-bc53-457fdd74f330
ObjectID 2 = urn:uuid:17dbb6a7-5271-4ea3-9ca3-58d1836b4575
…

What it basically was telling is that there were two objects with the same display name. The syncpolicy.ps1 script does not like this. Using the Object ID it’s quit easy to find out which ManagementPolicyRules (MPRs) are involved. One can use PowerShell to retrieve extra attributes given the ObjectID:

Set-Variable -Name URI -Value "http://fimsvc.corp.contoso.com:5725/resourcemanagementservice" -Option Constant
$dest = get-location

#Get information for a specific object
$ExportObject = Export-FIMConfig -uri $URI –customConfig "/*[ObjectID='acbcad3b-8394-4af3-a1d4-149cabae05d1']" -onlybaseresources -ErrorVariable Err -ErrorAction SilentlyContinue 
If($Err){Throw $Err}
If($ExportObject -eq $null) {throw "Object not found in your environment"}
$exportObject | ConvertFrom-FIMResource  -file $dest\object.xml

I am by no means a PowerShell guru so there are probably 10 ways to write the above code in a more decent/efficient way. But it gets the job done. A nice resource on FIM PowerShell stuff is the TechNet: FIM ScriptBox As an alternative to writing some code yourself there’s also the FIM Object Visualizer which has an option to get a HTML page of an object given it’s ObjectID. Quick and easy! The FIM Object Visualizer is also a great to tool to aid you in documenting your FIM solution. Just make sure you use the “c:\windows\system32\mshta.exe” when launching the HTA on Windows 2008 R2 (X64…), I like creating a shortcut to the HTA which has the mshta.exe path in front of it.

After doing the above research it seems there are two MPR’s with the same display name: “Users can create registration objects for themselves”. One which applies for create and one which applies for Create, Modify. 

After renaming one of those MPR’s, in both lab and acceptance, re-running the exportPolicy.ps1 scripts I re-ran the syncPolicy.ps1 script and everything worked out fine: 

While I was browsing the TechNet Forums: Two MPRs with the same name after FIM 2010 Update 1 today I noticed someone mentioning the same issue and workaround. As I already began writing this post a few days ago I decided to post it nevertheless. Anthony Ho mentioned there has been filed a bug request and that the FIM 2010 Update 1 release notes will be updated. Seems like one of the MPR’s should have replaced the other one. Renaming is a workaround, but not the ideal solution. We’ll get more info soon.