Brugere ved en migrering

En migrering flytter ikke brugere. Den flytter navne: DOMÆNE\jha på en mappe eller i Ændret af på en fil. For hvert navn skal migreringsværktøjet finde en bruger eller en gruppe i Entra ID. Finder det ingen, får filen destinationens standardrettigheder (Microsoft), og hvad der så sker med Oprettet af og Ændret af, står under “Det der driller”. Hvordan rettighederne selv oversættes, står i Rettigheder flyttes ikke, de oversættes.

Automatisk mapping#

Er Active Directory synkroniseret til Entra ID med Entra Connect, finder værktøjerne de fleste selv:

• SharePoint Migration Tool (SPMT): indstillingen Automatic user mapping er slået til som standard: “On-premises users are automatically mapped to Microsoft Entra ID users where possible” (Microsoft).
• Migration Manager: indstillingen hedder Microsoft Entra lookup. Kan en bruger ikke findes i mappingfilen, finder værktøjet selv brugeren ud fra kildebrugerens SID (Microsoft).

Det holder, så længe brugeren findes i begge. Mappingfilen er til resten: brugere, der har skiftet navn, gamle domæner, konti, der ikke er synkroniseret, og grupper, der skal oversættes til andre grupper.

Mappingfilen#

En CSV-fil uden overskriftslinje og med tre kolonner (Microsoft):

CONTOSO\jha,jens.hansen@firma.dk,FALSE
CONTOSO\Salg,Salg,TRUE

• SID i stedet for logonnavn. Fra SharePoint Server 2013 kan kolonne A også være brugerens SID. Samme side siger også, at kun SharePoint Server 2013 og 2016 kan bruge den form, så den modsiger sig selv.
• En AD-gruppe kan ikke mappes til en SharePoint-gruppe.
• Filen og den automatiske mapping. Bruges en mappingfil, og skal rettighederne med, skriver Microsoft, at Automatic user mapping skal slås fra. Så slår SPMT ikke længere en bruger op i Entra ID, hvis brugeren mangler i filen (Microsoft). Filen skal altså være komplet.
• Migration Manager bruger samme format. Filen lægges op under Global settings → User mapping file (Microsoft).

Filen med PowerShell#

Brugerne fra AD, holdt op mod Entra ID, så kun de brugere, der kan findes, kommer i filen, og resten skrives ud til at tage stilling til. Ikke kørt:

 1Import-Module ActiveDirectory
 2Connect-MgGraph -Scopes "User.Read.All"
 3
 4$domain = "<DOMÆNE>"
 5$cloud  = @{}
 6Get-MgUser -All -Select UserPrincipalName | ForEach-Object { $cloud[$_.UserPrincipalName] = $true }
 7
 8$rows = foreach ($u in Get-ADUser -Filter * -Properties UserPrincipalName) {
 9    if ($u.UserPrincipalName -and $cloud.ContainsKey($u.UserPrincipalName)) {
10        "$domain\$($u.SamAccountName),$($u.UserPrincipalName),FALSE"
11    }
12    else {
13        Write-Warning "Ikke fundet i Entra ID: $domain\$($u.SamAccountName) ($($u.UserPrincipalName))"
14    }
15}
16
17$rows | Set-Content -Path "C:\Migrering\brugermapping.csv" -Encoding utf8

Scriptet går ud fra, at UPN’en er den samme i AD og i Entra ID. Det gælder ikke, hvis AD bruger et domæne, der ikke kan bruges på internettet, fx firma.local. Så får brugerne i Entra ID en UPN på onmicrosoft.com, medmindre der er tilføjet et rigtigt UPN-suffiks i AD (Microsoft). I så fald skal kolonne B bygges ud fra mail eller den UPN, brugeren faktisk har i Entra ID. Hashtabellen i PowerShell skelner ikke mellem store og små bogstaver, så Jens.Hansen@ og jens.hansen@ er det samme.

Grupperne kommer oveni, med TRUE i kolonne C og gruppens navn i Entra ID i kolonne B.

Det der driller#

• Hvem der ikke blev fundet. SPMT skriver brugere, der ikke kunne mappes, i UserNotMapped.csv i rapportens mappe med detaljer (Microsoft). Den er listen over, hvad mappingfilen mangler, efter en prøvemigrering.
• Oprettet af og Ændret af. Migration API, som SPMT bygger på, erstatter en bruger, der ikke kan findes, med System Account i fx Oprettet af. Er brugerens SID med, opretter den i stedet en slettet bruger med det navn og SID (Microsoft). At SPMT gør det samme, har jeg ikke fundet skrevet på SPMT’s egne sider.
• Medarbejdere, der er stoppet. Deres konti er slettet i AD og findes ikke i Entra ID, men deres navne står på mange af de gamle filer. Det skal besluttes, hvad de skal stå som: System Account, en slettet bruger med det gamle navn, eller en fælles konto. Hvordan SPMT håndterer slettede eller deaktiverede konti i mappingfilen, har jeg ikke fundet noget om.
• Gæster. En gæst i Entra ID har en UPN som jens_partner.dk#EXT#@<tenant>.onmicrosoft.com (Microsoft). Om SPMT og Migration Manager kan mappe en kildebruger til en gæst, har jeg ikke fundet dokumenteret. Microsoft beskriver kun mapping af gæster ved migrering mellem to tenants, som er et andet værktøj.
• SharePoint Server som kilde. Til store farme har Microsoft SMAT Identity Mapping Tool, der laver en rapport over alle identiteter i farmen og deres match i Entra ID (Microsoft).
• AzureAD-modulet (Get-AzureADUser, New-AzureADUser) er udfaset siden 30. marts 2024, og Microsoft lovede kun, at det virkede til 30. marts 2025 (Microsoft). Det er Microsoft Graph PowerShell nu.

OneDrive’erne skal oprettes, før brugernes egne filer kan flyttes: Opret OneDrive på forhånd med PowerShell.