Migrazione delle cassette postali tra tenant
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
A partire da novembre 2022, la migrazione dei dati utente tra tenant è disponibile come componente aggiuntivo per i piani di sottoscrizione di Microsoft 365 seguenti per i clienti Enterprise Agreement ed è necessaria per le migrazioni tra tenant. Le licenze utente sono per ogni migrazione (tariffa una tantum) e possono essere assegnate nell'oggetto utente di origine o di destinazione. Questa licenza riguarda anche OneDrive for Business migrazione. Per informazioni dettagliate, contattare il team dell'account Microsoft.
Il componente aggiuntivo Migrazione dei dati utente tra tenant è disponibile come acquisto separato per Microsoft 365 Business Basic, Standard e Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; e OneDrive for Business.
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://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. 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
Accedere al Interfaccia di amministrazione di Microsoft Entra (https://portal.azure.com) con le credenziali di amministratore del tenant di destinazione.
In Gestisci Microsoft Entra ID selezionare Visualizza.
Nel riquadro di spostamento selezionare Registrazioni app.
Selezionare Nuova registrazione.
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.
Nell'angolo in alto a destra della pagina vedere la finestra di dialogo di notifica che indica che l'app è stata creata correttamente.
Indietro alla home page, passare a Microsoft Entra ID e quindi selezionare Registrazioni app.
In Applicazioni di proprietà individuare l'app creata e quindi selezionarla.
In Essentials copiare l'ID applicazione (client). Queste informazioni saranno necessarie in un secondo momento per creare un URL per il tenant di destinazione.
Nel riquadro di spostamento selezionare Autorizzazioni API per visualizzare le autorizzazioni assegnate all'app.
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.
Per aggiungere l'autorizzazione per la migrazione delle cassette postali, selezionare Aggiungi un'autorizzazione.
Nella finestra Richiedi autorizzazioni API selezionare API usate dall'organizzazione, cercare
Office 365 Exchange Onlinee quindi selezionarle.
Selezionare Autorizzazioni dell’applicazione.
In Selezionare le autorizzazioni espandere Cassetta postale e selezionare Cassetta postale.Migrazione e quindi selezionare Aggiungi autorizzazioni nella parte inferiore della schermata.
Selezionare Certificati & segreti nel riquadro di spostamento dell'applicazione.
In Segreti client selezionare Nuovo segreto client.
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.
Concedere il consenso all'applicazione
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.
Selezionare Concedi consenso amministratore per [tenant]. Verrà visualizzata una nuova finestra del browser.
Selezionare Accetta.
Indietro alla finestra del portale e selezionare Aggiorna per confermare l'accettazione.
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.comNota
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
Connettersi a Exchange Online PowerShell nel tenant di Exchange Online di destinazione.
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.
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -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 "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppIdCreare 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]" $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 }
Preparare il tenant di origine (posizione corrente della cassetta postale) accettando l'applicazione di migrazione e configurando la relazione dell'organizzazione
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.comNota
Sarà necessario l'ID applicazione dell'app di migrazione delle cassette postali appena creata. Nell'esempio precedente sarà necessario sostituire
contoso.onmicrosoft.comcon l'URL del tenant dionmicrosoft.comorigine. 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.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.
Connettersi a Exchange Online PowerShell nel tenant di Exchange Online di origine.
Creare un nuovo oggetto relazione dell'organizzazione o modificare l'oggetto relazione dell'organizzazione esistente nel tenant di destinazione (destinazione) in Exchange Online PowerShell:
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $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]" New-DistributionGroup -Type Security -Name $scope $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 }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:
L'oggetto MailUser di destinazione deve avere questi attributi della cassetta postale di origine o assegnato con il nuovo oggetto User:
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.
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.
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.
UserPrincipalName: UPN sarà allineato alla NUOVA identità dell'utente o alla società di destinazione (ad esempio, user@northwindtraders.onmicrosoft.com).
Indirizzo SMTP primario: l'indirizzo SMTP primario verrà allineato alla nuova società dell'utente , user@northwindtraders.comad esempio .
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.
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
Altri attributi possono essere già inclusi nel writeback ibrido di Exchange. In caso contrario, dovrebbero essere inclusi.
msExchBlockedSendersHash: scrive i dati del mittente bloccati online dai client in Active Directory locale.msExchSafeRecipientsHash: scrive i dati dei destinatari sicuri online dai client in Active Directory locale.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.
È 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
-MailboxMoveCapabilitycon 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, le funzionalità di sicurezza e 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 la lista di distribuzione dei commenti e suggerimenti tecnici all'indirizzo crosstenantmigrationpreview@service.microsoft.com.
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:
È 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 |
| Connettori Graph Search con Index |
| 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-MigrationUserAggiungere 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-MigrationUserAggiungere 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-MigrationUserAggiungere 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-MigrationUserAggiungere 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-b355b6b852c8Riprendere 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-MigrationUserAggiungere 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
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per