Migração de caixa de correio entre locatários
Durante fusões ou desinvestimentos, talvez seja necessário mover as caixas de correio Exchange Online dos usuários para um novo locatário. A migração de caixa de correio entre locatários permite que os administradores de locatários usem interfaces conhecidas como Exchange Online PowerShell e MRS para fazer a transição de usuários para sua nova organização.
Os administradores podem usar o cmdlet New-MigrationBatch , disponível por meio da função de gerenciamento Mover Caixas de Correio , para executar movimentos entre locatários.
Os usuários que migram devem estar presentes no sistema de Exchange Online de locatário de destino como um MailUser, marcado com atributos específicos para habilitar os movimentos entre locatários. O sistema falha ao mover usuários que não estão configurados corretamente no locatário de destino.
Depois que os movimentos são concluídos, a caixa de correio do usuário de origem é convertida em um MailUsere o targetAddress (mostrado como ExternalEmailAddress no Exchange) é carimbado com o endereço de roteamento para o locatário de destino. Esse processo deixa o legado MailUser no locatário de origem e permite coexistência e roteamento de email. Quando os processos empresariais permitem, o locatário de origem pode remover o MailUser de origem ou convertê-los em um contato de email.
Há suporte para migrações entre locatários da caixa de correio exchange para locatários somente em nuvem ou híbrida, ou uma combinação dos dois.
Este artigo descreve o processo para movimentações de caixa de correio entre locatários e fornece diretrizes sobre como preparar locatários de origem e destino para os movimentos de conteúdo da caixa de correio Exchange Online.
Importante
As caixas de correio que estão em qualquer tipo de espera não são migradas e a movimentação para essas caixas de correio está bloqueada.
Quando uma caixa de correio é migrada entre locatários com esse recurso, somente o conteúdo visível do usuário na caixa de correio (email, contatos, calendário, tarefas e anotações) é migrado para o destino (locatário de destino). Após uma migração bem-sucedida, a caixa de correio de origem é excluída. Essa exclusão significa que, após a migração, em nenhuma circunstância a caixa de correio de origem está disponível, detectável ou acessível no locatário de origem.
Licenciamento
Importante
A partir de novembro de 2022, a migração de dados do usuário entre locatários está disponível como um complemento aos seguintes planos de assinatura do Microsoft 365 para clientes Enterprise Agreement e é necessária para migrações entre locatários. As licenças de usuário são por migração (taxa única) e podem ser atribuídas no objeto de usuário de origem ou de destino. Essa licença também abrange OneDrive for Business migração. Entre em contato com sua equipe de conta da Microsoft para obter detalhes.
O complemento migração de dados do usuário entre locatários está disponível como uma compra separada para Microsoft 365 Business Basic, Standard e Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; e OneDrive for Business.
Aviso
Você deve ter comprado ou verificado que pode comprar licenças de migração de dados de usuário entre locatários antes das próximas etapas. As migrações falharão se essa etapa não tiver sido concluída. A Microsoft não oferece exceções para esse requisito de licenciamento.
Se você não tiver a licença adequada atribuída ao usuário que está sendo migrado, a migração falhará e você 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.
Preparando locatários de origem e destino
Pré-requisitos para locatários de origem e destino
Antes de iniciar, verifique se você tem as permissões necessárias para configurar o aplicativo Mover Caixa de Correio no Azure, ponto de extremidade de migração exo e a relação de organização exo.
Além disso, pelo menos um grupo de segurança habilitado para email no locatário de origem é necessário. Esses grupos são usados para escopo da lista de caixas de correio que podem passar do locatário de origem (ou às vezes chamado de recurso) para o locatário de destino. Esse escopo permite que o administrador do locatário de origem restrinja ou escopo o conjunto específico de caixas de correio que precisam ser movidas, impedindo que usuários não intencionais sejam migrados.
Se você estiver migrando mais de 10.000 usuários, recomendamos criar vários grupos para conter a lista de usuários para obter o melhor desempenho. Embora haja suporte para grupos aninhados, eles não são recomendados.
Você também precisa se comunicar com sua empresa parceira confiável (com quem você vai mover caixas de correio) para obter sua ID de locatário do Microsoft 365. Essa ID de locatário é usada no campo DomainName da Relação de Organização .
Para obter a ID do locatário de uma assinatura, entre no Centro de administração do Microsoft 365 e vá para https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. Selecione o ícone de cópia da propriedade ID do Locatário para copiá-la na área de transferência.
Todos os usuários das organizações de origem e de destino devem ser licenciados com as assinaturas de Exchange Online apropriadas. Além disso, verifique se você aplica licenças de migração de dados de usuário entre locatários a todos os usuários que serão migrados para o lado de destino.
Etapas de configuração para habilitar seus locatários para migrações de caixa de correio entre locatários
Observação
Você deve configurar o destino primeiro. Para concluir essas etapas, você não precisa ter ou conhecer as credenciais de administrador de locatário para o locatário 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
Entre em seu centro de administração do Microsoft Entra (https://portal.azure.com) com suas credenciais de administrador de locatário de destino.
Em Gerenciar Microsoft Entra ID, selecione Exibir.
No painel de navegação, selecione Registros de aplicativo.
Selecione Novo registro.
Na página Registrar um aplicativo, em Tipos de conta com suporte, selecione Contas em qualquer diretório organizacional (Qualquer diretório Microsoft Entra – Multilocatário). Em seguida, em URI de redirecionamento (opcional), selecione Web e digite
https://office.com. Em seguida, selecione Registrar.
No canto superior direito da página, confira a caixa de diálogo de notificação que afirma que o aplicativo foi criado com êxito.
Voltar para a Página Inicial, vá para Microsoft Entra ID e selecione Registros de aplicativo.
Em Aplicativos de propriedade, localize o aplicativo que você criou e selecione-o.
Em Essentials, copie a ID do Aplicativo (cliente). Você precisará dessas informações mais tarde para criar uma URL para o locatário de destino.
No painel de navegação, selecione permissões de API para exibir permissões atribuídas ao seu aplicativo.
Por padrão, as permissões User.Read são atribuídas ao aplicativo que você criou, mas essas permissões não são necessárias para migrações de caixa de correio. Você pode remover essas permissões.
Para adicionar permissão para migração de caixa de correio, selecione Adicionar uma permissão.
Na janela Solicitar permissões de API , selecione APIs que minha organização usa, pesquise
Office 365 Exchange Onlinee selecione-a.
Selecione Permissões de aplicativos.
Em Selecionar permissões, expanda Caixa de Correio e selecione Caixa de Correio.Migração e selecione Adicionar permissões na parte inferior da tela.
Agora selecione Certificados & segredos no painel de navegação do seu aplicativo.
Em Segredos do cliente, selecione Novo segredo do cliente.
Na janela Adicionar um segredo do cliente , digite uma descrição e configure as configurações de expiração.
Observação
A senha é usada ao criar o ponto de extremidade de migração. É extremamente importante que você copie essa senha para sua área de transferência e/ou para um local seguro/secreto de segurança de senha. O estágio de criação de segredo é a única hora durante a qual você pode ver essa senha! Se você de alguma forma perdê-lo ou precisar redefini-lo, você pode entrar novamente no portal do Azure, ir para Registros de aplicativo, encontrar seu aplicativo de migração, selecionar Segredos & certificados e criar um novo segredo para seu aplicativo.
Agora que você criou com êxito o aplicativo de migração e o segredo, a próxima etapa é consentir com o aplicativo.
Conceder consentimento ao aplicativo
Na página de destino Microsoft Entra ID, selecione Aplicativos Enterprise no painel de navegação; em seguida, localize o aplicativo de migração que você criou, selecione-o e selecione Permissões de API.
Selecione Conceder consentimento de administrador para [seu locatário]. Uma nova janela do navegador é aberta.
Selecione Aceitar.
Voltar à janela do portal e selecione Atualizar para confirmar sua aceitação.
Formular a URL para enviar ao seu parceiro confiável (administrador de locatário de origem) para que eles também possam aceitar o aplicativo para habilitar a migração de caixa de correio.
Aqui está um exemplo da URL a ser fornecida a eles:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comObservação
Você precisará da ID do aplicativo de migração da caixa de correio que acabou de criar. Você precisará substituir contoso.onmicrosoft.com no exemplo acima pelo nome de onmicrosoft.com correto do locatário de origem. Você também precisará substituir [application_id_of_the_app_you_just_created] pela ID do aplicativo de migração de caixa de correio que você 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
Conecte-se ao Exchange Online PowerShell no locatário de Exchange Online de destino.
Crie um novo ponto de extremidade de migração para movimentos de caixa de correio entre locatários.
Observação
Você precisará da ID do aplicativo de migração de caixa de correio que acabou de criar e a senha (segredo) configurada em Preparar o locatário de destino (destino) criando o aplicativo de migração e o segredo. Dependendo da instância de nuvem do Microsoft 365 que você usa, o ponto de extremidade pode ser diferente. Consulte a página pontos de extremidade do Microsoft 365; selecione a instância correta para seu locatário; em seguida, examine o Exchange Online Otimizar/Endereço Necessário e substitua conforme apropriado.
# 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 seu objeto de relação de organização existente para o locatário 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 }
Preparar o locatário de origem (local atual da caixa de correio) aceitando o aplicativo de migração e configurando a relação de organização
Usando seu navegador, acesse o link de URL fornecido pelo seu parceiro confiável para consentir com o aplicativo de migração de caixa de correio. A URL deve ser assim:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comObservação
Você precisará da ID do aplicativo de migração da caixa de correio que acabou de criar. Você precisará substituir
contoso.onmicrosoft.comno exemplo anterior pela URL do locatário deonmicrosoft.comorigem. Você também precisará substituir [application_id_of_the_app_you_just_created] pela ID do aplicativo de migração de caixa de correio que você acabou de criar.Aceite o aplicativo quando o pop-up for exibido. Você também pode entrar no centro de administração do Microsoft Entra e localizar o aplicativo em aplicativos Enterprise.
Conecte-se ao Exchange Online PowerShell no locatário de Exchange Online de origem.
Crie um novo objeto de relação de organização ou edite seu objeto de relação de organização existente para o locatário de destino (destino) no Exchange Online PowerShell:
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]" $appId="[application id of the mailbox migration app you consented to]" $scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]" New-DistributionGroup -Type Security -Name $scope $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope } If ($null -eq $existingOrgRel) { New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope }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 usuário de destino para migração
Os usuários que migram devem estar presentes no locatário de destino e no sistema de Exchange Online (como um MailUser) marcado com atributos específicos para habilitar os movimentos entre locatários. O sistema falhará em mover usuários que não estão configurados corretamente no locatário de destino. A seção Pré-requisitos para objetos de usuário de destino detalha os requisitos de objeto MailUser para o locatário de destino.
Pré-requisitos para objetos de usuário de destino
Verifique se os seguintes objetos e atributos estão definidos na organização de destino:
Dica
A Microsoft está desenvolvendo um recurso para fornecer um método automatizado seguro para definir muitos dos atributos (especificados abaixo, nesta seção). Esse recurso, chamado mapeamento de identidade entre locatários, está atualmente procurando clientes dispostos a participar de uma pequena visualização privada. Para obter mais informações sobre esse recurso de pré-lançamento e como ele pode simplificar seus processos de migração entre locatários, consulte Mapeamento de identidade entre locatários.
Para qualquer caixa de correio que se mova de uma organização de origem, você deve provisionar um objeto MailUser na organização Target:
O MailUser de destino deve ter esses atributos da caixa de correio de origem ou atribuídos com o novo objeto User:
ExchangeGUID (fluxo direto de origem para destino): o GUID da caixa de correio deve corresponder. O processo de movimentação não continuará se esse atributo não estiver presente no objeto de destino.
ArchiveGUID (fluxo direto de origem para destino): o GUID de arquivo deve corresponder. O processo de movimentação não continuará se esse atributo não estiver presente no objeto de destino. (Esse atributo só será necessário se a caixa de correio de origem estiver habilitada para Arquivo).
LegacyExchangeDN (fluxo como proxyAddress, "x500:<LegacyExchangeDN>"): o LegacyExchangeDN deve estar presente no MailUser de destino como x500: proxyAddress. Além disso, você também precisa copiar todos os endereços x500 da caixa de correio de origem para o usuário de email de destino. Os processos de movimentação não continuarão se esses endereços x500 não estiverem presentes no objeto de destino. Além disso, essa etapa é importante para habilitar a capacidade de resposta para emails enviados antes da migração. O endereço remetente/destinatário em cada item de email e o cache concluído automaticamente no Microsoft Outlook e em Microsoft Outlook Web App (OWA) usam o valor do atributo LegacyExchangeDN. Se um usuário não puder ser localizado usando o valor LegacyExchangeDN, a entrega de mensagens de email poderá falhar com um NDR 5.1.1.
UserPrincipalName: o UPN se alinhará à nova identidade do usuário ou à empresa de destino (por exemplo, user@northwindtraders.onmicrosoft.com).
SMTPAddress primário: o endereço SMTP primário se alinhará à nova empresa do usuário (por exemplo, user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: o MailUser fará referência à caixa de correio atual do usuário hospedada no locatário de origem (por exemplo user@contoso.onmicrosoft.com). Quando esse valor estiver sendo atribuído, verifique se você tem/também está atribuindo PrimarySMTPAddress; caso contrário, esse valor definirá o PrimarySMTPAddress, que causará falhas de movimentação.
Você não pode adicionar endereços proxy smtp herdados da caixa de correio de origem para o MailUser de destino. Por exemplo, você não pode manter contoso.com no MEU em objetos de locatário northwindtraders.onmicrosoft.com. Os domínios estão associados apenas a um locatário Microsoft Entra ID ou Exchange Online.
Exemplo de objeto MailUser de destino:
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=74e5385fce4b46d1900687694985035-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=Destinatários/cn=f161af74128f460fba5c0c23984b3d6c-Lara Exemplo de objeto caixa de correio de origem :
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=Destinatários/cn=f161af74128f460fba5c0c23984b3d6c-Lara
Outros atributos já podem ser incluídos no write-back híbrido do Exchange. Se não, eles devem ser incluídos.
msExchBlockedSendersHash– Grava de volta os dados do remetente bloqueados online de clientes para Active Directory local.msExchSafeRecipientsHash– Grava dados de destinatários seguros on-line de clientes para Active Directory local.msExchSafeSendersHash– Grava dados de remetente seguro on-line de clientes para Active Directory local.
Os usuários na organização de destino devem ser licenciados com as assinaturas do Exchange Online apropriadas aplicáveis à organização. Você pode aplicar uma licença antes de uma movimentação de caixa de correio, mas SOMENTE depois que o MailUser de destino for configurado corretamente com endereços ExchangeGUID e proxy. A aplicação de uma licença antes da aplicação do ExchangeGUID resultará em uma nova caixa de correio provisionada na organização de destino. Você também deve aplicar uma licença de Migração de Dados do Usuário entre Locatários; caso contrário, você pode ver que uma leitura de erro transitória precisa de aprovação, que relatará um aviso no relatório de movimentação de que uma licença não foi aplicada ao usuário 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.
Você deve garantir que o MailUser de destino não tenha nenhum ExchangeGUID anterior que não corresponda ao ExchangeGUID de origem. Essa incompatibilidade poderá ocorrer se o MEU de destino tiver sido licenciado anteriormente para Exchange Online e provisionado uma caixa de correio. Se o MailUser de destino tiver sido licenciado anteriormente ou tiver um ExchangeGUID que não corresponda ao ExchangeGUID de origem, você precisará executar uma limpeza da nuvem MEU. Para esses MEUs de nuvem, você 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. Uma vez desmarcada, no entanto, você pode sincronizar o ExchangeGUID correto com o objeto de destino e a MRS conectará a caixa de correio de origem à caixa de correio de destino recém-criada. (Blog EHLO de referência no novo parâmetro.)
Localize objetos que eram caixas de correio anteriormente usando 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
Desmarque a caixa de correio excluída com exclusão suave usando 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?
Você pode verificar a configuração de migração de caixa de correio entre locatários executando o cmdlet Test-MigrationServerAvailability no ponto de extremidade de migração entre locatários que você criou no locatário de destino. Execute o seguinte cmdlet do locatário 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, você pode querer aproveitar o script de validação de migração de caixa de correio entre locatários, o que permitirá que você valide as organizações que estão sendo configuradas corretamente entre elas e os objetos que você está planejando migrar de um locatário 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 de volta para a origem original
Se uma caixa de correio for necessária para voltar para o locatário de origem original, o mesmo conjunto de etapas e scripts deve ser executado em locatários de nova origem e de novo destino, com alguma variação.
Não execute os scripts de exemplo fornecidos para criar o OrganizationRelationship.
Atualize os seguintes valores no OrganizationRelationship existente criado em cada locatário:
- MailboxMovesCapability deve ter Entrada, RemoteOutbound como os recursos em locatários de origem e de destino.
- No novo locatário de origem, atualize o valor OAuthApplicationId com o valor do aplicativo recém-criado no novo locatário de origem.
- No novo locatário de origem, atualize o valor MailboxMovePublishedScopes com o grupo de segurança recém-criado no novo locatário de origem.
Executar migrações de caixa de correio
As migrações entre locatários da caixa de correio do Exchange são iniciadas do locatário de destino como lotes de migração. Esse processo é semelhante à maneira como os lotes de migração de embarque funcionam ao migrar do Exchange local para o Microsoft 365.
Criar lotes de migração
Aqui está 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 email no arquivo CSV deve ser o especificado no locatário de destino (por exemplo, userA@northwindtraders.onmicrosoft.com), não aquele no locatário de origem. Para obter mais informações sobre o cmdlet clique aquiPara obter alguns exemplos de informações de arquivo CSV clique aqui
Um exemplo mínimo de um arquivo CSV é:
EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com
O envio do lote de migração também tem suporte no novo centro de administração do Exchange ao selecionar a opção entre locatários.
Atualizar mailUsers locais
Depois que a caixa de correio passar de origem para destino, você deverá garantir que os usuários de email locais, na origem e no destino, sejam atualizados com o novo targetAddress. Nos exemplos, o targetDeliveryDomain usado na movimentação é northwindtraders.onmicrosoft.com. Atualize os usuários de email com esse destinoAddress.
Remover pontos de extremidade e relações de organização após a migração
Use o cmdlet Remove-MigrationEndpoint para remover pontos de extremidade de migração existentes para servidores de origem ou de destino após a conclusão da migração.
Use o cmdlet Remove-OrganizationRelationship para remover as relações de organização existentes para servidores de origem ou destino após a conclusão da migração.
Perguntas frequentes
Preciso atualizar RemoteMailboxes no locatário local de origem após a mudança?
Organização do Exchange de Origem
Você deve atualizar o targetAddress (RemoteRoutingAddress/ExternalEmailAddress) de cada usuário local de origem quando a caixa de correio do locatário de origem se move para o locatário de destino. Embora o roteamento de email possa seguir as referências entre vários usuários de email com destinos diferentesAddresses, pesquisas gratuitas/ocupadas para usuários de email devem direcionar o local do usuário da caixa de correio.
Organização de Exchange de Destino
Depois que a migração for concluída em uma organização híbrida, execute o seguinte comando do PowerShell se desejar que seus usuários tenham caixas de correio remotas locais:
Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox
As reuniões do Teams migram o locatário cruzado?
Enquanto as reuniões do Teams são movidas, a URL da reunião não é atualizada quando os itens migram entre locatários. Como a URL será inválida no locatário de destino, você deve remover e recriar reuniões do Teams.
Qual conteúdo é migrado entre locatários?
Quando uma caixa de correio é migrada entre locatários com esse recurso, apenas o conteúdo visível do usuário na caixa de correio, também conhecido como Top of Information Store (email, contatos, calendário, tarefas e anotações) e as pastas Itens Recuperáveis Exclusões, Versões e Purgações são migradas.
Os itens no Outbox são migrados entre locatários?
Os itens na Caixa de Saída não são migrados entre locatários, pois essa pasta é uma pasta baseada no cliente específica para o cliente do Outlook. Os itens na Caixa de Saída são armazenados localmente e não sincronizados com a nuvem.
O conteúdo da pasta de chat do Teams migra o locatário cruzado?
Não, o conteúdo da pasta de chat do Teams não migra o locatário cruzado. No entanto, depois que a caixa de correio tiver sido migrada entre locatários, o conteúdo da pasta de chat do Teams estará disponível para o administrador de locatário de origem pesquisar e exportar, usando uma pesquisa de conteúdo.
Como posso ver apenas movimentos que são movimentos entre locatários, não meus movimentos de integração e off-boarding?
Use o parâmetro Flags :
Get-MoveRequest -Flags "CrossTenant"
Você pode fornecer scripts de exemplo para copiar atributos usados no teste?
Observação
EXEMPLO – AS IS, NO WARRANTY Este script assume uma conexão com a caixa de correio de origem (para obter valores de origem) e o Active Directory 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 acessar o Outlook no primeiro dia após a movimentação da caixa de correio do usuário?
Como apenas um locatário pode possuir um domínio, o antigo SMTPAddress primário não será associado ao usuário no locatário de destino quando a movimentação da caixa de correio for concluída; somente os domínios associados ao novo locatário. O Outlook usa o novo UPN do usuário para se autenticar no serviço e o perfil do Outlook espera encontrar o SMTPAddress primário herdado para corresponder à caixa de correio no sistema de destino. Como o endereço herdado não está no sistema de destino, o perfil do Outlook não se conectará para encontrar a caixa de correio recém-movida.
Para essa implantação inicial, os usuários precisarão reconstruir seu perfil com seu novo endereço UPN, SMTP primário e conteúdo OST ressincronizado.
Observação
Planeje de acordo com o lote de seus usuários para conclusão. Você precisa responder pela utilização e capacidade de rede quando os perfis de cliente do Outlook são criados e arquivos OST e OAB subsequentes são baixados para clientes.
De quais funções do Exchange RBAC preciso ser membro para configurar ou concluir uma movimentação entre locatários?
Há uma matriz de funções baseada na suposição de tarefas delegadas ao executar um movimento de caixa de correio. Atualmente, duas funções são necessárias:
- A primeira função é para uma tarefa de instalação única que estabelece a autorização de mover conteúdo para dentro ou fora do limite locatário/organizacional. Como a movimentação de dados do controle organizacional é uma preocupação crítica para todas as empresas, optamos pela função mais alta atribuída do Administrador da Organização. Essa função deve alterar ou configurar uma nova OrganizationRelationship que define a
-MailboxMoveCapabilityconfiguração com a organização remota. Somente o administrador da organização pode alterar a-MailboxMoveCapabilityconfiguração, enquanto outros atributos na OrganizationRelationship podem ser gerenciados pelo administrador de compartilhamento federado. - A função de executar os comandos de movimento reais pode ser delegada para uma função de nível inferior. A função de Mover caixas de correio é atribuída à capacidade de mover caixas de correio dentro ou fora da organização.
Como direcionarmos qual endereço SMTP está selecionado para targetAddress (TargetDeliveryDomain) na caixa de correio convertida (para conversão do MailUser)?
A caixa de correio exchange move-se usando o MRS criar o targetAddress na caixa de correio de origem original ao converter em um MailUser correspondendo a um endereço de email (proxyAddress) no objeto de destino. O processo leva o -TargetDeliveryDomain valor passado para o comando e verifica se há um proxy correspondente para esse domínio no lado do destino. Quando encontramos uma correspondência, o proxy correspondenteAddress é usado para definir o objeto ExternalEmailAddress (targetAddress) na caixa de correio convertida (agora MailUser).
Como o fluxo de email funciona após a migração?
O fluxo de email entre locatários após a migração funciona de forma semelhante ao fluxo de email do Exchange Hybrid. Cada caixa de correio migrada precisa do MailUser de origem com o endereço de destino correto para encaminhar emails de entrada do locatário de origem para caixas de correio no locatário de destino. As regras de transporte, os recursos de segurança e conformidade serão executados conforme configurado em cada locatário pelo qual o email flui. Assim, para emails de entrada, recursos como anti-spam, anti-malware, quarentena, regras de transporte e regras de diário serão executados primeiro no locatário de origem e depois no locatário de destino.
Como as permissões de caixa de correio fazem a transição?
As permissões da caixa de correio incluem Enviar em nome do e acesso à caixa de correio:
- Send On Behalf Of (AD:publicDelegates) armazena a DN dos destinatários com acesso à caixa de correio de um usuário como delegado. Esse valor é armazenado no Active Directory e atualmente não se move como parte da transição da caixa de correio. Se a caixa de correio de origem tiver publicDelegates definido, você precisará ressoarçar os publicDelegates na caixa de correio de destino assim que a conversão MEU para Caixa de Correio for concluída no ambiente de destino executando
Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>. - As permissões de caixa de correio armazenadas na caixa de correio se moverão com a caixa de correio quando a entidade principal e o delegado forem movidos para o sistema de destino. Por exemplo, o TestUser7 de usuário recebe o FullAccess na caixa de correio TestUser_8 no SourceCompany.onmicrosoft.com de locatário. Depois que a caixa de correio for concluída para TargetCompany.onmicrosoft.com, as mesmas permissões serão configuradas no diretório de destino. Exemplos usando _Get-MailboxPermission para TestUser_7 em locatários de origem e de destino são mostrados abaixo. Os cmdlets do Exchange são prefixados com a origem e o destino de acordo.
Aqui está um exemplo da saída da permissão da caixa de correio antes de uma mudança 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
Aqui está um exemplo da saída da permissão da caixa de correio após a mudança 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
Não há suporte para permissões de caixa de correio e calendário entre locatários. Você deve organizar entidades e delegados em lotes de movimentação consolidados para que essas caixas de correio conectadas sejam transicionadas ao mesmo tempo do locatário de origem.
Qual proxy X500 deve ser adicionado aos endereços proxy do MailUser de destino para habilitar a migração?
A migração da caixa de correio entre locatários requer que o valor LegacyExchangeDN do objeto de caixa de correio de origem seja carimbado como um endereço de email 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 desse proxy X500, você precisará copiar todos os proxies X500 da caixa de correio na origem para a caixa de correio no destino. Embora raro, você também pode executar um endereço proxy X400 em uma caixa de correio, embora não seja um requisito para que a mudança seja concluída, é recomendável que você também carimbo esse endereço no objeto de usuário de email de destino.
Os locatários de origem e destino podem utilizar o mesmo nome de domínio?
Não, os nomes de domínio de locatário de origem e de locatário de destino devem 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 compartilhadas se moverão e ainda funcionarão?
Sim. No entanto, só mantemos as permissões do repositório conforme descrito neste artigo:
Você tem alguma recomendação para lotes?
Não exceda 2.000 caixas de correio por lote. Recomendamos enviar lotes duas semanas antes da data de corte, pois não há impacto sobre os usuários finais durante a sincronização. Se você precisar de diretrizes para quantidades de caixas de correio acima de 50.000, poderá entrar em contato com a Lista de Distribuição de Comentários de Engenharia em crosstenantmigrationpreview@service.microsoft.com.
E se eu usar a criptografia de serviço com a Chave do Cliente do Microsoft Purview?
A caixa de correio é descriptografada antes da movimentação. Verifique se a Chave do Cliente está configurada no locatário de destino se ela ainda for necessária. Para obter mais informações, confira aqui.
Qual é o tempo estimado de migração?
Para ajudá-lo a planejar sua migração, a tabela presente aqui mostra as diretrizes sobre quando esperar a conclusão de migrações em massa ou migrações individuais. Essas estimativas são baseadas em uma análise de dados de migrações de clientes anteriores. Como cada ambiente é exclusivo, sua velocidade de migração exata pode variar.
Proteger documentos no locatário de origem consumíveis pelos usuários no locatário de destino.**
A migração entre locatários só migra dados de caixa de correio e nada mais. Há várias outras opções, que estão documentadas na seguinte postagem no blog que podem ajudar:
Posso ter os mesmos rótulos no locatário de destino que você tinha no locatário de origem, como o único conjunto de rótulos ou um conjunto adicional de rótulos para os usuários migrados, dependendo do alinhamento entre as organizações.**
Como as migrações entre locatários não exportam rótulos e não há como compartilhar rótulos entre locatários, você só pode alcançar esse objetivo recriando os rótulos no locatário de destino.
Você dá suporte à Grupos do Microsoft 365 móvel?
Atualmente, o recurso migrações de caixa de correio entre locatários não dá suporte à migração de Grupos do Microsoft 365.
Um administrador de locatário de origem pode executar uma pesquisa de descoberta eletrônica em uma caixa de correio depois que a caixa de correio foi migrada para o locatário novo/destino?
Não, depois de uma migração de caixa de correio entre locatários, a descoberta eletrônica na caixa de correio do usuário migrado na origem não funciona. Essa falha de descoberta eletrônica ocorre porque não há mais uma caixa de correio na origem para pesquisar, pois a caixa de correio foi migrada para o locatário de destino e agora pertence ao locatário de destino. A descoberta eletrônica após a migração da caixa de correio só pode ser feita no locatário de destino (onde a caixa de correio agora existe). Se uma cópia da caixa de correio de origem precisar persistir no locatário de origem após a migração, o administrador do locatário de origem poderá copiar o conteúdo para uma pré-migração de caixa de correio alternativa para futuras operações de descoberta eletrônica em relação aos dados.
Em que ponto o MailUser de destino será convertido em uma caixa de correio de destino e a caixa de correio de origem convertida em um MailUser de origem?
Essas conversões acontecem automaticamente durante o processo de migração. Nenhuma etapa manual é necessária.
Em qual etapa devo atribuir a licença Exchange Online aos MailUsers de destino?
Essa atribuição de licença pode ser feita antes da conclusão da migração, mas você não deve atribuir uma licença antes de carimbar o atributo ExchangeGUID ; em vez disso, a conversão do objeto MailUser na caixa de correio falhará e uma nova caixa de correio será criada. Para atenuar esse risco, é melhor aguardar até que a migração seja concluída e atribuir licenças durante o período de carência de 30 dias.
Posso usar Microsoft Entra Conectar para sincronizar usuários com o novo locatário se estiver mantendo o Active Directory local?
Sim. É possível ter duas instâncias de Microsoft Entra Conectar sincronizar com locatários diferentes. No entanto, há algumas coisas que você precisa estar ciente de:
- A pré-exibição das contas do usuário com o script fornecido neste artigo não deve ser feita. Em vez disso, uma sincronização seletiva de OU dos usuários no escopo da migração pode ser executada para preencher o locatário de destino. Você receberá um aviso sobre o UPN não corresponder durante Microsoft Entra configuração do Connect.
- Dependendo do estado atual do Exchange híbrido, você precisa verificar se os objetos de diretório locais têm os atributos necessários (como msExchMailboxGUID e proxyAddresses) preenchidos corretamente antes de tentar sincronizar com outro locatário; caso contrário, você terá problemas com caixas de correio duplas e falhas de migração.
- Você deve tomar algumas etapas extras para gerenciar a transição upn, alterando-a localmente depois que a migração tiver sido concluída para um usuário, a menos que você também esteja movendo o domínio personalizado durante uma migração de corte.
Como devo lidar com caixas de correio próximas ou acima da cota.
As caixas de correio que se aproximam de sua cota antes da migração podem acabar acima da cota antes ou durante a migração real. Se isso acontecer, essas caixas de correio falharão na migração e precisarão ser corrigidas e reiniciadas. Para atenuar isso, é recomendável que o administrador do locatário de origem identifique as caixas de correio em ou perto da cota antes da migração e tome as etapas necessárias para reduzir o tamanho da caixa de correio, provisionar um arquivo primário ou, em alguns casos, habilitar a expansão automática de arquivos para as caixas de correio do usuário.
Observação
Depois de habilitar um arquivo ou um arquivo de expansão automática para um usuário, verifique se as políticas de arquivamento corretas são aplicadas ao usuário e o processo é executado para mover os dados da caixa de correio para seu novo local e liberar espaço.
As caixas de correio de arquivo expandidas automaticamente se movem?
Problema: os arquivos expandidos automaticamente não podem ser migrados. Sim, se o usuário na origem tiver arquivos de expansão automática habilitados e tiver arquivos auxiliares adicionais, a migração da caixa de correio entre locatários funcionará. Oferecemos suporte a usuários móveis que não têm mais de 12 caixas de correio de arquivo auxiliares. Além disso, usuários com grandes caixas de correio primárias, grandes main e grandes caixas de correio de arquivo auxiliares exigirão tempo extra para sincronizar e devem ser enviados com antecedência da data de corte. Se a caixa de correio de origem for expandida durante o processo de migração da caixa de correio, a migração falhará, pois um novo arquivo auxiliar será criado na origem, mas não no destino. Nesse caso, você precisará remover o usuário do lote e reenvia-lo.
Posso executar um locatário entre nuvens para migração de locatário?
Não há suporte para a migração entre locatários para locatários. Um cenário de exemplo seria passar de Office 365 Worldwide para Office 365 Government Cloud.
As mensagens de voz são migradas entre locatários?
Sim, as mensagens de voz são migradas entre locatários.
- As mensagens de voz recebidas no email como anexos estão disponíveis na caixa de correio de destino.
- As mensagens de voz recebidas estarão disponíveis no Teams se você chamar a caixa postal e ouvir mensagens salvas. (As VMs recebidas na origem estão disponíveis como mensagens salvas)
- As mensagens de voz recebidas não estão disponíveis na interface do usuário do cliente do Teams na migração pós-destino.
- A saudação de caixa postal também é migrada para o destino.
As assinaturas de caixa de correio são migradas entre locatários?
As assinaturas da caixa de correio não são migradas entre locatários e devem ser recriadas.
Problemas conhecidos
A funcionalidade do Teams pós-migração no locatário de origem será limitada. Depois que a caixa de correio é migrada para o locatário de destino, o Teams no locatário de origem não tem mais acesso à caixa de correio do usuário. Se um usuário entrar no Teams com a credencial de locatário de origem, haverá uma perda de funcionalidade, como a incapacidade de atualizar sua imagem de perfil, nenhum aplicativo de calendário e uma incapacidade de pesquisar e ingressar em equipes públicas.
Cloud MailUsers com proxy smtp não pertencenteAddress bloquear movimentos MRS. Ao criar objetos MailUser de locatário de destino, você deve garantir que todos os endereços proxy SMTP pertençam à organização de locatário de destino. Se houver um proxy SMTPAddress no usuário de email de destino que não pertence ao locatário local, a conversão do MailUser em uma caixa de correio será impedida. Essa prevenção deve-se à nossa garantia de que os objetos da caixa de correio só podem enviar emails de domínios para os quais o locatário é autoritativo (domínios reivindicados pelo locatário).
Se você sincronizar usuários do local usando Microsoft Entra Conectar no locatário de destino, poderá provisionar objetos MailUser locais com ExternalEmailAddress apontando para o locatário de origem onde a caixa de correio existe (LaraN@contoso.onmicrosoft.com) e carimbar o PrimarySMTPAddress como um domínio que reside no locatário de destino (Lara.Newton@northwindtraders.com). Esses valores são sincronizados com o locatário e um usuário de email apropriado está provisionado e está pronto para migração. Um objeto de exemplo é mostrado 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/redefinidos para domínios "internos" reivindicados pela empresa.
Objetos MailUser são ponteiros para caixas de correio não locais. No caso de migrações de caixa de correio entre locatários, usamos objetos MailUser para representar a caixa de correio de origem (da perspectiva da organização de destino) ou a caixa de correio de destino (na perspectiva 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 exibido do usuário da caixa de correio no diretório. Algumas organizações optam por exibir o endereço SMTP primário como um endereço SMTP externo, não como um endereço de propriedade/verificado pelo locatário local (por exemplo, como northwindtraders.com e não como contoso.com). No entanto, uma vez que um objeto de plano de serviço do Exchange é aplicado ao MailUser por meio de operações de licenciamento, o endereço SMTP primário é modificado para mostrar como um domínio verificado pela organização local (contoso.com). Há duas razões potenciais:
Quando qualquer plano de serviço do Exchange é aplicado a um MailUser, o processo Microsoft Entra ID começa a impor a eliminação de proxy para garantir que a organização local não seja capaz de enviar emails, falsificações ou emails de outro locatário. Qualquer endereço SMTP em um objeto destinatário com esses planos de serviço será removido se o endereço não for verificado pela organização local. Como é o caso no exemplo, o domínio northwindtraders.com não é verificado pelo locatário contoso.onmicrosoft.com; Portanto, a limpeza remove esse domínio northwindtraders.com. Se você quiser persistir esses domínios externos no MailUser, antes ou depois da migração, precisará alterar seus processos de migração para remover licenças após a conclusão da mudança ou antes da mudança para garantir que os usuários tenham a identidade visual externa esperada aplicada. Você precisará garantir que o objeto da caixa de correio esteja devidamente licenciado para não afetar o serviço de email. Um script de exemplo para remover os planos de serviço em um MailUser no locatário contoso.onmicrosoft.com é mostrado aqui.
Observação
O script a seguir usa o Microsoft Graph Powershell. Para obter mais informações, confira Visão geral do Microsoft Graph PowerShell.
Para obter informações sobre como usar métodos diferentes para se autenticar Connect-Graph em um script autônomo, confira 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 mostrados 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 usuário não é mais limpo. O domínio northwindtraders.com não pertence ao locatário contoso.onmicrosoft.com e persistirá como o endereço SMTP primário 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 é definido como 8 (DeprovisionMailbox), para MailUsers locais que são migrados para o locatário de destino, a lógica de limpeza de proxy no Azure remove domínios não pertencentes e redefine o primarySMTP para um domínio de propriedade. Com o msExchRemoteRecipientType no MailUser local sendo desmarcado, a lógica de limpeza de proxy não se aplica mais.
Veja abaixo o conjunto completo de planos de serviço atuais que incluem Exchange Online:
| Nome |
|---|
| Armazenamento de descoberta eletrônica (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 |
| Exchange Online Suplemento de Usuário Inativo |
| Quiosque do Exchange Online |
| Exchange Online Multi-Geo |
| Exchange Online Plano 1 |
| POP do Exchange Online |
| Proteção do Exchange Online |
| Conectores de grafo Pesquisa 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 por MyAnalytics |
| Governança de Informações da Microsoft |
| Auditoria do Microsoft Purview (Premium) |
| Microsoft Bookings |
| Microsoft Business Center |
| Investigações de dados da Microsoft |
| Microsoft MyAnalytics (Completo) |
| Conformidade com comunicações da Microsoft |
| DLP de Comunicações da Microsoft |
| Chave do Cliente da Microsoft |
| Auditoria Avançada do Microsoft 365 |
| Gerenciamento de Registros da Microsoft |
| Office 365 eDiscovery (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 |
| Criptografia Premium no Office 365 |
Falhas de migração
MailboxNotInCrossTenantMigrationScopeException
Verifique se o escopo de migração está configurado corretamente no locatário de origem e se MailboxMovesPublishedScopes está definido na relação da organização com o locatário de destino.
Verifique se a caixa de correio a ser migrada foi adicionada ao grupo de segurança no locatário de origem.
Depois de adicionar o usuário ao grupo de segurança correto, retome o lote de migração.AuxArchiveNotFoundInTargetRecipientException
Essa falha ocorre porque o usuário não estava no escopo de migração quando o lote foi iniciado e o usuário tem o AuxArchive na origem.
Adicione o usuário ao grupo de segurança correto no destino de origem.
Remova o usuário de migração do lote.
Remova os usuários com o seguinte comando:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserAdicionar usuário ao novo lote.
MailboxIsNotInExpectedDBException
Essa falha ocorre devido à manutenção interna da Microsoft.
Remova o usuário de migração do lote.
Remova os usuários com o seguinte comando:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserAdicionar usuário ao novo lote.
NotAcceptedDomainException
Há um endereço proxy inválido carimbado no usuário de destino. Um exemplo seria onde um usuário em contoso.onmicrosoft.com tinha um endereço proxy de fabrikam.onmicrosoft.com, que é o locatário de origem.
Remova o endereço proxy inválido usando o seguinte comando:Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}Retome o lote de migração.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException
Um novo AuxArchive foi provisionado durante a migração.
Remova o usuário de migração do lote.
Remova os usuários com o seguinte comando:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserAdicionar usuário ao novo lote.
UserDuplicateInOtherBatchException
O usuário já existe em outro lote.
Remova o usuário de migração do lote.
Remova os usuários com o seguinte comando:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserAdicionar usuário ao novo lote.
MissingExchangeGuidException
O objeto mailuser de destino está ausente do valor correto do ExchangeGuid.
Atualize o ExchangeGuid com o seguinte comando:Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8Retomar o lote de migração.
SourceMailboxAlreadyBeingMovedPermanentException
A caixa de correio de origem já tem uma solicitação de movimentação existente. Investigue e remova o movimento existente. É possível que este seja um movimento interno da Microsoft e você precisará aguardar a conclusão da mudança.
Remova o usuário de migração do lote.
Remova os usuários com o seguinte comando:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserAdicione o usuário ao novo lote depois que o movimento original tiver sido removido ou concluído.
UserAlreadyHasDemotedArchiveException
O usuário tinha uma caixa de correio de arquivo anteriormente desabilitada. Escolha uma das duas opções a seguir para resolve esse problema.
Exclua permanentemente a caixa de correio de arquivo desabilitada, isso é irrecuperável. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Habilite novamente a caixa de correio de arquivo desabilitada com o seguinte comando:Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.Se você habilitar novamente a caixa de correio de arquivo desabilitada, precisará atualizar o guia de arquivo no objeto mailuser de destino.
Retomar o 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