migration procedure from MIIS to FIM RRS feed

  • Question


    I am planning migration procedure from MIIS(SP1) to FIM2010 for galsync.

    I think there is two way.

    #1. use SQL2000 DB restore to SQL2008x64

    #2. do not use DB restore and import mailbox data to empty FIM DB and import and join existing contact object by join rule.

    In our migration scenario , we would like to avoid recreation of existing contact objects as possible because to avoid NDR and reduce tasks related to contact object recreation.

    As far as I see the above link, #2 looks preferable because our environment is MIIS(SP1) and SQL2000(SP1) and #1 plan need to upgrade to MIIS(SP2) and SQL2000(SP4).

    We have already FIM2010 in our domain where MIIS exists.

    I think we can import server configuration xml or each MA's setting xml of current MIIS to existing FIM.

    Question 1.  If we only define import attribute flow from AD mailbox to Metaverse person object for each MAs (delete import flow of contact and all others import and export flows) in FIM2010, and   import stage only of each MA and full sync and never run any export(delete export run profile)  ,  is thera any negative impact on current MIIS and AD environment ?

    After mailbox import and sync to FIM2010, I am thinking of making import attribute flow from existing AD contacts to FIM2010 Metaverse person object for each MAs with join rule by legacyExchangeDN value. ( I think in current MIIS setting, MIIS collects legacyExchangeDN of contact to MIIS metaverse person object's legacyExchangeDN(multi-value) and export collected  legacyExchangeDNs to source mailbox's proxyaddressses as X500 address.(some MA are not but I think we can change it in that way, and current MIIS import flow from AD mailbox to metevse person object of each MAs include import flow from AD mailbox X500 proxyaddresses  to metevse person object legacyExcangeDN by rule extension. FIM metaverse has legacyExchangeDN value of existing contact object  by this rule in previous mailbox import step and I think contact object is joinable by legacyExchangeDN value if we recompile current MIIS rule extenstion for FIM and put those DLLs to FIM extension folder).

    Question 2. If this contact object join fail, is it possible to recover by unchecking source synchronization OU which contacts are placed(say OU1)  and targer OU(OU1)  which contacts are created in  each MA's setting, or make new Empty OU(say OU2) and select OU2 for source and target OU in stead of OU1 without no negative impact to current MIIS and AD environment ? I thought  if we uncheck OU1 and import and sync contact object again, I guessed Connector Space object of contact object will be deleted and there is no negative impact if we do not run any export to ADs.

    Does this procedure make sense or how could we improve this migration procedure ?

    I am making test environment of this MIIS to FIM migration and will test that migration procedure in test environment at first.
    Saturday, May 18, 2013 6:28 PM


  • #2 Sounds reasonable especially if it is only GAL synchronization scenario and I would go for it as well. We went through option #1 recently for customer and it was also rather straightforward with exception sometimes for finding correct build which will work with given DB version etc. 

    Going with #2 will give you at least two additional benefits:

    - you will test your "bare metal" recovery procedure for synchronization solution.

    - during upgrades sometimes problems with database which are not causing any problems in daily life comes out and causes problems. You will not hit this problem but it was not said that you will hit it anyway. 

    Q1: I would import configuration without any change and just run a synch with disabled provisioning. This should give you all the synch and joins, and will not cause any disruption in your service as long as you will not run export profile anyway. Desired result is that after such synchronization you will not have any exports anyway as this should be environment in synchronized state.

    So what I would do is:

    - setup new FIM (or you have it already)

    - import existing configuration, disable provisioning and run synchronization to join objects

    - get reports from CS and identify incorrect joins etc. actually any object which will produce some export will be suspect of investigation

    - enable provisionin and run some time on a "dry runs" on FIM without commiting export operations to the target sources to see if it works as expected.l

    - stop MIIS and switch over to FIM. 

    Tomek Onyszko, memberOf Predica FIM Team (, IdAM knowledge provider @

    • Marked as answer by yuuichiro99 Thursday, June 6, 2013 7:44 PM
    Saturday, May 18, 2013 8:46 PM