Postlådemigrering mellan klientorganisationen (förhandsversion)

Vid sammanslagningar eller företag behöver du vanligtvis möjligheten att flytta din användares Exchange Online till en ny klientorganisation. Genom postlådemigrering med flera klientorganisationsadministratörer kan administratörer använda välkända gränssnitt som Remote PowerShell och MRS för att migrera användare till den nya organisationen.

Administratörer kan använda New-MigrationBatch-cmdleten som är tillgänglig via rollen Flytta postlådor för att utföra flyttningar mellan klientorganisationen.

Användare som migrerar måste finnas i målklientorganisationen i Exchange Online-system som MailUsers, markerat med specifika attribut för att aktivera flyttningar mellan klientorganisationen. Systemet kommer att misslyckas för användare som inte är korrekt konfigurerade i målklientorganisationen.

När flytten är slutförd konverteras källanvändarpostlådan till mailuser och targetAddress (visas som ExternalEmailAddress i Exchange) stämplas med routningsadressen till målklientorganisationen. Den här processen lämnar den äldre MailUser i källklientorganisationen och möjliggör samexistens och e-postdirigering. När affärsprocesser tillåter kan källklientorganisationen ta bort källan MailUser eller konvertera dem till en e-postkontakt.

Migrering av Exchange flera klientorganisationen stöds för klientorganisationen endast i hybrid- eller molnet, eller en kombination av dessa.

Den här artikeln beskriver processen för flytt av postlådor mellan klientorganisationen och innehåller anvisningar om hur du förbereder käll- och målklientorganisationen för Exchange Online postlådeinnehållsflyttningar.

Anteckning

Vi har nyligen uppdaterat våra konfigurationssteg för att göra det möjligt att migrera postlådor över klientorganisationen så att Azure Key Vault inte längre krävs! Om det är första gången du inför den här förhandsversionen krävs ingen åtgärd och du kan fortsätta med anvisningarna i det här dokumentet. Om du har börjat konfigurera klientorganisationen med den föregående AKV-metoden rekommenderar vi att du stoppar eller tar bort den konfigurationen för att börja använda den nya metoden. Om postlådemigreringarna pågår med den föregående AKV-metoden väntar du tills dina befintliga migreringar är slutförda och följer stegen nedan för att aktivera den nya förenklade metoden. De konfigurationssteg som krävs för Azure Key Vault arkiveras men finns här, som referens.

Förbereda käll- och målklientorganisationen

Krav för käll- och målklientorganisationen

Innan du startar bör du kontrollera att du har de behörigheter som krävs för att konfigurera programmet Flytta postlåda i Azure, EXO-migreringsslutpunkt och EXO-organisationsrelationen.

Dessutom krävs minst en e-postaktiverad säkerhetsgrupp i källklientorganisationen. De här grupperna används för att begränsa listan över postlådor som kan flyttas från källklientorganisationen (eller som ibland kallas för resurs) till målklientorganisationen. På så sätt kan källklientorganisationens administratör begränsa eller begränsa den specifika uppsättning postlådor som måste flyttas, vilket hindrar oavsiktliga användare från att migreras. Kapslade grupper stöds inte.

Du måste också kommunicera med ditt betrodda partnerföretag (som du kommer att flytta postlådor med) för att få deras Microsoft 365 klientorganisations-ID. Detta klientorganisations-ID används i fältet DomainName för organisationsrelation.

Om du vill ha klientorganisations-ID för en prenumeration loggar du in på Administrationscenter för Microsoft 365 går till https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties . Klicka på kopieringsikonen för egenskapen Klientorganisations-ID för att kopiera den till Urklipp.

Konfigurationssteg för att aktivera klientorganisationen för postlådemigrering mellan klientorganisationen

Anteckning

Du måste konfigurera målet (målet) först. För att utföra de här stegen behöver du inte ha eller känna till autentiseringsuppgifterna som innehavaradministratör för både käll- och målklientorganisationen. Olika administratörer kan utföra enskilda steg för varje klientorganisation.

