none
File Server Migration and ADMT

    Question

  • hi all,

    i have a case that i am planinning to migrate a file server from one forest to a another new forest, i have study similar posts but i have some quenstions on this...the target is to trasfer the users permissions to the new forest with the most safe way...

    first of all, accounts on the target forest have been already created so i am not want the case that i will tranfer the domain accounts from the old forest to the new one using ADMT

    my scenario for the migration is to copy the file server files to the new file server (new forest) using robocopy, then using subincal to get the permissions from the old file server and with the same tool apply the same permsissions on the new file server (using subincal and a map file to match the accounts from old an new domain) is this possible?

    i thing the above solution is the most safe to do in order to avoid a roll back in a case of a failure during file server (resource migration with ADMT)

    can i use ADMT tool to migrate just the SID attribute from the source domain users accounts and apply the SID to the domain users on the target domain? (users on target domain exists already couple years now)

    thank you for your time, looking foward to hear your opinion.

    Wednesday, May 30, 2012 7:53 AM

Answers

  • No problem Xaris,

    If you had used ADMT for moving users across domains exporting SIDHistory, you could at the end, with ADMT, translate the old domain ACL to the target domain values. I understand this is not the case, as user objects have been created from zero in the target domain.

    When I said "current ACLs will be exported with the info" I mean the info you copy from source FileServer to the new one (using robocopy) will retain the old domain ACLs for any file/folder.

    My concern is, if your users start using the new domain accounts, they will have issues accesing the new fileserver info, because the ACLs are for user/groups of your source domain, not for the target one. What you need to be sure is, the new server where you put the info must include the ACLs for the target domain (for example, any user with access to one folder must has the same access level for the same user account in the new domain, and this for all the groups/users). I know it sounds harder, but you can automate a task like that with SetACL, with this tool you can duplicate the entire ACL tree for a fileserver with the new user/groups of a new domain.

    Take a look to -> http://helgeklein.com/setacl/examples/managing-file-system-permissions-with-setacl-exe/

    You can use example 4 (safer, duplicate first and then delete legacy domain ACLs), or example 5 (just replace ACLs from legacy domain to target)

    Let me know if this clarifies your doubts.

    Regards.

    Julio

    • Marked as answer by xaris_sm Tuesday, June 05, 2012 10:28 AM
    Friday, June 01, 2012 12:15 PM
  • hi all and thank you for your support

    i have tested 2 ways to do the job, both of them seems to work fine

    1)using SubInACL like Julio propose, i create a new file server (joined to target domain) use the robocopy to copy files from source fileserver/domain to target fileserver/domain with the users permissions in place and then just run SubInACL with /migrate switch and use the a mapfile.txt to replace permissions from source domain accounts to target domain accounts (mapfile.txt works fine with domain accounts name and SID's)

    2)using the ADMT to migrate the file server from source domain to target domain and then run the Security Translation Wizzard for the migrated fileserver with a map file (like case 1) to apply permissions on the migrated file server for the accounts on the target domain.

    i did have in place 2way trust on forests in order ADMT and SubInACL to read domain accounts names not SID's (SID's mapfile is a trouble)

    i am waiting for the go from high level i hope migration will go like the tests did.

    thank you all


    • Marked as answer by xaris_sm Tuesday, June 05, 2012 10:28 AM
    • Edited by xaris_sm Wednesday, June 06, 2012 8:44 AM replace SetACL with SubInACL
    Tuesday, June 05, 2012 10:27 AM

