locked
AD group domain migration - Powershell Script RRS feed

  • Question

  • Hi,

    As far as i know anything can be done via PowerShell. But i wanna try something and i don't know where to begin.

    Basically we have an old domain and a new domain. Separate from one another, that have trusts.

    In the old domain we have some groups with users in them. In the new domain we already have equivalent users and equivalent groups.

    How should i go about making a script that can associate old groups with new groups, old users with new users, and add the new users to the  new groups according the old domain's format?

    I don't really know where to begin. I can't seem to imagine a strategy for doing this.

    • Moved by Bill_Stewart Monday, October 31, 2016 2:16 PM Move to more appropriate forum
    Monday, October 31, 2016 9:21 AM

Answers

  • migration always refers to moving the sids, yeh except when it doesn't!

    how do you migrate distribution groups between domains that have no trust relationship then?

    Technically it does mean moving SIDs. Just dumpling accounts and loading to a new domain is not migrating it is called copying the accounts.

    Also the OP states "associate".  The method for "associating" is to copy SIDs to SID history as well as moving the existing SID history.  There is no other way to do this.

    This question comes up frequently when untrained Admins are asked to move users from one domain to another for a domain restructuring.  It is one element of certification for advanced AD design and management and is beyond day-to-day user/account management.

    This question should really be asked in the Directory Services forum as they can support the ADMT. 

    ADMT can produce pre-migration reports and allow the techs to plan how they will do the move.


    \_(ツ)_/

    The thing is, the topicstarter says that they already have corresponding users and groups in the new domain. This is why I assumed that the question is simply how to copy the users/groups membership.

    If they really need to properly migrate accounts and if they already use new accounts and assign permissions to them, they may be in a tricky situation trying to use ADMT for the old accounts now.

    So it is really the question of what the topicstarter meens by "associate" - crate a mapping between the old and the new SID or copy the group membership structure into the new domain. Maybe he appears here and provides a bit more info about this.

    /Regards




    • Edited by Avendil Tuesday, November 1, 2016 1:06 PM
    • Proposed as answer by Alvwan Tuesday, November 8, 2016 5:47 AM
    • Marked as answer by Alvwan Friday, November 11, 2016 9:23 AM
    Tuesday, November 1, 2016 1:05 PM
  • In my experience this is common for untrained admins because trey think they can just copy account names and have everything work until they realize the accounts no longer have access to any secured resources.

    In many multi-domain network we would have a resource domain and email domain and one or more account domains.  We must keep the SIDs when migrating.

    It is possible to update the history after the accounts are created but is is easier to just delete the unusable accounts and use the migration tool to mirror the account and group structure..  This can also update the changes to the domain security.

    If you are just trying to have two sets of identical account names then there is no way to "associate" them and there is no real meaning to "associate".  They can only be totally independent accounts with the same name.  This doesn't make much sense or provide any useful functionality.


    \_(ツ)_/

    • Proposed as answer by Alvwan Tuesday, November 8, 2016 5:47 AM
    • Marked as answer by Alvwan Friday, November 11, 2016 9:23 AM
    Tuesday, November 1, 2016 1:18 PM

