Del via

Postboksoverføring på tvers av leier

  • Artikkel

Under sammenslåinger eller avhendelser trenger du kanskje muligheten til å flytte brukernes Exchange Online postbokser til en ny leier. Overføring av postboks over flere leiere gjør det mulig for leieradministratorer å bruke velkjente grensesnitt som Exchange Online PowerShell og MRS for å overføre brukere til den nye organisasjonen.

Administratorer kan bruke cmdleten New-MigrationBatch , som er tilgjengelig gjennom administrasjonsrollen Flytt postbokser , til å utføre flyttinger på tvers av leier.

Brukere som overfører, må finnes i målleieren Exchange Online systemet som en MailUser, merket med bestemte attributter for å aktivere flyttinger på tvers av leier. Systemet kan ikke flytte brukere som ikke er riktig konfigurert i målleieren.

Når overføringene er fullført, konverteres kildebrukerpostboksen til en MailUser, og targetAddress (vises som ExternalEmailAddress i Exchange) stemples med rutingadressen til målleieren. Denne prosessen etterlater arven MailUser i kildeleieren og muliggjør sameksistens og e-postruting. Når forretningsprosesser tillater det, kan kildeleieren fjerne kilde-MailUser eller konvertere dem til en e-postkontakt.

Exchange-postboksoverføringer på tvers av leiere støttes bare for leiere i hybrid- eller skybasert, eller en kombinasjon av de to.

Denne artikkelen beskriver prosessen for postbokstrekkinger på tvers av leiere, og gir veiledning om hvordan du klargjør kilde- og målleieren for Exchange Online postboksinnholdet flyttes.

Viktig

Postbokser som er på alle typer sperringer, overføres ikke, og flyttingen for disse postboksene blokkeres.

Når en postboks overføres på tvers av leier med denne funksjonen, overføres bare brukersynlig innhold i postboksen (e-post, kontakter, kalender, oppgaver og notater) til målet (målleieren). Kildepostboksen slettes etter en vellykket overføring. Denne slettingen betyr at kildepostboksen er tilgjengelig, synlig eller tilgjengelig i kildeleieren, etter overføring.

Lisenser

Viktig

Overføringer på tvers av leier krever en lisens per bruker (engangsavgift) og kan tilordnes enten på kilde- eller målbrukerobjektet. Denne lisensen dekker også OneDrive for Business overføring. Overføring av brukerdata på tvers av leier er tilgjengelig som et tillegg til følgende Microsoft 365-abonnementsplaner: Microsoft 365 Business Basic, Standard og Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; OneDrive for Business og EDU.

Advarsel

Du må ha kjøpt eller bekreftet at du kan kjøpe brukeroverføringslisenser på tvers av leiere før de neste trinnene. Overføringer mislykkes hvis dette trinnet ikke er fullført. Microsoft tilbyr ikke unntak for dette lisensieringskravet.

Hvis du ikke har tilordnet riktig lisens til brukeren som overføres, mislykkes overføringen, og du får en feilmelding som ligner på følgende:

Error: CrossTenantMigrationWithoutLicensePermanentException: No license was found for the source recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87', or the target recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87'. A Cross-tenant User Data Migration license is required to move a mailbox between tenants.

Klargjør kilde- og målleieren

Forutsetninger for kilde- og målleieren

Før du begynner, må du kontrollere at du har de nødvendige tillatelsene til å konfigurere Flytt postboks-programmet i Azure, EXO Migration Endpoint og EXO Organization Relationship.

I tillegg kreves minst én e-postaktivert sikkerhetsgruppe i kildeleieren. Disse gruppene brukes til å begrense listen over postbokser som kan flyttes fra kildeleieren (eller noen ganger kalt ressurs) til målleieren. Med denne omfanget kan leieradministratoren begrense eller begrense det bestemte settet med postbokser som må flyttes, og hindre utilsiktede brukere i å bli overført.

Hvis du overfører mer enn 10 000 brukere, anbefaler vi at du oppretter flere grupper for å inneholde brukerlisten for best ytelse. Selv om nestede grupper støttes, anbefales de ikke.

Du må også kommunisere med det klarerte partnerselskapet (som du skal flytte postbokser med) for å få leier-ID-en for Microsoft 365. Denne leier-ID-en brukes i feltet Domenenavn for organisasjonsrelasjon .

Hvis du vil hente leier-ID-en for et abonnement, logger du på Administrasjonssenter for Microsoft 365 og går til https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Velg kopier-ikonet for tenant-ID-egenskapen for å kopiere det til utklippstavlen.

Alle brukere i både kilde- og målorganisasjonene må være lisensiert med riktig Exchange Online abonnementer. Sørg også for at du bruker dataoverføringslisenser på tvers av leier for alle brukere som skal overføres til målsiden.

Konfigurasjonstrinn for å aktivere leiere for postboksoverføringer på tvers av leiere

Obs!

Du må konfigurere målet (målet) først. For å fullføre disse trinnene må du ikke ha eller kjenne til leieradministratorlegitimasjonen for både kilde- og målleieren. Trinn kan utføres individuelt for hver leier av forskjellige administratorer.