All replies

  • Hi Xaris,

    The safer and recommended action includes:

    - Move users across domains exporting SID History attribute to ensure users in the target domain can access to legacy fileservers during migration.

    - Once everyone is migrated, you will need to translate the source domain ACL entries http://technet.microsoft.com/en-us/library/cc974389(v=ws.10).asp

    - After that, just join the FileServer to the target domain.

    You don't need to copy or move info, just translate the ACLs from source to remote domain once everyone is moved. ADMT mantains a database with the legacy and target domain usernames to accomplish this ACL translation.

    Another option you have, if SIDHistory has not been exported, is using SEtACL tool to duplicate the ACL entries with the user/groups of both domains.

    Regards.

    Julio Rosua



    • Edited by Julio Rosua Wednesday, May 30, 2012 12:09 PM
    Wednesday, May 30, 2012 12:08 PM
  • Hi Julio,

    thank you for your reply,

    let me notice as my description on the first topic, the user accounts on the target domain already exist, they are new accounts with almost the same name as the accounts on the source domain, the company that buy us couple years ago just create new domain accounts for us

    so what accounts should i move? i dont want to have double accounts on the new domain

    Thursday, May 31, 2012 6:07 AM
  • Xaris,

    If the target domain has user accounts already created, and SiDHistory has not been exported, you need to do the hext steps (under my POV):

    - First of all, you won't need to move user accounts, as they are already created, but you will need to create security groups in target domains that match name from source or export throught ADMT

    - You will need to unjoin workstations/latpops from your domain and join to the target domain

    - Configure your fileservers with the ACLs from target domain. You can use SetACL Tool for it.

    - To recover user profile in target domain use moveuser.exe (windows binary)

    - Finally, last step is moving your servers across domains as computers.

    Julio Rosua

    Thursday, May 31, 2012 8:48 AM
  • Hi again Julio,

    i forget to mention that new domain users accounts (new domain) alread login on new workstations on the new domain, no need to transfer the workstations or user profile, all servers also are closed excpect file server

    i just looking for a way to export the permssions on the old file server, copy the files on the new file server on the new domain and assign permssions from the old server to the new one

    Thursday, May 31, 2012 9:06 AM
  • You can use Robocopy/Richcopy to migrate files with permission.

    http://technet.microsoft.com/en-us/magazine/2006.11.utilityspotlight.aspx


    Awinish Vishwakarma - MVP - Directory Services

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Thursday, May 31, 2012 9:40 AM
  • OK Xaris,

    Sorry for the missunderstanding, if you are looking for a way to copy the info between different fileservers, just use robo/richcopy as Awinish suggested and the current ACLs will be exported with the info.

    Assuming the legacy FileServer already has the ACLs for the new domain. If not, as I said before, you will need to use SetACL or another tool to create new ACLs or do it manually if the environments is not too large.

    Julio Rosua

    Thursday, May 31, 2012 9:52 AM
  • Julio,

    i hope i am not getting annoying,

    what you mean when you say "current ACLs will be exported with the info" i understand that current ACLs will be keeped on the transfered files (from the old to the new file server) is that right? and if yes how i will translate/map old SID's with the new ones? (different acounts from old and new domain)

    or the ACLs will be exported some way?

    also please clarify "Assuming the legacy FileServer already has the ACLs for the new domain" please help me understand what you mean by that...

    the enviroment is too large in order to re-apply permssions manual...

    than you again

    Friday, June 01, 2012 11:45 AM
  • No problem Xaris,

    If you had used ADMT for moving users across domains exporting SIDHistory, you could at the end, with ADMT, translate the old domain ACL to the target domain values. I understand this is not the case, as user objects have been created from zero in the target domain.

    When I said "current ACLs will be exported with the info" I mean the info you copy from source FileServer to the new one (using robocopy) will retain the old domain ACLs for any file/folder.

    My concern is, if your users start using the new domain accounts, they will have issues accesing the new fileserver info, because the ACLs are for user/groups of your source domain, not for the target one. What you need to be sure is, the new server where you put the info must include the ACLs for the target domain (for example, any user with access to one folder must has the same access level for the same user account in the new domain, and this for all the groups/users). I know it sounds harder, but you can automate a task like that with SetACL, with this tool you can duplicate the entire ACL tree for a fileserver with the new user/groups of a new domain.

    Take a look to -> http://helgeklein.com/setacl/examples/managing-file-system-permissions-with-setacl-exe/

    You can use example 4 (safer, duplicate first and then delete legacy domain ACLs), or example 5 (just replace ACLs from legacy domain to target)

    Let me know if this clarifies your doubts.

    Regards.

    Julio

    • Marked as answer by xaris_sm Tuesday, June 05, 2012 10:28 AM
    Friday, June 01, 2012 12:15 PM
  • Hi,
     
    How are things going? I just want to check the status of the issue. If you have any update or concern, please feel free to let us know.
     
    Best Regards,
    Aiden

    Aiden Cao

    TechNet Community Support

    Tuesday, June 05, 2012 1:22 AM
  • hi all and thank you for your support

    i have tested 2 ways to do the job, both of them seems to work fine

    1)using SubInACL like Julio propose, i create a new file server (joined to target domain) use the robocopy to copy files from source fileserver/domain to target fileserver/domain with the users permissions in place and then just run SubInACL with /migrate switch and use the a mapfile.txt to replace permissions from source domain accounts to target domain accounts (mapfile.txt works fine with domain accounts name and SID's)

    2)using the ADMT to migrate the file server from source domain to target domain and then run the Security Translation Wizzard for the migrated fileserver with a map file (like case 1) to apply permissions on the migrated file server for the accounts on the target domain.

    i did have in place 2way trust on forests in order ADMT and SubInACL to read domain accounts names not SID's (SID's mapfile is a trouble)

    i am waiting for the go from high level i hope migration will go like the tests did.

    thank you all


    • Marked as answer by xaris_sm Tuesday, June 05, 2012 10:28 AM
    • Edited by xaris_sm Wednesday, June 06, 2012 8:44 AM replace SetACL with SubInACL
    Tuesday, June 05, 2012 10:27 AM
  • Well done Xaris.

    Glad to see it worked well for you.

    Regards,

    Julio Rosua

    Tuesday, June 05, 2012 10:38 AM