Hi, I am exporting custom resource instances using standard Export-FIMConfig procedures. I exported the schema definition and after that I use: (Export, custom) $custom = Export-FIMConfig -MessageSize 9999999 -customConfig ("/MyCustomResource") Followed by a standard Sync and Commit. It worked fine, but commited resources ObjectIDs have been changed in production environment. I tried (Sync) $joinrules = @{ MyCustomResource= "ObjectID"; } ..... $matches = Join-FIMConfig -source $pilot -target $production -join $joinrules (Commit) $imports = ConvertTo-FIMResource -file $changes_filename -------------- But resources still change its ObjectID at production environment. Is it any way to request to have the SAME ObjectID? Thank you in advance!

I expect to have a similar challenge in the future once I get to the point where I am deploying FIM and not just testing and developing. Is it possible for you to join on a resource's name rather than the ObjectID?

You can't specify an ObjectID. As a result you end up having to join on something like DisplayName. This works up to the point where you start renaming objects.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

You can't specify an ObjectID. As a result you end up having to join on something like DisplayName. This works up to the point where you start renaming objects.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Hi Daniel, Objects that are created in FIM are automatically assigned an ObjectID. Since these IDs are generated randomly by your FIM instance, it is recommended that you do not use ObjectID as the join criteria. Billy

Hi Daniel, Objects that are created in FIM are automatically assigned an ObjectID. Since these IDs are generated randomly by your FIM instance, it is recommended that you do not use ObjectID as the join criteria. Billy

are these custom objects referenced by other objects in FIM portal, that's why you want the same ObjectID to be shipped ? if that's not the case, you can just migrate configuration objects only (schema, policies, sets, etc ...) from the pilot environment and re-load the actual resources again in the production Billy, so the SourceObjectIdentifier for ImportObjects (which are generated from the changes.xml) are not used for the actual resource creation ? It's never too late in life ... to start living

are these custom objects referenced by other objects in FIM portal, that's why you want the same ObjectID to be shipped ? if that's not the case, you can just migrate configuration objects only (schema, policies, sets, etc ...) from the pilot environment and re-load the actual resources again in the production Billy, so the SourceObjectIdentifier for ImportObjects (which are generated from the changes.xml) are not used for the actual resource creation ? It's never too late in life ... to start living

Hi everybody, Thank you very much for your multiple answers. Amer, SourceObjectIdentifier of ImportObjects is not used. We saw them in the changes.xml but new GUIDS are assigned at commit. Resuming our situation a) Custom resource objects are pointed by Person instances. b) Sets are established using user (any) CustomMultiValuedProperty contains CustomResourceInstance1 CustomProperty is CustomResourceInstance1 resolved as /Person[(CustomMultiValuedProperty = 'PilotObjectIDValue') or (CustomProperty = 'PilotObjectIDValue')] We are looking for workarounds using (very fragile) displaynames but we are surprised to see that all ObjectID examples in FIM documentation are in fact not exportable to production environment in a real life situation. Thank you again!