locked
Migrating MIM between environments RRS feed

  • Question

  • Hi,

    So we would like to migrate our MIM Sync and Service/Portal from 'test' to 'production'.

    There is an AD Forest namespace difference between 'test' and 'production'.

    We have matched the MIM version number in 'production' to 'test'.

    We have exported the MIM Sync server configuration. The import fails, as it complains that the MIM Portal MA is missing custom attributes - yes, that is expected, as we have extended the MIM Service/Portal schema.

    So we then proceeded to exporting the MIM Service policy and schema (to the policy.xml and schema.xml files, as per migration guide).

    When we try to commit the schema.xml file, it errors and says that many of the required MPRs either do not exist or are not configured correctly, or MPR permissions are missing.

    When we try to commit the policy.xml file, it errors and says that many of the required Schema objects/attributes are missing.

    So as can been seen, everything has dependencies on each other - how the heck is one meant to migrate a MIM Solution from 'test' to 'production' ????

    Cheers,

    SK

    Thursday, November 15, 2018 3:27 AM

Answers

  • It is often worth creating an "All Access" MPR prior to using this migration method. Ie All rights given to "All Objects", you can delete it afterwards.

    Also I highly recommend getting hold of FIMDelta so you can split your import files. For the schema, do objects types and attributes as one import, then the Bindings later. For policy do Sets and Workflows first, then MPRs on a latter import. FIMDelta will also help you excluding things like explicit members in sets, where the members don't exist in the target Portal.

    Personally I only use those scripts for config comparison, and do all my config build from Powershell scripts (ie NOT through the UI). Then I just run the same scripts against the target Portal. It's not something you can do after the fact though, you have to do all your development that way.


    http://www.wapshere.com/missmiis


    • Edited by Carol Wapshere Thursday, November 29, 2018 4:35 AM
    • Marked as answer by Shim Kwan Monday, December 3, 2018 2:49 AM
    Thursday, November 29, 2018 2:45 AM

All replies

  • The schema file shouldn't have any references to MPRs/Sets/etc. as I recall. Have you opened the XML file up to see what's in it? 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Sunday, November 18, 2018 10:57 PM
  • It is often worth creating an "All Access" MPR prior to using this migration method. Ie All rights given to "All Objects", you can delete it afterwards.

    Also I highly recommend getting hold of FIMDelta so you can split your import files. For the schema, do objects types and attributes as one import, then the Bindings later. For policy do Sets and Workflows first, then MPRs on a latter import. FIMDelta will also help you excluding things like explicit members in sets, where the members don't exist in the target Portal.

    Personally I only use those scripts for config comparison, and do all my config build from Powershell scripts (ie NOT through the UI). Then I just run the same scripts against the target Portal. It's not something you can do after the fact though, you have to do all your development that way.


    http://www.wapshere.com/missmiis


    • Edited by Carol Wapshere Thursday, November 29, 2018 4:35 AM
    • Marked as answer by Shim Kwan Monday, December 3, 2018 2:49 AM
    Thursday, November 29, 2018 2:45 AM
  • Danke Carol.
    Monday, December 3, 2018 2:50 AM