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

  • +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
  • 0 over 7 years ago
    Thanks for your prompt response, Luke. The workaround is doable albeit not best-practice it seems. Food for thought when I meet them next week.
  • 0 over 7 years ago
    Just to be sure, let's just say that this customer does NOT use well-known or built-in groups, as long as the security groups have been linked between source and target, migrating a file/print server has minimal risk? Again, if the customer insists on doing these f/p servers first, I want to level-set them on the potential risk.
    Thanks again,
    Eric
  • +1 over 7 years ago
    Correct, as long as the users and groups are migrated with sid history, the SID Filtering is disabled on the trust, and SID History enabled, they will have access.
    Luke
  • 0 over 7 years ago
    Thanks again, Luke. I appreciate your prompt response. That, fortunately, was the answer I was expecting but had to be absolutely sure.
  • +1 over 7 years ago
    Keep in mind, if you encounter issues with it, we will support you with this scenario as it is fully supported.
    LUke
  • 0 over 7 years ago
    Normally, I wait until the end to move SQL Servers (not clustered), do you know if I process a SQL box using the SQL processing wizard for a subset of users then migrate it to the target, will SQL authentication be broken for those users still in the source?
  • 0 over 7 years ago
    If you run SQL Processing wizard with a custom map file, you can just process these users, then if you move the server, as long as you have a good two way trust in place, they can still access.
    Luke