• State Suggested Answer
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 20 subscribers
  • Views 9977 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Not sure how to approach this migration scenario (5 Forests > 1) Domain E is not clear to me

questmigrator
over 6 years ago

Hello All,

Source Domains a mix of 2003 & 2008R2 > Target 2012 R2

Migrate Domains A-E > Domain F
Everyone trusts each other (SidHistory enabled)

The following is just one example of the way groups have been setup and nested
(User and resource Forest)
Source Domain A
GG-DomainA (Global security Group)

(User and resource Forest)
Source Domain B
GG-DomainB (Global security Group)

(User and resource Forest)
Source Domain C
GG-DomainC (Global security Group)

(User and resource Forest)
Source Domain D
GG-DomainD (Global security Group)

(Resource Forest for above forests)
Source Domain E
DL-DomainE (Domain Local Security Group) With all GG-Domain (A-D) nested within.  This is just one of a number of groups that are DLs in this forest that were created to give access to data.  100's of DLs with nested groups from the other Domains (GG-DomainA-D).  In turn these DLs (DL-DomainE) have been assigned permissions on the Data that resides in this Forest.


Target Forest F
Migrate Forests A-E here.

Which is the best way to tackle (migrate) such a scenario?

Please assist,
Jeffrey

Parents
  • 0 over 6 years ago

    Which is the best way to tackle (migrate) such a scenario?

    Well that is a large, vague question.  Maybe a better question would be about migrating the groups in your example above.

    Assuming a one to one migration of all objects from each of the source domains. A many to one migration for is also an option, it would be a different configuration with the same answer.

    For a one to one migration, the same service attributes for all domain pairs.

    For a many to one migration, each domain pair will require their service attributes for each domain pair.

    The sidhistory matching rule should be enabled on the domain E to domain F domain pair.

    1. Migrate each of the source domain A-D global groups to the target domain F.

    2. Migrate the source domain E domain local groups to domain E.  When the membership is migrated, all target groups created in step 1 will be members of the target domain local groups.  

Reply
  • 0 over 6 years ago

    Which is the best way to tackle (migrate) such a scenario?

    Well that is a large, vague question.  Maybe a better question would be about migrating the groups in your example above.

    Assuming a one to one migration of all objects from each of the source domains. A many to one migration for is also an option, it would be a different configuration with the same answer.

    For a one to one migration, the same service attributes for all domain pairs.

    For a many to one migration, each domain pair will require their service attributes for each domain pair.

    The sidhistory matching rule should be enabled on the domain E to domain F domain pair.

    1. Migrate each of the source domain A-D global groups to the target domain F.

    2. Migrate the source domain E domain local groups to domain E.  When the membership is migrated, all target groups created in step 1 will be members of the target domain local groups.  

Children
No Data