Condividi tramite

Migrazione delle cassette postali tra tenant

  • Articolo

Durante le fusioni o le cessioni, potrebbe essere necessaria la possibilità di spostare le cassette postali Exchange Online degli utenti in un nuovo tenant. La migrazione delle cassette postali tra tenant consente agli amministratori tenant di usare interfacce note come Exchange Online PowerShell e MRS per eseguire la transizione degli utenti alla nuova organizzazione.

Gli amministratori possono usare il cmdlet New-MigrationBatch , disponibile tramite il ruolo di gestione Sposta cassette postali , per eseguire spostamenti tra tenant.

Gli utenti di cui viene eseguita la migrazione devono essere presenti nel tenant di destinazione Exchange Online sistema come MailUser, contrassegnati con attributi specifici per abilitare gli spostamenti tra tenant. Il sistema non riesce a spostare gli utenti non configurati correttamente nel tenant di destinazione.

Al termine degli spostamenti, la cassetta postale dell'utente di origine viene convertita in un MailUsere l'oggetto targetAddress (visualizzato come ExternalEmailAddress in Exchange) viene contrassegnato con l'indirizzo di routing al tenant di destinazione. Questo processo lascia la legacy MailUser nel tenant di origine e consente la coesistenza e il routing della posta. Quando i processi aziendali lo consentono, il tenant di origine può rimuovere l'oggetto MailUser di origine o convertirlo in un contatto di posta elettronica.

Le migrazioni delle cassette postali di Exchange tra tenant sono supportate solo per i tenant ibridi o cloud o per una combinazione di questi due.

Questo articolo descrive il processo per lo spostamento di cassette postali tra tenant e fornisce indicazioni su come preparare i tenant di origine e di destinazione per gli spostamenti di contenuto della cassetta postale Exchange Online.

Importante

Le cassette postali che si trovano in qualsiasi tipo di blocco non vengono migrate e lo spostamento per tali cassette postali è bloccato.

Quando viene eseguita la migrazione di una cassetta postale tra tenant con questa funzionalità, solo il contenuto visibile all'utente nella cassetta postale (posta elettronica, contatti, calendario, attività e note) viene migrato alla destinazione (tenant di destinazione). Dopo la corretta migrazione, la cassetta postale di origine viene eliminata. Questa eliminazione significa che dopo la migrazione, in nessun caso la cassetta postale di origine è disponibile, individuabile o accessibile nel tenant di origine.

Licenze

Importante

Le migrazioni tra tenant richiedono una licenza per utente (una tantum) e possono essere assegnate nell'oggetto utente di origine o di destinazione. Questa licenza riguarda anche OneDrive for Business migrazione. Migrazione dei dati utente tra tenant è disponibile come componente aggiuntivo per i piani di sottoscrizione di Microsoft 365 seguenti: Microsoft 365 Business Basic, Standard e Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; OneDrive for Business ed EDU.

Avviso

È necessario aver acquistato o verificato che sia possibile acquistare licenze per la migrazione dei dati degli utenti tra tenant prima dei passaggi successivi. Le migrazioni hanno esito negativo se questo passaggio non è stato completato. Microsoft non offre eccezioni per questo requisito di licenza.

Se non si dispone della licenza appropriata assegnata all'utente di cui viene eseguita la migrazione, la migrazione ha esito negativo e viene visualizzato un errore simile al seguente:

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.

Preparazione dei tenant di origine e di destinazione

Prerequisiti per i tenant di origine e di destinazione

Prima di iniziare, assicurarsi di disporre delle autorizzazioni necessarie per configurare l'applicazione Sposta cassette postali in Azure, l'endpoint di migrazione EXO e la relazione dell'organizzazione EXO.

Inoltre, è necessario almeno un gruppo di sicurezza abilitato per la posta elettronica nel tenant di origine. Questi gruppi vengono usati per definire l'ambito dell'elenco di cassette postali che possono passare dal tenant di origine (o talvolta definito risorsa) al tenant di destinazione. Questa ambito consente all'amministratore del tenant di origine di limitare o definire l'ambito del set specifico di cassette postali che devono essere spostate, impedendo la migrazione di utenti imprevisti.

Se si esegue la migrazione di più di 10.000 utenti, è consigliabile creare più gruppi per contenere l'elenco utenti per ottenere prestazioni ottimali. Anche se i gruppi annidati sono supportati, non sono consigliati.

È anche necessario comunicare con la società partner attendibile (con cui si sposteranno le cassette postali) per ottenere l'ID tenant di Microsoft 365. Questo ID tenant viene usato nel campo NomeDominio relazione organizzazione .

Per ottenere l'ID tenant di una sottoscrizione, accedere al interfaccia di amministrazione di Microsoft 365 e passare a https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Selezionare l'icona di copia per la proprietà ID tenant per copiarla negli Appunti.

Tutti gli utenti delle organizzazioni di origine e di destinazione devono avere la licenza con le sottoscrizioni Exchange Online appropriate. Assicurarsi inoltre di applicare licenze di migrazione dei dati utente tra tenant a tutti gli utenti di cui verrà eseguita la migrazione al lato di destinazione.

Passaggi di configurazione per abilitare i tenant per le migrazioni delle cassette postali tra tenant

Nota

È prima necessario configurare la destinazione. Per completare questi passaggi, non è necessario avere o conoscere le credenziali di amministratore del tenant sia per il tenant di origine che per quello di destinazione. I passaggi possono essere eseguiti singolarmente per ogni tenant da amministratori diversi.

