How do you use parameters in a synchronization rule?For example, when I create the DN in an AD outbound rule, how can i set the DC part of the DN to use a constant value specified somewhere else, so that when I migrate the configuration from pilot to production, where the domain name is different, the rule still works with no modifications?Note: I opened a feature request on connect for this topic - please vote it if you think this could be useful.Thanks,Paolo Paolo Tedesco - http://cern.ch/idm

Hi Paolo! I must say I'm not familiar with the migration tool yet but if you don't migrate the outbound sync workflow (I'm not sure this is possible) you could add a function activity before the sync rule activity and write the DC part to for example [//WorkflowData/DCPart] and then use that value as a parameter into your outbound sync rule (you must specify the parameter in the sync rule first) by using the sync rule activity. Another more advanced option could be a custom resource for holding information specific to the environment and then a custom workflow activity to fetch the custom resource data and write it into the sync rule using the sync rule activity. Edit: The best way would be to use the Domain Attribute on your user and depending on that use a Function Activity (IIF function) before the outbound sync activity to create your DC part. //Henrik Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Hi Henrik, thanks for your reply! Using the domain attribute is a very good idea, but my question was more generic. I had thought to use workflow parameters and edit them after the migration, but I wanted to check if there was a recommended way to do this - I guess that whoever needs to migrate configuration from pilot to production will have to face this problem somehow... Cheers, PaoloPaolo Tedesco - http://cern.ch/idm

In ILM, we have using a XML file to retrieve custom parameters as a best practice.However, this is just necessary to avoid rebuilding a dll if a parameter changes. In FIM, we dont have this issue. An SR is already a configuration file - it is not a component that needs to be recompiled. From that perspective, I would think that modifying custom parameters such as the domain name is more a regular migration task.What I mean is that there is no difference between updating the SR itself or updating a configuration file (if there were one). There is not really a need to provide the values as parameters to avoid changing the SR.So, this is more a doc item update environment specific attribute values after importing SRs to the target environment What do you think?Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, Thanks for your answer. I see your point, but I still think that having a set of configuration constants defined somehow would be nice. I don't like much the idea of editing the SRs after the migration manually, as I'm sure I'll miss one item sooner or later, and editing the SRs programmatically, on the other hand, is not that easy... I would prefer to have all my configuration parameters in one place (be it a file or a set of objects in FIM). In that way, it would be easier to make sure that you edit them all, and the process would need to be done only on the first migration. This is just my opinion, anyway :) Cheers, PaoloPaolo Tedesco - http://cern.ch/idm

You can either file a bug via connect or you can also try to get some feedback from others by opening a Suggestion Box post. Right now, there is no best practice for this case defined, which doesnt mean that there is no need for it. Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, thanks for your suggestions, I made this thread a suggestion box discussion. I posted a feature request on connect . Cheers, Paolo Paolo Tedesco - http://cern.ch/idm