Hello,
I just want to know whether I should do re-ACL first on resources and then cleanup Sidhistory OR first I should cleanup of sidhistory and then re-ACL on resources? What is the correct order of these post migration tasks? Please explain what is the technical reason for the correct order?
Thanks in advance!
Shawn
Technologically, SIDHistory is meant to "help" you in the sense that if you want (or need) to cutover your users to using their new accounts before you re-ACL, you can usually rely on SIDHistory to keep them accessing the resources they need to work.
So, the order is:
1. Re-ACL
2. Cleanup SIDHistory.
Beware however, that once you do the SIDHistory cleanup, you may run into situations where users lose resource access because you missed migrating a group that was granting access. It's a quick thing to fix (by migrating the group in question and re-ACL'ing the resource again) but it could happen.
I have follow-up questions on this.
Q1: Relying on sidhistory (before re-ACL) in order to access resources - Does it have anything to do whether resources are in source domain or target domain post inter-forest migration scenario?
Q2: Does it mean that sidhistory (before re-ACL) must be required in both cases - accessing source domain resources as well as target domain resources?
Q3: If the resources have been migrated to target domain post inter-forest migration, then can I remove all source domain local groups applied on resource ACL provided those source domain local groups don't contain any external trusted members(domain which are not part of the migration)?
Q4: If the resources have been migrated to target domain post inter-forest migration, then can I still delete those source domain local groups which contains only source domain user accounts because as far as I know access token of those source domain user accounts contains SID of source domain local groups which is not going to be crossed in target domain?
Kindly answer and explain specific to above mentioned questions.
Thanks in advance!
Shawn
A1: No. The resources could actually be in either domain. It all depends on what you see in the permissions. If there are source domain groups found in target domain permissions then yes, you would rely on SIDHistory to access these before Re-ACL.
A2: Yes
A3: Yes - assuming that those domain local groups were migrated using QMM, you can have a Processing job perform the removal after you re-ACL.
A4: Yes - as long as you have re-ACL'd those resources
Thank you very much JohnnyQuest
I just only have last question.
In my environment, groups have been migrated with sidhistory from source domain to target domain inter-forest migration. Those groups still exist in source domain. Users have been migrated with sidhistory from source domain to target domain.Those users have been deleted in source domain after migration. Resources also have been migrated to target domain servers. Those resources are configured with source domain groups in ACL. Scope of source domain local groups have been changed to global in target domain.
As per above mentioned scenario, how should I use RUM for resource process of groups? Shall I choose to append target groups in resource ACL OR shall I replace source domain groups with target domain groups in resource ACL?
Kindly answer and explain specific to my environment.
Thanks in advance!
Shawn
It sounds like the source groups are now empty because you deleted the original member users so you may as well allow these groups to be replaced in the ACLs. In the worst case, you can always re-process the ACLs using a "revert" job to put them back.
It sounds like the source groups are now empty because you deleted the original member users so you may as well allow these groups to be replaced in the ACLs. In the worst case, you can always re-process the ACLs using a "revert" job to put them back.
