Contenido
Al mudarse deServidor Exchange local para Office 365o Exchange Online, el método híbrido de migración proporciona el proceso de migración más fluido. Pero también es el más largo. La configuración híbrida permite enviar datos a la nube sin afectar los buzones de correo de los usuarios. Esto también permite migrar carpetas públicas.
Sin embargo, hay una serie de problemas y errores que se pueden encontrar durante la migración. En este artículo, discutiremos laEndpointNotFoundTransientExceptionerror que se puede encontrar durante la migración y las posibles soluciones para resolverlo.
sobre el error
El error se produce al ejecutar un lote de migración de carpetas públicas desde la inicialización de Exchange Server local a Exchange Online. Después de ejecutar el comando, obtendrá elEndpointNotFoundTransientExceptionerror. Podría incluir los siguientes detalles:
- No había ningún punto final escuchando en https://mail..com/EWS/mrsproxy.svc que pudiera aceptar el mensaje.
- El servidor remoto devolvió un error: (404) No encontrado.
Prueba de los puntos finales
Debe asegurarse de que la conectividad de migración y la configuración del extremo de la carpeta pública sean correctas. Puede hacerlo ejecutando el siguiente comando en Exchange Management Shell (EMS).
Test-MigrationServerAvailability -Endpoint <endpoint name>
Esto confirmará si la configuración es correcta. Si hay algún problema, debe volver a visitar la configuración de la configuración híbrida.
Solución de problemas del problema
En primer lugar, debe verificar si hay algún problema de configuración con su Exchange Server. Aunque la migración híbrida es la más fluida, debe asegurarse de que Exchange Server esté en óptimas condiciones. Si la prueba no fue exitosa y la migración no funcionó, puede acceder a la situación con su caja local.
Ahora necesita verificar la red. Debe asegurarse de que haya un pasaje abierto entre Exchange Online y Exchange Server. Debe confirmar que no hay limitación o que los puertos no están bloqueados por el Firewall de Windows o el firewall de la red. Puede confirmar con los administradores de su red y servidor que todo está abierto entre los dos sistemas.
El siguiente paso es asegurarse de que Exchange Server esté completamente parcheado con las actualizaciones acumulativas (CU) más recientes, incluidos los parches de seguridad del sistema operativo. Todos los servicios necesarios deben estar funcionando y la configuración, sitios web (OWA y EWS) y Outlook En cualquier lugar están trabajando sin problemas. Puede verificar con sus administradores de Exchange para asegurarse de que todo funcione bien.
La otra cosa que debe confirmar es que está utilizando el SourcePFPrimaryMailboxGuid correcto al crear el lote de migración. Debe confirmar que se ha especificado el GUID del servidor de Exchange local.
Para confirmar esto, debe verificar SourcePFPrimaryMailboxGuid. Puede usar el siguiente procedimiento para asegurarse de que se usó el GUID de Exchange Server local.
Primero, conéctese a Exchange Online PowerShell para que pueda consultar Exchange Online. A continuación, identifique elFuentePFPrimaryMailboxGuidvalor del parámetro que ha especificado en el lote de migración. Esto se puede hacer ejecutando el siguiente comando.
(Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"}).SourcePFPrimaryMailboxGuid
Lo siguiente es verificar que el GUID que proporcionó es de Exchange Online ejecutando el comando Get-Mailbox como se indica a continuación.
Get-Mailbox -PublicFolder <GUID from previous command>
El GUID que se muestra en el paso anterior debe coincidir y no se creó el lote de migración.
Soluciones posibles
Para resolver el problema del GUID incorrecto, puede volver a crear el trabajo de migración. Para esto, use el Shell de administración de Exchange y ejecute el siguiente comando para obtener el GUID del buzón de correo de la carpeta pública del servidor de Exchange local.
(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid.GUID
El siguiente paso es volver a crear el lote de migración en Exchange Online eliminando el lote actual como se indica a continuación.
Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"} | Remove-MigrationBatch
Tomará de 10 a 15 minutos para que la eliminación surta efecto. Esto se puede confirmar usando el siguiente comando.
Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"}
El siguiente paso es crear el lote de migración desde cero utilizando el GUID correcto del servidor local.
Si esto funcionó, debería poder ejecutar los lotes. De lo contrario, debe buscar en Exchange Server, la red u otras configuraciones.
Conclusión
A veces, al tratar de solucionar un problema, se necesitaría una cantidad considerable de tiempo y recursos. También puede terminar empeorando las cosas o incluso la pérdida de datos. Para una migración sin problemas y un ahorro de tiempo, puede utilizar unHerramienta de conversión de EDB a PST, como Stellar Converter para EDB. Con esta herramienta, puede abrir fácilmente el archivo EDB, navegar por la base de datos y exportar la carpeta pública a PST y otros formatos. También puede exportar directamente carpetas públicas, buzones de correo, buzones de archivo, buzones de correo compartidos y buzones deshabilitados directamente a Office 365. La herramienta cuenta con coincidencia automática de buzones, exportaciones paralelas, sin límite de tamaño, exportaciones prioritarias y continuación en caso de falla.
