I am trying export from pilot to production and am having an issue with join btw pilot & prod. My MV join attribute is employeeID. Source MA anchor attribute flows into that MV attribute. All other systems join to that attribute, with different attribute names, ie. oracleID. I tried modifying SyncPolicy.ps1 for person object but I get the following error. What am I missing? modify: $joinrules = @{ # === Customer-dependent join rules === # Person and Group objects are not configuration will not be migrated. # However, some configuration objects like Sets may refer to these objects. # For this reason, we need to know how to join Person objects between # systems so that configuration objects have the same semantic meaning. Person = "employeeID"; Group = "DisplayName"; Thanks,Dan ERROR Join-FIMConfig : Unable to find anchor attribute 'employeeID' for object type 'Person' with identifier urn:uuid:b2a520 47-081e-485e-8000-32bc8ad136a1. At C:\Users\jamehi03\SyncPolicy.ps1:64 char:26 + $matches = Join-FIMConfig <<<< -source $pilot -target $production -join $joinrules -defaultJoin DisplayName + CategoryInfo : InvalidData: (:) [Join-FIMConfig], InvalidOperationException + FullyQualifiedErrorId : JoinConfig,Microsoft.ResourceManagement.Automation.JoinConfig Matches is null. Check that the join succeeded and join criteria is correct for your environment. At C:\Users\jamehi03\SyncPolicy.ps1:67 char:10 + throw <<<< (new-object NullReferenceException -ArgumentList "Matches is null. Check that the join succeeded and join criteria is correct for your environment.") + CategoryInfo : OperationStopped: (:) [], NullReferenceException + FullyQualifiedErrorId : Matches is null. Check that the join succeeded and join criteria is correct for your en vironment.

Are you aware why these "joinrules" exist for person/group? These are just to make sure that whenever such an object is referenced in a set, mpr, workflow, ... it's migrated happily. I'm not really sure how to read your error. Here's what I would do: Is the "employeeID" attribute bound to the Person object in the target FIM? Do you have any person objects in the target FIM with the employeeID value populated which should join up? => I think this is the cause, it's saying it jsut doesnt find a user... What object matches to guid b2a52047-081e-485e-8000-32bc8ad136a1 does it ring a bell? Tip to search that guid: go to the portal click administration, and then change the search scope to "look up by guid" orso. You'll might have to search both your target and source fim for this guid. i'm not 100% sure where it's coming from. http://setspn.blogspot.com

I find it in the Pilot config. Located in two places. Its an orphaned user in the pilot fim. Do I modify the xml, or delete then rerun exportpolicy for pilot?

are all persons on the portal pilot environment have employeeID filled, you have a SET or Group that has an explicit member - manual membership - pointing to that person who does not have a "employeeID". I think the anchor attribute "employeeID" should not be null on all persons.

Amer: Right there is two users that are of orphaned, no employeeID, not alot of info. I cant delet the in the Pilot portal. Can I delete them out of the pilot policy xml?I dont need them.

I deleted them out of the pilotPolicy xml, however it still sees them, still throws the error.

its not recommended to modify the xml files manually

I was able to delete the object guid and it got past that error. However I had two. The second is more prevalent in the xml, its attached to the AttributeName Creator for a ton of objects. <AttributeName>Creator</AttributeName> <HasReference>false</HasReference> <IsMultiValue>false</IsMultiValue> <Value>urn:uuid:fb89aefa-5ea1-47f1-8890-abe7797d6497</Value> </ResourceManagementAttribute> So I definitely more worried about deleting this one. If I can't modify then what are my options, I can't migrate at this point. It fails. Any thoughts? Thanks,Dan

I have the same situation as this thread: After applying FIM 2010 Update 1, the DisplayName, MailNickname, and (in some cases) Domain attributes for the built-in synchronziation account (uid=fb89aefa-5ea1-47f1-8890-abe7797d6497) are no longer there. We suspect this happens after the first run of the FIM MA import run profile. FIM 2010 with Update 1 was able to synchronize users even without the above attributes. The issues comes around when trying to run the Join-FIMConfig cmdlet. Since this cmdlet tries to join the Person objects with the DisplayName and MailNickname attributes. Since the attributes are not there, the cmdlet throws an exception and ends. A work around is to just add the DisplayName and MailNickname, but we need to know why these attributes are stripped after Update 1. http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/b1182e58-7e76-4a2b-bbd2-19e5bd034ca3 Not sure when it happened though. Buy how do you get the Built-In-Sync account back to "normal"?

As Amer points out it's definately not recommended on editting those XML's manually. Except for the resulting "changes.xml". For which (imo) you can do some intelligent search and replace (like for domain specific names and so). I would suggest you rexport the policy in both environments and start over migrating your config.http://setspn.blogspot.com

I'm curious as to why you would be wanting to migrate user objects between environments, since I always exclude users and (non-dynamic) groups entirely from the migration process ... loading both via the AD and FIM MAs as part of the "initial load" process. I gather that your "pilot" environment is a copy of your production AD ... and that you are doing it this way to save sync processing time? As stated above, if you nominate employeeID as the join attribute then there is a prerequisite that this attribute must be present in both environments for all users in order for migration to be successful ... so in your case (if your pilot environment is using users from the same AD) you may be able to join on objectSid ... or even "employee objectSid".Bob Bradley, www.unifysolutions.net (FIMBob?)

My problem was the duplicate MPR's from update 1. I was able to rename and rerun migration scripts. everything went great. Thanks, Dan