Preparare la destinazione creando l'applicazione di migrazione e il segreto

  1. Accedere al Interfaccia di amministrazione di Microsoft Entra (https://portal.azure.com) con le credenziali di amministratore del tenant di destinazione.

    Accesso ad Azure

  2. In Gestisci Microsoft Entra ID selezionare Visualizza.

    Pulsante Microsoft Entra

  3. Nel riquadro di spostamento selezionare Registrazioni app.

  4. Selezionare Nuova registrazione.

    Screenshot della nuova interfaccia utente dell'applicazione.

  5. Nella pagina Registra un'applicazione, in Tipi di account supportati selezionare Account in qualsiasi directory organizzativa (Qualsiasi directory Microsoft Entra - Multi-tenant). In URI di reindirizzamento (facoltativo) selezionare Quindi Web e quindi digitare https://office.com. Selezionare quindi Registra.

    Screenshot del modulo

    Nell'angolo in alto a destra della pagina vedere la finestra di dialogo di notifica che indica che l'app è stata creata correttamente.

  6. Indietro alla home page, passare a Microsoft Entra ID e quindi selezionare Registrazioni app.

  7. In Applicazioni di proprietà individuare l'app creata e quindi selezionarla.

  8. In Essentials copiare l'ID applicazione (client). Queste informazioni saranno necessarie in un secondo momento per creare un URL per il tenant di destinazione.

  9. Nel riquadro di spostamento selezionare Autorizzazioni API per visualizzare le autorizzazioni assegnate all'app.

  10. Per impostazione predefinita, le autorizzazioni User.Read vengono assegnate all'app creata, ma queste autorizzazioni non sono necessarie per le migrazioni delle cassette postali. È possibile rimuovere tali autorizzazioni.

    Screenshot di

  11. Per aggiungere l'autorizzazione per la migrazione delle cassette postali, selezionare Aggiungi un'autorizzazione.

  12. Nella finestra Richiedi autorizzazioni API selezionare API usate dall'organizzazione, cercare Office 365 Exchange Onlinee quindi selezionarle.

    Screenshot di

  13. Selezionare Autorizzazioni dell’applicazione.

  14. In Selezionare le autorizzazioni espandere Cassetta postale e selezionare Cassetta postale.Migrazione e quindi selezionare Aggiungi autorizzazioni nella parte inferiore della schermata.

    Screenshot di Mailbox.Migration e della relativa casella di controllo in

  15. Selezionare Certificati & segreti nel riquadro di spostamento dell'applicazione.

  16. In Segreti client selezionare Nuovo segreto client.

    Screenshot di

  17. Nella finestra Aggiungi un segreto client digitare una descrizione e quindi configurare le impostazioni di scadenza.

    Nota

    La password viene usata durante la creazione dell'endpoint di migrazione. È estremamente importante copiare questa password negli Appunti e/o in un percorso sicuro e sicuro. La fase di creazione del segreto è l'unico momento durante il quale è possibile visualizzare questa password. Se in qualche modo lo si perde o è necessario reimpostarlo, è possibile accedere di nuovo al portale di Azure, passare a Registrazioni app, trovare l'app di migrazione, selezionare Segreti & certificati e quindi creare un nuovo segreto per l'app.

Ora che l'applicazione di migrazione e il segreto sono stati creati correttamente, il passaggio successivo consiste nel fornire il consenso all'applicazione.

  1. Nella pagina di destinazione Microsoft Entra ID selezionare Applicazioni aziendali nel riquadro di spostamento, quindi individuare l'app di migrazione creata, selezionarla e quindi selezionare Autorizzazioni API.

  2. Selezionare Concedi consenso amministratore per [tenant]. Verrà visualizzata una nuova finestra del browser.

  3. Selezionare Accetta.

  4. Indietro alla finestra del portale e selezionare Aggiorna per confermare l'accettazione.

  5. Formulare l'URL da inviare al partner attendibile (amministratore del tenant di origine) in modo che possa accettare anche l'applicazione per abilitare la migrazione delle cassette postali.

    Ecco un esempio dell'URL da fornire:

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

    Nota

    Sarà necessario l'ID applicazione dell'app di migrazione delle cassette postali appena creata. Nell'esempio precedente è necessario sostituire contoso.onmicrosoft.com con il nome onmicrosoft.com corretto del tenant di origine. Sarà anche necessario sostituire [application_id_of_the_app_you_just_created] con l'ID applicazione dell'app di migrazione delle cassette postali appena creata.

Preparare il tenant di destinazione creando l'endpoint di migrazione di Exchange Online e la relazione dell'organizzazione

  1. Connettersi a Exchange Online PowerShell nel tenant di Exchange Online di destinazione.

  2. Creare un nuovo endpoint di migrazione per gli spostamenti delle cassette postali tra tenant.

    Nota

    Sarà necessario l'ID applicazione dell'app di migrazione della cassetta postale appena creata e la password (segreto) configurata in Preparare il tenant di destinazione (destinazione) creando l'applicazione di migrazione e il segreto. A seconda dell'istanza cloud di Microsoft 365 usata, l'endpoint potrebbe essere diverso. Vedere la pagina Degli endpoint di Microsoft 365; selezionare l'istanza corretta per il tenant; esaminare quindi l'indirizzo Exchange Online Optimize/Required e sostituire in base alle esigenze.

    $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

Nota

Se il comando precedente non riesce, rivolgersi all'amministratore del tenant di origine per verificare se all'applicazione è stato concesso il consenso amministratore.

  1. Creare un nuovo oggetto relazione dell'organizzazione o modificare l'oggetto relazione dell'organizzazione esistente nel tenant di origine.

    $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
}

Preparare il tenant di origine (posizione corrente della cassetta postale) accettando l'applicazione di migrazione e configurando la relazione dell'organizzazione

  1. Usando il browser, passare al collegamento URL fornito dal partner attendibile per fornire il consenso all'applicazione di migrazione delle cassette postali. L'URL dovrebbe essere simile al seguente:

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

    Nota

    Sarà necessario l'ID applicazione dell'app di migrazione delle cassette postali appena creata. Nell'esempio precedente sarà necessario sostituire contoso.onmicrosoft.com con l'URL del tenant di onmicrosoft.com origine. Sarà anche necessario sostituire [application_id_of_the_app_you_just_created] con l'ID applicazione dell'app di migrazione delle cassette postali appena creata.

  2. Accettare l'applicazione quando viene visualizzato il popup. È anche possibile accedere al Interfaccia di amministrazione di Microsoft Entra e trovare l'applicazione in Applicazioni aziendali.

  3. Connettersi a Exchange Online PowerShell nel tenant di Exchange Online di origine.

  4. Creare un nuovo oggetto relazione dell'organizzazione o modificare l'oggetto relazione dell'organizzazione esistente nel tenant di destinazione (destinazione) in 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
}

    Nota

    L'ID tenant immesso come $sourceTenantId e $targetTenantId è il GUID e non il nome di dominio del tenant. Per un esempio di ID tenant e informazioni sulla ricerca dell'ID tenant, vedere Trovare l'ID tenant di Microsoft 365.

Preparare gli oggetti utente di destinazione per la migrazione