Förbered målklientorganisationen (målklientorganisationen) genom att skapa migreringsprogrammet och hemligt

  1. Logga in på Azure AD-portalen https://portal.azure.com () med autentiseringsuppgifterna för målklientorganisationen

    Azure-inloggning

  2. Klicka på Visa under Hantera Azure Active Directory.

    Azure Active Directory knappen

  3. Välj Appregistreringar i det vänstra navigeringsfältet.

  4. Välj Ny registrering

    Nytt program

  5. På sidan Registrera ett program under Kontotyper som stöds väljer du Konton i valfri organisationskatalog (Valfri Azure AD-katalog – Multitenant). Under Omdirigera URI (valfritt) väljer du Sedan Webb och anger https://office.com . Slutligen väljer du Registrera.

    Appregistrering

  6. I det övre högra hörnet på sidan visas ett meddelande om att appen har skapats.

  7. Gå tillbaka till Startsidan, Azure Active Directory klicka på Appregistreringar.

  8. Leta rätt på appen du skapade under Ägda program och klicka på den.

  9. Under ^Essentials måste du kopiera program-ID:t (klient)eftersom du behöver det senare för att skapa en URL för målklientorganisationen.

  10. Klicka nu på API-behörigheter i det vänstra navigeringsfältet för att visa behörigheter som tilldelats programmet.

  11. Standardinställningen är Användare. Läsbehörigheter tilldelas appen du skapade, men vi kräver dem inte för postlådemigrering, du kan ta bort den behörigheten.

    Programbehörigheter

  12. Nu behöver vi lägga till behörighet för postlådemigrering och välja Lägg till en behörighet

  13. I fönstret Begär API-behörigheter väljer du API:er som min organisation använder, söker efter Office 365 Exchange Online och väljer det.

    Välj API

  14. Välj sedan Programbehörigheter

  15. Under Välj behörigheter expanderar du postlåda och markerar Postlådemigrering och Lägg till behörigheter längst ned på skärmen.

    Ange API

  16. Välj nu Certifikat & hemligheter i det vänstra navigeringsfältet för programmet.

  17. Välj Ny klienthemlighet under Klienthemligheter.

    Klienthemligheter

  18. Ange en beskrivning och konfigurera önskade inställningar för utgångsdatum i fönstret Lägg till en klienthemlighet.

    Anteckning

    Det här är lösenordet som används när migreringsslutpunkten skapas. Det är mycket viktigt att du kopierar lösenordet till Urklipp och eller kopierar lösenordet för säker/hemlig lösenords säker plats. Det är den enda gången du kan se lösenordet! Om du förlorar den eller behöver återställa den kan du logga in på vår Azure-portal, gå till Appregistreringar, hitta din migreringsapp, välja Secrets & certificates och skapa en ny hemlig app.

  19. Nu när du har skapat migreringsprogrammet och hemligheten måste du godkänna programmet. Om du vill ge ditt medgivande till programmet går du tillbaka till startsidan för Azure Active Directory, klickar på Enterprise-program i det vänstra navigeringsfältet, hittar migreringsappen som du har skapat, markerar den och väljer Behörigheter i det vänstra navigeringsfältet.

  20. Klicka på knappen Ge administratörsmedgivande för [din klientorganisation].

  21. Ett nytt webbläsarfönster öppnas och du väljer Acceptera.

  22. Du kan gå tillbaka till portalfönstret och välja Uppdatera för att bekräfta att du godkänner det.

  23. Utforma url:en så att den skickas till din betrodda partner (källklientorganisationens administratör) så att de också kan acceptera programmet för att aktivera postlådemigrering. Här är ett exempel på URL-adressen som du behöver för att kunna använda programmet du skapade:

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

    Anteckning

    Du behöver program-ID för migreringsappen för postlådan som du just skapade.

    Du måste ersätta sourcetenant.onmicrosoft.com exemplet ovan med källklienternas namn onmicrosoft.com namn.

    Du måste också ersätta [application_id_of_the_app_you_just_created] med program-ID:t för postlådans migreringsapp som du just skapade.

Förbereda målklientorganisationen genom att skapa den Exchange Online migreringsslutpunkten och organisationsrelationen

  1. Skapa en Fjärranslutning till PowerShell till Exchange Online klientorganisation.

  2. Skapa en ny migreringsslutpunkt för postlådeflyttningar mellan klientorganisationen

    Anteckning

    Du behöver program-ID för migreringsappen för postlådan du just skapade och lösenordet (hemligheten) som du konfigurerade under den här processen. Beroende på vilken Microsoft 365-instans du använder slutpunkten kan den se annorlunda ut. Gå till sidan Microsoft 365 slutpunkter, välj rätt instans för klientorganisationen och läs adressen Exchange Online optimera krävs och ersätt efter behov.

    
    # Enable customization if tenant is dehydrated
      $dehydrated=Get-OrganizationConfig | fl isdehydrated
      if ($dehy -eq $true) {Enable-OrganizationCustomization}
    
    $AppId = "[guid copied from the migrations app]"
    
    $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the previous steps]" -AsPlainText -Force)
    
    New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "sourcetenant.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId
    
  3. Skapa ett nytt eller redigera ditt befintliga organisationsrelationsobjekt i källklientorganisationen.

    $sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]"
    $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 "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
    }
    

Förbereda källklientorganisationen (aktuell postlådas plats) genom att acceptera migreringsprogrammet och konfigurera organisationsrelationen

  1. Gå till URL-länken från din betrodda partner i en webbläsare för att godkänna postlådemigreringsprogrammet. URL:en ser ut så här:

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

    Anteckning

    Du behöver program-ID för migreringsappen för postlådan som du just skapade. Du måste ersätta sourcetenant.onmicrosoft.com exemplet ovan med källklienternas namn onmicrosoft.com namn. Du måste också ersätta [application_id_of_the_app_you_just_created] med program-ID:t för postlådans migreringsapp som du just skapade.

  2. Acceptera programmet när popup-menyn visas. Du kan också logga in på Azure Active Directory-portalen och hitta programmet under Företagsprogram.

  3. Skapa ett nytt eller redigera ditt befintliga organisationsrelationsobjekt till målklientorganisationen (målklientorganisationen) från ett Exchange Online Remote PowerShell-fönster.

    $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]"
    $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 "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
    }
    

