locked
forest change? RRS feed

  • Question

  • We are using EOP service currently with DirSync with passwords.

    We are planning to switch to Office365.

    We intend to create a new forest and migrate current forests into it.

    Questions:

    If I migrate a user, does that remove the online account now, due to the dirsync?

    Can I Dirsync the new forest as well?

    I would only Office 365 enable users from the new forest.

    Basically, what is the best method of forest migration, without loosing current online accounts?

    This is one-time migration, so things like FIM are overkill.

    Tuesday, July 15, 2014 6:20 PM

Answers

  • Hi Steven,

    In this scenario you need to ensure that you plan this very carefully, If you are using Directory Sync then the default behavior is for the Object GUID base 64 to be set as the Immutable ID. If you are going to migrate a user to a new forest then you need to ensure that the Object GUID stays the same to ensure that the same immutable value is used during the sync. In this scenario at a very high level I would do the following:

    - Disable Directory Sync

    - Move Users to New Forest

    - Re-Configure DirSync @ New Forest

    - Re-Enable Directory Sync

    ^in this scenario, any existing accounts in the cloud that have been migrated with tie back together again when pulled into the metaverse. accounts that, were not migrated will become Cloud Only Users and therefore would need to be managed by the cloud management interface.

    If, this is not what you want and you want to be able to run both forests side by side then you are going to need to wait for AAD Sync to be Generally Available and then because that will support Multiple Domains you will be able to do this with-out FIM but again careful consideration needs to be taken into account when you select what attribute you wish to use as the Immutable ID as in AADSync this is something that will be configurable.

    Disabling Directory Sync will prevent mistakes from happening in terms of deletions during a move, but you need to ensure when it is re-enabled that the same Immutable ID value is used on both the AD and AAD to ensure they tie back together otherwise your new installation of Directory Sync will complain about duplicates.

    I hope that makes sense, if i be of any further help please be sure to let me know {or if you just want clarification}.

    Thanks,

    James.

    Tuesday, July 15, 2014 10:23 PM

All replies

  • Hi Steven,

    In this scenario you need to ensure that you plan this very carefully, If you are using Directory Sync then the default behavior is for the Object GUID base 64 to be set as the Immutable ID. If you are going to migrate a user to a new forest then you need to ensure that the Object GUID stays the same to ensure that the same immutable value is used during the sync. In this scenario at a very high level I would do the following:

    - Disable Directory Sync

    - Move Users to New Forest

    - Re-Configure DirSync @ New Forest

    - Re-Enable Directory Sync

    ^in this scenario, any existing accounts in the cloud that have been migrated with tie back together again when pulled into the metaverse. accounts that, were not migrated will become Cloud Only Users and therefore would need to be managed by the cloud management interface.

    If, this is not what you want and you want to be able to run both forests side by side then you are going to need to wait for AAD Sync to be Generally Available and then because that will support Multiple Domains you will be able to do this with-out FIM but again careful consideration needs to be taken into account when you select what attribute you wish to use as the Immutable ID as in AADSync this is something that will be configurable.

    Disabling Directory Sync will prevent mistakes from happening in terms of deletions during a move, but you need to ensure when it is re-enabled that the same Immutable ID value is used on both the AD and AAD to ensure they tie back together otherwise your new installation of Directory Sync will complain about duplicates.

    I hope that makes sense, if i be of any further help please be sure to let me know {or if you just want clarification}.

    Thanks,

    James.

    Tuesday, July 15, 2014 10:23 PM
  • I thought Metaverse was a FIM thing. If not, which part is the metaverse?

    Does ADMT retain the Object GUID base 64 when migrating between forests?

    I guess our current users are only using EOP, so really just the white/blacklist uploads.

    My admin login is also synced from the current forest, although, I think I could set up another non-sync admin account first.

    Wednesday, July 16, 2014 11:33 AM