Office 365 – Migrating Users Tenant-to-Tenant – Part Three Setup of New Tenant

This post continues the documentation of a single project – migration of a bunch of users between two 365 tenants.This is Part Three which goes over the setup of the new target tenant

Part One – Introduction and Approach
Part Two – Identifying Users and Objects
Part Three – Setup of New Tenant
Part Four – Data Migration with Quest-On-Demand
Part Five – Domain Migration
Part Six – Destination Tenant User Setup

All the scripts for this project are available at https://github.com/jmattmacd/O365-Tenant_to_tenant

Note – While I originally planned to do this work hence this section it was actually completed by the target tenants new provider – SoftCat¹ – so while this does show a working method it is not necessarily how it was done, for example I use the cloud accounts documented in in Part Two they used an AD extract.

Because we are pre-seeding all of the information the initial tenant build is extremely simple. No custom domains, no AD Connect, no custom licensing.

I’m not going to go through how to build an Office 365 tenant as its easier than installing Office. Once the tenant is built with its exciting new @newdomain.onmicrosoft.com we just need to create some new ADM users for the admins of the new tenant plus one Global Admin called “migration@newdomain.onmicrosoft.com” for me to use for migrating users and data that doesnt have MFA enforced. Yeah its generally a bad idea, but the tenant is empty right now. Calling it something like migration@ is actually really important due to some limitations in Quest for migrating data, we’ll get to that.

So we’ve got our tenant, we’ve got our admins roles now we can stick in some users. Most of the details dont actually matter – We be using AD Connect to softmatch the overwrite everything so all we are going to populate is the GivenName, Surname, DisplayName, mailNickName and new UPN (based on the new tenant onmicrosoft.com default). By an outstanding coincidence we already have an export of this data from Part Two in a file called “.\01-output-inscope_users.csv”, we’ll just read it back in and use it to generate our users (making sure we arent stupid enough to use a PowerShell instance still connected to the source tenant!): [09-user_import.ps1]
($DomainName1, $DomainName2 and $TargetDomainName require setting – note we arent using the wildcards anymore)

# Connect-AzureAD
$DomainName1 = "thisdomain.com"
$DomainName2 = "thatdomain.com"
$TargetDomainName = "newdomain.onmicrosoft.com"
$Users = Import-Csv -Path .\01-output-inscope_users.csv
$i=0
ForEach ($User in $Users) {
    $i++
    Write-Host $i "of" $users.COunt "-" $User.UserPrincipalName
    $newupn =  $user.UserPrincipalName.Replace($DomainName1,$TargetDomainName).Replace($DomainName2,$TargetDomainName)
    $PasswordProfile=New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
    $random = Get-random -Maximum 99999
    $PasswordProfile.Password="Passwords!"+$random
    New-AzureADUser -UserPrincipalName $user.UserPrincipalName.Replace($DomainName1,$TargetDomainName).Replace($DomainName2,$TargetDomainName) -DisplayName $User.DisplayName -GivenName $User.GivenName -Surname $user.Surname -AccountEnabled $true -PasswordProfile $PasswordProfile -MailNickName $user.mailNickName
}

This generates new cloud only accounts in your new tenant. Yay.

Licenses

Licenses in this particular case were applied by the target tenant’s MS partner (softcat) but basically the advice here is create some groups for personas – i.e. whether a user needs an F3, E1, E3, E5 licence and whether its M365, O365 then license the groups. Direct licensing is a ball-ache requiring service desk guys to be assigning licenses in the portal and badness will definitely ensue. I’ve got some scripts for checking license assignments that Ill share on another post sometime.

Gotcha here is the mailbox size, if you give someone an F3 license and their mailbox is 2.1 GB you’re gonna have a bad time.

Links

SoftCat – https://www.softcat.com/

Leave a Reply Cancel reply