Migración de buzones de inquilinos cruzados

Artículo
02/01/2024

Durante las fusiones o desinversiones, es posible que necesite la capacidad de mover los buzones de Exchange Online de los usuarios a un nuevo inquilino. La migración de buzones entre inquilinos permite a los administradores de inquilinos usar interfaces conocidas como Exchange Online PowerShell y MRS para realizar la transición de los usuarios a su nueva organización.

Los administradores pueden usar el cmdlet New-MigrationBatch , disponible a través del rol de administración Mover buzones , para ejecutar movimientos entre inquilinos.

Los usuarios que migran deben estar presentes en el inquilino de destino Exchange Online sistema como mailUser, marcado con atributos específicos para habilitar los movimientos entre inquilinos. El sistema no puede mover a los usuarios que no están configurados correctamente en el inquilino de destino.

Una vez completados los movimientos, el buzón de usuario de origen se convierte en y MailUser( targetAddress se muestra como ExternalEmailAddress en Exchange) se marca con la dirección de enrutamiento al inquilino de destino. Este proceso deja el heredado MailUser en el inquilino de origen y permite la coexistencia y el enrutamiento de correo. Cuando los procesos empresariales lo permiten, el inquilino de origen puede quitar el objeto MailUser de origen o convertirlo en un contacto de correo.

Las migraciones de buzones de Exchange entre inquilinos se admiten solo para inquilinos híbridos o en la nube, o una combinación de los dos.

En este artículo se describe el proceso de movimientos de buzones entre inquilinos y se proporcionan instrucciones sobre cómo preparar los inquilinos de origen y de destino para los movimientos de contenido del buzón de Exchange Online.

Importante

Los buzones que están en cualquier tipo de suspensión no se migran y el traslado de esos buzones está bloqueado.

Cuando se migra un buzón entre inquilinos con esta característica, solo el contenido visible por el usuario en el buzón (correo electrónico, contactos, calendario, tareas y notas) se migra al destino (inquilino de destino). Después de una migración correcta, se elimina el buzón de origen. Esta eliminación significa que, después de la migración, en ningún caso es el buzón de origen disponible, reconocible o accesible en el inquilino de origen.

Licencias

Importante

A partir de noviembre de 2022, migración de datos de usuario entre inquilinos está disponible como complemento a los siguientes planes de suscripción de Microsoft 365 para Enterprise Agreement clientes y es necesario para migraciones entre inquilinos. Las licencias de usuario son por migración (tarifa única) y se pueden asignar en el objeto de usuario de origen o de destino. Esta licencia también cubre OneDrive para la Empresa migración. Póngase en contacto con el equipo de su cuenta microsoft para obtener más información.

El complemento migración de datos de usuario entre inquilinos está disponible como una compra independiente para Microsoft 365 Empresa Básico, Estándar y Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; y OneDrive para la Empresa.

Advertencia

Debe haber comprado o comprobado que puede comprar licencias de migración de datos de usuario entre inquilinos antes de los pasos siguientes. Se produce un error en las migraciones si no se ha completado este paso. Microsoft no ofrece excepciones para este requisito de licencia.

Si no tiene la licencia adecuada asignada al usuario que se va a migrar, se produce un error en la migración y recibe un error similar al siguiente:

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.

Preparación de inquilinos de origen y destino

Requisitos previos para inquilinos de origen y destino

Antes de empezar, asegúrese de que tiene los permisos necesarios para configurar la aplicación Mover buzón de correo en Azure, el punto de conexión de migración EXO y la relación de la organización EXO.

Además, se requiere al menos un grupo de seguridad habilitado para correo en el inquilino de origen. Estos grupos se usan para limitar la lista de buzones que pueden pasar del inquilino de origen (o a veces denominado recurso) al inquilino de destino. Este ámbito permite al administrador de inquilinos de origen restringir o limitar el conjunto específico de buzones que se deben mover, lo que evita que se migren usuarios no deseados.

Si va a migrar más de 10 000 usuarios, se recomienda crear varios grupos para que contengan la lista de usuarios para obtener el mejor rendimiento. Aunque se admiten grupos anidados, no se recomiendan.

También debe comunicarse con su empresa asociada de confianza (con la que va a mover buzones) para obtener su identificador de inquilino de Microsoft 365. Este identificador de inquilino se usa en el campo NombreDeDominio de relación de organización.

Para obtener el identificador de inquilino de una suscripción, inicie sesión en el Centro de administración de Microsoft 365 y vaya a https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Seleccione el icono de copia de la propiedad Id. de inquilino para copiarla en el Portapapeles.

Todos los usuarios de las organizaciones de origen y de destino deben tener licencia con las suscripciones de Exchange Online adecuadas. Además, asegúrese de aplicar licencias de migración de datos de usuario entre inquilinos a todos los usuarios que se migrarán al lado de destino.

Pasos de configuración para habilitar los inquilinos para migraciones de buzones entre inquilinos

Nota:

Primero debe configurar el destino (destino). Para completar estos pasos, no es necesario tener ni conocer las credenciales de administrador de inquilinos para el inquilino de origen y de destino. Los distintos administradores pueden realizar los pasos individualmente para cada inquilino.

Preparación del inquilino objetivo (destino) mediante la creación de la aplicación de migración y el secreto

