Need to update AD target users from source users list

Welcome Forums General PowerShell Q&A Need to update AD target users from source users list

Viewing 2 reply threads
  • Author
    Posts
    • #213570
      Participant
      Topics: 4
      Replies: 8
      Points: 72
      Rank: Member

      Hi All,

      I am currently testing the following scenario and looking to automate it defining and validating parameters. I have put together the following cmdlets to get the script to work calling line-by-line, but what I ultimately like is for this to look at a  list of users in a CSV file. From this file, I would like to use two columns with the UserPrincipalName headers, such as:

      SourceUser | TargetUser

      #create variables
      $sourceUser = "TestUser1@old.domain.com"
      $targetUser = "TestUser1@new.domain.com"
      $sourceusername,$sourcedomain = $sourceUser -split ("@")
      $targetusername,$targetdomain = $targetUser -split ("@")
      $SourceAccount = Get-ADUser $sourceusername -server $sourcedomain -Properties objectSid
      $TargetAccount = Get-ADUser $targetusername -Server $targetdomain 
      
      #get the objectSid of the source account
      $objectSid = $SourceAccount.objectSid
      
      #copy source account objectSid to target account msExchMasterAccountSid
      $TargetAccount | Set-ADUser -Replace @{"msExchMasterAccountSid"=$objectSid}
      
      #enable target account
      $TargetAccount | Enable-ADAccount
      
      #disable the source account
      $SourceAccount | Disable-ADAccount
      
      #move the migrated user into prod OU
      $TargetAccount | Move-ADObject -TargetPath "OU=Test,OU=Users,DC=new,DC=domain,DC=com"

      I found already a couple of parameters that I believe would help to achieve two things such as the target domain and target OU:

      [CmdletBinding()]
      Param(
            #target domain
            [parameter(Mandatory,Position=1)]
            [ValidateScript({Get-ADDomain -Identity $_})]
            [String]$Domain,
      
            #target OU
            [parameter(Position=2)]
            [ValidateScript({Get-ADOrganizationalUnit -Identity $_})]
            [String]$TargetOu
            )

       

      Is there anyone able to help me put all this script together, please? 🙂

       

      Thanks,

      PowerDude

      • This topic was modified 1 month, 3 weeks ago by PowerDude.
      • This topic was modified 1 month, 3 weeks ago by PowerDude.
      • This topic was modified 1 month, 3 weeks ago by grokkit.
    • #214281
      Participant
      Topics: 12
      Replies: 1607
      Points: 2,495
      Helping Hand
      Rank: Community Hero
      • When I see an Exchange attribute being manipulated by an AD command (Set-ADUser -Replace @{“msExchMasterAccountSid”=$objectSid}), it sets off alarms. This is like skipping over the applications API or data layers and changing the database directly, which typically will not end well. There is a good possibility that there are other things need to occur for this to work as expected, which is why Exchange commands should be used for any changes to msExch attributes, IMHO.
      • Make sure that you add the -Server param to all Active Directory commands Get, Set, Enable, Disable, etc.
      • Need try\catch around all commands. Get commmands have -Identity, if they are not found then it throw an error. If you use -Filter, then it will either find a user or not, but you don’t have to handle an exception.

      Here is a framework for the function:

      function Invoke-NewDomainMigration {
          [CmdletBinding()]
          param (
              [Parameter(
                  Mandatory=$true,
                  ValueFromPipelineByPropertyName=$true
              )]
              [mailaddress]
              $SourceUser,
              [Parameter(
                  Mandatory=$true,
                  ValueFromPipelineByPropertyName=$true
              )]
              [mailaddress]
              $DestinationUser,
              [Parameter(
                  Mandatory=$false,
                  ValueFromPipelineByPropertyName=$true
              )]
              [string]
              $TargetOU
          )
          begin {}
          process {
              Write-Verbose ('Migrating user {0} to {1}' -f $SourceUser, $DestinationUser)
      
              $sourceDomain = ($SourceUser -split '@')[1]
              $destinationDomain = ($DestinationUser -split '@')[1]
      
              $adUserSource 
              
          }
          end {}
      }
      
      
      $csv = @"
      TestUser1@old.domain.com,TestUser1@new.domain.com
      TestUser2@old.domain.com,TestUser2@new.domain.com
      TestUser3@old.domain.com,TestUser3@new.domain.com
      TestUser4@old.domain.com,TestUser4@new.domain.com
      "@ | ConvertFrom-Csv -Header SourceUser, DestinationUser
      
      $csv | Invoke-NewDomainMigration -Verbose
      
    • #214587
      Participant
      Topics: 4
      Replies: 8
      Points: 72
      Rank: Member
      • When I see an Exchange attribute being manipulated by an AD command (Set-ADUser -Replace @{“msExchMasterAccountSid”=$objectSid}), it sets off alarms. This is like skipping over the applications API or data layers and changing the database directly, which typically will not end well. There is a good possibility that there are other things need to occur for this to work as expected, which is why Exchange commands should be used for any changes to msExch attributes, IMHO.
      • Make sure that you add the -Server param to all Active Directory commands Get, Set, Enable, Disable, etc.
      • Need try\catch around all commands. Get commmands have -Identity, if they are not found then it throw an error. If you use -Filter, then it will either find a user or not, but you don’t have to handle an exception.

      Here is a framework for the function:

      PowerShell
      45 lines

      <textarea class=”ace_text-input” style=”opacity: 0; height: 18px; width: 6.59781px; left: 110.38px; top: 0px;” spellcheck=”false” wrap=”off”></textarea>

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      function Invoke-NewDomainMigration {
      [CmdletBinding()]
      param (
      [Parameter(
      Mandatory=$true,
      ValueFromPipelineByPropertyName=$true
      )]
      [mailaddress]
      $SourceUser,
      [Parameter(
      Mandatory=$true,
      ValueFromPipelineByPropertyName=$true
      )]
      [mailaddress]
      $DestinationUser,
      [Parameter(
      Mandatory=$false,
      ValueFromPipelineByPropertyName=$true
      )]
      [string]
      $TargetOU
      )
      begin {}
      process {
      Write-Verbose (‘Migrating user {0} to {1}’ -f $SourceUser, $DestinationUser)
      $sourceDomain = ($SourceUser -split ‘@’)[1]
      $destinationDomain = ($DestinationUser -split ‘@’)[1]
      $adUserSource
      }
      end {}
      }
      $csv = @”
      TestUser1@old.domain.com,TestUser1@new.domain.com
      TestUser2@old.domain.com,TestUser2@new.domain.com
      TestUser3@old.domain.com,TestUser3@new.domain.com
      TestUser4@old.domain.com,TestUser4@new.domain.com
      “@ | ConvertFrom-Csv Header SourceUser, DestinationUser
      $csv | Invoke-NewDomainMigration Verbose
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

      Hi Rob,

      That’s a good point to start. I will prepare something around your suggestions and see how far I get. In the meantime I can confirm that the solution provided for the Exchange attribute is out of the box and even though it is not supported nor recommend it seems working so far.

      As I am also interested in getting to know your point on view on that matter. Could you please let me know if there is any other way to migrate that Exchange attribute to a new Active directory user assuming it has to connect then to the same office 365 account/email?

       

      Many thanks,

      PowerDude

Viewing 2 reply threads
  • You must be logged in to reply to this topic.