Klargjøre målleieren (mål) ved å opprette overføringsprogrammet og hemmeligheten

  1. Logg deg på Microsoft Entra administrasjonssenter (https://portal.azure.com) med administratorlegitimasjonen for målleieren.

    Azure-pålogging

  2. Velg Visunder Behandle Microsoft Entra ID.

    Microsoft Entra-knappen

  3. Velg Appregistreringer i navigasjonsruten.

  4. Velg Ny registrering.

    Skjermbilde av brukergrensesnittet for nytt program.

  5. Velg Kontoer i hvilken som helst organisasjonskatalog (Alle Microsoft Entra kataloger – flere leiere) under Støttede kontotyper på siden Registrer et program. Velg web under Omdiriger URI (valgfritt) og skriv deretter inn https://office.com. Velg deretter Registrer.

    Skjermbilde av skjemaet Registrer et program.

    Se varslingsdialogboksen som sier at appen ble opprettet, øverst til høyre på siden.

  6. Gå tilbake til hjemmesiden, gå til Microsoft Entra ID, og velg deretter Appregistreringer.

  7. Finn appen du opprettet, under Eide programmer, og velg den.

  8. Kopier program-ID-en (klient) under Essentials. Du trenger denne informasjonen senere for å opprette en nettadresse for målleieren.

  9. Velg API-tillatelser i navigasjonsruten for å vise tillatelser som er tilordnet appen.

  10. Som standard tilordnes User.Read-tillatelser til appen du opprettet, men disse tillatelsene er ikke nødvendige for postboksoverføringer. Du kan fjerne disse tillatelsene.

    Skjermbilde av «Konfigurerte tillatelser».

  11. Hvis du vil legge til tillatelse for postboksoverføring, velger du Legg til en tillatelse.

  12. Velg API-er som organisasjonen bruker, søk etter Office 365 Exchange Onlinei vinduet Be om API-tillatelser, og velg det.

    Skjermbilde av «Velg en API» under «Be om API-tillatelser».

  13. Velg programtillatelser.

  14. Utvid postboksen under Velg tillatelser, og velg Mailbox.Migration, og velg deretter Legg til tillatelser nederst på skjermen.

    Skjermbilde av Mailbox.Migration og avmerkingsboksen under Velg tillatelser.

  15. Nå velger du Sertifikater & hemmeligheter i navigasjonsruten for programmet.

  16. Velg Ny klienthemmelighetunder Klienthemmeligheter.

    Skjermbilde av Klienthemmeligheter og alternativet for å legge til en ny klienthemmelighet.

  17. Skriv inn en beskrivelse i vinduet Legg til en klienthemmelighet , og konfigurer deretter utløpsinnstillingene.

    Obs!

    Passordet brukes når du oppretter overføringsendepunktet. Det er svært viktig at du kopierer dette passordet til utklippstavlen og/eller til et sikkert/hemmelig passordsikkert sted. Den hemmelige opprettelsesfasen er den eneste gangen du kan se dette passordet. Hvis du på en eller annen måte mister den eller trenger å tilbakestille den, kan du logge deg på Azure Portal på nytt, gå til appregistreringer, finne overføringsappen, velge Hemmeligheter & sertifikater og deretter opprette en ny hemmelighet for appen.

Nå som du har opprettet overføringsprogrammet og hemmeligheten, er neste trinn å samtykke til programmet.

  1. Velg Enterprise-programmer i navigasjonsruten på Microsoft Entra ID målside. Finn deretter overføringsappen du opprettet, velg den, og velg deretter API-tillatelser.

  2. Velg Gi administratorsamtykke for [din leier]. Et nytt nettleservindu åpnes.

  3. Velg Godta.

  4. Gå tilbake til portalvinduet, og velg Oppdater for å bekrefte godkjenningen.

  5. Formuler nettadressen som skal sendes til den klarerte partneren (administrator for kildeleier), slik at vedkommende også kan godta programmet for å aktivere postboksoverføring.

    Her er et eksempel på nettadressen du kan oppgi til dem:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

    Obs!

    Du trenger program-ID-en for postboksoverføringsappen du nettopp opprettet. Du må erstatte contoso.onmicrosoft.com i eksemplet ovenfor med kildeleierens riktige onmicrosoft.com navn. Du må også erstatte [application_id_of_the_app_you_just_created] med program-ID-en for postboksoverføringsappen du nettopp opprettet.

Klargjøre målleieren ved å opprette Exchange Online overføringsendepunkt og organisasjonsrelasjon

  1. Koble til Exchange Online PowerShell i målleieren Exchange Online.

  2. Opprett et nytt overføringsendepunkt for postboksflyttinger på tvers av leier.

    Obs!

    Du trenger program-ID-en for postboksoverføringsappen du nettopp opprettet, og passordet (hemmeligheten) du konfigurerte i Klargjør målleieren (mål) ved å opprette overføringsprogrammet og hemmeligheten. Avhengig av hvilken Microsoft 365-skyforekomst du bruker, kan endepunktet være forskjellig. Se siden for Microsoft 365-endepunkter; velg riktig forekomst for leieren. se deretter gjennom Exchange Online Optimaliser/obligatorisk adresse, og erstatt etter behov.

    $AppId = "[Guid copied from the migrations app]"
$name = "[the name of your new migration endpoint]"
$remote = "<contoso>.onmicrosoft.com"
$secret = "[this is your secret password you saved in the previous steps]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String $secret -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant $remote -Credentials $Credential -ExchangeRemoteMove:$true -Name $name -ApplicationId $AppId

Obs!

Hvis kommandoen ovenfor mislykkes, kan du ta kontakt med administratoren for kildeleieren for å bekrefte om programmet ble gitt administratorsamtykke.

  1. Opprett et nytt organisasjonsrelasjonsobjekt, eller rediger det eksisterende organisasjonsrelasjonsobjektet til kildeleieren.

    $sourceTenantId = "[tenant ID of your trusted partner, where the source mailboxes are]"
$orgrelname = "[name of your new organization relationship]"
$orgrels = Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

Klargjøre kildeleieren (gjeldende postboksplassering) ved å godta overføringsprogrammet og konfigurere organisasjonsrelasjonen

  1. Bruk nettleseren til å gå til nettadressekoblingen som leveres av den klarerte partneren, for å samtykke til overføringsprogrammet for postboksen. URL-adressen skal se slik ut:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

    Obs!

    Du trenger program-ID-en for postboksoverføringsappen du nettopp opprettet. Du må erstatte contoso.onmicrosoft.com i det forrige eksemplet med nettadressen til kildeleieren onmicrosoft.com . Du må også erstatte [application_id_of_the_app_you_just_created] med program-ID-en for postboksoverføringsappen du nettopp opprettet.

  2. Godta programmet når popup-vinduet vises. Du kan også logge på Microsoft Entra administrasjonssenter og finne programmet under Enterprise-programmer.

  3. Koble til Exchange Online PowerShell på kilde-Exchange Online-leieren.

  4. Opprett et nytt organisasjonsrelasjonsobjekt eller rediger det eksisterende organisasjonsrelasjonsobjektet til målleieren i Exchange Online PowerShell:

    $targetTenantId = "[tenant ID of your trusted partner, where the mailboxes are being moved to]"
$appId = "[application ID of the mailbox migration app you consented to]"
$scope = "[name of the mail enabled security group that contains the list of users who are allowed to migrate]"
$orgrelname = "[name of your new organization relationship]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host "Group already exists." }
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

    Obs!

    Leier-ID-en du angir som $sourceTenantId og $targetTenantId, er GUID-en og ikke domenenavnet for leieren. Hvis du vil ha et eksempel på en leier-ID og informasjon om hvordan du finner leier-ID-en din, kan du se Finne leier-ID-en for Microsoft 365.

Klargjøre målbrukerobjekter for overføring

Brukere som overfører, må finnes i målleieren og Exchange Online systemet (som en MailUser) merket med bestemte attributter for å aktivere flyttinger på tvers av leier. Systemet kan ikke flytte brukere som ikke er riktig konfigurert i målleieren. Forutsetningene for delen om målbrukerobjekter beskriver E-postbruker-objektkravene for målleieren.

Forutsetninger for målbrukerobjekter

Kontroller at følgende objekter og attributter er angitt i målorganisasjonen:

Tips

Microsoft utvikler en funksjon for å gi en sikker automatisert metode for å angi mange av attributtene (angitt nedenfor, i denne delen). Denne funksjonen, kalt Identitetstilordning på tvers av leier, leter for øyeblikket etter kunder som er villige til å delta i en liten privat forhåndsvisning. Hvis du vil ha mer informasjon om denne forhåndsversjonen og hvordan den kan forenkle overføringsprosessene på tvers av leier, kan du se Tilordning av identitet på tvers av leier.

For alle postbokser som flytter fra en kildeorganisasjon, må du klargjøre et MailUser-objekt i målorganisasjonen:

  1. Target MailUser må ha disse attributtene fra kildepostboksen eller tilordnet med det nye brukerobjektet:

    1. ExchangeGUID (direkte flyt fra kilde til mål): POSTBOKS-GUID-en må samsvare. Flytteprosessen fortsetter ikke hvis dette attributtet ikke finnes på målobjektet.

    2. ArchiveGUID (direkte flyt fra kilde til mål): Arkiv-GUID-en må samsvare. Flytteprosessen fortsetter ikke hvis dette attributtet ikke finnes på målobjektet. (Dette attributtet er bare nødvendig hvis kildepostboksen er Arkivaktivert).

    3. LegacyExchangeDN (flyt som proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN må være til stede på målet MailUser som x500: proxyAddress. I tillegg må du også kopiere alle x500-adressene fra kildepostboksen til målpostbrukeren. Flytteprosessene fortsetter ikke hvis disse x500-adressene ikke finnes på målobjektet. Dette trinnet er også viktig for å aktivere svar-muligheten for e-postmeldinger som sendes før overføring. Avsender-/mottakeradressen i hvert e-postelement og hurtigbufferen for autofullføring i Microsoft Outlook og i Microsoft Outlook Web App (OWA) bruker verdien for LegacyExchangeDN-attributtet. Hvis en bruker ikke kan være plassert ved hjelp av LegacyExchangeDN-verdien, kan leveringen av e-postmeldinger mislykkes med en 5.1.1 NDR.

    4. UserPrincipalName: UPN justeres etter brukerens NYE identitet eller målselskap (for eksempel user@northwindtraders.onmicrosoft.com).

    5. Primær SMTPAddress: Primær SMTP-adresse justeres etter brukerens NYE firma (for eksempel user@northwindtraders.com).

    6. TargetAddress/ExternalEmailAddress: MailUser refererer til brukerens gjeldende postboks som driftes i kildeleieren (for eksempel user@contoso.onmicrosoft.com). Når denne verdien tilordnes, må du kontrollere at du har/også tilordner PrimarySMTPAddress. ellers vil denne verdien angi PrimarySMTPAddress, noe som vil føre til flyttingsfeil.

    7. Du kan ikke legge til eldre smtp-proxyadresser fra kildepostboksen til mål-MailUser. Du kan for eksempel ikke vedlikeholde contoso.com på MEU i northwindtraders.onmicrosoft.com leierobjekter. Domener er bare knyttet til én Microsoft Entra ID eller Exchange Online leier.

      Eksempel på mål-MailUser-objekt:

      Attributt Verdi
      Alias LaraN
      RecipientType MailUser
      RecipientTypeDetails MailUser
      UserPrincipalName LaraN@northwintraders.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@northwindtraders.com
      ExternalEmailAddress SMTP:LaraN@contoso.onmicrosoft.com
      ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara
      EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
      Smtp:LaraN@northwindtraders.onmicrosoft.com
      SMTP:Lara.Newton@northwindtraders.com
      X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

      Eksempel på postboksobjekt for kilde :

      Attributt Verdi
      Alias LaraN
      RecipientType UserMailbox
      RecipientTypeDetails UserMailbox
      UserPrincipalName LaraN@contoso.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@contoso.com
      ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
      EmailAddresses Smtp:LaraN@contoso.onmicrosoft.com
      SMTP:Lara.Newton@contoso.com
      X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

  2. Andre attributter kan være inkludert i Exchange hybrid tilbakeskriving allerede. Hvis ikke, bør de inkluderes.

    1. msExchBlockedSendersHash– Skriver tilbake blokkerte avsenderdata fra klienter til lokal Active Directory.
    2. msExchSafeRecipientsHash– Skriver tilbake data om klarerte mottakere fra klienter til lokal Active Directory.
    3. msExchSafeSendersHash– Skriver tilbake klarerte avsenderdata fra klienter til lokal Active Directory.

    Brukere i målorganisasjonen må være lisensiert med riktige Exchange Online abonnementer som gjelder for organisasjonen. Du kan bruke en lisens før en postboksflytting, men BARE når målet MailUser er riktig konfigurert med ExchangeGUID og proxy-adresser. Hvis du bruker en lisens før ExchangeGUID brukes, resulterer det i en ny postboks som er klargjort i målorganisasjonen. Du må også bruke en brukerdataoverføringslisens på tvers av leier. Ellers kan det hende du ser en midlertidig feillesing som krever godkjenning, som vil rapportere en advarsel i flytterapporten om at en lisens ikke har blitt brukt på målbrukeren.

    Obs!

    Når du bruker en lisens på et postboks- eller MailUser-objekt, blir alle SMTP-type proxyAddresses skrubbet for å sikre at bare bekreftede domener er inkludert i Exchange EmailAddresses-matrisen.

  3. Du må kontrollere at mål-MailUser ikke har noen tidligere ExchangeGUID som ikke samsvarer med Source ExchangeGUID. Denne manglende samsvarsfeilen kan oppstå hvis mål-MEU tidligere ble lisensiert for Exchange Online og klargjort en postboks. Hvis målet MailUser tidligere ble lisensiert for eller hadde en ExchangeGUID som ikke samsvarer med Source ExchangeGUID, må du utføre en opprydding av skyen MEU. For disse meus-skyene kan du kjøre Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Forsiktig!

Denne prosessen er irreversibel. Hvis objektet har en softDeleted-postboks, kan det ikke gjenopprettes etter dette punktet. Når den er fjernet, kan du imidlertid synkronisere riktig ExchangeGUID til målobjektet, og MRS kobler kildepostboksen til den nylig opprettede målpostboksen. (Referer EHLO-bloggen på den nye parameteren.)

Finn objekter som tidligere var postbokser ved hjelp av følgende kommando:

Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize

Her er et eksempel:

Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize

Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
----       ---------------------------- ------------- --------------------
John       UserMailbox                  MailUser      MailUser

Fjern den slettede postboksen ved hjelp av følgende kommando:

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Her er et eksempel:

Set-User John@northwindtraders.com -PermanentlyClearPreviousMailboxInfo -Confirm

Are you sure you want to perform this action?
Delete all existing information about user "John@northwindtraders.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY.
Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y

Hvordan vet at dette fungerte?

Du kan bekrefte konfigurasjonen av postboksoverføring på tvers av leier ved å kjøre cmdleten Test-MigrationServerAvailability mot overføringsendepunktet på tvers av leier som du opprettet på målleieren. Kjør følgende cmdlet fra målleieren:

Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"

Obs!

I tillegg vil du kanskje dra nytte av valideringsskriptet for postboksoverføring på tvers av leier, slik at du kan validere at organisasjonene konfigureres riktig mellom dem, og objektene du planlegger å overføre fra én leier til en annen. Skriptet vil bidra til å identifisere eventuelle avvik som kan være til stede på alle objekter samtidig, og som et resultat vil det redusere tiden som brukes på den innledende fasen.

Flytte postbokser tilbake til den opprinnelige kilden

Hvis en postboks kreves for å gå tilbake til den opprinnelige kildeleieren, må det samme settet med trinn og skript kjøres i både nye kilde- og nye målleieren, med noe avvik.

Ikke kjør de angitte eksempelskriptene for å opprette OrganizationRelationship.

Oppdater følgende verdier i eksisterende OrganizationRelationship som er opprettet i hver leier:

  • MailboxMovesCapability bør ha Innkommende, RemoteOutbound som funksjoner i både kilde- og målleieren.
  • Oppdater OAuthApplicationId-verdien i den nye kildeleieren med verdien fra det nylig opprettede programmet i den nye kildeleieren.
  • Oppdater MailboxMovePublishedScopes-verdien med den nyopprettede sikkerhetsgruppen i den nye kildeleieren i den nye kildeleieren i den nye kildeleieren.

Utføre postboksoverføringer

Exchange-postboksoverføringer på tvers av leiere startes fra målleieren som overføringsgrupper. Denne prosessen ligner på måten overføringsgrupper om bord fungerer når du overfører fra Exchange lokalt til Microsoft 365.

Opprett overføringsgrupper

Her er en eksempelkommando for å starte en satsvis overføring:

New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com

Identity                   Status  Type               TotalCount
--------                   ------  ----               ----------
T2Tbatch                   Syncing ExchangeRemoteMove 1

Obs!

E-postadressen i CSV-filen må være den som er angitt i målleieren (for eksempel userA@northwindtraders.onmicrosoft.com), ikke den i kildeleieren. Hvis du vil ha mer informasjon om cmdleten, kan du klikke herFor eksempel CSV-filinformasjon, klikk her

Et minimalt eksempel på en CSV-fil er:

EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com

Overføringsgruppeinnsending støttes også fra det nye administrasjonssenteret for Exchange når du velger alternativet på tvers av leier.

Oppdater lokale MailUsers

Når postboksen flyttes fra kilde til mål, bør du sørge for at de lokale e-postbrukerne, både i kilden og målet, oppdateres med den nye måladressen. I eksemplene er targetDeliveryDomain som brukes i flyttingen , northwindtraders.onmicrosoft.com. Oppdater e-postbrukerne med denne måladressen.

Fjerne endepunkter og organisasjonsrelasjoner etter overføring

Bruk cmdleten Remove-MigrationEndpoint til å fjerne eksisterende overføringsendepunkter for kilde- eller målservere etter at overføringen er fullført.

Bruk cmdleten Remove-OrganizationRelationship til å fjerne eksisterende organisasjonsrelasjoner for kilde- eller målservere etter at overføringen er fullført.

Vanlige spørsmål

Må jeg oppdatere RemoteMailboxes i den lokale kildeleieren etter flyttingen?

Kildeutvekslingsorganisasjon

Du bør oppdatere targetAddress (RemoteRoutingAddress/ExternalEmailAddress) for hver lokale kildebruker når postboksen for kildeleieren flyttes til målleieren. Selv om e-postruting kan følge henvisningene på tvers av flere e-postbrukere med ulike targetAddresses, må ledige/opptatte oppslag for e-postbrukere angi plasseringen til postboksbrukeren.

Målutvekslingsorganisasjon

Når overføringen er fullført i en hybridorganisasjon, kjører du følgende PowerShell-kommando hvis du vil at brukerne skal ha eksterne postbokser lokalt:

Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox

Overfører Teams-møter på tvers av leier?

Når Teams-møter flyttes, oppdateres ikke nettadressen for møtet når elementer overføres på tvers av leier. Siden nettadressen vil være ugyldig i målleieren, må du fjerne og opprette Teams-møter på nytt.

Hvilket innhold overføres på tvers av leier?

Når en postboks overføres på tvers av tenanten med denne funksjonen, overføres bare brukersynlig innhold i postboksen, også kalt Øverst i informasjonslageret (e-post, kontakter, kalender, oppgaver og notater) og mappene Gjenopprettelige elementer, Slettinger, Versjoner og Tømming.

Blir elementer i utboksen overført på tvers av leier?

Elementer i utboksen overføres ikke over flere leiere fordi denne mappen er en klientbasert mappe som er spesifikk for Outlook-klienten. Elementer i utboksen lagres lokalt og synkroniseres ikke til skyen.

Overfører innholdet i Teams-chattemappen på tvers av tenanten?

Nei, innholdet i Teams-chattemappen overfører ikke på tvers av leier. Men når postboksen har blitt overført på tvers av leier, vil teams chat-mappeinnholdet være tilgjengelig for kildeleieradministrator for å søke og eksportere, ved hjelp av et innholdssøk.

Hvordan kan jeg se bare flyttinger som er flyttinger på tvers av leiere, ikke pålastings- og avlastingstrekk?

Bruk Flagg-parameteren :

Get-MoveRequest -Flags "CrossTenant"

Kan du angi eksempelskript for kopiering av attributter som brukes i testing?

Obs!

EKSEMPEL – SOM DET ER, INGEN GARANTI Dette skriptet forutsetter en tilkobling til både kildepostboksen (for å hente kildeverdier) og målet lokal Active Directory Domain Services (for å stemple ADUser-objektet).

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the northwindtraders tenant
$outFileUsers = "$home\desktop\UsersToMigrate.txt"
$outFileUsersXML = "$home\desktop\UsersToMigrate.xml"
Get-Mailbox -Filter "CustomAttribute1 -like 'Cross-Tenant-Project'" -ResultSize Unlimited | Select-Object -ExpandProperty  Alias | Out-File $outFileUsers
$mailboxes = Get-Content $outFileUsers
$mailboxes | ForEach-Object {Get-Mailbox $_} | Select-Object PrimarySMTPAddress,Alias,SamAccountName,FirstName,LastName,DisplayName,Name,ExchangeGuid,ArchiveGuid,LegacyExchangeDn,EmailAddresses | Export-Clixml $outFileUsersXML

# Copy the file $outfile to the desktop of the target on-premises then run the below to create MEU in Target
$symbols = '!@#$%^&*'.ToCharArray()
$characterList = @([char[]]([char]'a'..[char]'z'), [char[]]([char]'A'..[char]'Z'), [char[]]([char]'0'..[char]'9') + $symbols)

function GeneratePassword {
    param(
        [ValidateRange(12, 256)]
        [int]
        $length = 16
    )

    do {
        $password = -join (0..$length | ForEach-Object { $characterList | Get-Random })
        [int]$hasLowerChar = $password -cmatch '[a-z]'
        [int]$hasUpperChar = $password -cmatch '[A-Z]'
        [int]$hasDigit = $password -match '[0-9]'
        [int]$hasSymbol = $password.IndexOfAny($symbols) -ne -1

    }
    until (($hasLowerChar + $hasUpperChar + $hasDigit + $hasSymbol) -ge 3)

    $password | ConvertTo-SecureString -AsPlainText
}

$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
foreach ($m in $mailboxes) {
    $organization = "@contoso.onmicrosoft.com"
    $mosi = $m.Alias + $organization
    $Password = GeneratePassword
    $x500 = "x500:" + $m.LegacyExchangeDn
    $tmpUser = New-MailUser -MicrosoftOnlineServicesID $mosi -PrimarySmtpAddress $mosi -ExternalEmailAddress $m.PrimarySmtpAddress -FirstName $m.FirstName -LastName $m.LastName -Name $m.Name -DisplayName $m.DisplayName -Alias $m.Alias -Password $Password
    $tmpUser | Set-MailUser -EmailAddresses @{add = $x500 } -ExchangeGuid $m.ExchangeGuid -ArchiveGuid $m.ArchiveGuid -CustomAttribute1 "Cross-Tenant-Project"
    $tmpx500 = $m.EmailAddresses | Where-Object { $_ -match "x500" }
    $tmpx500 | ForEach-Object { Set-MailUser $m.Alias -EmailAddresses @{add = "$_" } }
}

# Now synchronize the changes from On-Premises to Azure and Exchange Online in the target tenant
# This action should create the target mail enabled users (MEUs) in the Target tenant
Start-ADSyncSyncCycle

Hvordan får vi tilgang til Outlook på dag 1 etter at brukerpostboksen er flyttet?

Siden bare én leier kan eie et domene, knyttes ikke den tidligere primære SMTPAddress til brukeren i målleieren når postboksflyttingen fullføres. bare de domenene som er knyttet til den nye leieren. Outlook bruker brukerens nye UPN til å godkjenne til tjenesten, og Outlook-profilen forventer å finne den eldre primære SMTPAddress for å samsvare med postboksen i målsystemet. Siden den eldre adressen ikke er i målsystemet, vil ikke Outlook-profilen koble til for å finne den nylig flyttede postboksen.

For denne første distribusjonen må brukerne gjenoppbygge profilen sin med sin nye UPN, primære SMTP-adresse og synkronisere OST-innhold på nytt.

Obs!

Planlegg etter hvert som du satsviser brukerne for fullføring. Du må ta hensyn til nettverksutnyttelse og -kapasitet når Outlook-klientprofiler opprettes og påfølgende OST- og OAB-filer lastes ned til klienter.

Hvilke Exchange RBAC-roller må jeg være medlem av for å konfigurere eller fullføre en flytting på tvers av leier?

Det finnes en matrise med roller basert på antagelsen om delegerte oppgaver når du utfører en postboksflytting. To roller kreves for øyeblikket:

  • Den første rollen er for en engangsoppsettsoppgave som etablerer godkjenningen av å flytte innhold til eller ut av leier-/organisasjonsgrensen. Siden flytting av data fra organisasjonens kontroll er en viktig bekymring for alle firmaer, har vi valgt den høyeste tilordnede rollen som organisasjonsadministrator. Denne rollen må endre eller konfigurere et nytt OrganizationRelationship som definerer -MailboxMoveCapability innstillingen med den eksterne organisasjonen. Bare organisasjonsadministratoren -MailboxMoveCapability kan endre innstillingen, mens andre attributter i OrganizationRelationship kan administreres av administratoren for organisasjonsdeling.
  • Rollen til å utføre de faktiske flyttekommandoene kan delegeres til en funksjon på lavere nivå. Rollen til Flytt postbokser tilordnes muligheten til å flytte postbokser inn eller ut av organisasjonen.

Hvordan retter vi oss mot hvilken SMTP-adresse som er valgt for targetAddress (TargetDeliveryDomain) i den konverterte postboksen (til MailUser-konvertering)?

Exchange-postboksen flyttes ved hjelp av MRS utformet targetAddress på den opprinnelige kildepostboksen når du konverterer til en MailUser ved å matche en e-postadresse (proxyAddress) på målobjektet. Prosessen tar -TargetDeliveryDomain verdien som sendes til kommandoen, og ser deretter etter en samsvarende proxy for dette domenet på målsiden. Når vi finner et treff, brukes den samsvarende proxyAdressen til å angi ExternalEmailAddress (targetAddress) på det konverterte postboksobjektet (nå MailUser).

Hvordan fungerer e-postflyten etter overføring?

E-postflyt på tvers av leier etter overføring fungerer på samme måte som Exchange Hybrid-e-postflyt. Hver overførte postboks trenger kilde-MailUser med riktig måladresse for å videresende innkommende e-post fra kildeleieren til postbokser i målleieren. Funksjoner for transportregler, sikkerhet og samsvar kjøres som konfigurert i hver leier som e-posten flyter gjennom. Så for innkommende e-post kjøres funksjoner som søppelpost, skadelig programvare, karantene, transportregler og loggføringsregler først i kildeleieren, deretter i målleieren.

Hvordan overføres postbokstillatelser?

Postbokstillatelser inkluderer Send på vegne av og Postbokstilgang:

  • Send på vegne av (AD:publicDelegates) lagrer DN-en til mottakere med tilgang til en brukers postboks som representant. Denne verdien lagres i Active Directory og flyttes for øyeblikket ikke som en del av postboksovergangen. Hvis kildepostboksen har angitt publicDelegates, må du restampre publicDelegates på målpostboksen når MEU-til-postbokskonverteringen fullføres i målmiljøet ved å kjøre Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
  • Postbokstillatelser som er lagret i postboksen, flyttes med postboksen når både hovedstolen og representanten flyttes til målsystemet. Brukeren TestUser7 gis for eksempel FullAccess til postboksen TestUser_8 i tenanten SourceCompany.onmicrosoft.com. Når postboksen flyttes fullført til TargetCompany.onmicrosoft.com, konfigureres de samme tillatelsene i målkatalogen. Eksempler på bruk av _Get-MailboxPermission for TestUser_7 i både kilde- og målleieren, vises nedenfor. Exchange-cmdleter er prefikset med kilde og mål tilsvarende.

Her er et eksempel på utdataene fra postbokstillatelsen før du flytter fra kildesiden:

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, is Inherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@contoso.onmicrosoft.com               {FullAccess}                         False       False

Her er et eksempel på utdataene fra postbokstillatelsen etter flyttingen fra målsiden:

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@northwindtraders.onmicrosoft.com      {FullAccess}                         False       False

Obs!

Postboks og kalendertillatelser på tvers av leier støttes ikke. Du må organisere sikkerhetskontohavere og representanter i konsoliderte flyttegrupper slik at disse tilkoblede postboksene overføres samtidig fra kildeleieren.

Hvilken X500-proxy bør legges til i mål-MailUser-proxyadressene for å aktivere overføring?

Postboksoverføringen på tvers av leier krever at LegacyExchangeDN-verdien for kildepostboksobjektet stemples som en x500-e-postadresse på målet MailUser-objekt.

Eksempel:

LegacyExchangeDN value on source mailbox is:
/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara

so, the x500 email address to be added to target MailUser object would be:
x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara

Obs!

I tillegg til denne X500-proxyen må du kopiere alle X500-proxyer fra postboksen i kilden til postboksen i målet. Selv om det er sjeldent, kan du også kjøre på tvers av en X400-proxyadresse på en postboks, men ikke et krav for at flyttingen skal fullføres, anbefales det at du også stempler denne adressen på brukerobjektet for målpost.

Kan kilde- og målleieren bruke samme domenenavn?

Nei, domenenavnene for kildeleieren og målleieren må være unike, for eksempel et kildedomene for contoso.com og måldomenet for northwindtraders.com.

Flyttes delte postbokser og fungerer fortsatt?

Ja. Vi beholder imidlertid bare butikktillatelsene som beskrevet i denne artikkelen:

Har du noen anbefalinger for bunker?

Ikke overskride 2000 postbokser per parti. Vi anbefaler på det sterkeste å sende inn grupper to uker før den fullstendige datoen, da det ikke har noen innvirkning på sluttbrukerne under synkroniseringen. Hvis du trenger veiledning for postboksantall over 50 000, kan du kontakte CSAM eller åpne en støtteforespørsel.

Hva om jeg bruker tjenestekryptering med Microsoft Purview Customer Key?

Postboksen dekrypteres før den flyttes. Sørg for at kundenøkkelen er konfigurert i målleieren hvis den fortsatt er nødvendig. Hvis du vil ha mer informasjon, kan du se her.

Hva er den estimerte overføringstiden?

For å hjelpe deg med å planlegge overføringen, viser tabellen som finnes her retningslinjene for når du kan forvente at masseoverføringer av postbokser eller individuelle overføringer skal fullføres. Disse estimatene er basert på en dataanalyse av tidligere kundeoverføringer. Siden alle miljøer er unike, kan den nøyaktige overføringshastigheten variere.

Beskytt dokumenter i kildeleieren som kan brukes av brukere i målleieren.**

Overføring over flere leiere overfører bare postboksdata og ingenting annet. Det finnes flere andre alternativer, som er dokumentert i følgende blogginnlegg som kan hjelpe:

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

Kan jeg ha de samme etikettene i målleieren som du hadde i kildeleieren, enten som det eneste settet med etiketter eller et ekstra sett med etiketter for de overførte brukerne, avhengig av justeringen mellom organisasjonene.**

Fordi overføringer på tvers av leiere ikke eksporterer etiketter, og det er ikke mulig å dele etiketter mellom leiere, kan du bare oppnå dette målet ved å opprette etikettene i målleieren på nytt.

Støtter du flytting Microsoft 365 Groups?

Postboksoverføringer på tvers av leier støtter for øyeblikket ikke overføring av Microsoft 365 Groups.

Kan en administrator for kildeleier utføre et eDiscovery-søk mot en postboks etter at postboksen er overført til den nye/målleieren?

Nei, etter en postboksoverføring på tvers av leier fungerer ikke eDiscovery mot den overførte brukerens postboks i kilden. Denne eDiscovery-feilen er fordi det ikke lenger finnes en postboks i kilden du kan søke etter når postboksen er overført til målleieren og nå tilhører målleieren. eDiscovery etter postboksoverføring kan bare gjøres i målleieren (der postboksen nå finnes). Hvis en kopi av kildepostboksen må beholdes i kildeleieren etter overføring, kan administratoren i kildeleieren kopiere innholdet til en alternativ postboks forhåndsoverføring for fremtidige eDiscovery-operasjoner mot dataene.

På hvilket tidspunkt konverteres mailuseren til en målpostboks, og kildepostboksen konverteres til en kildepostbruker?

Disse konverteringene skjer automatisk under overføringsprosessen. Ingen manuelle trinn er nødvendig.

I hvilket trinn bør jeg tilordne Exchange Online lisensen til MailUsers som mål?

Denne lisenstilordning kan gjøres før overføringen er fullført, men du bør ikke tilordne en lisens før du stempler ExchangeGUID-attributtet . ellers vil konverteringen av MailUser-objektet til postboksen mislykkes, og en ny postboks opprettes i stedet. For å redusere denne risikoen er det best å vente til overføringen er fullført og tilordne lisenser i løpet av den 30-dagers løpeperioden.

Kan jeg bruke Microsoft Entra Koble til for å synkronisere brukere til den nye leieren hvis jeg beholder lokal Active Directory?

Ja. Det er mulig å ha to forekomster av Microsoft Entra Koble synkronisering til forskjellige leiere. Det er imidlertid noen ting du må være klar over:

  • Det må ikke gjøres før brukerens kontoer med skriptet som er angitt i denne artikkelen. I stedet kan en selektiv OU-synkronisering av brukerne i omfanget for overføringen utføres for å fylle ut målleieren. Du får en advarsel om at UPN ikke samsvarer under Microsoft Entra Connect-konfigurasjonen.
  • Avhengig av gjeldende tilstand for hybrid Exchange, må du kontrollere at de lokale katalogobjektene har de nødvendige attributtene (for eksempel msExchMailboxGUID og proxyAddresses) fylt ut riktig før du prøver å synkronisere til en annen leier. ellers får du problemer med doble postbokser og overføringsfeil.
  • Du må utføre noen ekstra trinn for å administrere UPN-overgang, endre den lokalt når overføringen er fullført for en bruker, med mindre du også flytter det egendefinerte domenet under en fullstendig overføring.

Hvordan skal jeg håndtere postbokser som er nær, eller over kvote.

Postbokser som nærmer seg kvoten før overføringen, kan ende opp over kvoten enten før eller under den faktiske overføringen. Hvis dette skjer, mislykkes overføringen av disse postboksene og må utbedres og startes på nytt. For å redusere dette anbefales det at administratoren for kildeleieren identifiserer postbokser ved eller nær kvote før overføring og utfører de nødvendige trinnene for enten å redusere postboksstørrelsen, klargjøre et primært arkiv eller i noen tilfeller aktivere automatisk utvidelse av arkiver for brukerens postbokser.

Obs!

Når du aktiverer et arkiv eller utvider arkivet automatisk for en bruker, må du sørge for at de riktige arkiveringspolicyene brukes for brukeren, og at prosessen kjøres for å flytte postboksdataene til den nye plasseringen og frigjøre plass.

Flyttes automatisk utvidede arkivpostbokser?

Problem: Automatisk utvidede arkiver kan ikke overføres. Ja, hvis brukeren i kilden har automatisk utvidende arkiver aktivert og har flere tilleggsarkiver, vil postboksoverføring på tvers av leier fungere. Vi støtter flytting av brukere som ikke har mer enn 12 hjelpearkivpostbokser. I tillegg vil brukere med store primære, store hovedarkiver og store hjelpearkivpostbokser kreve ekstra tid til å synkronisere og bør sendes inn i god tid før utskjæringsdatoen. Hvis kildepostboksen utvides under postboksoverføringsprosessen, vil overføringen mislykkes etter hvert som et nytt hjelpearkiv opprettes i kilden, men ikke i målet. I dette tilfellet må du fjerne brukeren fra overføringsgruppen og sende dem på nytt.

Kan jeg utføre en leier på tvers av skyen til leieroverføring?

Leieren på tvers av skyen til leieroverføring støttes ikke. Et eksempelscenario ville vært å flytte fra Office 365 worldwide til Office 365 Government Cloud.

Overføres talepost på tvers av leier?

Ja, talemeldinger overføres på tvers av leier.

  • Mottatte talemeldinger i e-post som vedlegg er tilgjengelige i målpostboksen.
  • Mottatte talemeldinger er tilgjengelige i Teams hvis du ringer telefonsvarer og lytter til lagrede meldinger. (VM-er som mottas i kilden, er tilgjengelige som lagrede meldinger)
  • Mottatte talemeldinger er ikke tilgjengelige i brukergrensesnittet for Teams-klienten i mål etter overføring.
  • Talemeldingshilsenen overføres også til målet.

Overføres postbokssignaturer på tvers av leier?

Postbokssignaturer overføres ikke på tvers av leier og må opprettes på nytt.

Kjente problemer

  • Teams-funksjonalitet etter overføring i kildeleieren vil være begrenset. Når postboksen er overført til målleieren, har ikke Teams i kildeleieren lenger tilgang til brukerens postboks. Hvis en bruker logger seg på Teams med legitimasjonen for kildeleieren, er det et tap av funksjonalitet, for eksempel manglende evne til å oppdatere profilbildet, ingen kalenderprogram og manglende evne til å søke og bli med i offentlige team.

  • Cloud MailUsers med ikke-eide smtp proxyAddress blokk MRS trekk. Når du oppretter MailUser-objekter for målleier, må du kontrollere at alle SMTP-proxy-adresser tilhører målleierens organisasjon. Hvis det finnes en SMTP-proxyadresse på målpostbrukeren som ikke tilhører den lokale leieren, forhindres konverteringen av MailUser til en postboks. Denne forebyggingen skyldes vår forsikring om at postboksobjekter bare kan sende e-post fra domener som leieren er autoritativ for (domener som hevdes av leieren).

  • Hvis du synkroniserer brukere lokalt ved hjelp av Microsoft Entra Koble til i målleieren, kan du klargjøre lokale MailUser-objekter med ExternalEmailAddress som peker til kildeleieren der postboksen finnes (LaraN@contoso.onmicrosoft.com), og du stempler PrimarySMTPAddress som et domene som ligger i målleieren (Lara.Newton@northwindtraders.com). Disse verdiene synkroniseres ned til leieren, og en passende e-postbruker klargjøres og er klar for overføring. Et eksempelobjekt vises her.

    Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

ExternalEmailAddress               EmailAddresses
--------------------               --------------
SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}

    Obs!

    Den contoso.onmicrosoft.com adressen finnes ikke i EmailAddresses/proxyAddresses-matrisen.

  • MailUser-objekter med «eksterne» primære SMTP-adresser endres/tilbakestilles til «interne» firmakraverte domener.

    MailUser-objekter er pekere til ikke-lokale postbokser. Når det gjelder postboksoverføringer på tvers av leier, bruker vi MailUser-objekter til å representere kildepostboksen (fra målorganisasjonens perspektiv) eller målpostboksen (fra kildeorganisasjonens perspektiv). MailUsers har en ExternalEmailAddress (targetAddress) som peker til smtp-adressen til den faktiske postboksen (ProxyTest@northwindtraders.onmicrosoft.com) og primærSMTP-adressen som representerer den viste SMTP-adressen til postboksbrukeren i katalogen. Noen organisasjoner velger å vise den primære SMTP-adressen som en ekstern SMTP-adresse, ikke som en adresse som eies/bekreftes av den lokale leieren (for eksempel som northwindtraders.com i stedet for som contoso.com). Men når et Exchange-tjenesteplanobjekt brukes på MailUser via lisensieringsoperasjoner, endres den primære SMTP-adressen til å vises som et domene bekreftet av den lokale organisasjonen (contoso.com). Det finnes to mulige årsaker:

  • Når en Exchange-tjenesteplan brukes på en MailUser, begynner Microsoft Entra ID prosessen å fremtvinge proxy-skrubbing for å sikre at den lokale organisasjonen ikke kan sende ut e-post, forfalsking eller e-post fra en annen leier. Alle SMTP-adresser på et mottakerobjekt med disse tjenesteplanene vil bli fjernet hvis adressen ikke er bekreftet av den lokale organisasjonen. Som tilfellet er i eksemplet, bekreftes ikke northwindtraders.com-domenet av contoso.onmicrosoft.com-leieren. derfor fjerner skrubbingen det northwindtraders.com domenet. Hvis du vil beholde disse eksterne domenene på MailUser, enten før eller etter overføringen, må du endre overføringsprosessene til å fjerne lisenser etter at flyttingen er fullført, eller før flyttingen for å sikre at brukerne har brukt den forventede eksterne varemerkingen. Du må kontrollere at postboksobjektet er riktig lisensiert til ikke å påvirke e-posttjenesten. Et eksempelskript for å fjerne serviceplanene på en MailUser i den contoso.onmicrosoft.com leieren, vises her.

Obs!

Følgende skript bruker Microsoft Graph Powershell. Hvis du vil ha mer informasjon, kan du se Oversikt over Microsoft Graph PowerShell.

Hvis du vil ha informasjon om hvordan du bruker ulike metoder til å godkjenne Connect-Graph i et uovervåket skript, kan du se artikkelen Cmdleter for godkjenningsmodul i Microsoft Graph PowerShell.

# Connect to Microsoft Graph
Connect-Graph -Scopes User.ReadWrite.All, Organization.Read.All

# Get licensing plans and include disabled plans
$EmsSku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'ENTERPRISEPREMIUM'
$User = Get-MgUser -UserId LaraN@contoso.onmicrosoft.com
$userLicense = Get-MgUserLicenseDetail -UserId $User.Id

$userDisabledPlans = $userLicense.ServicePlans |
  Where ProvisioningStatus -eq "Disabled" |
  Select -ExpandProperty ServicePlanId

$newDisabledPlans = $EmsSku.ServicePlans |
  Where ServicePlanName -in ("LOCKBOX_ENTERPRISE","EXCHANGE_S_ENTERPRISE","INFORMATION_BARRIERS","MIP_S_CLP2","MIP_S_CLP1","MYANALYTICS_P2","EXCHANGE_ANALYTICS","EQUIVIO_ANALYTICS","THREAT_INTELLIGENCE","PAM_ENTERPRISE","PREMIUM_ENCRYPTION") |
  Select -ExpandProperty ServicePlanId

$disabledPlans = $userDisabledPlans + $newDisabledPlans | Select -Unique

$addLicenses = @(
  @{SkuId = $EmsSku.SkuId
  DisabledPlans = $disabledPlans
  }
  )

Set-MgUserLicense -UserId '38955658-c844-4f59-9430-6519430ac89b' -AddLicenses $addLicenses -RemoveLicenses @()

Id                                   DisplayName   Mail UserPrincipalName                     UserType
--                                   -----------   ---- -----------------                     --------
38955658-c844-4f59-9430-6519430ac89b Bianca Pisani      BiancaP@contoso.onmicrosoft.com       Member

Resultater i settet med tilordnede ServicePlans vises her:

$order = @(
  @{ Expression = 'ProvisioningStatus'; Ascending = $true }
)
Get-MgUserLicenseDetail -UserId '38955658-c844-4f59-9430-6519430ac89b' | Select-Object -ExpandProperty ServicePlans | sort ProvisioningStatus $order

AppliesTo ProvisioningStatus  ServicePlanId                        ServicePlanName
--------- ------------------  -------------                        ---------------
User      Success             2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2 ADALLOM_S_STANDALONE
User      Success             6c6042f5-6f01-4d67-b8c1-eb99d36eed3e STREAM_O365_E5
User      Success             e212cbc7-0961-4c40-9825-01117710dcb1 FORMS_PLAN_E5
User      Success             07699545-9485-468e-95b6-2fca3738be01 FLOW_O365_P3
User      Success             9c0dab89-a30c-4117-86e7-97bda240acd2 POWERAPPS_O365_P3
User      Success             871d91ec-ec1a-452b-a83f-bd76c7d770ef WINDEFATP
User      Success             21b439ba-a0ca-424f-a6cc-52f954a5b111 WIN10_PRO_ENT_SUB
User      Success             57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
User      Success             8c7d2df8-86f0-4902-b2ed-a0458298f3b3 Deskless
User      Success             8e0c0a52-6a6c-4d40-8370-dd62790dcd70 THREAT_INTELLIGENCE
User      Success             4a51bca5-1eff-43f5-878c-177680f191af WHITEBOARD_PLAN3
User      Success             efb0351d-3b08-4503-993d-383af8de41e3 MIP_S_CLP2
User      Success             617b097b-4b93-4ede-83de-5f075bb5fb2f PREMIUM_ENCRYPTION
User      Success             8c098270-9dd4-4350-9b30-ba4703f3b36b ADALLOM_S_O365
Company   Success             94065c59-bc8e-4e8b-89e5-5138d471eaff MICROSOFT_SEARCH
User      Success             14ab5db5-e6c4-4b20-b4bc-13e36fd2227f ATA
User      Success             3fb82609-8c27-4f7b-bd51-30634711ee67 BPOS_S_TODO_3
User      Success             b1188c4c-1b36-4018-b48b-ee07604f6feb PAM_ENTERPRISE
User      Success             5136a095-5cf0-4aff-bec3-e84448b38ea5 MIP_S_CLP1
User      Success             33c4f319-9bdd-48d6-9c4d-410b750a4a5a MYANALYTICS_P2
User      Success             5689bec4-755d-4753-8b61-40975025187c RMS_S_PREMIUM2
User      Success             4828c8ec-dc2e-4779-b502-87ac9ce28ab7 MCOEV
User      Success             9f431833-0334-42de-a7dc-70aa40db46db LOCKBOX_ENTERPRISE
User      Success             3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40 MCOMEETADV
User      Success             43de0ff5-c92c-492b-9116-175376d08c38 OFFICESUBSCRIPTION
User      Success             0feaeb32-d00e-4d66-bd5a-43b5b83db82c MCOSTANDARD
User      Success             70d33638-9c74-4d01-bfd3-562de28bd4ba BI_AZURE_P2
Company   Success             f20fedf3-f3c3-43c3-8267-2bfdd51c0939 ATP_ENTERPRISE
User      Success             4de31727-a228-4ec3-a5bf-8e45b5ca48cc EQUIVIO_ANALYTICS
User      Success             efb87545-963c-4e0d-99df-69c6916d9eb0 EXCHANGE_S_ENTERPRISE
User      Success             34c0d7a0-a70f-4668-9238-47f9fc208882 EXCHANGE_ANALYTICS
User      Success             8a256a2b-b617-496d-b51b-e76466e88db0 MFA_PREMIUM
User      Success             41781fb2-bc02-4b7c-bd55-b576c07bb09d AAD_PREMIUM
User      Success             bea4c11e-220a-4e6d-8eb8-8ea15d019f90 RMS_S_ENTERPRISE
User      Success             eec0eb4f-6444-4f95-aba0-50c24d67f998 AAD_PREMIUM_P2
User      Success             6c57d4b6-3b23-47a5-9bc9-69f17b4947b3 RMS_S_PREMIUM
User      Success             5dbe027f-2339-4123-9542-606e4d348a72 SHAREPOINTENTERPRISE
User      Success             b737dad2-2f6c-4c65-90e3-ca563267e8b9 PROJECTWORKMANAGEMENT
User      Success             e95bec33-7c88-4a70-8e19-b10bd9d0c014 SHAREPOINTWAC
User      Success             7547a3fe-08ee-4ccb-b430-5077c5041653 YAMMER_ENTERPRISE
User      Success             a23b959c-7ce8-4e57-9140-b90eb88a9e97 SWAY
User      Success             c4801e8a-cb58-4c35-aca6-f2dcc106f287 INFORMATION_BARRIERS
User      Success             b76fb638-6ba6-402a-b9f9-83d28acb3d86 VIVA_LEARNING_SEEDED
Company   Success             db4d623d-b514-490b-b7ef-8885eee514de Nucleus
Company   Success             6f23d6a9-adbf-481c-8538-b4c095654487 M365_LIGHTHOUSE_CUSTOMER_PLAN1
User      Success             a82fbf69-b4d7-49f4-83a6-915b2cf354f4 VIVAENGAGE_CORE
User      Success             9a6eeb79-0b4b-4bf0-9808-39d99a2cd5a3 Windows_Autopatch
User      Success             cd31b152-6326-4d1b-ae1b-997b625182e6 MIP_S_Exchange
User      Success             a413a9ff-720c-4822-98ef-2f37c2a21f4c MICROSOFT_COMMUNICATION_COMPLIANCE
User      Success             795f6fe0-cc4d-4773-b050-5dde4dc704c9 UNIVERSAL_PRINT_01
Company   Success             2b815d45-56e4-4e3a-b65c-66cb9175b560 ContentExplorer_Standard
User      Success             7bf960f6-2cd9-443a-8046-5dbff9558365 WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE
User      Success             3ec18638-bd4c-4d3b-8905-479ed636b83e CustomerLockboxA_Enterprise
User      Success             3efbd4ed-8958-4824-8389-1321f8730af8 MESH_AVATARS_ADDITIONAL_FOR_TEAMS
User      Success             99cd49a9-0e54-4e07-aea1-d8d9f5f704f5 Defender_for_Iot_Enterprise
User      Success             0898bdbb-73b0-471a-81e5-20f1fe4dd66e KAIZALA_STANDALONE
User      Success             c948ea65-2053-4a5a-8a62-9eaaaf11b522 PURVIEW_DISCOVERY
User      Success             a1ace008-72f3-4ea0-8dac-33b3a23a2472 CLIPCHAMP
User      Success             f6de4823-28fa-440b-b886-4783fa86ddba M365_AUDIT_PLATFORM
User      Success             0d0c0d31-fae7-41f2-b909-eaf4d7f26dba Bing_Chat_Enterprise
User      Success             dcf9d2f4-772e-4434-b757-77a453cfbc02 MESH_AVATARS_FOR_TEAMS
User      Success             c4b8c31a-fb44-4c65-9837-a21f55fcabda MICROSOFT_LOOP
User      Success             a6520331-d7d4-4276-95f5-15c0933bc757 GRAPH_CONNECTORS_SEARCH_INDEX
User      Success             e26c2fcc-ab91-4a61-b35c-03cdc8dddf66 INFO_GOVERNANCE
User      Success             46129a58-a698-46f0-aa5b-17f6586297d9 DATA_INVESTIGATIONS
User      Success             9d0c4ee5-e4a1-4625-ab39-d82b619b1a34 INSIDER_RISK_MANAGEMENT
User      Success             65cc641f-cccd-4643-97e0-a17e3045e541 RECORDS_MANAGEMENT
User      Success             d2d51368-76c9-4317-ada2-a12c004c432f ML_CLASSIFICATION
User      Success             bf6f5520-59e3-4f82-974b-7dbbc4fd27c7 SAFEDOCS
User      Success             2f442157-a11c-46b9-ae5b-6e39ff4e5849 M365_ADVANCED_AUDITING
User      Success             41fcdd7d-4733-4863-9cf4-c65b83ce2df4 COMMUNICATIONS_COMPLIANCE
User      Success             6db1f1db-2b46-403f-be40-e39395f08dbb CUSTOMER_KEY
User      Success             6dc145d6-95dd-4191-b9c3-185575ee6f6b COMMUNICATIONS_DLP
User      Success             199a5c09-e0ca-4e37-8f7c-b05d533e1ea2 MICROSOFTBOOKINGS
User      Success             ded3d325-1bdc-453e-8432-5bac26d7a014 POWER_VIRTUAL_AGENTS_O365_P3
Company   Success             d9fa6af4-e046-4c89-9226-729a0786685d Content_Explorer
User      Success             afa73018-811e-46e9-988f-f75d2b1b8430 CDS_O365_P3
User      Success             b21a6b06-1988-436e-a07b-51ec6d9f52ad PROJECT_O365_P3
User      Success             64bfac92-2b17-4482-b5e5-a0304429de3e MICROSOFTENDPOINTDLP
User      Success             bf28f719-7844-4079-9c78-c1307898e192 MTP
User      Success             28b0fa46-c39a-4188-89e2-58e979a6b014 DYN365_CDS_O365_P3
User      Success             d587c7a3-bda9-4f99-8776-9bcf59c84f75 INSIDER_RISK
User      Success             531ee2f8-b1cb-453b-9c21-d2180d014ca5 EXCEL_PREMIUM
User      PendingProvisioning f0ff6ac6-297d-49cd-be34-6dfef97f0c28 MESH_IMMERSIVE_FOR_TEAMS
User      PendingInput        c1ec4a95-1f05-45b3-a911-aa3fa01094f5 INTUNE_A
Company   PendingActivation   882e1d05-acd1-4ccb-8708-6ee03664b117 INTUNE_O365

Brukerens PrimarySMTPAddress er ikke lenger skrubbet. Det northwindtraders.com domenet eies ikke av den contoso.onmicrosoft.com leieren og beholdes som den primære SMTP-adressen som vises i katalogen.

Her er et eksempel:

Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
UserPrincipalName               PrimarySmtpAddress              ExternalEmailAddress                 ExternalDirectoryObjectId
-----------------               ------------------              --------------------                 -------------------------
ProxyTest@contoso.com          ProxyTest@contoso.com          SMTP:ProxyTest@contoso.com          e2513482-1d5b-4066-936a-cbc7f8f6f817

Når msExchRemoteRecipientType den er satt til 8 (DeprovisionMailbox), for lokale MailUsers som overføres til målleieren, fjerner proxy-skrubbingslogikken i Azure ikke-eide domener og tilbakestiller primærSMTP til et eid domene. Når msExchRemoteRecipientType i den lokale MailUser tømmes, gjelder ikke lenger proxy-skrubblogikken.

Nedenfor finner du hele settet med gjeldende serviceplaner som inkluderer Exchange Online:

Navn
eDiscovery (Premium) Storage (500 GB)
Customer Lockbox
Hindring av datatap
Exchange Enterprise CAL Services (EOP, DLP)
Exchange-Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (plan 1)
Exchange Online (plan 2)
Exchange Online Archiving for Exchange Online
Exchange Online Archiving for Exchange Server
Exchange Online Inaktivt brukertillegg
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online plan 1
Exchange Online POP
Exchange Online Protection
Søk i graph-koblinger med indeks
Informasjonsbarrierer
Information Protection for Office 365 – Premium
Information Protection for Office 365 – Standard
Innsikt av MyAnalytics
Microsoft Information Governance
Microsoft Purview overvåking (Premium)
Microsoft bestillinger
Microsoft Business Center
Microsoft Data Investigations
Microsoft MyAnalytics (fullstendig)
Samsvar med Microsoft Communications
Microsoft Communications DLP
Microsoft Customer Key
Microsoft 365 Advanced Auditing
Microsoft Records Management
Office 365 eDiscovery (Premium)
Office 365 Avansert eDiscovery
Microsoft Defender for Office 365 (pakke 1)
Microsoft Defender for Office 365 (Plan 2)
Office 365 privileged Access Management
Premium-kryptering i Office 365

Overføringsfeil

  • MailboxNotInCrossTenantMigrationScopeException

    Kontroller at overføringsomfanget er riktig konfigurert på kildeleieren, og at MailboxMovesPublishedScopes er angitt i organisasjonsrelasjonen med målleieren.
    Kontroller at postboksen som skal overføres, er lagt til sikkerhetsgruppen i kildeleieren.
    Når du har lagt til en bruker for å korrigere sikkerhetsgruppen, kan du gjenoppta overføringsgruppen.

  • AuxArchiveNotFoundInTargetRecipientException

    Denne feilen skyldes at brukeren ikke var i overføringsomfanget da overføringsgruppen ble startet, og brukeren har AuxArchive på kilden.
    Legg til bruker i riktig sikkerhetsgruppe på kildemålet.
    Fjern overføringsbrukeren fra overføringsgruppen.
    Fjern brukere med følgende kommando:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Legg til bruker i en ny gruppe.

  • MailboxIsNotInExpectedDBException

    Denne feilen skyldes internt Microsoft-vedlikehold.
    Fjern overføringsbrukeren fra overføringsgruppen.
    Fjern brukere med følgende kommando:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Legg til bruker i en ny gruppe.

  • NotAcceptedDomainException

    Det er stemplet en ugyldig proxy-adresse på målbrukeren. Et eksempel er hvor en bruker i contoso.onmicrosoft.com hadde en proxy-adresse for fabrikam.onmicrosoft.com, som er kildeleieren.
    Fjern den ugyldige proxy-adressen ved hjelp av følgende kommando:

    Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}

    Fortsett overføringsgruppen.

  • SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

    En ny AuxArchive ble klargjort under overføringen.
    Fjern overføringsbrukeren fra overføringsgruppen.
    Fjern brukere med følgende kommando:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Legg til bruker i en ny gruppe.

  • UserDuplicateInOtherBatchException

    Brukeren finnes allerede i en annen gruppe.
    Fjern overføringsbrukeren fra overføringsgruppen.
    Fjern brukere med følgende kommando:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Legg til bruker i en ny gruppe.

  • MissingExchangeGuidException

    Target mailuser-objektet mangler riktig ExchangeGuid-verdi.
    Oppdater ExchangeGuid med følgende kommando:

    Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8

    Fortsett overføringsgruppen.

  • SourceMailboxAlreadyBeingMovedPermanentException

    Kildepostboksen har allerede en eksisterende overføringsforespørsel. Undersøk og fjern den eksisterende flyttingen. Det er mulig at dette er et internt Microsoft-trekk, og du må vente på at flyttingen skal fullføres.
    Fjern overføringsbrukeren fra overføringsgruppen.
    Fjern brukere med følgende kommando:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Legg til bruker i en ny gruppe etter at den opprinnelige flyttingen er fjernet eller fullført.

  • UserAlreadyHasDemotedArchiveException

    Brukeren hadde en arkivpostboks som tidligere ble deaktivert. Velg ett av de to følgende alternativene for å løse dette problemet.
    Slett permanent den deaktiverte arkivpostboksen, dette er uopprettelig. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
    Aktiver den deaktiverte arkivpostboksen på nytt med følgende kommando:

    Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.

    Hvis du aktiverer den deaktiverte arkivpostboksen på nytt, må du oppdatere arkiv-GUID-en på målpostbrukerobjektet.
    Fortsett overføringsgruppen.

Se også