All replies

  • There are tools that do this.  https://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx

    We would not do this with PowerShell.

    Post questions about domain migration in the Directory Services forum.


    \_(ツ)_/

    Monday, October 31, 2016 9:55 AM
  • >>>making a script that can associate old groups with new groups

    What do you mean by "associate old groups"? What is your goal here?

    Why can't you use a migration tool like ADMT?  Please provide more information about requirements


    Santhosh Sivarajan | Houston, TX | www.sivarajan.com
    ITIL,MCITP,MCTS,MCSE (W2K3/W2K/NT4),MCSA(W2K3/W2K/MSG),Network+,CCNA

    My Books: | Windows Server Security | Windows Server 2012

    Blogs | Twitter | LinkedIn | Facebook|

    This posting is provided AS IS with no warranties, and confers no rights.

    Monday, October 31, 2016 4:34 PM
  • Hello,

    If your users and group names are the same, you may use PowerShell to export group membership for each group into a CSV (Get-ADGroupMember) and then use this CSV as an input to another script that would import the group membership for each group accroding to this list (Add-ADGroupMember). Note That you will only need the samaccountname of the object, not it's DN, as otherwise it would contain references to your old domain and that this will only work if names are the same.

    /Regards


    • Edited by Avendil Tuesday, November 1, 2016 9:38 AM
    Tuesday, November 1, 2016 9:37 AM
  • Hello,

    If your users and group names are the same, you may use PowerShell to export group membership for each group into a CSV (Get-ADGroupMember) and then use this CSV as an input to another script that would import the group membership for each group accroding to this list (Add-ADGroupMember). Note That you will only need the samaccountname of the object, not it's DN, as otherwise it would contain references to your old domain and that this will only work if names are the same.

    /Regards


    This does not migrate SIDs so all security will be lost.  Migration is NOT copying it is creating a n account and adding the SIDs to SID history so the security descriptors continue to work.


    \_(ツ)_/

    Tuesday, November 1, 2016 9:40 AM

  • This does not migrate SIDs so all security will be lost.  Migration is NOT copying it is creating a n account and adding the SIDs to SID history so the security descriptors continue to work.

    The topic starter never said that he needs to do the repermissioning. What he asked was "add the new users to the  new groups according the old domain's format", so I assumed, that he only needы to have groups with the same names containing users with same names.

    Sorry, if I misread the situation. Of course, if the task is to create an association between the old SID and the new one, so that the new users automatically get the access to old resources, it should be done using a specialized tooling, like suggested above (although it can be done using scripts, this task requires high expertise and understanding of what you are doing and I would not suggest to try this if you are not sure about that).

    /Regards



    • Edited by Avendil Tuesday, November 1, 2016 11:40 AM
    Tuesday, November 1, 2016 10:47 AM
  • you don't need sid history per se but your script will need to lookup identities in the new forest and match them via some attribute e.g. email address, samaccoutnname. Ideally you would of used ADMT to migrate the groups and memberships and then just use powerhsell to "fix them up" as admt does a terrible job of distro groups as it has no knowledge of exchange attributes.

    Tuesday, November 1, 2016 11:37 AM
  • you don't need sid history per se but your script will need to lookup identities in the new forest and match them via some attribute e.g. email address, samaccoutnname. Ideally you would of used ADMT to migrate the groups and memberships and then just use powerhsell to "fix them up" as admt does a terrible job of distro groups as it has no knowledge of exchange attributes.

    The original post says "migration".  That is what the word means.  It means to migrate the users and the security.  If we are just copying then the ADMT can also just copy users and groups without SIDs but "migration" always refers to moving the SIDs.  There is no other way to keep the security on the users files.  Just copying groups and users will not do that.  Security descriptors use the SID and not the name.  The system just looks up the name when displaying the security.  What is stored is the SID. A new domain will generate all new SIDs when the accounts are created.


    \_(ツ)_/


    • Edited by jrv Tuesday, November 1, 2016 11:42 AM
    Tuesday, November 1, 2016 11:42 AM
  • migration always refers to moving the sids, yeh except when it doesn't!

    how do you migrate distribution groups between domains that have no trust relationship then?

    Tuesday, November 1, 2016 12:14 PM
  • migration always refers to moving the sids, yeh except when it doesn't!

    how do you migrate distribution groups between domains that have no trust relationship then?

    Technically it does mean moving SIDs. Just dumpling accounts and loading to a new domain is not migrating it is called copying the accounts.

    Also the OP states "associate".  The method for "associating" is to copy SIDs to SID history as well as moving the existing SID history.  There is no other way to do this.

    This question comes up frequently when untrained Admins are asked to move users from one domain to another for a domain restructuring.  It is one element of certification for advanced AD design and management and is beyond day-to-day user/account management.

    This question should really be asked in the Directory Services forum as they can support the ADMT. 

    ADMT can produce pre-migration reports and allow the techs to plan how they will do the move.


    \_(ツ)_/

    • Proposed as answer by Alvwan Tuesday, November 8, 2016 5:47 AM
    Tuesday, November 1, 2016 12:24 PM
  • migration always refers to moving the sids, yeh except when it doesn't!

    how do you migrate distribution groups between domains that have no trust relationship then?

    Technically it does mean moving SIDs. Just dumpling accounts and loading to a new domain is not migrating it is called copying the accounts.

    Also the OP states "associate".  The method for "associating" is to copy SIDs to SID history as well as moving the existing SID history.  There is no other way to do this.

    This question comes up frequently when untrained Admins are asked to move users from one domain to another for a domain restructuring.  It is one element of certification for advanced AD design and management and is beyond day-to-day user/account management.

    This question should really be asked in the Directory Services forum as they can support the ADMT. 

    ADMT can produce pre-migration reports and allow the techs to plan how they will do the move.


    \_(ツ)_/

    The thing is, the topicstarter says that they already have corresponding users and groups in the new domain. This is why I assumed that the question is simply how to copy the users/groups membership.

    If they really need to properly migrate accounts and if they already use new accounts and assign permissions to them, they may be in a tricky situation trying to use ADMT for the old accounts now.

    So it is really the question of what the topicstarter meens by "associate" - crate a mapping between the old and the new SID or copy the group membership structure into the new domain. Maybe he appears here and provides a bit more info about this.

    /Regards




    • Edited by Avendil Tuesday, November 1, 2016 1:06 PM
    • Proposed as answer by Alvwan Tuesday, November 8, 2016 5:47 AM
    • Marked as answer by Alvwan Friday, November 11, 2016 9:23 AM
    Tuesday, November 1, 2016 1:05 PM
  • In my experience this is common for untrained admins because trey think they can just copy account names and have everything work until they realize the accounts no longer have access to any secured resources.

    In many multi-domain network we would have a resource domain and email domain and one or more account domains.  We must keep the SIDs when migrating.

    It is possible to update the history after the accounts are created but is is easier to just delete the unusable accounts and use the migration tool to mirror the account and group structure..  This can also update the changes to the domain security.

    If you are just trying to have two sets of identical account names then there is no way to "associate" them and there is no real meaning to "associate".  They can only be totally independent accounts with the same name.  This doesn't make much sense or provide any useful functionality.


    \_(ツ)_/

    • Proposed as answer by Alvwan Tuesday, November 8, 2016 5:47 AM
    • Marked as answer by Alvwan Friday, November 11, 2016 9:23 AM
    Tuesday, November 1, 2016 1:18 PM
  • Hi,

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 8, 2016 5:48 AM