Moving config from fim 2010 to fim 2010 R2 RRS feed

  • Question

  • I am taking a old, stressed install of FIM and planning to move it to a FIM 2010 R2 environment where the Database Role and the service and portal are built on R2 and are separated as per best practices.

    Can I:

    Import FIM 2010 MA's , schema and config into the new FIM 2010 R2 environment.


    Do I build the new environment to the same spec as the old one, then do the config changeover, then upgrade to R2.

    After do the discovery imports on the setup and verify sync.

    Is there an easy way to do this :)

    I mean, I am unsure the current environment will survive or have enough resources to take the R2 upgrade. I would prefer to build the new setup and get the rules from the old server over.

    Thoughts would be greatly appreciated.



    Wednesday, December 18, 2013 2:09 PM

All replies

  • Hello Rob,

    default update scenario is to copy over the DBs of Sync and Service and Install R2 by reuse this databases.

    But I think you will do the restart with a clean DB, is the old DB really that bad ?

    For the Sync Service doing export/import of schema and MAs i see no problem going from 2010 to 2010 R2.
    But Portal Rules, MPRs and workflow, maybe will leads to errors (never done this).

    So if DB reuse is no option i would install a fresh FIM 2010 and copy over all configs, then do the upgrade to R2, just to be sure not to overwrite and new configs with old ones.

    But i still would preferr the DB copy method, then maybe cleaning up the config and data.
    Also have a look to my blog for doing additional database maintenance (indexes rebuilt).


    Peter Stapf - Doeres AG - My blog:

    Wednesday, December 18, 2013 3:10 PM
  • Thanks, that was the one I was hoping to do. As far as I know I need to ensure the 2 (old and new) environments are the same.

    If the primary install accounts are new (as in there is a new FIMInstaller account) and the topology are different (in the same domain) will I have a problem porting this over ? I was under the impression the cert and the orginal installer account was important when moving like this ?

    And yes, the MPR's and worflows+schema will never import correctly between FIM versions , I have been stung with this in the past.

    The Database is in pretty poor shape , as is the machine. For example, via some work that was done prior there are now over 190,000 ERE's orphaned alone. The server is so strained that the creation of new sets, mpr's etc is impossible.

    So I would be reluctant to upgrade that one to R2 first :)


    Wednesday, December 18, 2013 3:22 PM
  • Hello,

    i see no problem with the accounts, as this normally also occur when wou migrate the config from dev to prod stages, like I do in my environment.

    the powershell config migration scripts will resolv the identities and guids on both sides to match the correct once. same with the SyncRules and the guids of the MAs referenced with them.

    So its a new environment beside the old one, nothing can go wrong, worth testing.


    Peter Stapf - Doeres AG - My blog:

    Friday, December 20, 2013 4:06 PM
  • The clean install idea followed by swapping over the 2 databases is the approach I would take, but not before I had at least tried to address some of the performance issues you allude to.  You have probably already looked at this, but just in case:

    • Have you tried rebuilding the full text index on the FIMService db?  I generally rebuild this on a nightly basis.
    • Have you checked index fragmentation on both FIM dbs?  I regularly rebuild these because they will invariably become badly fragmented quite quickly - mainly because of FIM's architectural dependency on the use of guids as db keys.
    • Have you tried either writing a script or setting up a custom workflow to delete your orphaned EREs?

    I generally find after doing all of the above I find an immediate improvement in FIM performance - including being able to create sets that wouldn't be created prior to the reindexing.

    On the upgrade itself, be aware of the various traps that you can walk into depending on your FIM design, such as:

    Bob Bradley (FIMBob @ ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Saturday, December 28, 2013 4:08 AM
  • Hey Peter,

    on another note, the new primary install domain account, is a standard domain account. This is a different account to what the old FIM was installed under. Will I have a problem when I bring the database over from the old setup to the new ?

    I ask this as there will be a different SID for the master admin account.



    Thursday, January 2, 2014 12:31 PM
  • Hi Bob,

    thanks for the pointers, I checked the fragmentation on the Service database and it ranges from 40% lowest to 99% highest, with 70% being around the norm. That is interesting as well. I have over 100,000 orphan ERE's as well , I have a script to clear them down, but would best let it run over the weekend.

    Is there any risk is putting the database into a maintenance task to re-build the indexes on the live server ? Is this a straightforward job to run ?



    Thursday, January 2, 2014 1:42 PM
  • The orphaned EREs need to be deleted, yes - a script is OK, but runs in a single thread, which makes it slow (unless you can spawn multiple threads?).  I always delete these orphaned EREs through housekeeping policy within the FIM Portal, using a custom workflow activity to delete a FIM object by ID, firing it on a set transition (all orphaned EREs) and this is the quickest way I know of.

    On the rebuilding of the indexes, I have had the best results using the SQL Enterprise Manager IDE by expanding selected database tables in the treeview and selecting Rebuild All ... from the right mouse menu.  I run a TSQL script to identify the worst fragmentation and then go through the process of rebuilding the indexes this way.  I have tried setting up a SQL agent job to automate this but it consistently fails half way through the script and I've yet to work out why (at first thought it was because the FIM Service was running, but not so sure now) - however I have it on my own TODO list to get something together to do this.  When I rebuild interactively I have generally had success without taking the db offline or stopping the FIM Service.

    Bob Bradley (FIMBob @ ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, January 2, 2014 2:39 PM
  • Thanks Bob,

    I can afford to use the script on the ERE's over the weekend, I collected their ID's from another script and can feed them back to the Service from PowerShell.

    Yea, DB is definitely my big challenge, found that the database tasks for FIM index and FIM index reorg never fired properly, in fact as a correction to that, FIM Index ran, about 2 years ago :)



    Thursday, January 2, 2014 2:58 PM
  • For this time it may be best to rebuild all -- yes it will task your system and some operations can't be performed when it takes the indexes offline. So find some downtime.

    On the other hand you could try the lighter approach I recommend for ongoing maintenance: Ola Hallengren's scripts to automate the Index Maintenance of FIM Databases. While it is free it is well written and frequently updated to fix issues and adopt new features.

    One of the things I like best about his scripts is that it looks for indexes that are highly fragmented (over 30%), and are big enough to matter (over 1000 pages) and then it will rebuild them. For those that are big enough to matter and between 5% and 30% it will Reorganize them rather than rebuild. If the indexes are neither fragmented enough nor big enough then it leaves them alone. Whereas the Maintenance plans are dumb and will rebuild every index whether it needs it or not. I have seen a difference of hours vs. minutes.

    My recommendation:

    1) Try Ola's script to rebuild/reorganize just what's needed. Run it nightly. See if that helps.

    2) If that doesn't help try to schedule some down time to do a complete rebuild of the indexes.

    David Lundell, Get your copy of FIM Best Practices Volume 1

    Thursday, January 2, 2014 5:53 PM