Gli utenti di cui viene eseguita la migrazione devono essere presenti nel tenant di destinazione e Exchange Online sistema (come MailUser) contrassegnato con attributi specifici per abilitare gli spostamenti tra tenant. Il sistema non riuscirà a spostare gli utenti non configurati correttamente nel tenant di destinazione. La sezione Prerequisiti per gli oggetti utente di destinazione descrive in dettaglio i requisiti dell'oggetto MailUser per il tenant di destinazione.

Prerequisiti per gli oggetti utente di destinazione

Verificare che nell'organizzazione di destinazione siano impostati gli oggetti e gli attributi seguenti:

Consiglio

Microsoft sta sviluppando una funzionalità per fornire un metodo automatizzato sicuro per impostare molti degli attributi (specificati di seguito, in questa sezione). Questa funzionalità, denominata Mapping identità tra tenant, è attualmente alla ricerca di clienti disposti a partecipare a una piccola anteprima privata. Per altre informazioni su questa funzionalità non definitiva e su come semplificare i processi di migrazione tra tenant, vedere Mapping delle identità tra tenant.

Per qualsiasi cassetta postale che si sposta da un'organizzazione di origine, è necessario effettuare il provisioning di un oggetto MailUser nell'organizzazione di destinazione:

  1. L'oggetto MailUser di destinazione deve avere questi attributi della cassetta postale di origine o assegnato con il nuovo oggetto User:

    1. ExchangeGUID (flusso diretto dall'origine alla destinazione): il GUID della cassetta postale deve corrispondere. Il processo di spostamento non procederà se questo attributo non è presente nell'oggetto di destinazione.

    2. ArchiveGUID (flusso diretto dall'origine alla destinazione): il GUID dell'archivio deve corrispondere. Il processo di spostamento non procederà se questo attributo non è presente nell'oggetto di destinazione. Questo attributo è obbligatorio solo se la cassetta postale di origine è abilitata per l'archiviazione.

    3. LegacyExchangeDN (flusso come proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN deve essere presente in MailUser di destinazione come x500: proxyAddress. È anche necessario copiare tutti gli indirizzi x500 dalla cassetta postale di origine all'utente di posta elettronica di destinazione. I processi di spostamento non procederanno se questi indirizzi x500 non sono presenti nell'oggetto di destinazione. Inoltre, questo passaggio è importante per abilitare la capacità di risposta per i messaggi di posta elettronica inviati prima della migrazione. L'indirizzo mittente/destinatario in ogni elemento di posta elettronica e la cache di completamento automatico in Microsoft Outlook e in Microsoft Outlook Web App (OWA) usano il valore dell'attributo LegacyExchangeDN. Se non è possibile individuare un utente usando il valore LegacyExchangeDN, il recapito dei messaggi di posta elettronica potrebbe non riuscire con un rapporto di mancato recapito 5.1.1.

    4. UserPrincipalName: UPN sarà allineato alla NUOVA identità dell'utente o alla società di destinazione (ad esempio, user@northwindtraders.onmicrosoft.com).

    5. Indirizzo SMTP primario: l'indirizzo SMTP primario verrà allineato alla nuova società dell'utente , user@northwindtraders.comad esempio .

    6. TargetAddress/ExternalEmailAddress: MailUser farà riferimento alla cassetta postale corrente dell'utente ospitata nel tenant di origine , ad esempio user@contoso.onmicrosoft.com. Quando viene assegnato questo valore, verificare di avere o assegnare anche PrimarySMTPAddress; in caso contrario, questo valore imposterà PrimarySMTPAddress, che causerà errori di spostamento.

    7. Non è possibile aggiungere indirizzi proxy SMTP legacy dalla cassetta postale di origine a MailUser di destinazione. Ad esempio, non è possibile gestire contoso.com nella MEU negli oggetti tenant northwindtraders.onmicrosoft.com. I domini sono associati a un solo tenant Microsoft Entra ID o Exchange Online.

      Oggetto MailUser di destinazione di esempio:

      Attributo Valore
      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

      Oggetto Mailbox di origine di esempio :

      Attributo Valore
      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. Altri attributi possono essere già inclusi nel writeback ibrido di Exchange. In caso contrario, dovrebbero essere inclusi.

    1. msExchBlockedSendersHash: scrive i dati del mittente bloccati online dai client in Active Directory locale.
    2. msExchSafeRecipientsHash: scrive i dati dei destinatari sicuri online dai client in Active Directory locale.
    3. msExchSafeSendersHash: scrive i dati del mittente online sicuro dai client in Active Directory locale.

    Gli utenti dell'organizzazione di destinazione devono disporre di una licenza con le sottoscrizioni di Exchange Online appropriate applicabili per l'organizzazione. È possibile applicare una licenza prima dello spostamento di una cassetta postale, ma SOLO una volta che l'oggetto MailUser di destinazione è configurato correttamente con ExchangeGUID e gli indirizzi proxy. L'applicazione di una licenza prima dell'applicazione di ExchangeGUID comporterà il provisioning di una nuova cassetta postale nell'organizzazione di destinazione. È anche necessario applicare una licenza per la migrazione dei dati utente tra tenant. in caso contrario, è possibile che venga visualizzato un errore temporaneo durante la lettura richiede l'approvazione, che segnala nel report di spostamento che una licenza non è stata applicata all'utente di destinazione.

    Nota

    Quando si applica una licenza a un oggetto Mailbox o MailUser, tutti gli indirizzi proxy di tipo SMTP vengono eliminati per assicurarsi che solo i domini verificati siano inclusi nell'array EmailAddresses di Exchange.

  3. È necessario assicurarsi che l'oggetto MailUser di destinazione non disponga di exchangeGUID precedente che non corrisponda a ExchangeGUID di origine. Questa mancata corrispondenza può verificarsi se il MEU di destinazione è stato precedentemente concesso in licenza per Exchange Online ed è stato effettuato il provisioning di una cassetta postale. Se l'oggetto MailUser di destinazione era precedentemente concesso in licenza per o aveva un ExchangeGUID che non corrisponde a ExchangeGUID di origine, è necessario eseguire una pulizia dell'UNITÀ UTENTE cloud. Per queste MEU cloud, è possibile eseguire Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Attenzione

Questo processo è irreversibile. Se l'oggetto ha una cassetta postale softDeleted, non può essere ripristinato dopo questo punto. Dopo la cancellazione, tuttavia, è possibile sincronizzare exchangeGUID corretto con l'oggetto di destinazione e MRS connetterà la cassetta postale di origine alla cassetta postale di destinazione appena creata. (Fare riferimento al blog EHLO sul nuovo parametro).

Trovare gli oggetti che in precedenza erano cassette postali usando il comando seguente:

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

Ecco un esempio:

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

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

Cancellare la cassetta postale eliminata temporaneamente usando il comando seguente:

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Ecco un esempio:

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

Come verificare se l'operazione ha avuto esito positivo?

È possibile verificare la configurazione della migrazione delle cassette postali tra tenant eseguendo il cmdlet Test-MigrationServerAvailability sull'endpoint di migrazione tra tenant creato nel tenant di destinazione. Eseguire il cmdlet seguente dal tenant di destinazione:

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

Nota

È anche possibile sfruttare lo script di convalida della migrazione delle cassette postali tra tenant, che consente di convalidare la corretta configurazione delle organizzazioni tra di esse e gli oggetti di cui si prevede di eseguire la migrazione da un tenant a un altro. Lo script consentirà di identificare eventuali discrepanze che possono essere presenti contemporaneamente su tutti gli oggetti e, di conseguenza, ridurrà il tempo impiegato per la fase iniziale.

Spostare nuovamente le cassette postali nell'origine originale

Se è necessaria una cassetta postale per tornare al tenant di origine originale, è necessario eseguire lo stesso set di passaggi e script sia nei nuovi tenant di origine che in nuovi tenant di destinazione, con una certa varianza.

Non eseguire gli script di esempio forniti per creare OrganizationRelationship.

Aggiornare i valori seguenti nell'oggetto OrganizationRelationship esistente creato in ogni tenant:

  • MailboxMovesCapability deve avere in ingresso, RemoteOutbound come funzionalità sia nei tenant di origine che in quello di destinazione.
  • Nel nuovo tenant di origine aggiornare il valore OAuthApplicationId con il valore dell'applicazione appena creata nel nuovo tenant di origine.
  • Nel nuovo tenant di origine aggiornare il valore MailboxMovePublishedScopes con il gruppo di sicurezza appena creato nel nuovo tenant di origine.

Eseguire migrazioni delle cassette postali

Le migrazioni delle cassette postali di Exchange tra tenant vengono avviate dal tenant di destinazione come batch di migrazione. Questo processo è simile al funzionamento dei batch di migrazione on-boarding durante la migrazione da Exchange locale a Microsoft 365.

Creare batch di migrazione

Ecco un comando di esempio per avviare una migrazione batch:

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

Nota

L'indirizzo di posta elettronica nel file CSV deve essere quello specificato nel tenant di destinazione (ad esempio, userA@northwindtraders.onmicrosoft.com), non quello nel tenant di origine. Per altre informazioni sul cmdlet, fare clic quiPer informazioni sui file CSV di esempio, fare clic qui

Un esempio minimo di un file CSV è:

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

L'invio batch di migrazione è supportato anche dalla nuova interfaccia di amministrazione di Exchange quando si seleziona l'opzione tra tenant.

Aggiornare MailUsers locali

Dopo che la cassetta postale si sposta dall'origine alla destinazione, è necessario assicurarsi che gli utenti di posta elettronica locali, sia nell'origine che nella destinazione, vengano aggiornati con il nuovo targetAddress. Negli esempi, il targetDeliveryDomain usato nello spostamento è northwindtraders.onmicrosoft.com. Aggiornare gli utenti di posta elettronica con questo targetAddress.

Rimuovere gli endpoint e le relazioni dell'organizzazione dopo la migrazione

Usare il cmdlet Remove-MigrationEndpoint per rimuovere gli endpoint di migrazione esistenti per i server di origine o di destinazione al termine della migrazione.

Usare il cmdlet Remove-OrganizationRelationship per rimuovere le relazioni dell'organizzazione esistenti per i server di origine o di destinazione al termine della migrazione.

Domande frequenti

È necessario aggiornare RemoteMailboxes nel tenant locale di origine dopo lo spostamento?

Organizzazione di Exchange di origine

È necessario aggiornare targetAddress (RemoteRoutingAddress/ExternalEmailAddress) di ogni utente locale di origine quando la cassetta postale del tenant di origine si sposta nel tenant di destinazione. Mentre il routing della posta elettronica può seguire le segnalazioni tra più utenti di posta elettronica con targetAddresses diversi, le ricerche di disponibilità per gli utenti di posta elettronica devono avere come destinazione la posizione dell'utente della cassetta postale.

Organizzazione exchange di destinazione

Al termine della migrazione in un'organizzazione ibrida, eseguire il comando PowerShell seguente se si vuole che gli utenti dispongano di cassette postali remote in locale:

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

Le riunioni di Teams migrano tra tenant?

Mentre le riunioni di Teams vengono spostate, l'URL della riunione non viene aggiornato quando gli elementi eseguono la migrazione tra tenant. Poiché l'URL non sarà valido nel tenant di destinazione, è necessario rimuovere e ricreare le riunioni di Teams.

Quale contenuto viene migrato tra tenant?

Quando viene eseguita la migrazione di una cassetta postale tra tenant con questa funzionalità, vengono migrati solo il contenuto visibile dall'utente nella cassetta postale, noto anche come Top of Information Store (posta elettronica, contatti, calendario, attività e note) e le cartelle Elementi ripristinabili Eliminazioni, versioni e ripuliture.

Gli elementi nella posta in uscita vengono migrati tra tenant?

Gli elementi nella posta in uscita non vengono migrati tra tenant perché questa cartella è una cartella basata su client specifica del client outlook. Gli elementi nella posta in uscita vengono archiviati in locale e non sincronizzati con il cloud.

Il contenuto della cartella chat di Teams esegue la migrazione tra tenant?

No, il contenuto della cartella chat di Teams non esegue la migrazione tra tenant. Tuttavia, dopo la migrazione della cassetta postale tra tenant, il contenuto della cartella chat di Teams sarà disponibile per l'amministratore del tenant di origine per la ricerca e l'esportazione, usando una ricerca di contenuto.

Come posso vedere solo le mosse che sono spostamenti tra tenant, non le mie mosse di onboarding e off-boarding?

Usare il parametro Flags :

Get-MoveRequest -Flags "CrossTenant"

È possibile fornire script di esempio per la copia degli attributi usati nel test?

Nota

SAMPLE– AS IS, NO WARRANTY Questo script presuppone una connessione sia alla cassetta postale di origine (per ottenere i valori di origine) che al Active Directory locale Domain Services di destinazione (per contrassegnare l'oggetto ADUser).

# 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

Come si accede a Outlook il giorno 1 dopo lo spostamento della cassetta postale utente?

Poiché un solo tenant può essere proprietario di un dominio, l'indirizzo SMTP primario precedente non verrà associato all'utente nel tenant di destinazione al termine dello spostamento della cassetta postale; solo i domini associati al nuovo tenant. Outlook usa il nuovo UPN dell'utente per eseguire l'autenticazione al servizio e il profilo di Outlook prevede di trovare l'indirizzo SMTP primario legacy in modo che corrisponda alla cassetta postale nel sistema di destinazione. Poiché l'indirizzo legacy non si trova nel sistema di destinazione, il profilo di Outlook non si connetterà per trovare la cassetta postale appena spostata.

Per questa distribuzione iniziale, gli utenti dovranno ricompilare il profilo con il nuovo UPN, l'indirizzo SMTP primario e risincronizzazione del contenuto OST.

Nota

Pianificare di conseguenza quando si esegue il batch degli utenti per il completamento. È necessario tenere conto dell'utilizzo della rete e della capacità quando vengono creati i profili client di Outlook e i successivi file OST e OAB vengono scaricati nei client.

Di quali ruoli del controllo degli accessi in base al ruolo di Exchange è necessario essere membri per configurare o completare uno spostamento tra tenant?

È disponibile una matrice di ruoli basata sul presupposto di compiti delegati durante l'esecuzione di uno spostamento della cassetta postale. Attualmente sono necessari due ruoli:

  • Il primo ruolo è per un'attività di configurazione occasionale che stabilisce l'autorizzazione per lo spostamento di contenuto all'interno o all'esterno del limite tenant/organizzazione. Poiché lo spostamento dei dati al di fuori del controllo dell'organizzazione è una preoccupazione critica per tutte le aziende, è stato scelto il ruolo assegnato più alto di Amministratore organizzazione. Questo ruolo deve modificare o configurare una nuova organizationRelationship che definisce l'impostazione -MailboxMoveCapability con l'organizzazione remota. Solo l'amministratore dell'organizzazione può modificare l'impostazione -MailboxMoveCapability , mentre altri attributi in OrganizationRelationship possono essere gestiti dall'amministratore della condivisione federata.
  • Il ruolo di esecuzione dei comandi di spostamento effettivi può essere delegato a una funzione di livello inferiore. Il ruolo di Spostamento cassette postali viene assegnato alla funzionalità di spostamento delle cassette postali all'interno o all'esterno dell'organizzazione.

Come si fa a scegliere quale indirizzo SMTP è selezionato per targetAddress (TargetDeliveryDomain) nella cassetta postale convertita (in conversione MailUser)?

La cassetta postale di Exchange si sposta usando MRS crea targetAddress nella cassetta postale di origine originale quando si converte in un oggetto MailUser corrispondente a un indirizzo di posta elettronica (proxyAddress) nell'oggetto di destinazione. Il processo accetta il -TargetDeliveryDomain valore passato al comando, quindi verifica la presenza di un proxy corrispondente per il dominio sul lato di destinazione. Quando viene individuata una corrispondenza, il proxyAddress corrispondente viene usato per impostare ExternalEmailAddress (targetAddress) nell'oggetto cassetta postale convertito (ora MailUser).

Come funziona il flusso di posta dopo la migrazione?

Il flusso di posta tra tenant dopo la migrazione funziona in modo simile al flusso di posta ibrida di Exchange. Per inoltrare la posta in ingresso dal tenant di origine alle cassette postali nel tenant di destinazione, ogni cassetta postale di cui è stata eseguita la migrazione deve disporre dell'indirizzo mailUser di origine con l'indirizzo di destinazione corretto. Le regole di trasporto, la sicurezza e le funzionalità di conformità verranno eseguite come configurate in ogni tenant in cui scorre la posta. Quindi, per la posta in ingresso, le funzionalità come la posta indesiderata, l'antimalware, la quarantena, le regole di trasporto e le regole di inserimento nel journal verranno eseguite prima nel tenant di origine, quindi nel tenant di destinazione.

Come si esegue la transizione delle autorizzazioni delle cassette postali?

Le autorizzazioni per le cassette postali includono l'invio per conto di e l'accesso alle cassette postali:

  • Send On Behalf Of (AD:publicDelegates) archivia il DN dei destinatari con accesso alla cassetta postale di un utente come delegato. Questo valore viene archiviato in Active Directory e attualmente non viene spostato come parte della transizione della cassetta postale. Se la cassetta postale di origine ha publicDelegates impostato, sarà necessario ripristinare publicDelegates nella cassetta postale di destinazione al termine della conversione da MEU a Cassetta postale nell'ambiente di destinazione eseguendo Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
  • Le autorizzazioni per le cassette postali archiviate nella cassetta postale verranno spostate con la cassetta postale quando l'entità e il delegato vengono spostati nel sistema di destinazione. Ad esempio, all'utente TestUser7 viene concesso FullAccess alla cassetta postale TestUser_8 nel tenant SourceCompany.onmicrosoft.com. Al termine dello spostamento della cassetta postale in TargetCompany.onmicrosoft.com, nella directory di destinazione vengono configurate le stesse autorizzazioni. Di seguito sono riportati esempi che usano _Get-MailboxPermission per TestUser_7 nei tenant di origine e di destinazione. I cmdlet di Exchange sono preceduti da origine e destinazione di conseguenza.

Ecco un esempio dell'output dell'autorizzazione della cassetta postale prima di uno spostamento dal lato di origine:

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

Ecco un esempio dell'output dell'autorizzazione della cassetta postale dopo lo spostamento dal lato di destinazione:

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

Nota

Le autorizzazioni per le cassette postali e il calendario tra tenant non sono supportate. È necessario organizzare entità e delegati in batch di spostamento consolidati in modo che queste cassette postali connesse vengano sottoposte contemporaneamente alla transizione dal tenant di origine.

Quale proxy X500 deve essere aggiunto agli indirizzi proxy MailUser di destinazione per abilitare la migrazione?

La migrazione della cassetta postale tra tenant richiede che il valore LegacyExchangeDN dell'oggetto cassetta postale di origine venga contrassegnato come indirizzo di posta elettronica x500 nell'oggetto MailUser di destinazione.

Esempio:

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

Nota

Oltre a questo proxy X500, sarà necessario copiare tutti i proxy X500 dalla cassetta postale nell'origine alla cassetta postale nella destinazione. Sebbene sia raro, è anche possibile eseguire su un indirizzo proxy X400 in una cassetta postale, anche se non è un requisito per il completamento dello spostamento, è consigliabile contrassegnare anche questo indirizzo nell'oggetto utente di posta elettronica di destinazione.

I tenant di origine e di destinazione possono usare lo stesso nome di dominio?

No, i nomi di dominio del tenant di origine e del tenant di destinazione devono essere univoci, ad esempio un dominio di origine di contoso.com e il dominio di destinazione di northwindtraders.com.

Le cassette postali condivise verranno spostate e continueranno a funzionare?

Sì. Mantieniamo tuttavia solo le autorizzazioni dell'archivio come descritto in questo articolo:

Sono disponibili raccomandazioni per i batch?

Non superare le 2.000 cassette postali per batch. È consigliabile inviare batch due settimane prima della data di cut-over, in quanto non si verifica alcun impatto sugli utenti finali durante la sincronizzazione. Se sono necessarie indicazioni per le quantità di cassette postali superiori a 50.000, è possibile contattare il CSAM o aprire una richiesta di supporto.

Cosa accade se si usa la crittografia del servizio con la chiave del cliente Microsoft Purview?

La cassetta postale viene decrittografata prima dello spostamento. Verificare che la chiave del cliente sia configurata nel tenant di destinazione se è ancora necessaria. Per altre informazioni, vedere qui.

Qual è il tempo stimato per la migrazione?

Per pianificare la migrazione, la tabella seguente mostra le linee guida su quando prevedere il completamento delle migrazioni in blocco delle cassette postali o delle singole migrazioni. Queste stime si basano su un'analisi dei dati delle migrazioni precedenti dei clienti. Poiché ogni ambiente è univoco, la velocità di migrazione esatta può variare.

Protezione dei documenti nel tenant di origine di consumo da parte degli utenti nel tenant di destinazione.**

La migrazione tra tenant esegue la migrazione solo dei dati delle cassette postali e nient'altro. Esistono più altre opzioni, documentate nel post di blog seguente che possono essere utili:

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

È possibile avere le stesse etichette nel tenant di destinazione del tenant di origine, come unico set di etichette o un set aggiuntivo di etichette per gli utenti migrati a seconda dell'allineamento tra le organizzazioni.**

Poiché le migrazioni tra tenant non esportano etichette e non è possibile condividere le etichette tra tenant, è possibile raggiungere questo obiettivo solo ricreando le etichette nel tenant di destinazione.

Si supporta lo spostamento di Gruppi di Microsoft 365?

Attualmente la funzionalità di migrazione delle cassette postali tra tenant non supporta la migrazione di Gruppi di Microsoft 365.

Un amministratore del tenant di origine può eseguire una ricerca eDiscovery in una cassetta postale dopo la migrazione della cassetta postale al tenant nuovo/di destinazione?

No, dopo la migrazione di una cassetta postale tra tenant, eDiscovery sulla cassetta postale dell'utente migrato nell'origine non funziona. Questo errore di eDiscovery è dovuto al fatto che non esiste più una cassetta postale nell'origine da cercare perché la cassetta postale è stata migrata nel tenant di destinazione e ora appartiene al tenant di destinazione. eDiscovery dopo la migrazione delle cassette postali può essere eseguito solo nel tenant di destinazione (dove la cassetta postale esiste ora). Se una copia della cassetta postale di origine deve essere mantenuta nel tenant di origine dopo la migrazione, l'amministratore nel tenant di origine può copiare il contenuto in una cassetta postale alternativa pre-migrazione per le operazioni future di eDiscovery sui dati.

A che punto l'oggetto MailUser di destinazione verrà convertito in una cassetta postale di destinazione e la cassetta postale di origine verrà convertita in un oggetto MailUser di origine?

Queste conversioni vengono eseguite automaticamente durante il processo di migrazione. Non sono necessari passaggi manuali.

In quale passaggio è necessario assegnare la licenza Exchange Online a MailUsers di destinazione?

Questa assegnazione di licenza può essere eseguita prima del completamento della migrazione, ma non è consigliabile assegnare una licenza prima di contrassegnare l'attributo ExchangeGUID ; in caso contrario, la conversione dell'oggetto MailUser in cassetta postale avrà esito negativo e verrà creata una nuova cassetta postale. Per ridurre questo rischio, è consigliabile attendere il completamento della migrazione e assegnare licenze durante il periodo di tolleranza di 30 giorni.

È possibile usare Microsoft Entra Connettersi per sincronizzare gli utenti con il nuovo tenant se si mantiene il Active Directory locale?

Sì. È possibile avere due istanze di Microsoft Entra Connect sincronizzate con tenant diversi. Tuttavia, è necessario tenere presente alcuni aspetti:

  • Il preprovisioning degli account dell'utente con lo script fornito in questo articolo non deve essere eseguito. È invece possibile eseguire una sincronizzazione dell'unità organizzativa selettiva degli utenti nell'ambito della migrazione per popolare il tenant di destinazione. Verrà visualizzato un avviso relativo alla mancata corrispondenza dell'UPN durante la configurazione di Microsoft Entra Connect.
  • A seconda dello stato corrente di Exchange ibrido, è necessario verificare che gli oggetti directory locali abbiano gli attributi necessari (ad esempio msExchMailboxGUID e proxyAddresses) popolati correttamente prima di tentare la sincronizzazione con un altro tenant; in caso contrario si verificano problemi con cassette postali doppie e errori di migrazione.
  • È necessario eseguire alcuni passaggi aggiuntivi per gestire la transizione UPN, modificandola in locale una volta completata la migrazione per un utente, a meno che non si sposti anche il dominio personalizzato durante una migrazione cut-over.

Come gestire le cassette postali vicine o con una quota eccessiva.

Le cassette postali che si avvicinano alla quota prima della migrazione possono superare la quota prima o durante la migrazione effettiva. In questo caso, la migrazione di queste cassette postali avrà esito negativo e dovrà essere corretta e riavviata. Per mitigare questo problema, è consigliabile che l'amministratore del tenant di origine identifichi le cassette postali in corrispondenza o vicino alla quota prima della migrazione e prenda i passaggi necessari per ridurre le dimensioni della cassetta postale, effettuare il provisioning di un archivio primario o in alcuni casi abilitare l'espansione automatica degli archivi per le cassette postali dell'utente.

Nota

Dopo aver abilitato un archivio o un archivio a espansione automatica per un utente, assicurarsi che i criteri di archiviazione corretti vengano applicati all'utente e che il processo venga eseguito per spostare i dati della cassetta postale nella nuova posizione e liberare spazio.

Le cassette postali di archiviazione espanse automaticamente vengono spostate?

Problema: non è possibile eseguire la migrazione degli archivi espansi automaticamente. Sì, se l'utente nell'origine ha abilitato l'espansione automatica degli archivi e dispone di archivi ausiliari aggiuntivi, la migrazione delle cassette postali tra tenant funzionerà. Microsoft supporta lo spostamento di utenti che non dispongono di più di 12 cassette postali di archiviazione ausiliarie. Inoltre, gli utenti con grandi cassette postali di archivio principale principale, principale e archivio ausiliario di grandi dimensioni richiedono tempo aggiuntivo per la sincronizzazione e devono essere inviati con largo anticipo rispetto alla data di cut-over. Se la cassetta postale di origine viene espansa durante il processo di migrazione della cassetta postale, la migrazione avrà esito negativo perché verrà creato un nuovo archivio ausiliario nell'origine, ma non nella destinazione. In questo caso, sarà necessario rimuovere l'utente dal batch e inviarlo di nuovo.

È possibile eseguire una migrazione tra tenant cloud e tenant?

La migrazione tra tenant cloud e tenant non è supportata. Uno scenario di esempio potrebbe essere il passaggio da Office 365 Worldwide a Office 365 Government Cloud.

La migrazione dei messaggi vocali viene eseguita tra tenant?

Sì, la migrazione dei messaggi vocali viene eseguita tra tenant.

  • I messaggi vocali ricevuti tramite posta elettronica come allegati sono disponibili nella cassetta postale di destinazione.
  • I messaggi vocali ricevuti sono disponibili in Teams se si chiama la segreteria telefonica e si ascoltano i messaggi salvati. (Le macchine virtuali ricevute nell'origine sono disponibili come messaggi salvati)
  • I messaggi vocali ricevuti non sono disponibili nell'interfaccia utente client di Teams nella post-migrazione di destinazione.
  • Viene eseguita anche la migrazione del messaggio di saluto della segreteria telefonica alla destinazione.

Le firme delle cassette postali vengono migrate tra tenant?

Le firme delle cassette postali non vengono migrate tra tenant e devono essere ricreate.

Problemi noti

  • Le funzionalità di Teams post-migrazione nel tenant di origine saranno limitate. Dopo la migrazione della cassetta postale al tenant di destinazione, Teams nel tenant di origine non ha più accesso alla cassetta postale dell'utente. Se un utente accede a Teams con le credenziali del tenant di origine, si verifica una perdita di funzionalità, ad esempio l'impossibilità di aggiornare l'immagine del profilo, nessuna applicazione calendario e l'impossibilità di cercare e partecipare a team pubblici.

  • Cloud MailUsers con proxy smtp non di proprietàIndirizzo blocco MRS si sposta. Quando si creano oggetti MailUser del tenant di destinazione, è necessario assicurarsi che tutti gli indirizzi proxy SMTP appartengano all'organizzazione del tenant di destinazione. Se esiste un proxy SMTPAddress nell'utente di posta elettronica di destinazione che non appartiene al tenant locale, la conversione di MailUser in una cassetta postale viene impedita. Questa prevenzione è dovuta alla garanzia che gli oggetti cassetta postale possono inviare posta solo da domini per i quali il tenant è autorevole (domini richiesti dal tenant).

  • Se si sincronizzano gli utenti dall'ambiente locale usando Microsoft Entra Connect nel tenant di destinazione, è possibile effettuare il provisioning di oggetti MailUser locali con ExternalEmailAddress che punta al tenant di origine in cui è presente la cassetta postale (LaraN@contoso.onmicrosoft.com) e si contrassegna PrimarySMTPAddress come dominio che risiede nel tenant di destinazione (Lara.Newton@northwindtraders.com). Questi valori si sincronizzano fino al tenant e viene effettuato il provisioning di un utente di posta elettronica appropriato ed è pronto per la migrazione. Di seguito è riportato un oggetto di esempio.

    Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

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

    Nota

    L'indirizzo contoso.onmicrosoft.comnon è presente nella matrice EmailAddresses/proxyAddresses.

  • Gli oggetti MailUser con indirizzi SMTP primari "esterni" vengono modificati/reimpostati in domini aziendali "interni".

    Gli oggetti MailUser sono puntatori a cassette postali non locali. Nel caso delle migrazioni di cassette postali tra tenant, vengono usati oggetti MailUser per rappresentare la cassetta postale di origine (dal punto di vista dell'organizzazione di destinazione) o la cassetta postale di destinazione (dal punto di vista dell'organizzazione di origine). MailUsers avrà un ExternalEmailAddress (targetAddress) che punta all'indirizzo smtp della cassetta postale effettiva (ProxyTest@northwindtraders.onmicrosoft.com) e all'indirizzo primarySMTP che rappresenta l'indirizzo SMTP visualizzato dell'utente della cassetta postale nella directory. Alcune organizzazioni scelgono di visualizzare l'indirizzo SMTP primario come indirizzo SMTP esterno, non come indirizzo di proprietà o verificato dal tenant locale (ad esempio, come northwindtraders.com anziché come contoso.com). Tuttavia, dopo che un oggetto del piano di servizio di Exchange viene applicato a MailUser tramite operazioni di licenza, l'indirizzo SMTP primario viene modificato per essere visualizzato come dominio verificato dall'organizzazione locale (contoso.com). Esistono due possibili motivi:

  • Quando un piano di servizio di Exchange viene applicato a un oggetto MailUser, il processo di Microsoft Entra ID inizia a applicare lo scrubbing proxy per garantire che l'organizzazione locale non sia in grado di inviare messaggi di posta elettronica, spoofing o posta da un altro tenant. Qualsiasi indirizzo SMTP in un oggetto destinatario con questi piani di servizio verrà rimosso se l'indirizzo non viene verificato dall'organizzazione locale. Come nell'esempio, il dominio northwindtraders.com non viene verificato dal tenant contoso.onmicrosoft.com. di conseguenza, lo scrubbing rimuove tale northwindtraders.com dominio. Se si desidera rendere persistenti questi domini esterni in MailUser, prima o dopo la migrazione, è necessario modificare i processi di migrazione per rimuovere le licenze dopo il completamento dello spostamento o prima dello spostamento per assicurarsi che agli utenti sia applicata la personalizzazione esterna prevista. È necessario assicurarsi che l'oggetto cassetta postale abbia una licenza appropriata per non influire sul servizio di posta elettronica. Di seguito è riportato uno script di esempio per rimuovere i piani di servizio in un oggetto MailUser nel tenant contoso.onmicrosoft.com.

Nota

Lo script seguente usa Microsoft Graph PowerShell. Per altre informazioni, vedere Panoramica di PowerShell di Microsoft Graph.

Per informazioni su come usare metodi diversi per l'autenticazione Connect-Graph in uno script automatico, vedere l'articolo Cmdlet del modulo di autenticazione in 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

I risultati nel set di ServicePlans assegnati sono visualizzati qui:

$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

PrimarySMTPAddress dell'utente non viene più rimosso. Il dominio northwindtraders.com non è di proprietà del tenant contoso.onmicrosoft.com e verrà mantenuto come indirizzo SMTP primario visualizzato nella directory.

Ecco un esempio:

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

Quando msExchRemoteRecipientType è impostato su 8 (DeprovisionMailbox), per i mailuser locali di cui viene eseguita la migrazione al tenant di destinazione, la logica di scrubbing proxy in Azure rimuove i domini non di proprietà e reimposta il protocollo primarySMTP su un dominio di proprietà. Con msExchRemoteRecipientType nell'oggetto MailUser locale cancellato, la logica di scrub proxy non viene più applicata.

Di seguito è riportato il set completo di piani di servizio correnti che includono Exchange Online:

Nome
Archiviazione eDiscovery (Premium) (500 GB)
Archivio protetto del cliente
Prevenzione della perdita di dati
Exchange Enterprise CAL Services (EOP, DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (Piano 1)
Exchange Online (Piano 2)
Archiviazione Exchange Online per Exchange Online
Archiviazione Exchange Online per Exchange Server
componente aggiuntivo utente inattivo Exchange Online
Chiosco Exchange Online
Exchange Online Multi-Geo
Exchange Online Piano 1
Exchange Online POP
Exchange Online Protection
Ricerca di connettori graph con indice
Barriere informative
Information Protection per Office 365 - Premium
Information Protection per Office 365 - Standard
Informazioni dettagliate di MyAnalytics
Microsoft Information Governance
Microsoft Purview Audit (Premium)
Microsoft Bookings
Microsoft Business Center
Indagini sui dati Microsoft
Microsoft MyAnalytics (completo)
Conformità delle comunicazioni Microsoft
Microsoft Communications DLP
Chiave del cliente Microsoft
Controllo avanzato di Microsoft 365
Gestione record Microsoft
Office 365 eDiscovery (Premium)
Office 365 Advanced eDiscovery
Microsoft Defender per Office 365 (piano 1)
Microsoft Defender per Office 365 (piano 2)
Office 365 Privileged Access Management
Crittografia Premium in Office 365

Errori di migrazione

  • MailboxNotInCrossTenantMigrationScopeException

    Assicurarsi che l'ambito di migrazione sia configurato correttamente nel tenant di origine e che MailboxMovesPublishedScopes sia impostato nella relazione dell'organizzazione con il tenant di destinazione.
    Verificare che la cassetta postale di cui eseguire la migrazione sia stata aggiunta al gruppo di sicurezza nel tenant di origine.
    Dopo aver aggiunto l'utente al gruppo di sicurezza corretto, riprendere il batch di migrazione.

  • AuxArchiveNotFoundInTargetRecipientException

    Questo errore è dovuto al fatto che l'utente non era nell'ambito della migrazione all'avvio del batch e l'utente ha AuxArchive nell'origine.
    Aggiungere l'utente al gruppo di sicurezza corretto nella destinazione di origine.
    Rimuovere l'utente della migrazione dal batch.
    Rimuovere gli utenti con il comando seguente:

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

    Aggiungere l'utente al nuovo batch.

  • MailboxIsNotInExpectedDBException

    Questo errore è dovuto alla manutenzione interna di Microsoft.
    Rimuovere l'utente della migrazione dal batch.
    Rimuovere gli utenti con il comando seguente:

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

    Aggiungere l'utente al nuovo batch.

  • NotAcceptedDomainException

    È presente un indirizzo proxy non valido contrassegnato per l'utente di destinazione. Ad esempio, un utente in contoso.onmicrosoft.com aveva un indirizzo proxy di fabrikam.onmicrosoft.com, ovvero il tenant di origine.
    Rimuovere l'indirizzo proxy non valido usando il comando seguente:

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

    Riprendere il batch di migrazione.

  • SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

    Durante la migrazione è stato effettuato il provisioning di un nuovo AuxArchive.
    Rimuovere l'utente della migrazione dal batch.
    Rimuovere gli utenti con il comando seguente:

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

    Aggiungere l'utente al nuovo batch.

  • UserDuplicateInOtherBatchException

    L'utente esiste già in un altro batch.
    Rimuovere l'utente della migrazione dal batch.
    Rimuovere gli utenti con il comando seguente:

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

    Aggiungere l'utente al nuovo batch.

  • MissingExchangeGuidException

    All'oggetto mailuser di destinazione manca il valore ExchangeGuid corretto.
    Aggiornare ExchangeGuid con il comando seguente:

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

    Riprendere il batch di migrazione.

  • SourceMailboxAlreadyBeingMovedPermanentException

    La cassetta postale di origine ha già una richiesta di spostamento esistente. Analizzare e rimuovere lo spostamento esistente. È possibile che si tratti di uno spostamento interno di Microsoft ed è necessario attendere il completamento dello spostamento.
    Rimuovere l'utente della migrazione dal batch.
    Rimuovere gli utenti con il comando seguente:

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

    Aggiungere l'utente al nuovo batch dopo che lo spostamento originale è stato rimosso o completato.

  • UserAlreadyHasDemotedArchiveException

    In precedenza l'utente aveva una cassetta postale di archiviazione disabilitata. Scegliere una delle due opzioni seguenti per risolvere il problema.
    Eliminare definitivamente la cassetta postale di archiviazione disabilitata, che non è inversa. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
    Riabilitare la cassetta postale di archiviazione disabilitata con il comando seguente:

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

    Se si riabilitare la cassetta postale di archiviazione disabilitata, sarà necessario aggiornare il GUID dell'archivio nell'oggetto mailuser di destinazione.
    Riprendere il batch di migrazione.

Vedere anche