Migração de caixas de correio entre inquilinos

Artigo
03/10/2024

Durante fusões ou alienações, poderá precisar da capacidade de mover as caixas de correio Exchange Online dos seus utilizadores para um novo inquilino. A migração de caixas de correio entre inquilinos permite que os administradores inquilinos utilizem interfaces conhecidas, como Exchange Online PowerShell e MRS, para fazer a transição de utilizadores para a nova organização.

Os administradores podem utilizar o cmdlet New-MigrationBatch , disponível através da função de gestão Mover Caixas de Correio , para executar movimentações entre inquilinos.

Os utilizadores que migram têm de estar presentes no inquilino de destino Exchange Online sistema como um MailUser, marcado com atributos específicos para ativar as movimentações entre inquilinos. O sistema não consegue mover utilizadores que não estão corretamente configurados no inquilino de destino.

Após a conclusão das movimentações, a caixa de correio do utilizador de origem é convertida num MailUsere o targetAddress (apresentado como ExternalEmailAddress no Exchange) é carimbado com o endereço de encaminhamento para o inquilino de destino. Este processo deixa o legado MailUser no inquilino de origem e permite a coexistência e o encaminhamento de correio. Quando os processos empresariais o permitem, o inquilino de origem pode remover o MailUser de origem ou convertê-lo num contacto de correio.

As migrações de caixas de correio do Exchange entre inquilinos são suportadas apenas para inquilinos na cloud ou híbrida ou numa combinação dos dois.

Este artigo descreve o processo de movimentação de caixas de correio entre inquilinos e fornece orientações sobre como preparar os inquilinos de origem e de destino para as movimentações de conteúdo da caixa de correio Exchange Online.

Importante

As caixas de correio que estejam em qualquer tipo de suspensão não são migradas e a movimentação dessas caixas de correio está bloqueada.

Quando uma caixa de correio é migrada entre inquilinos com esta funcionalidade, apenas o conteúdo visível pelo utilizador na caixa de correio (e-mail, contactos, calendário, tarefas e notas) é migrado para o destino (inquilino de destino). Após uma migração bem-sucedida, a caixa de correio de origem é eliminada. Esta eliminação significa que, após a migração, em nenhuma circunstância a caixa de correio de origem está disponível, detetável ou acessível no inquilino de origem.

Licenciamento

Importante

A partir de novembro de 2022, a Migração de Dados de Utilizador Entre Inquilinos está disponível como um suplemento para os seguintes planos de subscrição do Microsoft 365 para clientes Contrato Enterprise e é necessária para migrações entre inquilinos. As licenças de utilizador são por migração (taxa única) e podem ser atribuídas no objeto de utilizador de origem ou de destino. Esta licença também abrange OneDrive para Empresas migração. Contacte a equipa da sua conta Microsoft para obter detalhes.

O suplemento migração de dados de utilizador entre inquilinos está disponível como uma compra separada para Microsoft 365 Empresas Basic, Standard e Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; e OneDrive para Empresas.

Aviso

Tem de ter comprado ou verificado que pode comprar licenças de migração de dados de utilizador entre inquilinos antes dos passos seguintes. As migrações falham se este passo ainda não tiver sido concluído. A Microsoft não oferece exceções para este requisito de licenciamento.

Se não tiver a licença adequada atribuída ao utilizador que está a ser migrado, a migração falhará e receberá um erro semelhante ao seguinte:

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.

Preparar inquilinos de origem e de destino

Pré-requisitos para inquilinos de origem e de destino

Antes de começar, certifique-se de que tem as permissões necessárias para configurar a aplicação Mover Caixa de Correio no Azure, o Ponto Final de Migração EXO e a Relação organizacional EXO.

Além disso, é necessário, pelo menos, um grupo de segurança com capacidade de correio no inquilino de origem. Estes grupos são utilizados para definir o âmbito da lista de caixas de correio que podem ser movidas do inquilino de origem (ou por vezes referido como recurso) para o inquilino de destino. Este âmbito permite ao administrador inquilino de origem restringir ou definir o âmbito do conjunto específico de caixas de correio que precisam de ser movidas, impedindo a migração de utilizadores não intencionais.

Se estiver a migrar mais de 10 000 utilizadores, recomendamos que crie vários grupos para conter a lista de utilizadores para um melhor desempenho. Embora os grupos aninhados sejam suportados, não são recomendados.

Também tem de comunicar com a sua empresa parceira fidedigna (com quem irá mover caixas de correio) para obter o respetivo ID de inquilino do Microsoft 365. Este ID de inquilino é utilizado no campo Nome de Domínio da Relação de Organização .

Para obter o ID de inquilino de uma subscrição, inicie sessão no centro de administração do Microsoft 365 e aceda a https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Selecione o ícone de cópia da propriedade ID do Inquilino para copiá-lo para a área de transferência.

Todos os utilizadores nas organizações de origem e de destino têm de estar licenciados com as subscrições Exchange Online adequadas. Além disso, certifique-se de que aplica licenças de Migração de Dados de Utilizador entre Inquilinos a todos os utilizadores que serão migrados para o lado de destino.

Passos de configuração para ativar os inquilinos para migrações de caixas de correio entre inquilinos

Nota

Primeiro, tem de configurar o destino (destino). Para concluir estes passos, não é necessário ter ou conhecer as credenciais de administrador inquilino para o inquilino de origem e de destino. Os passos podem ser executados individualmente para cada inquilino por diferentes administradores.

Preparar o inquilino de destino (destino) ao criar a aplicação de migração e o segredo

