Source Domains a mix of 2003 & 2008R2 > Target 2012 R2
Migrate Domains A-E > Domain FEveryone 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 AGG-DomainA (Global security Group)
(User and resource Forest)Source Domain BGG-DomainB (Global security Group)
(User and resource Forest)Source Domain CGG-DomainC (Global security Group)
(User and resource Forest)Source Domain DGG-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 FMigrate Forests A-E here.
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.
* For a one to one migration DomainA\GG-Resource = DomainF\GG-Resource-DA DomainB\GG-Resource = DomainF\GG-Resource-DB And so on * For a many to one migration DomainA\GG-Resource = DomainF\GG-Resource DomainB\GG-Resource = DomainF\GG-Resource And so on Will the user (with Sidhistory along with the Groups SidHistory) that has been migrated from A > F still have access to the resources in E? Actually, no. The domain local group Sid will not present in the users access token, so access will be denied. To resolve this you will use the Active Directory Processing Wizard (ADPW) to process group membership in domain E. This will add domain F global groups to the domain E domain local groups, and maintain access.