Inicie sesión en el Centro de administración Microsoft Entra (https://portal.azure.com) con las credenciales de administrador de inquilinos de destino.
En Administrar Microsoft Entra ID, seleccione Ver.
En el panel de navegación, seleccione Registros de aplicaciones.
Seleccione Nuevo registro.
En la página Registrar una aplicación, en Tipos de cuenta admitidos, seleccione Cuentas en cualquier directorio organizativo (Cualquier directorio Microsoft Entra : multiinquilino). A continuación, en URI de redirección (opcional), seleccione Web y https://office.comescriba . A continuación, seleccione Registrar.

En la esquina superior derecha de la página, vea el cuadro de diálogo de notificación que indica que la aplicación se creó correctamente.
Volver a la página Inicio, vaya a Microsoft Entra ID y, a continuación, seleccione Registros de aplicaciones.
En Aplicaciones de propiedad, busque la aplicación que creó y selecciónela.
En Essentials, copie el identificador de aplicación (cliente). Necesitará esta información más adelante para crear una dirección URL para el inquilino de destino.
En el panel de navegación, seleccione Permisos de API para ver los permisos asignados a la aplicación.
De forma predeterminada, los permisos User.Read se asignan a la aplicación que ha creado, pero estos permisos no son necesarios para las migraciones de buzones de correo. Puede quitar esos permisos.
Para agregar permiso para la migración de buzones, seleccione Agregar un permiso.
En la ventana Solicitar permisos de API , seleccione API que usa mi organización, busque Office 365 Exchange Onliney, a continuación, selecciónela.
Seleccione Permisos de aplicación.
En Seleccionar permisos, expanda Buzón y seleccione Mailbox.Migration y, a continuación, seleccione Agregar permisos en la parte inferior de la pantalla.
Ahora, seleccione Certificados & secretos en el panel de navegación de la aplicación.
En Secretos de cliente, seleccione Nuevo secreto de cliente.
En la ventana Agregar un secreto de cliente , escriba una descripción y, a continuación, configure los valores de expiración.

Nota:

La contraseña se usa al crear el punto de conexión de migración. Es muy importante copiar esta contraseña en el Portapapeles o en una ubicación segura de contraseña segura o secreta. La fase de creación del secreto es el único tiempo durante el cual puede ver esta contraseña. Si de alguna manera la pierde o necesita restablecerla, puede volver a iniciar sesión en el Azure Portal, ir a Registros de aplicaciones, buscar la aplicación de migración, seleccionar Secretos & certificados y, a continuación, crear un nuevo secreto para la aplicación.

Ahora que ha creado correctamente la aplicación de migración y el secreto, el siguiente paso es dar su consentimiento a la aplicación.

En la página de aterrizaje de Microsoft Entra ID, seleccione Aplicaciones empresariales en el panel de navegación; a continuación, busque la aplicación de migración que creó, selecciónela y, a continuación, seleccione Permisos de API.
Seleccione Conceder consentimiento de administrador para [su inquilino]. Se abre una nueva ventana del explorador.
Seleccione Aceptar.
Volver a la ventana del portal y seleccione Actualizar para confirmar su aceptación.
Formule la dirección URL que se va a enviar a su asociado de confianza (administrador de inquilinos de origen) para que también pueda aceptar la aplicación para habilitar la migración de buzones.

Este es un ejemplo de la dirección URL que se les proporciona:

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

Nota:

Necesitará el identificador de aplicación de la aplicación de migración de buzón de correo que acaba de crear. Tendrá que reemplazar contoso.onmicrosoft.com en el ejemplo anterior por el nombre de onmicrosoft.com correcto del inquilino de origen. También tendrá que reemplazar [application_id_of_the_app_you_just_created] por el identificador de aplicación de la aplicación de migración de buzón que acaba de crear.

Prepare el inquilino de destino mediante la creación del extremo de migración de Exchange Online y la relación de la organización

Conéctese a Exchange Online PowerShell en el inquilino de Exchange Online de destino.

Cree un nuevo punto de conexión de migración para movimientos de buzón entre inquilinos.

Nota:

Necesitará el identificador de aplicación de la aplicación de migración de buzón que acaba de crear y la contraseña (secreto) que configuró en Preparar el inquilino de destino (destino) mediante la creación de la aplicación de migración y el secreto. En función de la instancia en la nube de Microsoft 365 que use, el punto de conexión puede ser diferente. Consulte la página Puntos de conexión de Microsoft 365; seleccione la instancia correcta para el inquilino; a continuación, revise la dirección Exchange Online Optimize/Required y reemplace según corresponda.

$AppId = "[Guid copied from the migrations app]"
$name = "[the name of your new migration endpoint]"
$remote = "<contoso>.onmicrosoft.com"
$secret = "[this is your secret password you saved in the previous steps]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String $secret -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant $remote -Credentials $Credential -ExchangeRemoteMove:$true -Name $name -ApplicationId $AppId

Cree un nuevo objeto de relación de organización o edite el objeto de relación de la organización existente con el inquilino de origen.

$sourceTenantId = "[tenant ID of your trusted partner, where the source mailboxes are]"
$orgrelname = "[name of your new organization relationship]"
$orgrels = Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

Prepare el inquilino de origen (ubicación actual del buzón de correo) aceptando la aplicación de migración y configurando la relación de la organización.

Con el explorador, vaya al vínculo url proporcionado por el asociado de confianza para dar su consentimiento a la aplicación de migración de buzones. La dirección URL debe tener este aspecto:

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

Nota:

Necesitará el identificador de aplicación de la aplicación de migración de buzón de correo que acaba de crear. Tendrá que reemplazar contoso.onmicrosoft.com en el ejemplo anterior por la dirección URL del inquilino de onmicrosoft.com origen. También tendrá que reemplazar [application_id_of_the_app_you_just_created] por el identificador de aplicación de la aplicación de migración de buzón que acaba de crear.
Acepte la aplicación cuando aparezca el elemento emergente. También puede iniciar sesión en el Centro de administración Microsoft Entra y buscar la aplicación en Aplicaciones empresariales.
Conéctese a Exchange Online PowerShell en el inquilino de origen Exchange Online.

Cree un nuevo objeto de relación de organización o edite el objeto de relación de la organización existente con el inquilino de destino (destino) en Exchange Online PowerShell:

$targetTenantId = "[tenant ID of your trusted partner, where the mailboxes are being moved to]"
$appId = "[application ID of the mailbox migration app you consented to]"
$scope = "[name of the mail enabled security group that contains the list of users who are allowed to migrate]"
$orgrelname = "[name of your new organization relationship]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host "Group already exists." }
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

Nota:

El identificador de inquilino que escriba como $sourceTenantId y $targetTenantId es el GUID y no el nombre de dominio del inquilino. Para obtener un ejemplo de un identificador de inquilino e información sobre cómo buscar el identificador de inquilino, consulte Buscar el identificador de inquilino de Microsoft 365.

Preparación de objetos de usuario de destino para la migración

Los usuarios que migran deben estar presentes en el inquilino de destino y Exchange Online sistema (como MailUser) marcado con atributos específicos para habilitar los movimientos entre inquilinos. El sistema no podrá mover usuarios que no estén configurados correctamente en el inquilino de destino. En la sección Requisitos previos para objetos de usuario de destino se detallan los requisitos del objeto MailUser para el inquilino de destino.

Requisitos previos para objetos de usuario de destino

Asegúrese de que los siguientes objetos y atributos se establecen en la organización de destino:

Sugerencia

Microsoft está desarrollando una característica para proporcionar un método automatizado seguro para establecer muchos de los atributos (especificados a continuación, en esta sección). Esta característica, denominada Asignación de identidades entre inquilinos, busca actualmente clientes dispuestos a participar en una pequeña versión preliminar privada. Para obtener más información sobre esta característica de versión preliminar y cómo puede simplificar los procesos de migración entre inquilinos, consulte Asignación de identidades entre inquilinos.

Para cualquier buzón que se mueva desde una organización de origen, debe aprovisionar un objeto MailUser en la organización de destino:

Target MailUser debe tener estos atributos desde el buzón de origen o asignados con el nuevo objeto User:

ExchangeGUID (flujo directo de origen a destino): el GUID del buzón debe coincidir. El proceso de movimiento no continuará si este atributo no está presente en el objeto de destino.
ArchiveGUID (flujo directo de origen a destino): el GUID de archivo debe coincidir. El proceso de movimiento no continuará si este atributo no está presente en el objeto de destino. (Este atributo solo es necesario si el buzón de origen está habilitado para el archivo).
LegacyExchangeDN (flujo como proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN debe estar presente en mailUser de destino como x500: proxyAddress. Además, también debe copiar todas las direcciones x500 del buzón de origen al usuario de correo de destino. Los procesos de movimiento no continuarán si estas direcciones x500 no están presentes en el objeto de destino. Además, este paso es importante para habilitar la capacidad de respuesta para los correos electrónicos que se envían antes de la migración. La dirección de remitente o destinatario de cada elemento de correo electrónico y la caché de autocompletar en Microsoft Outlook y en Microsoft Outlook Web App (OWA) usan el valor del atributo LegacyExchangeDN. Si un usuario no se puede encontrar con el valor LegacyExchangeDN, es posible que se produzca un error en la entrega de mensajes de correo electrónico con un NDR 5.1.1.
UserPrincipalName: UPN se alineará con la nueva identidad del usuario o la empresa de destino (por ejemplo, user@northwindtraders.onmicrosoft.com).
SMTPAddress principal: la dirección SMTP principal se alineará con la nueva empresa del usuario (por ejemplo, user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: MailUser hará referencia al buzón actual del usuario hospedado en el inquilino de origen (por ejemplo user@contoso.onmicrosoft.com, ). Cuando se asigna este valor, compruebe que también tiene o está asignando PrimarySMTPAddress; De lo contrario, este valor establecerá PrimarySMTPAddress, lo que provocará errores de movimiento.

No puede agregar direcciones de proxy smtp heredadas desde el buzón de origen a MailUser de destino. Por ejemplo, no puede mantener contoso.com en el MEU en northwindtraders.onmicrosoft.com objetos de inquilino. Los dominios solo están asociados a un inquilino de Microsoft Entra ID o Exchange Online.

Ejemplo 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=74e5385fce4b46d19006876949855035-Lara
EmailAddresses	x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
	SMTP:LaraN@northwindtraders.onmicrosoft.com
	SMTP:Lara.Newton@northwindtraders.com
	X500:/o=ExchangeLabs/ou=Grupo administrativo de Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Ejemplo de objeto buzón de origen :

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
EmailAddresses	SMTP:LaraN@contoso.onmicrosoft.com
	SMTP:Lara.Newton@contoso.com
	X500:/o=ExchangeLabs/ou=Grupo administrativo de Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Es posible que ya se incluyan otros atributos en la escritura diferida híbrida de Exchange. Si no es así, deben incluirse.
1. msExchBlockedSendersHash: reescriba los datos de remitente bloqueados en línea de los clientes en Active Directory local.
2. msExchSafeRecipientsHash: reescriba los datos de destinatarios seguros en línea de los clientes en Active Directory local.
3. msExchSafeSendersHash– Reescriba los datos de remitente seguro en línea de los clientes en Active Directory local.
Los usuarios de la organización de destino deben tener una licencia con las suscripciones de Exchange Online adecuadas aplicables a la organización. Puede aplicar una licencia antes de que se mueva un buzón de correo, pero SOLO una vez que mailUser de destino esté configurado correctamente con ExchangeGUID y direcciones proxy. La aplicación de una licencia antes de que se aplique ExchangeGUID dará como resultado un nuevo buzón aprovisionado en la organización de destino. También debe aplicar una licencia de migración de datos de usuario entre inquilinos; De lo contrario, es posible que vea que una lectura de errores transitorios necesita aprobación, lo que notificará una advertencia en el informe de movimiento de que no se ha aplicado una licencia al usuario de destino.

Nota:

Cuando se aplica una licencia en un objeto Mailbox o MailUser, todas las proxyAddresses de tipo SMTP se depuran para garantizar que solo se incluyan dominios verificados en la matriz EmailAddresses de Exchange.
Debe asegurarse de que mailUser de destino no tiene ningún ExchangeGUID anterior que no coincida con exchangeGUID de origen. Esta falta de coincidencia podría producirse si el MEU de destino se licenciaba previamente para Exchange Online y aprovisionaba un buzón de correo. Si el objeto MailUser de destino tenía una licencia anterior para ExchangeGUID o tenía un exchangeGUID que no coincide con exchangeGUID de origen, debe realizar una limpieza de la MEU en la nube. Para estas MEU en la nube, puede ejecutar Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Precaución

Este proceso es irreversible. Si el objeto tiene un buzón softDeleted, no se puede restaurar después de este punto. Sin embargo, una vez desactivado, puede sincronizar el ExchangeGUID correcto con el objeto de destino y MRS conectará el buzón de origen al buzón de destino recién creado. (Blog de referencia de EHLO sobre el nuevo parámetro).

Busque objetos que anteriormente eran buzones de correo mediante el siguiente comando:

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

Aquí le mostramos un ejemplo:

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

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

Borre el buzón eliminado temporalmente mediante el siguiente comando:

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Aquí le mostramos un ejemplo:

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

¿Cómo saber si el proceso se ha completado correctamente?

Para comprobar la configuración de migración de buzones entre inquilinos, ejecute el cmdlet Test-MigrationServerAvailability en el punto de conexión de migración entre inquilinos que creó en el inquilino de destino. Ejecute el siguiente cmdlet desde el inquilino de destino:

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

Nota:

Además, es posible que quiera aprovechar el script de validación de migración de buzones entre inquilinos, que le permitirá validar que las organizaciones están configuradas correctamente entre ellas y los objetos que planea migrar de un inquilino a otro. El script ayudará a identificar las discrepancias que puedan estar presentes en todos los objetos a la vez y, como resultado, reducirá el tiempo empleado en la fase inicial.

Volver a mover los buzones al origen original

Si se requiere un buzón de correo para volver al inquilino de origen original, el mismo conjunto de pasos y scripts se debe ejecutar en los nuevos inquilinos de origen y de destino nuevos, con cierta varianza.

No ejecute los scripts de ejemplo proporcionados para crear OrganizationRelationship.

Actualice los siguientes valores en la organización existenteRelationship creada en cada inquilino:

MailboxMovesCapability debe tener Inbound, RemoteOutbound como las funcionalidades de los inquilinos de origen y de destino.
En el nuevo inquilino de origen, actualice el valor de OAuthApplicationId con el valor de la aplicación recién creada en el nuevo inquilino de origen.
En el nuevo inquilino de origen, actualice el valor MailboxMovePublishedScopes con el grupo de seguridad recién creado en el nuevo inquilino de origen.

Realizar migraciones de buzones

Las migraciones de buzones de Exchange entre inquilinos se inician desde el inquilino de destino como lotes de migración. Este proceso es similar a la forma en que funcionan los lotes de migración de incorporación al migrar desde Exchange local a Microsoft 365.

Creación de lotes de migración

Este es un comando de ejemplo para iniciar una migración por lotes:

New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com

Identity                   Status  Type               TotalCount
--------                   ------  ----               ----------
T2Tbatch                   Syncing ExchangeRemoteMove 1

Nota:

La dirección de correo electrónico del archivo CSV debe ser la especificada en el inquilino de destino (por ejemplo, userA@northwindtraders.onmicrosoft.com), no la del inquilino de origen. Para obtener más información sobre el cmdlet, haga clic aquí Para obtener información de archivo CSV de ejemplo, haga clic aquí.

Un ejemplo mínimo de un archivo CSV es:

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

El envío por lotes de migración también se admite desde el nuevo Centro de administración de Exchange al seleccionar la opción entre inquilinos.

Actualización de MailUsers local

Una vez que el buzón se mueve de origen a destino, debe asegurarse de que los usuarios de correo local, tanto en el origen como en el destino, se actualizan con el nuevo targetAddress. En los ejemplos, se northwindtraders.onmicrosoft.com el targetDeliveryDomain usado en el movimiento. Actualice los usuarios de correo con este targetAddress.

Eliminación de puntos de conexión y relaciones de la organización después de la migración

Use el cmdlet Remove-MigrationEndpoint para quitar los puntos de conexión de migración existentes para los servidores de origen o destino una vez completada la migración.

Use el cmdlet Remove-OrganizationRelationship para quitar las relaciones de organización existentes para los servidores de origen o destino una vez completada la migración.

Preguntas frecuentes

¿Es necesario actualizar RemoteMailboxes en el inquilino local de origen después del traslado?

Organización de Exchange de origen

Debe actualizar targetAddress (RemoteRoutingAddress/ExternalEmailAddress) de cada usuario local de origen cuando el buzón de inquilino de origen se mueva al inquilino de destino. Aunque el enrutamiento de correo puede seguir las referencias entre varios usuarios de correo con diferentes targetAddresses, las búsquedas de disponibilidad para los usuarios de correo deben tener como destino la ubicación del usuario del buzón.

Organización de Exchange de destino

Una vez completada la migración en una organización híbrida, ejecute el siguiente comando de PowerShell si desea que los usuarios tengan buzones remotos en el entorno local:

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

¿Las reuniones de Teams migran entre inquilinos?

Mientras se mueven las reuniones de Teams, la dirección URL de la reunión no se actualiza cuando los elementos migran entre inquilinos. Dado que la dirección URL no será válida en el inquilino de destino, debe quitar y volver a crear reuniones de Teams.

¿Qué contenido se migra entre inquilinos?

Cuando se migra un buzón entre inquilinos con esta característica, solo se migra el contenido visible por el usuario en el buzón, también conocido como Top of Information Store (correo electrónico, contactos, calendario, tareas y notas) y las carpetas Eliminaciones, versiones y purgas de elementos recuperables.

¿Los elementos de la Bandeja de salida se migran entre inquilinos?

Los elementos de la Bandeja de salida no se migran entre inquilinos, ya que esta carpeta es una carpeta basada en cliente específica del cliente de Outlook. Los elementos de la Bandeja de salida se almacenan localmente y no se sincronizan con la nube.

¿El contenido de la carpeta de chat de Teams migra entre inquilinos?

No, el contenido de la carpeta de chat de Teams no migra entre inquilinos. Sin embargo, una vez migrado el buzón entre inquilinos, el contenido de la carpeta de chat de Teams estará disponible para que el administrador de inquilinos de origen busque y exporte mediante una búsqueda de contenido.

¿Cómo puedo ver solo movimientos que son movimientos entre inquilinos, no mis movimientos de incorporación y desembarque?

Use el parámetro Flags :

Get-MoveRequest -Flags "CrossTenant"

¿Puede proporcionar scripts de ejemplo para copiar los atributos usados en las pruebas?

Nota:

EJEMPLO: TAL CUAL, SIN GARANTÍA Este script supone una conexión con el buzón de origen (para obtener los valores de origen) y el Active Directory local Servicios de dominio de destino (para marcar el 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

¿Cómo se accede a Outlook el día 1 después de mover el buzón de usuario?

Dado que solo un inquilino puede poseer un dominio, la dirección SMTPAddress principal anterior no se asociará al usuario en el inquilino de destino cuando se complete el movimiento del buzón; solo los dominios asociados al nuevo inquilino. Outlook usa el nuevo UPN del usuario para autenticarse en el servicio y el perfil de Outlook espera encontrar la dirección SMTPAddress principal heredada para que coincida con el buzón del sistema de destino. Dado que la dirección heredada no está en el sistema de destino, el perfil de Outlook no se conectará para buscar el buzón recién movido.

Para esta implementación inicial, los usuarios tendrán que volver a generar su perfil con su nuevo UPN, dirección SMTP principal y contenido OST resincronizar.

Nota:

Planee en consecuencia a medida que realice el procesamiento por lotes de los usuarios para su finalización. Debe tener en cuenta el uso de la red y la capacidad cuando se crean perfiles de cliente de Outlook y los archivos OST y OAB posteriores se descargan en los clientes.

¿De qué roles de RBAC de Exchange debo ser miembro para configurar o completar un traslado entre inquilinos?

Hay una matriz de roles basada en la suposición de tareas delegadas al ejecutar un movimiento de buzón. Actualmente, se requieren dos roles:

El primer rol es para una tarea de configuración única que establece la autorización para mover contenido dentro o fuera del límite empresarial o organizativo. Dado que el traslado de datos fuera del control de la organización es una preocupación crítica para todas las empresas, hemos optado por el rol más alto asignado de administrador de la organización. Este rol debe modificar o configurar una nueva organizaciónRelationship que defina la -MailboxMoveCapability configuración con la organización remota. Solo el administrador de la organización puede modificar la -MailboxMoveCapability configuración, mientras que el administrador de uso compartido federado puede administrar otros atributos de OrganizationRelationship.
El rol de ejecutar los comandos de movimiento reales se puede delegar en una función de nivel inferior. El rol Mover buzones se asigna a la capacidad de mover buzones dentro o fuera de la organización.

¿Cómo se destina a qué dirección SMTP se selecciona targetAddress (TargetDeliveryDomain) en el buzón convertido (a la conversión MailUser)?

El buzón de Exchange se mueve mediante MRS crea el targetAddress en el buzón de origen original al convertirse en un mailUser mediante la coincidencia de una dirección de correo electrónico (proxyAddress) en el objeto de destino. El proceso toma el -TargetDeliveryDomain valor pasado al comando y, a continuación, comprueba si hay un proxy coincidente para ese dominio en el lado de destino. Cuando se encuentra una coincidencia, el proxyAddress coincidente se usa para establecer externalEmailAddress (targetAddress) en el objeto de buzón convertido (ahora MailUser).

¿Cómo funciona el flujo de correo después de la migración?

El flujo de correo entre inquilinos después de la migración funciona de forma similar al flujo de correo híbrido de Exchange. Cada buzón migrado necesita el origen MailUser con la dirección de destino correcta para reenviar el correo entrante desde el inquilino de origen a los buzones del inquilino de destino. Las reglas de transporte, las características de seguridad y cumplimiento se ejecutarán según lo configurado en cada inquilino por el que fluye el correo. Por lo tanto, para el correo entrante, las características como antispam, antimalware, cuarentena, reglas de transporte y reglas de registro en diario se ejecutarán primero en el inquilino de origen y luego en el inquilino de destino.

¿Cómo se realiza la transición de los permisos de buzón de correo?

Los permisos de buzón incluyen Enviar en nombre de y Acceso al buzón:

Enviar en nombre de (AD:publicDelegates) almacena el DN de los destinatarios con acceso al buzón de un usuario como delegado. Este valor se almacena en Active Directory y actualmente no se mueve como parte de la transición del buzón. Si el buzón de origen tiene publicDelegates establecido, deberá volver a rellenar publicDelegates en el buzón de destino una vez que se complete la conversión de MEU a Buzón en el entorno de destino mediante la ejecución Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>de .
Los permisos de buzón que se almacenan en el buzón se moverán con el buzón cuando la entidad de seguridad y el delegado se muevan al sistema de destino. Por ejemplo, al usuario TestUser7 se le concede FullAccess al buzón TestUser_8 en el inquilino SourceCompany.onmicrosoft.com. Una vez que el buzón se mueve a TargetCompany.onmicrosoft.com, se configuran los mismos permisos en el directorio de destino. A continuación se muestran ejemplos de uso de _Get-MailboxPermission para TestUser_7 en inquilinos de origen y de destino. Los cmdlets de Exchange tienen como prefijo el origen y el destino en consecuencia.

Este es un ejemplo de la salida del permiso de buzón antes de un traslado desde el lado de origen:

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

Este es un ejemplo de la salida del permiso de buzón después del traslado desde el lado de destino:

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@northwindtraders.onmicrosoft.com      {FullAccess}                         False       False

Nota:

No se admiten los permisos de calendario y buzón entre inquilinos. Debe organizar entidades de seguridad y delegados en lotes de movimiento consolidados para que estos buzones conectados se realicen la transición al mismo tiempo desde el inquilino de origen.

¿Qué proxy X500 se debe agregar a las direcciones proxy de MailUser de destino para habilitar la migración?

La migración del buzón entre inquilinos requiere que el valor LegacyExchangeDN del objeto de buzón de correo de origen se stampe como una dirección de correo electrónico x500 en el objeto MailUser de destino.

Ejemplo:

LegacyExchangeDN value on source mailbox is:
/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara

so, the x500 email address to be added to target MailUser object would be:
x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara

Nota:

Además de este proxy X500, deberá copiar todos los servidores proxy X500 del buzón del origen al buzón del destino. Aunque es poco frecuente, también podría ejecutar una dirección de proxy X400 en un buzón de correo, aunque no es un requisito para que se complete el traslado, se recomienda que también estampa esta dirección en el objeto de usuario de correo de destino.

¿Pueden los inquilinos de origen y de destino usar el mismo nombre de dominio?

No, los nombres de dominio de inquilino de origen y de inquilino de destino deben ser únicos, por ejemplo, un dominio de origen de contoso.com y el dominio de destino de northwindtraders.com.

¿Los buzones compartidos se moverán y seguirán funcionando?

Sí. Sin embargo, solo conservamos los permisos de almacén como se describe en este artículo:

Administración de permisos para destinatarios en Exchange Online

¿Tiene alguna recomendación para lotes?

No supere los 2000 buzones por lote. Se recomienda encarecidamente enviar lotes dos semanas antes de la fecha de finalización, ya que no hay ningún impacto en los usuarios finales durante la sincronización. Si necesita instrucciones para las cantidades de buzones de más de 50 000, puede ponerse en contacto con el CSAM o abrir una solicitud de soporte técnico.

¿Qué ocurre si uso el cifrado de servicio con la clave de cliente de Microsoft Purview?

El buzón de correo se descifra antes de moverse. Asegúrese de que la clave de cliente está configurada en el inquilino de destino si todavía es necesaria. Para obtener más información, consulte aquí.

¿Cuál es el tiempo de migración estimado?

Para ayudarle a planear la migración, en la tabla que se muestra aquí se muestran las instrucciones sobre cuándo esperar que se completen migraciones masivas de buzones o migraciones individuales. Estas estimaciones se basan en un análisis de datos de migraciones de clientes anteriores. Dado que cada entorno es único, la velocidad de migración exacta puede variar.

Protección de documentos en el inquilino de origen que los usuarios del inquilino de destino consumen.**

La migración entre inquilinos solo migra los datos del buzón de correo y nada más. Hay varias otras opciones, que se documentan en la siguiente entrada de blog que pueden ayudar:

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

¿Puedo tener las mismas etiquetas en el inquilino de destino que tenía en el inquilino de origen, ya sea como el único conjunto de etiquetas o un conjunto adicional de etiquetas para los usuarios migrados en función de la alineación entre las organizaciones.**

Dado que las migraciones entre inquilinos no exportan etiquetas y no hay ninguna manera de compartir etiquetas entre inquilinos, solo puede lograr este objetivo mediante la recreación de las etiquetas en el inquilino de destino.

¿Admite el traslado de Grupos de Microsoft 365?

Actualmente, la característica de migraciones de buzones entre inquilinos no admite la migración de Grupos de Microsoft 365.

¿Puede un administrador de inquilinos de origen realizar una búsqueda de exhibición de documentos electrónicos en un buzón después de migrar el buzón al inquilino nuevo o de destino?

No, después de una migración de buzón entre inquilinos, eDiscovery en el buzón del usuario migrado en el origen no funciona. Este error de eDiscovery se debe a que ya no hay un buzón en el origen para buscar, ya que el buzón se ha migrado al inquilino de destino y ahora pertenece al inquilino de destino. eDiscovery después de la migración del buzón solo se puede realizar en el inquilino de destino (donde ahora existe el buzón). Si una copia del buzón de origen debe conservarse en el inquilino de origen después de la migración, el administrador del inquilino de origen puede copiar el contenido en un buzón alternativo previo a la migración para futuras operaciones de exhibición de documentos electrónicos en los datos.

¿En qué momento se convertirá el mailuser de destino en un buzón de destino y el buzón de origen se convertirá en un mailuser de origen?

Estas conversiones se producen automáticamente durante el proceso de migración. No es necesario realizar ningún paso manual.

¿En qué paso debo asignar la licencia de Exchange Online a mailUsers de destino?

Esta asignación de licencias se puede realizar antes de que se complete la migración, pero no debe asignar una licencia antes de marcar el atributo ExchangeGUID ; De lo contrario, se producirá un error en la conversión del objeto MailUser al buzón y se creará un nuevo buzón en su lugar. Para mitigar este riesgo, es mejor esperar hasta que se complete la migración y asignar licencias durante el período de gracia de 30 días.

¿Puedo usar Microsoft Entra Connect para sincronizar usuarios con el nuevo inquilino si manteno el Active Directory local?

Sí. Es posible tener dos instancias de Microsoft Entra Conectar sincronización con inquilinos diferentes. Sin embargo, hay algunas cosas que debe tener en cuenta:

No se debe aprovisionar previamente las cuentas del usuario con el script proporcionado en este artículo. En su lugar, se puede realizar una sincronización de unidad organizativa selectiva de los usuarios en el ámbito de la migración para rellenar el inquilino de destino. Recibirá una advertencia sobre que el UPN no coincide durante la configuración de Microsoft Entra Connect.
En función del estado actual de Exchange híbrido, debe comprobar que los objetos de directorio local tienen los atributos necesarios (como msExchMailboxGUID y proxyAddresses) rellenados correctamente antes de intentar sincronizar con otro inquilino; de lo contrario, se encontrará con problemas con buzones dobles y errores de migración.
Debe realizar algunos pasos adicionales para administrar la transición de UPN y cambiarla localmente una vez completada la migración para un usuario, a menos que también mueva el dominio personalizado durante una migración de paso a paso.

¿Cómo debo controlar los buzones que están cerca o por encima de la cuota?

Los buzones que se aproximan a su cuota antes de la migración pueden terminar por encima de la cuota antes o durante la migración real. Si esto sucede, estos buzones producirán un error en la migración y tendrán que corregirse y reiniciarse. Para mitigar esto, se recomienda que el administrador de inquilinos de origen identifique buzones a una cuota cercana o cercana antes de la migración y realice los pasos necesarios para reducir el tamaño del buzón, aprovisionar un archivo principal o, en algunos casos, habilitar archivos de expansión automática para los buzones del usuario.

Nota:

Una vez que se habilita un archivo o se expande automáticamente para un usuario, asegúrese de que las directivas de archivado correctas se aplican al usuario y que el proceso se ejecuta para mover los datos del buzón a su nueva ubicación y liberar espacio.

¿Se mueven los buzones de archivo expandidos automáticamente?

Problema: no se pueden migrar los archivos expandidos automáticamente. Sí, si el usuario de origen tiene habilitados los archivos de expansión automática y tiene archivos auxiliares adicionales, la migración de buzones entre inquilinos funcionará. Se admite el traslado de usuarios que no tienen más de 12 buzones de archivo auxiliares. Además, los usuarios con grandes buzones de archivo principal, principal grande y auxiliar de gran tamaño necesitarán tiempo adicional para sincronizarse y deben enviarse con bastante antelación a la fecha de finalización. Si el buzón de origen se expande durante el proceso de migración del buzón, se producirá un error en la migración, ya que se creará un nuevo archivo auxiliar en el origen, pero no en el destino. En este caso, tendrá que quitar el usuario del lote y volver a enviarlo.

¿Puedo realizar una migración entre inquilinos a inquilinos entre nubes?

No se admite la migración de inquilinos entre nubes a inquilinos. Un escenario de ejemplo sería pasar de Office 365 en todo el mundo a Office 365 Administración Pública Cloud.

¿Los buzones de voz se migran entre inquilinos?

Sí, los mensajes de voz se migran entre inquilinos.

Los correos de voz recibidos en el correo electrónico como datos adjuntos están disponibles en el buzón de destino.
Los mensajes de voz recibidos están disponibles en Teams si llama al correo de voz y escucha los mensajes guardados. (Las máquinas virtuales recibidas en el origen están disponibles como mensajes guardados)
Los mensajes de voz recibidos no están disponibles en la interfaz de usuario de cliente de Teams en la migración posterior a la migración de destino.
El saludo del correo de voz también se migra al destino.

¿Se migran las firmas de buzón entre inquilinos?

Las firmas de buzón de correo no se migran entre inquilinos y se deben volver a crear.

Problemas conocidos

La funcionalidad de Teams posterior a la migración en el inquilino de origen estará limitada. Después de migrar el buzón al inquilino de destino, Teams en el inquilino de origen ya no tiene acceso al buzón del usuario. Si un usuario inicia sesión en Teams con la credencial de inquilino de origen, se produce una pérdida de funcionalidad, como la incapacidad para actualizar su imagen de perfil, la no aplicación de calendario y la incapacidad de buscar y unirse a equipos públicos.
Cloud MailUsers with non-owned smtp proxyAddress block MRS moves . Al crear objetos MailUser del inquilino de destino, debe asegurarse de que todas las direcciones proxy SMTP pertenecen a la organización del inquilino de destino. Si existe un proxyAddress SMTP en el usuario de correo de destino que no pertenece al inquilino local, se impide la conversión de MailUser en un buzón. Esta prevención se debe a nuestra garantía de que los objetos de buzón solo pueden enviar correo desde dominios para los que el inquilino es autoritativo (dominios reclamados por el inquilino).
Si sincroniza usuarios del entorno local mediante Microsoft Entra Connect en el inquilino de destino, puede aprovisionar objetos MailUser locales con ExternalEmailAddress que apunten al inquilino de origen donde existe el buzón (LaraN@contoso.onmicrosoft.com) y marcar PrimarySMTPAddress como un dominio que reside en el inquilino de destino (Lara.Newton@northwindtraders.com). Estos valores se sincronizan con el inquilino y se aprovisiona un usuario de correo adecuado y está listo para la migración. Aquí se muestra un objeto de ejemplo.
```
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

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

La dirección contoso.onmicrosoft.comno está presente en la matriz EmailAddresses/proxyAddresses.
Los objetos MailUser con direcciones SMTP principales "externas" se modifican o restablecen en dominios "internos" reclamados por la empresa.

Los objetos MailUser son punteros a buzones no locales. En el caso de las migraciones de buzones entre inquilinos, usamos objetos MailUser para representar el buzón de origen (desde la perspectiva de la organización de destino) o el buzón de destino (desde la perspectiva de la organización de origen). MailUsers tendrá una externalEmailAddress (targetAddress) que apunta a la dirección smtp del buzón real (ProxyTest@northwindtraders.onmicrosoft.com) y la dirección primarySMTP que representa la dirección SMTP mostrada del usuario del buzón en el directorio. Algunas organizaciones optan por mostrar la dirección SMTP principal como una dirección SMTP externa, no como una dirección propiedad o comprobada por el inquilino local (por ejemplo, como northwindtraders.com en lugar de como contoso.com). Sin embargo, una vez que se aplica un objeto de plan de servicio de Exchange a MailUser mediante operaciones de licencia, la dirección SMTP principal se modifica para mostrarse como un dominio comprobado por la organización local (contoso.com). Hay dos posibles razones:
Cuando se aplica un plan de servicio de Exchange a un MailUser, el proceso de Microsoft Entra ID comienza a aplicar la depuración de proxy para asegurarse de que la organización local no puede enviar correo, suplantación de identidad o correo desde otro inquilino. Cualquier dirección SMTP de un objeto de destinatario con estos planes de servicio se quitará si la organización local no comprueba la dirección. Como sucede en el ejemplo, el inquilino de contoso.onmicrosoft.com no comprueba el dominio northwindtraders.com; por lo tanto, la limpieza quita ese dominio northwindtraders.com. Si desea conservar estos dominios externos en MailUser, antes o después de la migración, debe modificar los procesos de migración para quitar licencias una vez completado el movimiento o antes del traslado para asegurarse de que los usuarios tienen aplicada la personalización de marca externa esperada. Tendrá que asegurarse de que el objeto de buzón de correo tenga una licencia adecuada para no afectar al servicio de correo. Aquí se muestra un script de ejemplo para quitar los planes de servicio de un objeto MailUser en el inquilino contoso.onmicrosoft.com.

Nota:

El siguiente script usa Microsoft Graph PowerShell. Para obtener más información, consulte Introducción a PowerShell de Microsoft Graph.

Para obtener información sobre cómo usar diferentes métodos para autenticarse Connect-Graph en un script desatendido, consulte el artículo Cmdlets del módulo de autenticación en 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

Los resultados en el conjunto de ServicePlans asignados se muestran aquí:

$order = @(
  @{ Expression = 'ProvisioningStatus'; Ascending = $true }
)
Get-MgUserLicenseDetail -UserId '38955658-c844-4f59-9430-6519430ac89b' | Select-Object -ExpandProperty ServicePlans | sort ProvisioningStatus $order

AppliesTo ProvisioningStatus  ServicePlanId                        ServicePlanName
--------- ------------------  -------------                        ---------------
User      Success             2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2 ADALLOM_S_STANDALONE
User      Success             6c6042f5-6f01-4d67-b8c1-eb99d36eed3e STREAM_O365_E5
User      Success             e212cbc7-0961-4c40-9825-01117710dcb1 FORMS_PLAN_E5
User      Success             07699545-9485-468e-95b6-2fca3738be01 FLOW_O365_P3
User      Success             9c0dab89-a30c-4117-86e7-97bda240acd2 POWERAPPS_O365_P3
User      Success             871d91ec-ec1a-452b-a83f-bd76c7d770ef WINDEFATP
User      Success             21b439ba-a0ca-424f-a6cc-52f954a5b111 WIN10_PRO_ENT_SUB
User      Success             57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
User      Success             8c7d2df8-86f0-4902-b2ed-a0458298f3b3 Deskless
User      Success             8e0c0a52-6a6c-4d40-8370-dd62790dcd70 THREAT_INTELLIGENCE
User      Success             4a51bca5-1eff-43f5-878c-177680f191af WHITEBOARD_PLAN3
User      Success             efb0351d-3b08-4503-993d-383af8de41e3 MIP_S_CLP2
User      Success             617b097b-4b93-4ede-83de-5f075bb5fb2f PREMIUM_ENCRYPTION
User      Success             8c098270-9dd4-4350-9b30-ba4703f3b36b ADALLOM_S_O365
Company   Success             94065c59-bc8e-4e8b-89e5-5138d471eaff MICROSOFT_SEARCH
User      Success             14ab5db5-e6c4-4b20-b4bc-13e36fd2227f ATA
User      Success             3fb82609-8c27-4f7b-bd51-30634711ee67 BPOS_S_TODO_3
User      Success             b1188c4c-1b36-4018-b48b-ee07604f6feb PAM_ENTERPRISE
User      Success             5136a095-5cf0-4aff-bec3-e84448b38ea5 MIP_S_CLP1
User      Success             33c4f319-9bdd-48d6-9c4d-410b750a4a5a MYANALYTICS_P2
User      Success             5689bec4-755d-4753-8b61-40975025187c RMS_S_PREMIUM2
User      Success             4828c8ec-dc2e-4779-b502-87ac9ce28ab7 MCOEV
User      Success             9f431833-0334-42de-a7dc-70aa40db46db LOCKBOX_ENTERPRISE
User      Success             3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40 MCOMEETADV
User      Success             43de0ff5-c92c-492b-9116-175376d08c38 OFFICESUBSCRIPTION
User      Success             0feaeb32-d00e-4d66-bd5a-43b5b83db82c MCOSTANDARD
User      Success             70d33638-9c74-4d01-bfd3-562de28bd4ba BI_AZURE_P2
Company   Success             f20fedf3-f3c3-43c3-8267-2bfdd51c0939 ATP_ENTERPRISE
User      Success             4de31727-a228-4ec3-a5bf-8e45b5ca48cc EQUIVIO_ANALYTICS
User      Success             efb87545-963c-4e0d-99df-69c6916d9eb0 EXCHANGE_S_ENTERPRISE
User      Success             34c0d7a0-a70f-4668-9238-47f9fc208882 EXCHANGE_ANALYTICS
User      Success             8a256a2b-b617-496d-b51b-e76466e88db0 MFA_PREMIUM
User      Success             41781fb2-bc02-4b7c-bd55-b576c07bb09d AAD_PREMIUM
User      Success             bea4c11e-220a-4e6d-8eb8-8ea15d019f90 RMS_S_ENTERPRISE
User      Success             eec0eb4f-6444-4f95-aba0-50c24d67f998 AAD_PREMIUM_P2
User      Success             6c57d4b6-3b23-47a5-9bc9-69f17b4947b3 RMS_S_PREMIUM
User      Success             5dbe027f-2339-4123-9542-606e4d348a72 SHAREPOINTENTERPRISE
User      Success             b737dad2-2f6c-4c65-90e3-ca563267e8b9 PROJECTWORKMANAGEMENT
User      Success             e95bec33-7c88-4a70-8e19-b10bd9d0c014 SHAREPOINTWAC
User      Success             7547a3fe-08ee-4ccb-b430-5077c5041653 YAMMER_ENTERPRISE
User      Success             a23b959c-7ce8-4e57-9140-b90eb88a9e97 SWAY
User      Success             c4801e8a-cb58-4c35-aca6-f2dcc106f287 INFORMATION_BARRIERS
User      Success             b76fb638-6ba6-402a-b9f9-83d28acb3d86 VIVA_LEARNING_SEEDED
Company   Success             db4d623d-b514-490b-b7ef-8885eee514de Nucleus
Company   Success             6f23d6a9-adbf-481c-8538-b4c095654487 M365_LIGHTHOUSE_CUSTOMER_PLAN1
User      Success             a82fbf69-b4d7-49f4-83a6-915b2cf354f4 VIVAENGAGE_CORE
User      Success             9a6eeb79-0b4b-4bf0-9808-39d99a2cd5a3 Windows_Autopatch
User      Success             cd31b152-6326-4d1b-ae1b-997b625182e6 MIP_S_Exchange
User      Success             a413a9ff-720c-4822-98ef-2f37c2a21f4c MICROSOFT_COMMUNICATION_COMPLIANCE
User      Success             795f6fe0-cc4d-4773-b050-5dde4dc704c9 UNIVERSAL_PRINT_01
Company   Success             2b815d45-56e4-4e3a-b65c-66cb9175b560 ContentExplorer_Standard
User      Success             7bf960f6-2cd9-443a-8046-5dbff9558365 WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE
User      Success             3ec18638-bd4c-4d3b-8905-479ed636b83e CustomerLockboxA_Enterprise
User      Success             3efbd4ed-8958-4824-8389-1321f8730af8 MESH_AVATARS_ADDITIONAL_FOR_TEAMS
User      Success             99cd49a9-0e54-4e07-aea1-d8d9f5f704f5 Defender_for_Iot_Enterprise
User      Success             0898bdbb-73b0-471a-81e5-20f1fe4dd66e KAIZALA_STANDALONE
User      Success             c948ea65-2053-4a5a-8a62-9eaaaf11b522 PURVIEW_DISCOVERY
User      Success             a1ace008-72f3-4ea0-8dac-33b3a23a2472 CLIPCHAMP
User      Success             f6de4823-28fa-440b-b886-4783fa86ddba M365_AUDIT_PLATFORM
User      Success             0d0c0d31-fae7-41f2-b909-eaf4d7f26dba Bing_Chat_Enterprise
User      Success             dcf9d2f4-772e-4434-b757-77a453cfbc02 MESH_AVATARS_FOR_TEAMS
User      Success             c4b8c31a-fb44-4c65-9837-a21f55fcabda MICROSOFT_LOOP
User      Success             a6520331-d7d4-4276-95f5-15c0933bc757 GRAPH_CONNECTORS_SEARCH_INDEX
User      Success             e26c2fcc-ab91-4a61-b35c-03cdc8dddf66 INFO_GOVERNANCE
User      Success             46129a58-a698-46f0-aa5b-17f6586297d9 DATA_INVESTIGATIONS
User      Success             9d0c4ee5-e4a1-4625-ab39-d82b619b1a34 INSIDER_RISK_MANAGEMENT
User      Success             65cc641f-cccd-4643-97e0-a17e3045e541 RECORDS_MANAGEMENT
User      Success             d2d51368-76c9-4317-ada2-a12c004c432f ML_CLASSIFICATION
User      Success             bf6f5520-59e3-4f82-974b-7dbbc4fd27c7 SAFEDOCS
User      Success             2f442157-a11c-46b9-ae5b-6e39ff4e5849 M365_ADVANCED_AUDITING
User      Success             41fcdd7d-4733-4863-9cf4-c65b83ce2df4 COMMUNICATIONS_COMPLIANCE
User      Success             6db1f1db-2b46-403f-be40-e39395f08dbb CUSTOMER_KEY
User      Success             6dc145d6-95dd-4191-b9c3-185575ee6f6b COMMUNICATIONS_DLP
User      Success             199a5c09-e0ca-4e37-8f7c-b05d533e1ea2 MICROSOFTBOOKINGS
User      Success             ded3d325-1bdc-453e-8432-5bac26d7a014 POWER_VIRTUAL_AGENTS_O365_P3
Company   Success             d9fa6af4-e046-4c89-9226-729a0786685d Content_Explorer
User      Success             afa73018-811e-46e9-988f-f75d2b1b8430 CDS_O365_P3
User      Success             b21a6b06-1988-436e-a07b-51ec6d9f52ad PROJECT_O365_P3
User      Success             64bfac92-2b17-4482-b5e5-a0304429de3e MICROSOFTENDPOINTDLP
User      Success             bf28f719-7844-4079-9c78-c1307898e192 MTP
User      Success             28b0fa46-c39a-4188-89e2-58e979a6b014 DYN365_CDS_O365_P3
User      Success             d587c7a3-bda9-4f99-8776-9bcf59c84f75 INSIDER_RISK
User      Success             531ee2f8-b1cb-453b-9c21-d2180d014ca5 EXCEL_PREMIUM
User      PendingProvisioning f0ff6ac6-297d-49cd-be34-6dfef97f0c28 MESH_IMMERSIVE_FOR_TEAMS
User      PendingInput        c1ec4a95-1f05-45b3-a911-aa3fa01094f5 INTUNE_A
Company   PendingActivation   882e1d05-acd1-4ccb-8708-6ee03664b117 INTUNE_O365

PrimarySMTPAddress del usuario ya no se limpia. El dominio northwindtraders.com no pertenece al inquilino de contoso.onmicrosoft.com y se conservará como la dirección SMTP principal que se muestra en el directorio.

Aquí le mostramos un ejemplo:

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

Cuando msExchRemoteRecipientType se establece en 8 (DeprovisionMailbox), para los usuarios de correo locales que se migran al inquilino de destino, la lógica de limpieza de proxy de Azure quita los dominios no propiedad y restablece el primarySMTP a un dominio propiedad. Con msExchRemoteRecipientType en el mailUser local que se va a borrar, la lógica de limpieza de proxy ya no se aplica.

A continuación se muestra el conjunto completo de planes de servicio actuales que incluyen Exchange Online:

Nombre
Almacenamiento de eDiscovery (Premium) (500 GB)
Caja de seguridad del cliente
Prevención de pérdida de datos
Servicios de Exchange Enterprise CAL (EOP, DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (plan 1)
Exchange Online (plan 2)
Archivado de Exchange Online para Exchange Online
Archivado de Exchange Online para Exchange Server
Exchange Online complemento de usuario inactivo
Quiosco de Exchange Online
Exchange Online Multi-Geo
Plan 1 de Exchange Online
POP de Exchange Online
Exchange Online Protection
Búsqueda de conectores de Graph con índice
Barreras de información
Information Protection para Office 365 - Premium
Information Protection para Office 365 - Estándar
Conclusiones de MyAnalytics
Gobernanza de información de Microsoft
Auditoría de Microsoft Purview (Premium)
Microsoft Bookings
Centro de negocios de Microsoft
Investigaciones de datos de Microsoft
Microsoft MyAnalytics (Completo)
Cumplimiento de comunicaciones de Microsoft
Microsoft Communications DLP
Clave de cliente de Microsoft
Auditoría avanzada de Microsoft 365
Administración de registros de Microsoft
Office 365 eDiscovery (Premium)
eDiscovery avanzado de Office 365
Microsoft Defender para Office 365 (Plan 1)
Microsoft Defender para Office 365 (plan 2)
Office 365 Privileged Access Management
Cifrado Premium en Office 365

Errores de migración

MailboxNotInCrossTenantMigrationScopeException

Asegúrese de que el ámbito de migración está configurado correctamente en el inquilino de origen y de que MailboxMovesPublishedScopes está establecido en la relación de la organización con el inquilino de destino.
Compruebe que el buzón que se va a migrar se haya agregado al grupo de seguridad del inquilino de origen.
Después de agregar el usuario para corregir el grupo de seguridad, reanude el lote de migración.
AuxArchiveNotFoundInTargetRecipientException

Este error se debe a que el usuario no estaba en el ámbito de migración cuando se inició el lote y el usuario tiene AuxArchive en el origen.
Agregue un usuario al grupo de seguridad correcto en el destino de origen.
Quite el usuario de migración del lote.
Quite los usuarios con el siguiente comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Agregar usuario al nuevo lote.
MailboxIsNotInExpectedDBException

Este error se debe al mantenimiento interno de Microsoft.
Quite el usuario de migración del lote.
Quite los usuarios con el siguiente comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Agregar usuario al nuevo lote.
NotAcceptedDomainException

Hay una dirección de proxy no válida sellada en el usuario de destino. Un ejemplo sería donde un usuario de contoso.onmicrosoft.com tenía una dirección de proxy de fabrikam.onmicrosoft.com, que es el inquilino de origen.
Quite la dirección de proxy no válida mediante el siguiente comando:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
```
Reanude el lote de migración.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

Durante la migración se aprovisionó un nuevo elemento AuxArchive.
Quite el usuario de migración del lote.
Quite los usuarios con el siguiente comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser 
```
Agregar usuario al nuevo lote.
UserDuplicateInOtherBatchException

El usuario ya existe en otro lote.
Quite el usuario de migración del lote.
Quite los usuarios con el siguiente comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Agregar usuario al nuevo lote.
MissingExchangeGuidException

Al objeto mailuser de destino le falta el valor de ExchangeGuid correcto.
Actualice ExchangeGuid con el siguiente comando:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8  
```
Reanude el lote de migración.
SourceMailboxAlreadyBeingMovedPermanentException

El buzón de origen ya tiene una solicitud de movimiento existente. Investigue y quite el movimiento existente. Es posible que se trata de un movimiento interno de Microsoft y que tenga que esperar a que se complete el traslado.
Quite el usuario de migración del lote.
Quite los usuarios con el siguiente comando:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Agregue el usuario al nuevo lote una vez que se haya quitado o completado el movimiento original.
UserAlreadyHasDemotedArchiveException

El usuario tenía un buzón de archivo previamente deshabilitado. Elija una de las dos opciones siguientes para resolver este problema.
Elimine permanentemente el buzón de archivo deshabilitado, lo que no se puede revertir. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Vuelva a habilitar el buzón de archivo deshabilitado con el siguiente comando:
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
Si vuelve a habilitar el buzón de archivo deshabilitado, deberá actualizar el guid de archivo en el objeto mailuser de destino.
Reanude el lote de migración.

Consulte también

Administrar Microsoft 365 con PowerShell
Introducción al SDK de Microsoft Graph de Powershell
[https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]

Compartir a través de

Migración de buzones de inquilinos cruzados

Licencias

Preparación de inquilinos de origen y destino

Requisitos previos para inquilinos de origen y destino

Pasos de configuración para habilitar los inquilinos para migraciones de buzones entre inquilinos

Preparación del inquilino objetivo (destino) mediante la creación de la aplicación de migración y el secreto

Concesión de consentimiento a la aplicación

Prepare el inquilino de destino mediante la creación del extremo de migración de Exchange Online y la relación de la organización

Prepare el inquilino de origen (ubicación actual del buzón de correo) aceptando la aplicación de migración y configurando la relación de la organización.

Preparación de objetos de usuario de destino para la migración

Requisitos previos para objetos de usuario de destino

¿Cómo saber si el proceso se ha completado correctamente?

Volver a mover los buzones al origen original

Realizar migraciones de buzones

Creación de lotes de migración

Actualización de MailUsers local

Eliminación de puntos de conexión y relaciones de la organización después de la migración

Preguntas frecuentes

¿Es necesario actualizar RemoteMailboxes en el inquilino local de origen después del traslado?

Organización de Exchange de origen

Organización de Exchange de destino

¿Las reuniones de Teams migran entre inquilinos?

¿Qué contenido se migra entre inquilinos?

¿Los elementos de la Bandeja de salida se migran entre inquilinos?

¿El contenido de la carpeta de chat de Teams migra entre inquilinos?

¿Cómo puedo ver solo movimientos que son movimientos entre inquilinos, no mis movimientos de incorporación y desembarque?

¿Puede proporcionar scripts de ejemplo para copiar los atributos usados en las pruebas?

¿Cómo se accede a Outlook el día 1 después de mover el buzón de usuario?

¿De qué roles de RBAC de Exchange debo ser miembro para configurar o completar un traslado entre inquilinos?

¿Cómo se destina a qué dirección SMTP se selecciona targetAddress (TargetDeliveryDomain) en el buzón convertido (a la conversión MailUser)?

¿Cómo funciona el flujo de correo después de la migración?

¿Cómo se realiza la transición de los permisos de buzón de correo?

¿Qué proxy X500 se debe agregar a las direcciones proxy de MailUser de destino para habilitar la migración?

¿Pueden los inquilinos de origen y de destino usar el mismo nombre de dominio?

¿Los buzones compartidos se moverán y seguirán funcionando?

¿Tiene alguna recomendación para lotes?

¿Qué ocurre si uso el cifrado de servicio con la clave de cliente de Microsoft Purview?

¿Cuál es el tiempo de migración estimado?

Protección de documentos en el inquilino de origen que los usuarios del inquilino de destino consumen.**

¿Puedo tener las mismas etiquetas en el inquilino de destino que tenía en el inquilino de origen, ya sea como el único conjunto de etiquetas o un conjunto adicional de etiquetas para los usuarios migrados en función de la alineación entre las organizaciones.**

¿Admite el traslado de Grupos de Microsoft 365?

¿Puede un administrador de inquilinos de origen realizar una búsqueda de exhibición de documentos electrónicos en un buzón después de migrar el buzón al inquilino nuevo o de destino?

¿En qué momento se convertirá el mailuser de destino en un buzón de destino y el buzón de origen se convertirá en un mailuser de origen?

¿En qué paso debo asignar la licencia de Exchange Online a mailUsers de destino?

¿Puedo usar Microsoft Entra Connect para sincronizar usuarios con el nuevo inquilino si manteno el Active Directory local?

¿Cómo debo controlar los buzones que están cerca o por encima de la cuota?

¿Se mueven los buzones de archivo expandidos automáticamente?

¿Puedo realizar una migración entre inquilinos a inquilinos entre nubes?

¿Los buzones de voz se migran entre inquilinos?

¿Se migran las firmas de buzón entre inquilinos?

Problemas conocidos

Errores de migración

Consulte también

Comentarios

Recursos adicionales