Inicie sessão no seu centro de administração Microsoft Entra (https://portal.azure.com) com as suas credenciais de administrador inquilino de destino.
Em Gerir Microsoft Entra ID, selecione Ver.
No painel de navegação, selecione Registos de aplicações.
Selecione Novo registo.
Na página Registar uma aplicação, em Tipos de conta suportados, selecione Contas em qualquer diretório organizacional (Qualquer diretório de Microsoft Entra - Multi-inquilino). Em seguida, em URI de Redirecionamento (opcional), selecione Web e, em seguida, escreva https://office.com. Em seguida, selecione Registar.

No canto superior direito da página, consulte a caixa de diálogo de notificação que indica que a aplicação foi criada com êxito.
Voltar à Home page, aceda a Microsoft Entra ID e, em seguida, selecione Registos de aplicações.
Em Aplicações próprias, localize a aplicação que criou e, em seguida, selecione-a.
Em Essentials, copie o ID da Aplicação (cliente). Irá precisar destas informações mais tarde para criar um URL para o inquilino de destino.
No painel de navegação, selecione Permissões da API para ver as permissões atribuídas à sua aplicação.
Por predefinição, as permissões User.Read são atribuídas à aplicação que criou, mas estas permissões não são necessárias para migrações de caixas de correio. Pode remover essas permissões.
Para adicionar permissão para a migração da caixa de correio, selecione Adicionar uma permissão.
Na janela Pedir permissões da API , selecione APIs que a minha organização utiliza, procure Office 365 Exchange Onlinee, em seguida, selecione-a.
Selecione Permissões da aplicação.
Em Selecionar permissões, expanda Caixa de Correio e selecione Caixa de Correio.Migração e, em seguida, selecione Adicionar permissões na parte inferior do ecrã.
Agora, selecione Certificados & segredos no painel de navegação da sua aplicação.
Em Segredos do cliente, selecione Novo segredo do cliente.
Na janela Adicionar um segredo do cliente , escreva uma descrição e, em seguida, configure as definições de expiração.

Nota

A palavra-passe é utilizada ao criar o ponto final de migração. É extremamente importante que copie esta palavra-passe para a área de transferência e/ou para uma localização segura de palavra-passe segura/secreta. A fase de criação de segredos é a única altura em que pode ver esta palavra-passe! Se, de alguma forma, o perder ou precisar de o repor, pode voltar a iniciar sessão no portal do Azure, aceder a Registos de aplicações, localizar a aplicação de migração, selecionar Segredos & certificados e, em seguida, criar um novo segredo para a sua aplicação.

Agora que criou com êxito a aplicação de migração e o segredo, o próximo passo é dar consentimento à aplicação.

Na página de destino Microsoft Entra ID, selecione Aplicações empresariais no painel de navegação; em seguida, localize a aplicação de migração que criou, selecione-a e, em seguida, selecione Permissões da API.
Selecione Conceder consentimento do administrador para [o seu inquilino]. É aberta uma nova janela do browser.
Selecione Aceitar.
Voltar à janela do portal e selecione Atualizar para confirmar a sua aceitação.
Formular o URL para enviar para o seu parceiro fidedigno (administrador inquilino de origem) para que também possa aceitar a aplicação para ativar a migração da caixa de correio.

Eis um exemplo do URL a fornecer:

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

Nota

Precisará do ID da aplicação de migração da caixa de correio que acabou de criar. Terá de substituir contoso.onmicrosoft.com no exemplo acima pelo nome de onmicrosoft.com correto do inquilino de origem. Também terá de substituir [application_id_of_the_app_you_just_created] pelo ID da aplicação de migração da caixa de correio que acabou de criar.

Preparar o inquilino de destino ao criar o ponto final de migração Exchange Online e a relação da organização

Ligue-se ao Exchange Online PowerShell no inquilino Exchange Online de destino.

Crie um novo ponto final de migração para movimentações de caixas de correio entre inquilinos.

Nota

Precisará do ID da aplicação de migração da caixa de correio que acabou de criar e da palavra-passe (segredo) que configurou em Preparar o inquilino de destino (destino) ao criar a aplicação de migração e o segredo. Consoante a instância da cloud do Microsoft 365 que utiliza, o ponto final pode ser diferente. Consulte a página pontos finais do Microsoft 365; selecione a instância correta para o seu inquilino; em seguida, reveja o Exchange Online o endereço Otimizar/Necessário e substitua conforme adequado.

$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

Crie um novo objeto de relação de organização ou edite o objeto de relação da organização existente para o inquilino de origem.

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

Prepare o inquilino de origem (localização da caixa de correio atual) ao aceitar a aplicação de migração e configurar a relação da organização

Com o browser, aceda à ligação de URL fornecida pelo seu parceiro fidedigno para dar consentimento à aplicação de migração da caixa de correio. O URL deve ter o seguinte aspeto:

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

Nota

Precisará do ID da aplicação de migração da caixa de correio que acabou de criar. Terá de substituir contoso.onmicrosoft.com no exemplo anterior pelo URL do inquilino de onmicrosoft.com origem. Também terá de substituir [application_id_of_the_app_you_just_created] pelo ID da aplicação de migração da caixa de correio que acabou de criar.
Aceite a aplicação quando o pop-up for apresentado. Também pode iniciar sessão no seu centro de administração Microsoft Entra e encontrar a aplicação em Aplicações empresariais.
Ligue-se ao Exchange Online PowerShell no inquilino de Exchange Online de origem.

Crie um novo objeto de relação de organização ou edite o objeto de relação da organização existente para o inquilino de destino (destino) no 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

O ID de inquilino que introduzir como $sourceTenantId e $targetTenantId é o GUID e não o nome de domínio do inquilino. Para obter um exemplo de um ID de inquilino e informações sobre como encontrar o seu ID de inquilino, consulte Localizar o seu ID de inquilino do Microsoft 365.

Preparar objetos de utilizador de destino para migração

Os utilizadores que migram têm de estar presentes no inquilino de destino e Exchange Online sistema (como um MailUser) marcado com atributos específicos para ativar as movimentações entre inquilinos. O sistema não irá mover os utilizadores que não estão corretamente configurados no inquilino de destino. A secção Pré-requisitos para objetos de utilizador de destino detalha os requisitos do objeto MailUser para o inquilino de destino.

Pré-requisitos para objetos de utilizador de destino

Certifique-se de que os seguintes objetos e atributos estão definidos na organização de destino:

Sugestão

A Microsoft está a desenvolver uma funcionalidade para fornecer um método automatizado seguro para definir muitos dos atributos (especificados abaixo, nesta secção). Esta funcionalidade, denominada Mapeamento de Identidade Entre Inquilinos, está atualmente à procura de clientes dispostos a participar numa pequena pré-visualização privada. Para obter mais informações sobre esta funcionalidade de pré-lançamento e como pode simplificar os processos de migração entre inquilinos, veja Mapeamento de Identidade Entre Inquilinos.

Para qualquer caixa de correio movida de uma organização de origem, tem de aprovisionar um objeto MailUser na organização De destino:

O MailUser de Destino tem de ter estes atributos da caixa de correio de origem ou atribuído com o novo objeto Utilizador:

ExchangeGUID (fluxo direto da origem para o destino): o GUID da caixa de correio tem de corresponder. O processo de movimentação não irá prosseguir se este atributo não estiver presente no objeto de destino.
ArchiveGUID (fluxo direto da origem para o destino): o GUID de arquivo tem de corresponder. O processo de movimentação não irá prosseguir se este atributo não estiver presente no objeto de destino. (Este atributo só é necessário se a caixa de correio de origem estiver ativada para Arquivo).
LegacyExchangeDN (fluxo como proxyAddress, "x500:<LegacyExchangeDN>"): o LegacyExchangeDN tem de estar presente no MailUser de destino como x500: proxyAddress. Além disso, também tem de copiar todos os endereços x500 da caixa de correio de origem para o utilizador de correio de destino. Os processos de movimentação não continuarão se estes endereços x500 não estiverem presentes no objeto de destino. Além disso, este passo é importante para permitir a capacidade de resposta para e-mails que são enviados antes da migração. O endereço do remetente/destinatário em cada item de e-mail e a cache de conclusão automática no Microsoft Outlook e no Microsoft Outlook Web App (OWA) utilizam o valor do atributo LegacyExchangeDN. Se não for possível localizar um utilizador com o valor LegacyExchangeDN, a entrega de mensagens de e-mail poderá falhar com um NDR 5.1.1.
UserPrincipalName: o UPN será alinhado com a nova identidade ou empresa de destino do utilizador (por exemplo, user@northwindtraders.onmicrosoft.com).
SMTPAddress Principal: o endereço SMTP principal será alinhado com a nova empresa do utilizador (por exemplo, user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: MailUser fará referência à caixa de correio atual do utilizador alojada no inquilino de origem (por exemplo user@contoso.onmicrosoft.com, ). Quando este valor estiver a ser atribuído, verifique se tem/também está a atribuir PrimarySMTPAddress; caso contrário, este valor definirá PrimarySMTPAddress, o que causará falhas de movimentação.

Não pode adicionar endereços proxy smtp legados da caixa de correio de origem ao MailUser de destino. Por exemplo, não pode manter contoso.com no MEU em objetos de inquilino northwindtraders.onmicrosoft.com. Os domínios estão associados apenas a um inquilino Microsoft Entra ID ou Exchange Online.

Objeto MailUser de destino de exemplo:

Atributo	Valor
Alias	LaraN
Tipode Destinatário	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
Endereços de Correio Eletrónico	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=Grupo Administrativo do Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Objeto caixa de correio de origem de exemplo:

Atributo	Valor
Alias	LaraN
Tipode Destinatário	Caixa de Correio do Utilizador
RecipientTypeDetails	Caixa de Correio do Utilizador
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
Endereços de Correio Eletrónico	smtp:LaraN@contoso.onmicrosoft.com
	SMTP:Lara.Newton@contoso.com
	X500:/o=ExchangeLabs/ou=Grupo Administrativo do Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Outros atributos podem já estar incluídos na repetição de escrita híbrida do Exchange. Caso contrário, devem ser incluídos.
1. msExchBlockedSendersHash– Escreve novamente dados de remetentes bloqueados online de clientes para Active Directory no local.
2. msExchSafeRecipientsHash– Escreve novamente dados de destinatários seguros online de clientes para Active Directory no local.
3. msExchSafeSendersHash– Escreve novamente dados de remetentes seguros online de clientes para Active Directory no local.
Os utilizadores na organização de destino têm de ter uma licença com subscrições adequadas Exchange Online aplicáveis à organização. Pode aplicar uma licença antes da movimentação de uma caixa de correio, mas apenas quando o MailUser de destino estiver configurado corretamente com o ExchangeGUID e endereços proxy. Aplicar uma licença antes de o ExchangeGUID ser aplicado resultará numa nova caixa de correio aprovisionada na organização de destino. Também tem de aplicar uma licença de Migração de Dados de Utilizador entre Inquilinos; caso contrário, poderá ver um erro transitório a ler precisa de aprovação, o que irá comunicar um aviso no relatório de movimentação de que não foi aplicada uma licença ao utilizador de destino.

Nota

Quando aplica uma licença num objeto Caixa de Correio ou MailUser, todos os proxyAddresses do tipo SMTP são limpos para garantir que apenas os domínios verificados estão incluídos na matriz Endereços de E-mail do Exchange.
Tem de garantir que o MailUser de destino não tem nenhum ExchangeGUID anterior que não corresponda ao ExchangeGUID de Origem. Este erro de correspondência poderá ocorrer se o MEU de destino tiver sido anteriormente licenciado para Exchange Online e tiver aprovisionado uma caixa de correio. Se o MailUser de destino estava anteriormente licenciado ou tinha um ExchangeGUID que não corresponde ao ExchangeGUID de Origem, tem de efetuar uma limpeza do MEU na nuvem. Para estas MEUs na cloud, pode executar Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Atenção

Este processo é irreversível. Se o objeto tiver uma caixa de correio softDeleted, não poderá ser restaurado após este ponto. No entanto, depois de desmarcado, pode sincronizar o ExchangeGUID correto com o objeto de destino e a MRS irá ligar a caixa de correio de origem à caixa de correio de destino recém-criada. (Blogue EHLO de referência sobre o novo parâmetro.)

Localize objetos que eram anteriormente caixas de correio com o seguinte comando:

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

Eis um exemplo:

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

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

Limpe a caixa de correio eliminada de forma recuperável com o seguinte comando:

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Eis um exemplo:

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

Como devo proceder para saber que isto funcionou?

Pode verificar a configuração da migração da caixa de correio entre inquilinos ao executar o cmdlet Test-MigrationServerAvailability no ponto final de migração entre inquilinos que criou no inquilino de destino. Execute o seguinte cmdlet a partir do inquilino de destino:

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

Nota

Além disso, poderá querer tirar partido do script de validação da migração da caixa de correio entre inquilinos, que lhe permitirá validar a configuração correta das organizações entre elas e os objetos que está a planear migrar de um inquilino para outro. O script ajudará a identificar quaisquer discrepâncias que possam estar presentes em todos os objetos ao mesmo tempo e, como resultado, reduzirá o tempo gasto na fase inicial.

Mover caixas de correio novamente para a origem original

Se for necessária uma caixa de correio para voltar ao inquilino de origem original, o mesmo conjunto de passos e scripts tem de ser executado nos novos inquilinos de origem e de destino novos, com alguma variância.

Não execute os scripts de exemplo fornecidos para criar a OrganizationRelationship.

Atualize os seguintes valores na OrganizationRelationship existente criada em cada inquilino:

MailboxMovesCapability deve ter Entrada, RemoteOutbound como as capacidades nos inquilinos de origem e de destino.
No novo inquilino de origem, atualize o valor OAuthApplicationId com o valor da aplicação recém-criada no novo inquilino de origem.
No novo inquilino de origem, atualize o valor MailboxMovePublishedScopes com o grupo de segurança recém-criado no novo inquilino de origem.

Efetuar migrações de caixas de correio

As migrações de caixas de correio do Exchange entre inquilinos são iniciadas a partir do inquilino de destino como lotes de migração. Este processo é semelhante à forma como os lotes de migração de integração funcionam ao migrar do Exchange no local para o Microsoft 365.

Criar lotes de Migração

Eis um comando de exemplo para iniciar uma migração em lote:

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

O endereço de e-mail no ficheiro CSV tem de ser o especificado no inquilino de destino (por exemplo, userA@northwindtraders.onmicrosoft.com), e não o do inquilino de origem. Para obter mais informações sobre o cmdlet, clique aqui Para obter alguns exemplos de informações de ficheiro CSV, clique aqui

Um exemplo mínimo de um ficheiro CSV é:

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

A submissão de lote de migração também é suportada a partir do novo centro de administração do Exchange ao selecionar a opção entre inquilinos.

Atualizar os MailUsers no local

Assim que a caixa de correio for movida de origem para destino, deve certificar-se de que os utilizadores de correio no local, tanto na origem como no destino, são atualizados com o novo targetAddress. Nos exemplos, o targetDeliveryDomain utilizado na movimentação é northwindtraders.onmicrosoft.com. Atualize os utilizadores de correio com este endereço de destino.

Remover pontos finais e relações organizacionais após a migração

Utilize o cmdlet Remove-MigrationEndpoint para remover pontos finais de migração existentes para servidores de origem ou de destino após a conclusão da migração.

Utilize o cmdlet Remove-OrganizationRelationship para remover relações organizacionais existentes para servidores de origem ou de destino após a conclusão da migração.

Perguntas mais frequentes

Preciso de atualizar o RemoteMailboxes no inquilino de origem no local após a movimentação?

Organização do Exchange de Origem

Deve atualizar o targetAddress (RemoteRoutingAddress/ExternalEmailAddress) de cada utilizador de origem no local quando a caixa de correio do inquilino de origem for movida para o inquilino de destino. Embora o encaminhamento de correio possa seguir as referências em vários utilizadores de correio com endereços de destino diferentes, as pesquisas De Disponibilidade para utilizadores de correio têm de visar a localização do utilizador da caixa de correio.

Organização do Exchange de Destino

Após a conclusão da migração numa organização híbrida, execute o seguinte comando do PowerShell se pretender que os seus utilizadores tenham caixas de correio remotas no local:

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

As reuniões do Teams migram entre inquilinos?

Enquanto as reuniões do Teams são movidas, o URL da reunião não é atualizado quando os itens migram entre inquilinos. Uma vez que o URL será inválido no inquilino de destino, tem de remover e recriar reuniões do Teams.

Que conteúdo é migrado entre inquilinos?

Quando uma caixa de correio é migrada entre inquilinos com esta funcionalidade, apenas os conteúdos visíveis pelo utilizador na caixa de correio, também conhecido como Top of Information Store (e-mail, contactos, calendário, tarefas e notas) e as pastas Itens Recuperáveis Eliminações, Versões e Remoção são migradas.

Os itens na Caixa de Saída são migrados entre inquilinos?

Os itens na Caixa de Saída não são migrados entre inquilinos, uma vez que esta pasta é uma pasta baseada no cliente específica do cliente do Outlook. Os itens na Caixa de Saída são armazenados localmente e não são sincronizados com a cloud.

O conteúdo da pasta de chat do Teams migra entre inquilinos?

Não, o conteúdo da pasta de chat do Teams não migra entre inquilinos. No entanto, assim que a caixa de correio tiver sido migrada entre inquilinos, o conteúdo da pasta de chat do Teams estará disponível para o administrador do inquilino de origem procurar e exportar, através de uma pesquisa de conteúdos.

Como posso ver apenas movimentos que são movimentações entre inquilinos, não os meus movimentos de inclusão e exclusão?

Utilize o parâmetro Sinalizadores :

Get-MoveRequest -Flags "CrossTenant"

Pode fornecer scripts de exemplo para copiar atributos utilizados nos testes?

Nota

EXEMPLO – TAL como ESTÁ, SEM GARANTIA Este script assume uma ligação à caixa de correio de origem (para obter valores de origem) e ao Active Directory no local Domain Services de destino (para carimbar o objeto 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

Como acedemos ao Outlook no dia 1 depois de a caixa de correio do utilizador ser movida?

Uma vez que apenas um inquilino pode ser proprietário de um domínio, o antigo SMTPAddress principal não será associado ao utilizador no inquilino de destino quando a movimentação da caixa de correio estiver concluída; apenas os domínios associados ao novo inquilino. O Outlook utiliza o novo UPN do utilizador para se autenticar no serviço e o perfil do Outlook espera encontrar o SMTPAddress principal legado para corresponder à caixa de correio no sistema de destino. Uma vez que o endereço legado não está no sistema de destino, o perfil do Outlook não se liga para localizar a caixa de correio recém-movida.

Para esta implementação inicial, os utilizadores terão de reconstruir o respetivo perfil com o seu novo UPN, endereço SMTP principal e ressincronizar conteúdo OST.

Nota

Planeie em conformidade à medida que cria um lote dos seus utilizadores para conclusão. Tem de ter em conta a utilização e a capacidade da rede quando os perfis de cliente do Outlook são criados e os ficheiros OST e OAB subsequentes são transferidos para os clientes.

De que funções RBAC do Exchange preciso de ser membro para configurar ou concluir uma movimentação entre inquilinos?

Existe uma matriz de funções baseada no pressuposto de deveres delegados ao executar uma movimentação de caixa de correio. Atualmente, são necessárias duas funções:

A primeira função destina-se a uma tarefa de configuração única que estabelece a autorização de mover conteúdo para dentro ou para fora do seu limite organizacional/inquilino. Uma vez que a transferência de dados para fora do controlo organizacional é uma preocupação fundamental para todas as empresas, optámos pela função mais elevada atribuída de Administrador da Organização. Esta função tem de alterar ou configurar uma nova OrganizationRelationship que defina a -MailboxMoveCapability definição com a organização remota. Apenas o administrador da organização pode alterar a -MailboxMoveCapability definição, enquanto outros atributos na OrganizationRelationship podem ser geridos pelo administrador da Partilha Federada.
A função de execução dos comandos de movimentação reais pode ser delegada a uma função de nível inferior. A função Mover Caixas de Correio é atribuída à capacidade de mover caixas de correio para dentro ou para fora da organização.

Como direcionamos o endereço SMTP selecionado para targetAddress (TargetDeliveryDomain) na caixa de correio convertida (para conversão do MailUser)?

A caixa de correio do Exchange é movida através de MRS para criar o targetAddress na caixa de correio de origem original ao converter para um MailUser ao corresponder um endereço de e-mail (proxyAddress) no objeto de destino. O processo utiliza o -TargetDeliveryDomain valor transmitido para o comando e, em seguida, verifica a existência de um proxy correspondente para esse domínio no lado do destino. Quando encontramos uma correspondência, o proxyAddress correspondente é utilizado para definir o objeto ExternalEmailAddress (targetAddress) na caixa de correio convertida (agora MailUser).

Como funciona o fluxo de correio após a migração?

O fluxo de correio entre inquilinos após a migração funciona de forma semelhante ao fluxo de correio híbrido do Exchange. Cada caixa de correio migrada precisa do MailUser de origem com o endereço de destino correto para reencaminhar correio recebido do inquilino de origem para caixas de correio no inquilino de destino. As regras de transporte, as funcionalidades de segurança e conformidade serão executadas conforme configurado em cada inquilino através do qual o correio flui. Assim, para o correio de entrada, as funcionalidades como antisspam, antimalware, quarentena, regras de transporte e regras de registo diário serão executadas primeiro no inquilino de origem e, em seguida, no inquilino de destino.

Como é que as permissões da caixa de correio fazem a transição?

As permissões da caixa de correio incluem Enviar em Nome de e Acesso à Caixa de Correio:

Enviar Em Nome de (AD:publicDelegates) armazena o DN dos destinatários com acesso à caixa de correio de um utilizador como delegado. Este valor é armazenado no Active Directory e atualmente não é movido como parte da transição da caixa de correio. Se a caixa de correio de origem tiver publicaDelegates definidos, terá de voltar a colocar os publicamenteDelegates na Caixa de Correio de destino assim que a conversão do MEU para a Caixa de Correio for concluída no ambiente de destino ao executar Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
Permissões de Caixa de Correio armazenadas na caixa de correio serão movidas com a caixa de correio quando o principal e o delegado forem movidos para o sistema de destino. Por exemplo, o utilizador TestUser7 recebe FullAccess à caixa de correio TestUser_8 no inquilino SourceCompany.onmicrosoft.com. Após a conclusão da caixa de correio para TargetCompany.onmicrosoft.com, as mesmas permissões são configuradas no diretório de destino. Os exemplos que utilizam _Get MailboxPermission para TestUser_7 nos inquilinos de origem e de destino são apresentados abaixo. Os cmdlets do Exchange têm o prefixo origem e o destino em conformidade.

Eis um exemplo da saída da permissão da caixa de correio antes de uma movimentação do lado da origem:

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

Eis um exemplo do resultado da permissão da caixa de correio após a movimentação do lado de destino:

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

As permissões de calendário e caixa de correio entre inquilinos não são suportadas. Tem de organizar principais e delegados em lotes de movimentação consolidados para que estas caixas de correio ligadas sejam transferidas ao mesmo tempo do inquilino de origem.

Que proxy X500 deve ser adicionado aos endereços proxy mailUser de destino para ativar a migração?

A migração da caixa de correio entre inquilinos requer que o valor LegacyExchangeDN do objeto da caixa de correio de origem seja carimbado como um endereço de e-mail x500 no objeto MailUser de destino.

Exemplo:

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

Além deste proxy X500, terá de copiar todos os proxies X500 da caixa de correio na origem para a caixa de correio no destino. Embora seja raro, também pode ser executado num endereço proxy X400 numa caixa de correio, embora não seja um requisito para que a movimentação seja concluída, recomenda-se que também carimba este endereço no objeto de utilizador de correio de destino.

Os inquilinos de origem e de destino podem utilizar o mesmo nome de domínio?

Não, os nomes de domínio do inquilino de origem e do inquilino de destino têm de ser exclusivos, por exemplo, um domínio de origem de contoso.com e o domínio de destino de northwindtraders.com.

As caixas de correio partilhadas serão movidas e continuarão a funcionar?

Sim. No entanto, só mantemos as permissões de arquivo conforme descrito neste artigo:

Gerir permissões para destinatários no Exchange Online

Tem alguma recomendação para lotes?

Não exceda 2000 caixas de correio por lote. Recomendamos vivamente a submissão de lotes duas semanas antes da data de transferência, uma vez que não há impacto nos utilizadores finais durante a sincronização. Se precisar de orientação para caixas de correio superiores a 50 000, pode contactar a sua CSAM ou abrir um pedido de suporte.

E se utilizar a Encriptação de serviço com a Chave de Cliente do Microsoft Purview?

A caixa de correio é desencriptada antes de ser movida. Certifique-se de que a Chave de Cliente está configurada no inquilino de destino, se ainda for necessário. Para obter mais informações, veja aqui.

Qual é o tempo estimado de migração?

Para o ajudar a planear a migração, a tabela aqui presente mostra as diretrizes sobre quando esperar que as migrações de caixas de correio em massa ou migrações individuais estejam concluídas. Estas estimativas baseiam-se numa análise de dados de migrações de clientes anteriores. Uma vez que cada ambiente é exclusivo, a velocidade exata da migração pode variar.

Proteger documentos no inquilino de origem consumível pelos utilizadores no inquilino de destino.**

A migração entre inquilinos só migra os dados da caixa de correio e nada mais. Existem várias outras opções, que estão documentadas na seguinte publicação de blogue que podem ajudar:

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

Posso ter as mesmas etiquetas no inquilino de destino que tinha no inquilino de origem, seja como o único conjunto de etiquetas ou um conjunto adicional de etiquetas para os utilizadores migrados, consoante o alinhamento entre as organizações.**

Uma vez que as migrações entre inquilinos não exportam etiquetas e não há forma de partilhar etiquetas entre inquilinos, só pode alcançar este objetivo recriando as etiquetas no inquilino de destino.

Suporta a movimentação de Grupos do Microsoft 365?

Atualmente, a funcionalidade de migrações de caixas de correio entre inquilinos não suporta a migração de Grupos do Microsoft 365.

Um administrador de inquilinos de origem pode efetuar uma pesquisa de Deteção de Dados Eletrónicos numa caixa de correio depois de a caixa de correio ter sido migrada para o inquilino novo/de destino?

Não, após a migração de uma caixa de correio entre inquilinos, a Deteção de Dados Eletrónicos na caixa de correio do utilizador migrado na origem não funciona. Esta falha de Deteção de Dados Eletrónicos deve-se ao facto de já não existir uma caixa de correio na origem para procurar, uma vez que a caixa de correio foi migrada para o inquilino de destino e agora pertence ao inquilino de destino. A Deteção de Dados Eletrónicos após a migração da caixa de correio só pode ser efetuada no inquilino de destino (onde a caixa de correio existe agora). Se uma cópia da caixa de correio de origem tiver de persistir no inquilino de origem após a migração, o administrador no inquilino de origem pode copiar os conteúdos para uma pré-migração de caixa de correio alternativa para futuras operações de Deteção de Dados Eletrónicos em relação aos dados.

Em que ponto o MailUser de destino será convertido numa caixa de correio de destino e a caixa de correio de origem será convertida num MailUser de origem?

Estas conversões ocorrem automaticamente durante o processo de migração. Não são necessários passos manuais.

Em que passo devo atribuir a licença de Exchange Online aos MailUsers de destino?

Esta atribuição de licença pode ser feita antes de a migração estar concluída, mas não deve atribuir uma licença antes de carimbar o atributo ExchangeGUID ; senão, a conversão do objeto MailUser na caixa de correio falhará e será criada uma nova caixa de correio. Para mitigar este risco, é melhor aguardar até que a migração esteja concluída e atribuir licenças durante o período de tolerância de 30 dias.

Posso utilizar o Microsoft Entra Ligar para sincronizar os utilizadores com o novo inquilino se estiver a manter o Active Directory no local?

Sim. É possível ter duas instâncias do Microsoft Entra Ligar sincronizar com inquilinos diferentes. No entanto, existem alguns aspetos que tem de ter em conta:

O pré-aprovisionamento das contas do utilizador com o script fornecido neste artigo não deve ser feito. Em vez disso, pode ser realizada uma sincronização seletiva da UO dos utilizadores no âmbito da migração para preencher o inquilino de destino. Receberá um aviso sobre o UPN não corresponder durante a configuração do Microsoft Entra Connect.
Consoante o estado atual do Exchange híbrido, tem de verificar se os objetos de diretório no local têm os atributos necessários (como msExchMailboxGUID e proxyAddresses) preenchidos corretamente antes de tentar sincronizar com outro inquilino; caso contrário, terá problemas com caixas de correio duplas e falhas de migração.
Tem de efetuar alguns passos adicionais para gerir a transição do UPN, alterando-o no local após a conclusão da migração para um utilizador, a menos que também esteja a mover o domínio personalizado durante uma migração de transferência.

Como devo lidar com caixas de correio próximas ou acima da quota.

As caixas de correio que se aproximam da quota antes da migração podem ficar acima da quota antes ou durante a migração real. Se isto acontecer, estas caixas de correio falharão a migração e terão de ser remediadas e reiniciadas. Para mitigar esta situação, recomenda-se que o administrador do inquilino de origem identifique as caixas de correio com ou perto da quota antes da migração e siga os passos necessários para reduzir o tamanho da caixa de correio, aprovisionar um arquivo primário ou, em alguns casos, ativar a expansão automática de arquivos para as caixas de correio do utilizador.

Nota

Depois de ativar um arquivo ou expandir automaticamente o arquivo para um utilizador, certifique-se de que as políticas de arquivo corretas são aplicadas ao utilizador e que o processo é executado para mover os dados da caixa de correio para a nova localização e libertar espaço.

As caixas de correio de arquivo expandidas automaticamente são movidas?

Problema: não é possível migrar arquivos expandidos automaticamente. Sim, se o utilizador na origem tiver arquivos de expansão automática ativados e tiver arquivos auxiliares adicionais, a migração da caixa de correio entre inquilinos funcionará. Suportamos a movimentação de utilizadores que não tenham mais de 12 caixas de correio de arquivo auxiliares. Além disso, os utilizadores com grandes arquivos principais, grandes e grandes caixas de correio de arquivo auxiliares exigirão tempo extra para sincronizar e devem ser submetidos bem antes da data de transferência. Se a caixa de correio de origem for expandida durante o processo de migração da caixa de correio, a migração falhará, uma vez que será criado um novo arquivo auxiliar na origem, mas não no destino. Neste caso, terá de remover o utilizador do lote e submetê-lo novamente.

Posso efetuar uma migração entre inquilinos na cloud para inquilinos?

A migração entre inquilinos para inquilinos não é suportada. Um cenário de exemplo seria passar do Office 365 Global para o Office 365 Administração Pública Cloud.

As mensagens de voz são migradas entre inquilinos?

Sim, os voicemails são migrados entre inquilinos.

Mensagens de voz recebidas por e-mail, uma vez que os anexos estão disponíveis na caixa de correio de destino.
As mensagens de voz recebidas estão disponíveis no Teams se ligar para o voicemail e ouvir mensagens guardadas. (As VMs recebidas na origem estão disponíveis como mensagens guardadas)
As mensagens de voz recebidas não estão disponíveis na IU do cliente do Teams no destino após a migração.
A saudação de voicemail também é migrada para o destino.

As assinaturas de caixa de correio são migradas entre inquilinos?

As assinaturas de caixa de correio não são migradas entre inquilinos e têm de ser recriadas.

Problemas conhecidos

A funcionalidade do Teams pós-migração no inquilino de origem será limitada. Depois de a caixa de correio ser migrada para o inquilino de destino, o Teams no inquilino de origem já não tem acesso à caixa de correio do utilizador. Se um utilizador iniciar sessão no Teams com a credencial de inquilino de origem, haverá uma perda de funcionalidade, como a incapacidade de atualizar a sua imagem de perfil, nenhuma aplicação de calendário e a incapacidade de procurar e aderir a equipas públicas.
Cloud MailUsers com movimentos MRS de bloco smtp proxyAddress não pertencentes. Ao criar objetos MailUser do inquilino de destino, tem de garantir que todos os endereços proxy SMTP pertencem à organização do inquilino de destino. Se existir um proxyAddress SMTP no utilizador de correio de destino que não pertence ao inquilino local, a conversão do MailUser numa caixa de correio é impedida. Esta prevenção deve-se à nossa garantia de que os objetos de caixa de correio só podem enviar correio de domínios para os quais o inquilino é autoritativo (domínios reclamados pelo inquilino).
Se sincronizar utilizadores no local com o Microsoft Entra Ligar no inquilino de destino, pode aprovisionar objetos mailUser no local com ExternalEmailAddress apontando para o inquilino de origem onde a caixa de correio existe (LaraN@contoso.onmicrosoft.com) e carimbar PrimarySMTPAddress como um domínio que reside no inquilino de destino (Lara.Newton@northwindtraders.com). Estes valores são sincronizados com o inquilino e um utilizador de correio adequado é aprovisionado e está pronto para migração. É apresentado um objeto de exemplo aqui.
```
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

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

O endereço contoso.onmicrosoft.comnão está presente na matriz EmailAddresses/proxyAddresses.
Os objetos MailUser com endereços SMTP primários "externos" são modificados/repostos para domínios "internos" reclamados pela empresa.

Os objetos mailUser são ponteiros para caixas de correio não locais. No caso das migrações de caixas de correio entre inquilinos, utilizamos objetos MailUser para representar a caixa de correio de origem (do ponto de vista da organização de destino) ou a caixa de correio de destino (do ponto de vista da organização de origem). Os MailUsers terão um ExternalEmailAddress (targetAddress) que aponta para o endereço smtp da caixa de correio real (ProxyTest@northwindtraders.onmicrosoft.com) e o endereço primarySMTP que representa o endereço SMTP apresentado do utilizador da caixa de correio no diretório. Algumas organizações optam por apresentar o endereço SMTP principal como um endereço SMTP externo, não como um endereço propriedade/verificado pelo inquilino local (por exemplo, como northwindtraders.com em vez de como contoso.com). No entanto, assim que um objeto de plano de serviço do Exchange for aplicado ao MailUser através de operações de licenciamento, o endereço SMTP principal é modificado para ser apresentado como um domínio verificado pela organização local (contoso.com). Existem duas razões potenciais:
Quando qualquer plano de serviço do Exchange é aplicado a um MailUser, o processo de Microsoft Entra ID começa a impor a limpeza de proxy para garantir que a organização local não consegue enviar correio, spoof ou correio de outro inquilino. Qualquer endereço SMTP num objeto de destinatário com estes planos de serviço será removido se o endereço não for verificado pela organização local. Como acontece no exemplo, o domínio northwindtraders.com não é verificado pelo inquilino contoso.onmicrosoft.com; por conseguinte, a limpeza remove esse domínio northwindtraders.com. Se quiser manter estes domínios externos no MailUser, antes ou depois da migração, tem de alterar os seus processos de migração para retirar licenças após a conclusão da movimentação ou antes da mudança para garantir que os utilizadores têm a imagem corporativa externa esperada aplicada. Terá de garantir que o objeto da caixa de correio está devidamente licenciado para não afetar o serviço de correio. É apresentado aqui um script de exemplo para remover os planos de serviço num MailUser no inquilino contoso.onmicrosoft.com.

Nota

O script seguinte utiliza o PowerShell do Microsoft Graph. Para obter mais informações, veja Microsoft Graph PowerShell overview (Descrição geral do PowerShell do Microsoft Graph).

Para obter informações sobre como utilizar métodos diferentes para autenticar Connect-Graph num script sem supervisão, consulte o artigo Cmdlets do módulo de autenticação no 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

Os resultados no conjunto de ServicePlans atribuídos são apresentados aqui:

$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

O PrimarySMTPAddress do utilizador já não está limpo. O domínio northwindtraders.com não pertence ao inquilino contoso.onmicrosoft.com e irá persistir como o endereço SMTP principal mostrado no diretório.

Eis um exemplo:

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 está definido como 8 (DeprovisionMailbox), para os MailUsers no local que são migrados para o inquilino de destino, a lógica de limpeza de proxy no Azure remove os domínios não pertencentes e repõe o primarySMTP para um domínio propriedade. Com o msExchRemoteRecipientType no MailUser no local a ser limpo, a lógica de limpeza de proxy já não se aplica.

Segue-se o conjunto completo de planos de serviço atuais que incluem Exchange Online:

Name
Armazenamento de Deteção de Dados Eletrónicos (Premium) (500 GB)
Sistema de Proteção de Dados do Cliente
Prevenção de Perda de Dados
Exchange Enterprise CAL Services (EOP, DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (Plano 1)
Exchange Online (Plano 2)
Arquivo de Exchange Online para Exchange Online
Arquivo de Exchange Online para Exchange Server
Exchange Online Suplemento de Utilizador Inativo
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online Plano 1
Acesso POP ao Exchange Online
Proteção do Exchange Online
Pesquisa de Conectores de Gráficos com Índice
Barreiras de informação
Information Protection para Office 365 – Premium
Information Protection para Office 365 - Standard
Insights by MyAnalytics
Governação de Informações da Microsoft
Auditoria do Microsoft Purview (Premium)
Microsoft Bookings
Centro de Empresas da Microsoft
Investigações de Dados da Microsoft
Microsoft MyAnalytics (Completo)
Conformidade de Comunicações da Microsoft
Microsoft Communications DLP
Chave de Cliente Microsoft
Auditoria Avançada do Microsoft 365
Gestão de Registos Microsoft
Office 365 Deteção de Dados Eletrónicos (Premium)
Deteção de Dados Eletrónicos Avançada do Office 365
Microsoft Defender para o Office 365 (Plano 1)
Microsoft Defender para Office 365 (Plano 2)
Office 365 Privileged Access Management
Encriptação Premium no Office 365

Falhas de Migração

MailboxNotInCrossTenantMigrationScopeException

Confirme que o âmbito de migração está configurado corretamente no inquilino de origem e que MailboxMovesPublishedScopes está definido na relação da organização com o inquilino de destino.
Verifique se a caixa de correio a migrar foi adicionada ao grupo de segurança no inquilino de origem.
Depois de adicionar o utilizador para corrigir o grupo de segurança, retome o lote de migração.
AuxArchiveNotFoundInTargetRecipientException

Esta falha deve-se ao facto de o utilizador não estar no âmbito da migração quando o batch foi iniciado e o utilizador ter o AuxArchive na origem.
Adicione o utilizador ao grupo de segurança correto no destino de origem.
Remova o utilizador de migração do lote.
Remova os utilizadores com o seguinte comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Adicionar utilizador ao novo lote.
MailboxIsNotInExpectedDBException

Esta falha deve-se à manutenção interna da Microsoft.
Remova o utilizador de migração do lote.
Remova os utilizadores com o seguinte comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Adicionar utilizador ao novo lote.
NotAcceptedDomainException

Existe um endereço proxy inválido carimbado no utilizador de destino. Um exemplo seria quando um utilizador no contoso.onmicrosoft.com tinha um endereço proxy de fabrikam.onmicrosoft.com, que é o inquilino de origem.
Remova o endereço proxy inválido com o seguinte comando:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
```
Retomar o lote de migração.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

Foi aprovisionado um novo AuxArchive durante a migração.
Remova o utilizador de migração do lote.
Remova os utilizadores com o seguinte comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser 
```
Adicionar utilizador ao novo lote.
UserDuplicateInOtherBatchException

O utilizador já existe noutro lote.
Remova o utilizador de migração do lote.
Remova os utilizadores com o seguinte comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Adicionar utilizador ao novo lote.
MissingExchangeGuidException

O objeto mailuser de destino não tem o valor exchangeGuid correto.
Atualize o ExchangeGuid com o seguinte comando:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8  
```
Retomar lote de migração.
SourceMailboxAlreadyBeingMovedPermanentException

A caixa de correio de origem já tem um pedido de movimentação existente. Investigue e remova a movimentação existente. É possível que se trata de uma movimentação interna da Microsoft e terá de aguardar pela conclusão da mudança.
Remova o utilizador de migração do lote.
Remova os utilizadores com o seguinte comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Adicione o utilizador ao novo lote depois de a movimentação original ter sido removida ou concluída.
UserAlreadyHasDemotedArchiveException

O utilizador tinha uma caixa de correio de arquivo que estava desativada anteriormente. Escolha uma das duas opções seguintes para resolver este problema.
Elimine permanentemente a caixa de correio de arquivo desativada, o que é irreversível. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Volte a ativar a caixa de correio de arquivo desativada com o seguinte comando:
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
Se reativar a caixa de correio de arquivo desativada, terá de atualizar o guid de arquivo no objeto mailuser de destino.
Retomar lote de migração.

Consulte também

Gerir o Microsoft 365 com o PowerShell
Introdução ao SDK do PowerShell do Microsoft Graph
[https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]

Partilhar via

Migração de caixas de correio entre inquilinos

Licenciamento

Preparar inquilinos de origem e de destino

Pré-requisitos para inquilinos de origem e de destino

Passos de configuração para ativar os inquilinos para migrações de caixas de correio entre inquilinos

Preparar o inquilino de destino (destino) ao criar a aplicação de migração e o segredo

Conceder consentimento à aplicação

Preparar o inquilino de destino ao criar o ponto final de migração Exchange Online e a relação da organização

Prepare o inquilino de origem (localização da caixa de correio atual) ao aceitar a aplicação de migração e configurar a relação da organização

Preparar objetos de utilizador de destino para migração

Pré-requisitos para objetos de utilizador de destino

Como devo proceder para saber que isto funcionou?

Mover caixas de correio novamente para a origem original

Efetuar migrações de caixas de correio

Criar lotes de Migração

Atualizar os MailUsers no local

Remover pontos finais e relações organizacionais após a migração

Perguntas mais frequentes

Preciso de atualizar o RemoteMailboxes no inquilino de origem no local após a movimentação?

Organização do Exchange de Origem

Organização do Exchange de Destino

As reuniões do Teams migram entre inquilinos?

Que conteúdo é migrado entre inquilinos?

Os itens na Caixa de Saída são migrados entre inquilinos?

O conteúdo da pasta de chat do Teams migra entre inquilinos?

Como posso ver apenas movimentos que são movimentações entre inquilinos, não os meus movimentos de inclusão e exclusão?

Pode fornecer scripts de exemplo para copiar atributos utilizados nos testes?

Como acedemos ao Outlook no dia 1 depois de a caixa de correio do utilizador ser movida?

De que funções RBAC do Exchange preciso de ser membro para configurar ou concluir uma movimentação entre inquilinos?

Como direcionamos o endereço SMTP selecionado para targetAddress (TargetDeliveryDomain) na caixa de correio convertida (para conversão do MailUser)?

Como funciona o fluxo de correio após a migração?

Como é que as permissões da caixa de correio fazem a transição?

Que proxy X500 deve ser adicionado aos endereços proxy mailUser de destino para ativar a migração?

Os inquilinos de origem e de destino podem utilizar o mesmo nome de domínio?

As caixas de correio partilhadas serão movidas e continuarão a funcionar?

Tem alguma recomendação para lotes?

E se utilizar a Encriptação de serviço com a Chave de Cliente do Microsoft Purview?

Qual é o tempo estimado de migração?

Proteger documentos no inquilino de origem consumível pelos utilizadores no inquilino de destino.**

Posso ter as mesmas etiquetas no inquilino de destino que tinha no inquilino de origem, seja como o único conjunto de etiquetas ou um conjunto adicional de etiquetas para os utilizadores migrados, consoante o alinhamento entre as organizações.**

Suporta a movimentação de Grupos do Microsoft 365?

Um administrador de inquilinos de origem pode efetuar uma pesquisa de Deteção de Dados Eletrónicos numa caixa de correio depois de a caixa de correio ter sido migrada para o inquilino novo/de destino?

Em que ponto o MailUser de destino será convertido numa caixa de correio de destino e a caixa de correio de origem será convertida num MailUser de origem?

Em que passo devo atribuir a licença de Exchange Online aos MailUsers de destino?

Posso utilizar o Microsoft Entra Ligar para sincronizar os utilizadores com o novo inquilino se estiver a manter o Active Directory no local?

Como devo lidar com caixas de correio próximas ou acima da quota.

As caixas de correio de arquivo expandidas automaticamente são movidas?

Posso efetuar uma migração entre inquilinos na cloud para inquilinos?

As mensagens de voz são migradas entre inquilinos?

As assinaturas de caixa de correio são migradas entre inquilinos?

Problemas conhecidos

Falhas de Migração

Consulte também

Comentários

Recursos adicionais