Migração de caixa de correio entre locatários
Durante fusões ou alienações, poderá precisar da capacidade de mover as caixas de correio do 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 bem conhecidas, como o Exchange Online PowerShell e a 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 sistema exchange Online do inquilino de destino 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 inquilinos de origem e destino para os movimentos de conteúdo da caixa de correio do 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 do Utilizador Entre Inquilinos está disponível como um suplemento para os seguintes planos de subscrição do Microsoft 365 para clientes do 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 a migração do OneDrive para Empresas. 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 o Microsoft 365 Empresas Básico, Standard e Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; e o 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, pelo menos um grupo de segurança habilitado para email no locatário de origem é necessário. 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://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. 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 do 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
Observação
Você deve configurar o destino primeiro. Para concluir estes passos, não é necessário ter ou conhecer as credenciais de administrador inquilino para o inquilino de origem e de destino. As etapas podem ser executadas individualmente para cada locatário por administradores diferentes.
Preparar o locatário de destino criando o aplicativo de migração e o segredo
Inicie sessão no centro de administração do Microsoft Entra (https://portal.azure.com) com as suas credenciais de administrador inquilino de destino.
Em Gerir o ID do Microsoft Entra, selecione Ver.
No painel de navegação, selecione Registos de aplicações.
Selecione Novo registro.
Na página Registar uma aplicação , em Tipos de conta suportados, selecione Contas em qualquer diretório organizacional (Qualquer diretório do 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.
Volte à 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 migração de 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 de aplicativos.
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.
Observação
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.
Conceder consentimento à aplicação
Na página de destino do 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.
Volte à 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.comObservação
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.
Prepare o locatário de destino criando o ponto de extremidade de migração do Exchange Online e a relação de organização
Ligue-se ao PowerShell do Exchange Online no inquilino do Exchange Online de destino.
Crie um novo ponto final de migração para movimentações de caixas de correio entre inquilinos.
Observação
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 endereço Otimizar/Necessário do Exchange Online e substitua conforme adequado.
# 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 $AppIdCrie 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]" $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 }
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.comObservação
Precisará do ID da aplicação de migração da caixa de correio que acabou de criar. Terá de substituir
contoso.onmicrosoft.comno exemplo anterior pelo URL do inquilino deonmicrosoft.comorigem. 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 do Microsoft Entra e encontrar a aplicação em Aplicações empresariais.
Ligue-se ao PowerShell do Exchange Online no inquilino do 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 PowerShell do Exchange Online:
# 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 }Observação
A ID de locatário que você insere como $sourceTenantId e $targetTenantId é o GUID e não o nome de domínio do locatário. Para obter um exemplo de uma ID de locatário e informações sobre como localizar sua ID de locatário, consulte Como encontrar sua ID de locatário 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 no sistema Exchange Online (como um MailUser) marcados 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:
Dica
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 do Microsoft Entra ID ou do Exchange Online.
Objeto MailUser de destino de exemplo:
Atributo Valor 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 EndereçosEmail 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 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 EndereçosEmail 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.
msExchBlockedSendersHash– Escreve novamente dados de remetentes bloqueados online de clientes para o Active Directory no local.msExchSafeRecipientsHash– Escreve novamente dados de destinatários seguros online de clientes para o Active Directory no local.msExchSafeSendersHash– Escreve novamente dados de remetentes seguros online de clientes para o Active Directory no local.
Os usuários na organização de destino devem ser licenciados com as assinaturas do Exchange Online apropriadas 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.
Observação
Ao aplicar uma licença em um objeto Mailbox ou MailUser, todos os proxyAddresses do tipo SMTP são limpos para garantir que apenas domínios verificados sejam incluídos na matriz EmailAddresses 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 o 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.
Cuidado
Esse processo é irreversível. Se o objeto tiver uma caixa de correio softDeleted, ele não poderá ser restaurado após esse 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
Veja 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
Veja 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 saber se 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]"
Observação
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
Observação
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 aquiPara 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 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?
Observação
EXEMPLO – TAL como ESTÁ, SEM GARANTIA Este script assume uma ligação para a caixa de correio de origem (para obter valores de origem) e para os Serviços de Domínio do Active Directory no local 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.
Observação
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
-MailboxMoveCapabilitydefinição com a organização remota. Apenas o administrador da organização pode alterar a-MailboxMoveCapabilitydefiniçã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
Observação
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
Observação
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:
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 com mais de 50 000, pode contactar o seu 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:
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 do 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 Connect 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 Connect sincronizadas 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.
Observação
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 a Cloud do Office 365 Para a Administração Pública.
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 Connect 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}Observação
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 do 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.
Observação
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.
Veja 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 o Exchange Online:
| Nome |
|---|
| Armazenamento de Deteção de Dados Eletrónicos (Premium) (500 GB) |
| Sistema de Proteção de Dados do Cliente |
| Prevenção contra Perda de Dados |
| Exchange Enterprise CAL Services (EOP, DLP) |
| Exchange Essentials |
| Exchange Foundation |
| Exchange Online (P1) |
| Exchange Online (Plano 1) |
| Exchange Online (Plano 2) |
| Arquivamento do Exchange Online para Exchange Online |
| Arquivamento do Exchange Online para Exchange Server |
| Suplemento de Utilizador Inativo do Exchange Online |
| Quiosque do Exchange Online |
| Exchange Online Multi-Geo |
| Exchange Online Plano 1 |
| Exchange Online POP |
| Proteção do Exchange Online |
| Pesquisa de Conectores de Gráficos com Índice |
| Barreiras de informações |
| Proteção de Informações para o Office 365 – Premium |
| Proteção de informações para o Office 365 – Padrão |
| Insights by MyAnalytics |
| Governança 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 |
| Deteção de Dados Eletrónicos do Office 365 (Premium) |
| Descoberta Eletrônica Avançada do Office 365 |
| Microsoft Defender para Office 365 (Plano 1) |
| Microsoft Defender para Office 365 (Plano 2) |
| Privileged Access Management para Office 365 |
| 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-MigrationUserAdicionar 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-MigrationUserAdicionar 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-MigrationUserAdicionar 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-MigrationUserAdicionar 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-b355b6b852c8Retomar 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-MigrationUserAdicione 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.
Confira também
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de