# FIM Configuration Migration

• ### Question

• Has anyone had much success with migrating FIM configurations from lab to prod (or the other way around) using this TechNet article?

http://technet.microsoft.com/en-us/library/ff400277(WS.10).aspx

I've used it a couple of times but always seem to have an issue when migrating the portal policy from one environment to the next.  If you have any custom sets created in the source, it will fail because the members of those sets are likely not in destination environment.  So what's the best way to overcome this issue?  I'm attempting to rebuild my lab based on what I've got in production.  It's not practical to remove the sets in Prod just so I can export a policy config that will work in my lab.  The other option that MS recommends is bringing those users into the Portal prior to running the policy import.  Has anyone tried this?  Won't the resource IDs be different on the user accounts from one environment to another?  If that's the case I would think it would fail anyway.  Not to mention the fact that if you're using Sync Rules to bring in data to the MV, rather than an MA, those won't be available because you haven't yet Synced the policy into this environment.

Jeff

Thursday, January 5, 2012 2:18 PM

• Yes Jeff - that's what I am saying.  Have a look on  http://technet.microsoft.com/en-us/library/ff400264(WS.10).aspx and scroll down to where it talks about the -customConfig directive.  To use this you can specify as many queries in quotes separated by commas, e.g.

... -customConfig "/Set[not(starts-with(DisplayName,'ZZZ'))]","/Group[not(starts-with(DisplayName,'ZZZ'))]" -MessageSize 9999999 -AllLocales

Note the use of the last 2 directives which are explained on the above link.

Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
• Marked as answer by Friday, January 6, 2012 2:20 PM
Friday, January 6, 2012 3:27 AM

### All replies

• Has anyone had much success with migrating FIM configurations from lab to prod (or the other way around) using this TechNet article?

Yes ... the concept works well in principle, but does require you to understand it enough to allow for the inevitable exceptions that will be thrown your way.

I've used it a couple of times but always seem to have an issue when migrating the portal policy from one environment to the next.  If you have any custom sets created in the source, it will fail because the members of those sets are likely not in destination environment.  So what's the best way to overcome this issue?

Apart from the MS-recommended method you mention below (which DOES work because the sync process looks up each user by AccountName and substitutes the local guids for static set/group members) a method I often use when I need to migrate static set/group members (when there are only a handful) is to use an equivalent dynamic filter definition (e.g. /Person[AccountName='xxx' or AccountName='yyy']).  Note that in some cases this could conceivably lead to performance degradation, but I haven't found this a problem as a rule.

I'm attempting to rebuild my lab based on what I've got in production.  It's not practical to remove the sets in Prod just so I can export a policy config that will work in my lab.  The other option that MS recommends is bringing those users into the Portal prior to running the policy import.  Has anyone tried this?  Won't the resource IDs be different on the user accounts from one environment to another?  If that's the case I would think it would fail anyway.  Not to mention the fact that if you're using Sync Rules to bring in data to the MV, rather than an MA, those won't be available because you haven't yet Synced the policy into this environment.

A couple of tips from my experience:

• There will invariably be some components in your "pilot" environment which you will want to selectively exclude from the scope of your migration, so I always have a convention whereby I use a standard prefix (e.g. 'ZZZ') for schema/policy which I wish to exclude, and I adjust the PowerShell scripts accordingly
• When you have nested sets or groups you will often find that the first COMMIT fails because of the missing dependencies.  Be prepared to re-export from "production" then resync/commit as many times as necessary to negotiate all levels of nesting
• When migrating custom schema which is being synchronised to the metaverse, there is a "catch 22" which occurs whereby there are cross-dependencies between the sync engine config and your policy config (sync rules are dependent upon ma-data and mv-data, but the FIM MA in your sync server config is equally dependent on the FIM policy/custom schema) which will lead to exceptions.  I have found that I can avoid this conflict by splitting the SyncPolicy.ps1 script into parts 1 (mainly grants rights policy) and 2 (everything), and importing the sync server config in between these 2 sync/commit steps.

So the approach definitely works, but you will have to extend it a little if you wish it to run without exceptions in certain scenarios.

Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
Thursday, January 5, 2012 3:14 PM
• Thanks Bob for your thorough reply.  I believe I could resolve this if I am able to understand what you've stated below:

There will invariably be some components in your "pilot" environment which you will want to selectively exclude from the scope of your migration, so I always have a convention whereby I use a standard prefix (e.g. 'ZZZ') for schema/policy which I wish to exclude, and I adjust the PowerShell scripts accordingly

Are you saying there is a way to explicitly exclude specific sets from the migration process?.  Is this done using the Policy Export script?   Any chance you could point me to where I could find a simple example of how this is done (sample code)?

Thanks again.

Jeff

Thursday, January 5, 2012 3:54 PM
• Yes Jeff - that's what I am saying.  Have a look on  http://technet.microsoft.com/en-us/library/ff400264(WS.10).aspx and scroll down to where it talks about the -customConfig directive.  To use this you can specify as many queries in quotes separated by commas, e.g.

... -customConfig "/Set[not(starts-with(DisplayName,'ZZZ'))]","/Group[not(starts-with(DisplayName,'ZZZ'))]" -MessageSize 9999999 -AllLocales

Note the use of the last 2 directives which are explained on the above link.

Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
• Marked as answer by Friday, January 6, 2012 2:20 PM
Friday, January 6, 2012 3:27 AM
• I'm currently working on this and I don't know if this works yet, but I imagine you can use PowerShell to rip out the ExplicitMember attributes on the sets and then exclude the builtin sets from getting promoted to the other environment:

$policy = [XML](Get-Content 'path\to\fim-export-policy.xml') # Remove ExplicitMember attribute from all sets$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'']/ResourceManagementAttributes/ResourceManagementAttribute[AttributeName = ''ExplicitMember'']') |% { $_.RemoveAll() } # Remove built-in sets$policy.SelectSingleNode('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''Administrators'']').RemoveAll()
$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''Anonymous Users'']').RemoveAll()$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''All Button Viewable Sets'']').RemoveAll()
$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''Group Administrators'']').RemoveAll()$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''Password Reset Objects Set'']').RemoveAll()
$policy.SelectNodes('/Results/ExportObject/ResourceManagementObject[ObjectType = ''Set'' and ResourceManagementAttributes/ResourceManagementAttribute/Value = ''Synchronization Engine'']').RemoveAll() # Save the XML$policy.Save('path\to\modified-fim-export-policy.xml')