Anteckning

Det klientorganisations-ID som du anger $sourceTenantId och $targetTenantId är GUID och inte klientorganisationens domännamn. Ett exempel på ett klientorganisations-ID och information om hur du hittar ditt klientorganisations-ID finns i hitta Microsoft 365 klientorganisations-ID.

Hur vet jag att det fungerade?

Du kan verifiera postlådemigreringskonfigurationen för flera klientorganisationen genom att köra Test-MigrationServerAvailability-cmdleten mot den migreringsslutpunkt för flera klientorganisationen som du skapade på målklientorganisationen.

Anteckning

Test-MigrationServerAvailability -Slutpunkt "[namnet på migreringsslutpunkten mellan klientorganisationen]" -TestMailbox "[e-postadressen till en källpostlåda som ingår i migreringen]"

Flytta tillbaka postlådor till den ursprungliga källan

Om en postlåda krävs för att flytta tillbaka till den ursprungliga källklientorganisationen måste samma uppsättning steg och skript köras i både den nya källklientorganisationen och den nya målklientorganisationen. Det befintliga organisationsrelationsobjektet uppdateras eller läggs till, återskapas inte

Förbereda målanvändarobjekt för migrering

Användare som migrerar måste finnas i målklientorganisationen och Exchange Online -systemet (som MailUsers) markerade med specifika attribut för att aktivera flyttningar mellan klientorganisationen. Systemet kommer att misslyckas för användare som inte är korrekt konfigurerade i målklientorganisationen. I följande avsnitt finns information om MailUser-objektkraven för målklientorganisationen.

Krav för målanvändares objekt

