• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 19 subscribers
  • Views 12527 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

Migrating file/print/app servers first

eric_bergstrom
over 7 years ago

 Hello all-

Theoretical question regarding resource processing with the RUM.

Typically on any migration project, we've brought over the users and groups first, processed workstations and servers, move workstations then, after all users now log into the target, move servers.

My customer has a requirement to move some app and file/print servers BEFORE migrating users and computers. As long as all the source users are copied/matched to the target and SIDHistory is brought over, the only potential issue I can see is any perms/ACLs based on Domain Local groups or maybe Built In groups as the RUM appends ACLs, not overwrites.

SQL and SharePoint are special. I'm not too concerned about that. Those really should wait until the end as it's an perms replace.

Anything I'm missing here? I'm walking into a migration project already in flight and I know I'll be asked this question.

Regards,

Eric

Parents
  • +1 over 7 years ago
    Hi Eric,

    Well, this one is tricky as the SID of well known groups are filtered out by trusts. Because of the security around these groups, you cannot rely on SID History, as the trust will block it.

    The workaround we have come up with is to Migrate the Domain Users to the target domain, renaming it using an import file in a migration session to the target. You will now have a new group in the target, that while in the scope of the Directory Synchronization will populate the membership with the matched source side users. BEWARE, if you want to include the group in scope, you have to first allow the processing of Wellknown Groups by going to the properties of the Domain pair, Skip Objects, Active Directory Default Objects, and uncheck this one. Once unchecked, you can move the Domain Users group to an OU in your source scope to populate it.

    Now that you have this group in the target (Renamed to "Source Domain Users" or similar, and it's membership is populated, you can then RUM the resources in the source, and the users in the target that match the source Domain Users, will have access.

    I hope this helps,
    Luke
Reply
  • +1 over 7 years ago
    Hi Eric,

    Well, this one is tricky as the SID of well known groups are filtered out by trusts. Because of the security around these groups, you cannot rely on SID History, as the trust will block it.

    The workaround we have come up with is to Migrate the Domain Users to the target domain, renaming it using an import file in a migration session to the target. You will now have a new group in the target, that while in the scope of the Directory Synchronization will populate the membership with the matched source side users. BEWARE, if you want to include the group in scope, you have to first allow the processing of Wellknown Groups by going to the properties of the Domain pair, Skip Objects, Active Directory Default Objects, and uncheck this one. Once unchecked, you can move the Domain Users group to an OU in your source scope to populate it.

    Now that you have this group in the target (Renamed to "Source Domain Users" or similar, and it's membership is populated, you can then RUM the resources in the source, and the users in the target that match the source Domain Users, will have access.

    I hope this helps,
    Luke
Children
No Data