Se till att följande objekt och attribut anges i målorganisationen.

  1. För alla postlådor som flyttas från en källorganisation måste du etablera ett MailUser-objekt i målorganisationen:

    • Target MailUser måste ha följande attribut från källpostlådan eller ha tilldelats det nya användarobjektet:

      • ExchangeGUID (direktflöde från källa till mål): Postlådans GUID måste matcha. Flyttningsprocessen fortsätter inte om detta inte finns i målobjektet.
      • ArchiveGUID (direkt flöde från källa till mål): Arkiv-GUID måste matcha. Flyttningsprocessen fortsätter inte om det inte finns i målobjektet. (Detta krävs endast om källpostlådan är aktiverad).
      • LegacyExchangeDN (flöde som proxyAddress, "x500: "): LegacyExchangeDN måste finnas på target <LegacyExchangeDN> MailUser som x500: proxyAddress. Dessutom måste du kopiera alla x500-adresser från källpostlådan till målanvändaren för e-post. Flyttprocesserna fortsätter inte om de inte finns i målobjektet.
      • UserPrincipalName: UPN justeras mot användarens NYA identitet eller målföretag (till exempel user@northwindtraders.onmicrosoft.com).
      • Primary SMTPAddress: Primary SMTP address will align to the user's NEW company (for example, user@northwind.com).
      • TargetAddress/ExternalEmailAddress: MailUser refererar till användarens aktuella postlåda hos källklientorganisationen (till exempel user@contoso.onmicrosoft.com). När du tilldelar det här värdet ska du kontrollera att du har/även tilldelar PrimarySMTPAddress, annars anges PrimarySMTPAddress, vilket orsakar flyttningsfel.
      • Du kan inte lägga till äldre smtp-proxyadresser från källpostlådan till MailUser som mål. Du kan till exempel inte underhålla contoso.com e-postadressen i fabrikam.onmicrosoft.com klientobjekt). Domäner är kopplade till en Azure AD- eller Exchange Online-klientorganisation.

      Exempel på target MailUser-objekt:

      Attribut Värde
      Alias LaraN
      RecipientType MailUser
      RecipientTypeDetails MailUser
      UserPrincipalName LaraN@northwintraders.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@northwind.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=74e5385fce4b46d19006876949855035Lara
      EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (RÅDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c8190
      7273f1f9-Lara
      smtp:LaraN@northwindtraders.onmicrosoft.com
      SMTP:Lara.Newton@northwind.com

      Exempel på källpostlådeobjekt:

      Attribut Värde
      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=d11ec1a2cacd4f81858c81907273f1f9Lara
      EmailAddresses smtp:LaraN@contoso.onmicrosoft.com
      SMTP:Lara.Newton@contoso.com
    • Ytterligare attribut kan inkluderas i Exchange återskrivning av hybrider redan. Om inte bör de inkluderas.

    • msExchBlockedSendersHash – Skriver tillbaka data om betrodda och spärrade avsändare online från klienter till lokal Active Directory.

    • msExchSafeRecipientsHash – Skriver tillbaka data om betrodda och spärrade avsändare online från klienter till lokalt Active Directory.

    • msExchSafeSendersHash – Skriver tillbaka data om betrodda och spärrade avsändare från klienter till lokala Active Directory.

  2. Om källpostlådan finns i LitigationHold och storleken på återställningsbara objekt i källpostlådan är större än databasens standardstorlek (30 GB), fortsätter inte flyttningar eftersom målkvoten är mindre än källpostlådans storlek. Du kan uppdatera mailuser-målobjektet för att flytta över ELC-postlådeflaggor från källmiljön till målet, vilket utlöser målsystemet att utöka kvoten för MailUser till 100 GB, vilket gör att flytten till målet tillåts. De här instruktionerna fungerar bara för hybrididentitet som kör Azure AD Anslut, eftersom kommandon för att stämpla ELC-flaggor inte exponeras för innehavaradministratörer.

    Anteckning

    EXEMPEL – I SIN RÄTT TILL EXEMPEL INGEN GARANTI

    Det här skriptet förutsätter en anslutning till både källpostlådan (för att få källvärden) och målet lokalt Active Directory (för att stämpla ADUser-objektet). Om källan har aktiverat återställning av juridiska skäl eller enstaka objekt ska du ange detta i målkontot. Detta ökar storleken på destinationskontot till 100 GB.

    $ELCValue = 0
    if ($source.LitigationHoldEnabled) {$ELCValue = $ELCValue + 8} if ($source.SingleItemRecoveryEnabled) {$ELCValue = $ELCValue + 16} if ($ELCValue -gt 0) {Set-ADUser -Server $domainController -Identity $destination.SamAccountName -Replace @{msExchELCMailboxFlags=$ELCValue}}
    
  3. Icke-hybridmålklienter kan ändra kvoten för mappen Återställningsbara objekt för MailUsers innan migreringen genom att köra följande kommando för att aktivera Bevarande av juridiska skäl i MailUser-objektet och öka kvoten till 100 GB: Set-MailUser -EnableLitigationHoldForMigration . Observera att detta inte fungerar för klientorganisationen i hybriden.

  4. Användare i målorganisationen måste vara licensierade med lämpliga Exchange Online prenumerationer som gäller för organisationen. Du kan använda en licens i förväg för en postlådeflyttning men BARA när målets MailUser är korrekt konfigurerad med ExchangeGUID- och proxyadresser. Om du tillämpar en licens innan ExchangeGUID tillämpas kommer en ny postlåda etableras i målorganisationen.

    Anteckning

    När du använder en licens för ett Mailbox- eller MailUser-objekt rensas alla SMTP-typer proxyAddresses för att säkerställa att endast verifierade domäner ingår i matrisen Exchange E-postadresser.

  5. Du måste säkerställa att målets MailUser inte har någon tidigare ExchangeGuid som inte matchar Source ExchangeGuid. Det här kan inträffa om mål-e-postservern tidigare har licensierats för Exchange Online har etablerat en postlåda. Om målet MailUser tidigare har licensieras för eller hade en ExchangeGuid som inte matchar Source ExchangeGuid måste du rensa den molnbaserade e-postanvändaren. Du kan köra för de här molnbaserade e-moln-e-tjänstanvändarna. Set-User <identity> -PermanentlyClearPreviousMailboxInfo

    Varning

    Den här processen är bestående. Om objektet har en softDeleted-postlåda går det inte att återställa det efter den här punkten. När du rensat kan du dock synkronisera rätt ExchangeGuid till målobjektet, och MRS ansluter källpostlådan till den nya målpostlådan. (Referens EHLO-bloggen om den nya parametern.)

    Hitta objekt som tidigare var postlådor med det här kommandot.

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

    Här är ett exempel.

    Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize
    
    Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
    ----       ---------------------------- ------------- --------------------
    John       UserMailbox                  MailUser      MailUser
    

    Ta bort den mjukt borttagna postlådan med det här kommandot.

    Set-User <identity> -PermanentlyClearPreviousMailboxInfo
    

    Här är ett exempel.

    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
    

Utföra postlådemigrering

Migreringar mellan klient Exchange postlådor initieras från målklientorganisationen som migreringsbatchar. Det här är som det sätt som migreringsbatcharna på plats fungerar när du migrerar från en lokal Exchange till en Microsoft 365.

Skapa migreringsbatchar

Här är ett exempel på cmdlet för migreringsbatch för att starta flyttningar.

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

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

Anteckning

E-postadressen i CSV-filen måste vara den som anges i målklientorganisationen, inte källklientorganisationen.

Om du vill ha mer information om cmdleten klickar du här

Exempel på CSV-fil: klicka här

Inskickning av migreringsbatch stöds också från det Exchange administrationscentret när du väljer alternativet för flera innehavare.

Uppdatera lokala MailUsers

När postlådan flyttas från källa till mål bör du se till att de lokala e-postanvändarna, både i källan och målet, uppdateras med den nya targetAddress. I exemplen är targetDeliveryDomain som används i flyttningen contoso.onmicrosoft.com. Uppdatera e-postanvändarna med denna targetAddress.

Vanliga frågor och svar

Behöver vi uppdatera RemoteMailboxes lokalt i källan efter flytten?

Ja, du bör uppdatera targetAddress (RemoteRoutingAddress/ExternalEmailAddress) för den lokala källans användare när källklientorganisationens postlåda flyttas till målklientorganisationen. Även om e-postdirigering kan följa referenserna för flera e-postanvändare med olika targetAddresses måste uppslag för ledig/upptagen för e-postanvändare vara målet för postlådans användare. Uppslag av ledig/upptagen-information duar inte efter flera omdirigeringar.

Migrera Teams möten mellan klientorganisationen?

Mötena flyttas, men Teams mötes-URL uppdateras inte när objekt migreras mellan klientorganisationen. Eftersom URL:en blir ogiltig i målklientorganisationen måste du ta bort och återskapa Teams möten.

Migrerar Teams-chattmappens innehåll mellan klientorganisationen?

Nej, Teams-mappens innehåll migreras inte mellan klientorganisationen.

Hur kan jag se flyttningar mellan klientorganisationen, inte flyttningar av registrering och off-boarding?

Använd parametern Flags. Här är ett exempel.

Get-MoveRequest -Flags "CrossTenant"

Kan du ange exempelskript för kopiering av attribut som används vid testning?

Anteckning

EXEMPEL – I DESSFÖRD, INGEN GARANTI Det här skriptet förutsätter en anslutning till både källpostlådan (för att få källvärden) och målets lokala Active Directory Domain Services (för att stämpla ADUser-objektet). Om källan har aktiverat återställning av juridiska skäl eller enstaka objekt ska du ange detta i målkontot. Detta ökar storleken på destinationskontot till 100 GB.

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the Northwind org 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
$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
add-type -AssemblyName System.Web
foreach ($m in $mailboxes) {
    $organization = "@contoso.onmicrosoft.com"
    $mosi = $m.Alias+$organization
    $Password = [System.Web.Security.Membership]::GeneratePassword(16,4) | ConvertTo-SecureString -AsPlainText -Force
    $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 | ?{$_ -match "x500"}
    $tmpx500 | %{Set-MailUser $m.Alias -EmailAddresses @{add="$_"}}
    }
# Now sync 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-ADSyncCycle

Hur kommer vi åt Outlook dag 1 när den använda postlådan har flyttats?

Eftersom endast en klientorganisation kan äga en domän kommer den tidigare primära SMTPAddressen inte att kopplas till användaren i målklientorganisationen när postlådeflyttningen har slutförts. endast de domäner som är kopplade till den nya klientorganisationen. Outlook använder användarnas nya UPN för att autentisera i tjänsten, och Outlook-profilen förväntar sig att hitta den äldre primära SMTPAddressen för att matcha postlådan i målsystemet. Eftersom den äldre adressen inte finns i målets system kan inte Outlook-profilen ansluta för att hitta den flyttade postlådan.

För den här första distributionen måste användarna återskapa sin profil med sin nya UPN-adress, primära SMTP-adress och synkronisera OST-innehåll igen.

Anteckning

Planera enligt detta när du grupperar användarna så att de kan slutföras. Du måste ta med nätverksanvändningen och kapaciteten när Outlook klientprofiler skapas och efterföljande OST- och OAB-filer laddas ned till klienter.

Vilka Exchange rollerna för RBAC måste jag vara medlem i för att konfigurera eller slutföra en flytt mellan klientorganisationen?

Det finns en matris med roller utifrån antagandet om delegerade uppgifter när postlådeflyttning körs. För närvarande krävs två roller:

  • Den första rollen är för en 1:a konfigurationsaktivitet som upprättar auktoriseringen för att flytta innehåll till eller från organisationens klientorganisations-/organisationsgräns. Eftersom flytten av data från organisationens kontroll är ett viktigt problem för alla företag har vi valt den högsta tilldelade rollen som organisationsadministratör (OrgAdmin). Den här rollen måste ändra eller konfigurera ett nytt OrganizationRelationship som definierar -MailboxMoveCapability med den fjärranslutna organisationen. Endast OrgAdmin kan ändra inställningen MailboxMoveCapability, medan andra attribut i OrganizationRelationship kan hanteras av administratören för Federated Sharing.

  • Rollen för att köra de faktiska flyttningskommandona kan delegeras till en lägre nivå-funktion. Rollen Flytta postlådor tilldelas möjligheten att flytta postlådor till eller från organisationen.

Hur riktar vi den SMTP-adress som valts för targetAddress (TargetDeliveryDomain) på den konverterade postlådan (till MailUser-konvertering)?

Exchange postlådeflyttningar med MRS-skick av måladressen på den ursprungliga källpostlådan när du konverterar till en MailUser genom att matcha en e-postadress (proxyAdress) på målobjektet. Processen tar värdet -TargetDeliveryDomain som skickas till flyttningskommandot och söker sedan efter en matchande proxy för den domänen på målsidan. När vi hittar en matchning används den matchande proxyAdressen till att ange ExternalEmailAddress (targetAddress) på den konverterade postlådan (nu MailUser) objektet.

Hur går postlådebehörigheter över?

Postlådebehörigheter omfattar Skicka för och Åtkomst till postlåda:

  • I Skicka för (AD:publicDelegates) lagras DN för mottagare med åtkomst till en användares postlåda som ombud. Det här värdet lagras i Active Directory och flyttas för närvarande inte som en del av postlådeövergången. Om källpostlådan har angetts med offentligDelegerat måste du skapa en ombyggnad av den offentligaDelegeringen på målpostlådan när konverteringen av e-postlådor har slutförts i målmiljön genom att köra Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate> .

  • Postlådebehörigheter som lagras i postlådan flyttas med postlådan när både huvudmannen och ombudet flyttas till målsystemet. Till exempel tilldelas användaren TestUser_7 FullAccess till postlådan i TestUser_8 i SourceCompany.onmicrosoft.com. När postlådeflyttningen har TargetCompany.onmicrosoft.com postlådeflyttningen konfigureras samma behörigheter i målkatalogen. Exempel på hur Get-MailboxPermission används TestUser_7 i både käll- och målklientorganisationen visas nedan. Exchange-cmdlets föregås av käll- och mål.

Här är ett exempel på resultatet av postlådebehörigheten före flytten.

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

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

Här är ett exempel på utdata för postlådebehörigheten efter flytten.

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

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

Anteckning

Behörigheter för postlådor och kalendrar mellan klientorganisationen stöds INTE. Du måste organisera huvudnamn och ombud i konsoliderade flyttbatchar så att dessa anslutna postlådor flyttas samtidigt från källklientorganisationen.

Vilken X500-proxy ska läggas till i mål-MailUser-proxyadresserna för att aktivera migrering?

Postlådemigrering mellan klientorganisationen kräver att LegacyExchangeDN-värdet för källpostlådeobjektet stämplas som en x500-e-postadress på målets MailUser-objekt.

Exempel:

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

Anteckning

Utöver den här X500-proxyn måste du kopiera alla X500-proxyservrar från postlådan i källan till postlådan i målet.

Kan käll- och målklientorganisationen använda samma domännamn?

Nej. Domännamnen för käll- och målklientorganisationen måste vara unika. En källdomän av contoso.com och måldomänen för fourthcoffee.com.

Kommer delade postlådor att flyttas och fungerar fortfarande?

Ja, men vi behåller bara lagringsbehörigheterna enligt beskrivningen i följande artiklar:

Har du några rekommendationer för batchar?

Överstig inte 2 000 postlådor per batch. Vi rekommenderar att du skickar in batchar två veckor före brytdatumet eftersom det inte påverkar slutanvändarna under synkroniseringen. Om du behöver vägledning för postlådemängder över 50 000 kan du kontakta distributionslistan för teknisk feedback crosstenantmigrationpreview@service.microsoft.com.

Vad händer om jag använder tjänstkryptering med kundnyckel?

Postlådan dekrypteras innan du flyttar den. Se till att kundnyckeln är konfigurerad i målklientorganisationen om den fortfarande krävs. Mer information finns här.

Vilken migreringstid beräknas?

I tabellen som finns här visas riktlinjer för när du kan förvänta dig att masspostlådemigrering eller enskilda migreringar ska slutföras för att hjälpa dig planera migreringen. De här uppskattningarna baseras på en dataanalys av tidigare kundmigreringar. Eftersom varje miljö är unik kan den exakta migreringshastigheten variera.

Kom ihåg att den här funktionen är i förhandsversion och SLA, och tillämpliga servicenivåer gäller inte för prestanda- eller tillgänglighetsproblem under förhandsgranskningsstatusen för den här funktionen.

Skydda dokument i källklientorganisationen som kan användas av användare i målklientorganisationen.

Migrering mellan klientorganisationen migrerar bara postlådedata och ingenting annat. Det finns flera andra alternativ som beskrivs i följande blogginlägg och som kan vara till hjälp: https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

Kan jag ha samma etiketter i målklientorganisationen som du hade i källklientorganisationen, antingen som den enda uppsättningen etiketter eller ytterligare en uppsättning etiketter för de migrerade användarna beroende på justeringen mellan organisationer.

Eftersom flerklientsmigrering inte exporterar etiketter och det finns inget sätt att dela etiketter mellan klientorganisationen kan du bara uppnå detta genom att återskapa etiketterna i målklientorganisationen.

Stöder du flytt av Microsoft 365 grupper?

För närvarande stöder inte funktionen postlådemigrering med flera klientorganisationer migrering Microsoft 365 grupper.

Kan en administratör för källklientorganisationen utföra en eDiscovery-sökning mot en postlåda efter att postlådan har migrerats till den nya klientorganisationen/målklientorganisationen?

Nej, efter en migrering av postlådor för flera klientorganisationen fungerar inte eDiscovery mot den migrerade användarens postlåda i källan. Det beror på att det inte längre finns någon postlåda i källan att söka mot eftersom postlådan har migrerats till målklientorganisationen och nu tillhör målklientorganisationen. eDiscovery, efter postlådemigrering kan endast utföras i målklientorganisationen (där postlådan nu finns). Om en kopia av källpostlådan måste finnas kvar i källklientorganisationen efter migreringen kan administratören i källan kopiera innehållet till en alternativ postlåda före migreringen för framtida eDiscovery-åtgärder mot data.

Kända problem

  • Problem: Funktionen Teams migrering i källklientorganisationen är begränsad. När postlådan har migrerats till målklientorganisationen har Teams i källklientorganisationen inte längre åtkomst till användarens postlåda. Så om en användare loggar in i Teams med autentiseringsuppgifter för källklientorganisationen kommer det att finnas en funktionsnedsättning, till exempel att det inte går att uppdatera din profilbild, inget kalenderprogram och att det inte går att söka i och gå med i offentliga team.

  • Problem: Automatiskt utökade arkiv kan inte migreras. Funktionen för migrering mellan klientorganisationen har stöd för migreringar av den primära postlådan och arkivpostlådan för en viss användare. Om användaren i källan däremot har ett automatiskt expanderat arkiv, vilket innebär fler än en arkivpostlåda, kan funktionen inte migrera de extra arkiven och bör misslyckas.

  • Problem: Cloud MailUsers med icke-ägd smtp-proxyAddress-block MRS flyttar bakgrunden. När du skapar MailUser-objekt för målklientorganisationen måste du se till att alla SMTP-proxyadresser tillhör målklientorganisationen. Om det finns en SMTP-proxyAddress på målanvändaren för e-post som inte tillhör den lokala klientorganisationen förhindras konverteringen av MailUser till Mailbox. Detta beror på vår garanti för att postlådeobjekt bara kan skicka e-post från domäner som klientorganisationen är auktoritativ för (domäner som anspråksklienten gör anspråk på):

    • När du synkroniserar användare från lokala med Hjälp av Azure AD Anslut etablerar du lokala MailUser-objekt med ExternalEmailAddress som pekar på källklientorganisationen där postlådan finns (LaraN@contoso.onmicrosoft.com) och du stämplar PrimarySMTPAddress som en domän som finns i målklientorganisationen (Lara.Newton@northwind.com). Dessa värden synkroniseras ned till klientorganisationen och en lämplig e-postanvändare har etablerats och är redo för migrering. Här visas ett exempelobjekt.

      Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses
      
      ExternalEmailAddress               EmailAddresses
      --------------------               --------------
      SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwind.com}
      

    Anteckning

    Den contoso.onmicrosoft.com finns inte i matrisen E-postadresser/proxyAddresses.

  • Problem: MailUser-objekt med "externa" primära SMTP-adresser ändras/återställs till "interna" företagsdrekuterade domäner

    MailUser-objekt är pekare till icke-lokala postlådor. För postlådemigrering mellan klientorganisationen använder vi MailUser-objekt för att representera antingen källpostlådan (från målorganisationens perspektiv) eller målpostlådan (från källorganisationens perspektiv). MailUsers har en ExternalEmailAddress (targetAddress) som pekar på smtp-adressen för den faktiska postlådan (ProxyTest@fabrikam.onmicrosoft.com) och primarySMTP-adressen som representerar den SMTP-adress som visas för postlådans användare i katalogen. Vissa organisationer väljer att visa den primära SMTP-adressen som en extern SMTP-adress, inte som en adress som ägs/verifieras av den lokala klientorganisationen (till exempel fabrikam.com i stället för som contoso.com). Men när ett Exchange-tjänstplansobjekt tillämpas på MailUser via licensieringsåtgärder ändras den primära SMTP-adressen så att den visas som en domän som verifierats av den lokala organisationen (contoso.com). Det finns två möjliga orsaker:

    • När ett Exchange-tjänstabonnemang tillämpas på en MailUser börjar Azure AD-processen att framtvinga proxyskrubbning för att säkerställa att den lokala organisationen inte kan skicka ut e-post, förfalskning eller e-post från en annan klientorganisation. Alla SMTP-adresser på ett mottagarobjekt med dessa tjänstplaner tas bort om adressen inte verifieras av den lokala organisationen. Som i exemplet har Fabikam.com INTE verifierats av contoso.onmicrosoft.com-klientorganisationen, så skrubbningen tar bort det fabrikam.com domänen. Om du vill ha kvar dessa externa domäner på MailUser, antingen före migreringen eller efter migreringen, måste du ändra dina migreringsprocesser till ränder på licenser efter flytten eller innan flytten för att säkerställa att användarna har den förväntade externa varumärkeskopplingen tillämpad. Du måste se till att postlådeobjektet är korrekt licensierat för att inte påverka e-posttjänsten.

    • Ett exempelskript för att ta bort tjänstplaner på en MailUser i contoso.onmicrosoft.com klientorganisationen visas här.

      $LO = New-MsolLicenseOptions -AccountSkuId "contoso:ENTERPRISEPREMIUM" DisabledPlans "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"
      Set-MsolUserLicense -UserPrincipalName ProxyTest@contoso.com LicenseOptions $lo
      

      Resultatet för uppsättningen serviceplaner som har tilldelats visas här.

      (Get-MsolUser -UserPrincipalName ProxyTest@contoso.com).licenses | Select-Object -ExpandProperty ServiceStatus |sort ProvisioningStatus -Descending
      
      ServicePlan           ProvisioningStatus
      -----------           ------------------
      ATP_ENTERPRISE        PendingProvisioning
      MICROSOFT_SEARCH      PendingProvisioning
      INTUNE_O365           PendingActivation
      PAM_ENTERPRISE        Disabled
      EXCHANGE_ANALYTICS    Disabled
      EQUIVIO_ANALYTICS     Disabled
      THREAT_INTELLIGENCE   Disabled
      LOCKBOX_ENTERPRISE    Disabled
      PREMIUM_ENCRYPTION    Disabled
      EXCHANGE_S_ENTERPRISE Disabled
      INFORMATION_BARRIERS  Disabled
      MYANALYTICS_P2        Disabled
      MIP_S_CLP1            Disabled
      MIP_S_CLP2            Disabled
      ADALLOM_S_O365        PendingInput
      RMS_S_ENTERPRISE      Success
      YAMMER_ENTERPRISE     Success
      PROJECTWORKMANAGEMENT Success
      BI_AZURE_P2           Success
      WHITEBOARD_PLAN3      Success
      SHAREPOINTENTERPRISE  Success
      SHAREPOINTWAC         Success
      KAIZALA_STANDALONE    Success
      OFFICESUBSCRIPTION    Success
      MCOSTANDARD           Success
      Deskless              Success
      STREAM_O365_E5        Success
      FLOW_O365_P3          Success
      POWERAPPS_O365_P3     Success
      TEAMS1                Success
      MCOEV                 Success
      MCOMEETADV            Success
      BPOS_S_TODO_3         Success
      FORMS_PLAN_E5         Success
      SWAY                  Success
      

      Användarens PrimarySMTPAddress är inte längre rensad. Domänen fabrikam.com inte ägs av contoso.onmicrosoft.com och finns kvar som den primära SMTP-adressen som visas i katalogen.

      Här är ett exempel.

      Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
      UserPrincipalName               PrimarySmtpAddress              ExternalEmailAddress                 ExternalDirectoryObjectId
      -----------------               ------------------              --------------------                 -------------------------
      ProxyTest@fabrikam.com          ProxyTest@fabrikam.com          SMTP:ProxyTest@fabrikam.com          e2513482-1d5b-4066-936a-cbc7f8f6f817
      
      • När msExchRemoteRecipientType är inställt på 8 (DeprovisionMailbox), kommer den lokala MailUsers som migreras till målklientorganisationen att ta bort icke-ägda domäner och återställa primarySMTP till en ägd domän. Genom att rensa msExchRemoteRecipientType i den lokala MailUser tillämpas inte längre proxy-scrub-logiken.

        Nedan visas alla aktuella tjänstplaner som innehåller alla Exchange Online.

        Namn
        Advanced eDiscovery Storage (500 GB)
        Customer Lockbox
        Dataförlustskydd
        Exchange Enterprise CAL Services (EOP, DLP)
        Exchange Essentials
        Exchange Foundation
        Exchange Online (P1)
        Exchange Online (alternativ 1)
        Exchange Online (alternativ 2)
        Exchange Online Archiving för Exchange Online
        Exchange Online Archiving för Exchange Server
        Exchange Online Inaktivt användar tillägg
        Exchange Online – kiosk
        Exchange Online Multi-Geo
        Exchange Online-abonnemang 1
        Exchange Online - POP
        Exchange Online Protection
        Informationsbarriärer
        Informationsskydd för Office 365 – Premium
        Informationsskydd för Office 365 – Standard
        Insights av MyAnalytics
        Microsoft 365 avancerad granskning
        Microsoft Bookings
        Microsoft Business Center
        Microsoft MyAnalytics (fullständig)
        Avancerad eDiscovery för Office 365
        Microsoft Defender för Office 365 (abonnemang 1)
        Microsoft Defender för Office 365 (abonnemang 2)
        Office 365 behörighetshantering
        Premium kryptering i Office 365