Exchange Hybrid conecta una organización de Exchange local con Exchange Online. Los usuarios pueden tener buzones en ambos lados y, aun así, utilizar los mismos dominios SMTP, una libreta de direcciones común y determinadas funciones entre organizaciones. Por ello, Hybrid es más que un par de conectores: conecta datos de directorio, destinatarios, autenticación, Autodiscover, funciones de calendario, migración y transporte de correo (Implementaciones híbridas de Exchange).
Aclare primero tres preguntas: ¿Dónde está el buzón? ¿Dónde se administra su objeto de destinatario? Y ¿qué servicio ejecuta la operación solicitada? Cuando estas tres respuestas están claras, los numerosos componentes híbridos se convierten en una cadena comprensible.
Comandos relacionados
Comandos listos para usar sobre Exchange Hybrid para PowerShell y la shell de Unix, con ejemplos para copiar.
Artículos sobre Exchange Hybrid (5)
- 7 sept 2026 EXO-Enforcement 09/2026 Exchange Online limita y bloquea servidores Exchange 2016 y 2019 obsoletos a partir de septiembre de 2026: así funciona el enforcement de transporte
- 26 ago 2026 AuthMechanism 10 AuthMechanism 10 y AuthAs Internal: cómo Exchange clasifica la entrega en el encabezado
- 26 ago 2026 Leer encabezados híbridos ¿Interno o externo? Clasificar correos híbridos de Exchange en los encabezados: AuthAs, MessageDirectionality y X-originatorOrg
- 11 ago 2026 Analizar el flujo de correo Análisis del flujo de correo de Exchange: seguimiento de mensajes, registros SMTP y conectores de recepción
- 11 ago 2026 IP de entrega ¿Quién entrega realmente correo a su tenant? Agregar direcciones IP de entrega
Lo que Hybrid reúne para los usuarios
Sin Hybrid, la organización local de Exchange y Exchange Online son dos sistemas separados. Hybrid crea una experiencia de usuario común. Los buzones pueden utilizar el mismo dominio SMTP principal. La información de la libreta de direcciones se sincroniza. Las consultas de libre/ocupado y MailTips pueden funcionar entre organizaciones. Los buzones se pueden mover mediante Remote Moves compatibles (Implementaciones híbridas de Exchange).
Sin embargo, estas funciones no comparten un único almacén de datos común. Un buzón local permanece en una base de datos ESE local; un buzón en la nube permanece en Exchange Online. Active Directory y Entra ID mantienen objetos de directorio respectivamente. Las relaciones de organización y OAuth permiten consultas seleccionadas a través de ese límite. Los conectores SMTP transportan mensajes. El visible «un solo Exchange» surge de conexiones coordinadas.
Para los administradores, de ello se deriva una regla importante: un flujo de correo correcto no demuestra que libre/ocupado funcione, y una consulta de libre/ocupado correcta no demuestra que sea posible un Remote Move. Cada función tiene su propio camino y sus propias evidencias.
Los componentes en un orden lógico
Una implementación híbrida comienza con sus requisitos, no con el asistente. La organización local de Exchange debe estar en una versión compatible. Los nombres públicos, certificados, DNS, accesibilidad HTTPS y SMTP deben ser correctos. Un tenant de Microsoft 365 con Exchange Online y una sincronización de directorios compatible conectan posteriormente las identidades (Requisitos previos para implementaciones híbridas).
Sobre ello se basa el Hybrid Configuration Wizard, HCW. Lee la configuración deseada, escribe un objeto HybridConfiguration en el Active Directory local y configura los ajustes adecuados localmente y en Exchange Online. Estos pueden incluir relaciones de organización, OAuth, conectores intraorganizativos y conectores de transporte (Hybrid Configuration Wizard, Crear una implementación híbrida).
| Componente | Tarea básica | Qué se comprueba primero ante un fallo |
|---|---|---|
| Active Directory | atributos locales de usuarios y Exchange | Objeto, tipo de destinatario, direcciones proxy y hora de modificación |
| Sincronización de Entra | transfiere atributos compatibles de identidad y destinatarios | Errores de exportación, estado de sincronización y objeto en la nube |
| Exchange Online | buzón y configuración en la nube | Tipo de destinatario, licencia, estado del buzón y RBAC |
| Configuración de HCW | coordina las dos organizaciones de Exchange | Registro de HCW, parámetros seleccionados y objetos modificados posteriormente |
| Relación de organización y OAuth | funciones entre organizaciones | URI de destino, Autodiscover, certificados y flujo de tokens |
| Conectores SMTP | mensajes entre ambos lados | Nombre del certificado, host de origen/destino, TLS y Message Trace |
La tabla también muestra por qué «ejecutar HCW de nuevo» no es una reparación universal. El asistente puede volver a coordinar objetos híbridos documentados. No repara una zona DNS defectuosa, una ruta de firewall bloqueada ni un objeto de destinatario mantenido incorrectamente.
Pila tecnológica: protocolos y herramientas de administración
Hybrid no es un proceso adicional de servidor Exchange, sino una conexión de sistemas existentes. Active Directory y Entra ID mantienen identidades y atributos de destinatarios. La sincronización de Entra transfiere valores compatibles. HTTPS transporta Autodiscover, libre/ocupado, llamadas de servicio protegidas por OAuth y movimientos de buzones. SMTP con TLS transporta mensajes. PowerShell, Exchange Admin Center y HCW administran los objetos implicados (Requisitos previos para implementaciones híbridas, Hybrid Configuration Wizard).
Esta división también determina el orden ante incidencias. Un error de objeto se busca en el directorio y la sincronización, un problema de calendario en la ruta HTTPS/OAuth y un problema de correo en SMTP y los conectores. Así, el conjunto de herramientas permanece vinculado a la función afectada.
Sincronización de directorios y autoridad de destinatarios
Una vez conectadas las plataformas, el origen de los datos de destinatarios se convierte en la cuestión operativa más importante. En entornos híbridos clásicos, un usuario se crea en el Active Directory local. Las herramientas de Exchange escriben los atributos relacionados con el correo. Entra Connect sincroniza el objeto con la nube, donde Exchange Online proporciona el objeto en la nube correspondiente y, en su caso, un buzón (Requisitos previos para implementaciones híbridas).
Un Remote Mailbox es un objeto local habilitado para correo que hace referencia a un buzón de Exchange Online. Atributos como remoteRoutingAddress, proxyAddresses y el tipo de destinatario ayudan a la organización local a dirigir mensajes y administración hacia la nube. Enable-RemoteMailbox crea o habilita esta representación local; el buzón en la nube solo se crea mediante sincronización y asignación de licencia.
Por tanto, la pregunta habitual del administrador es: ¿dónde debo modificar este valor? La pregunta experta es: ¿qué sistema es autoritativo para este atributo concreto y qué ciclo de sincronización lo transfiere? Un portal en la nube puede mostrar un valor sincronizado sin permitir editarlo de forma permanente.
Microsoft admite escenarios en los que solo permanecen las Exchange Management Tools para los atributos locales de destinatarios. Para determinados entornos, también existe un procedimiento para transferir a la nube la administración de atributos de Exchange. Son modelos operativos distintos con requisitos; desactivar el último servidor por sí solo no transfiere la autoridad sobre los datos (Administrar destinatarios con Exchange Management Tools, Retirar después de la transferencia de Source of Authority).
Autodiscover y la ruta del cliente
Cuando los destinatarios son correctos, un cliente debe encontrar la ubicación del buzón. Autodiscover responde a esta pregunta. Los puntos de conexión locales de Exchange pueden redirigir a un cliente con un buzón en la nube a Exchange Online; los puntos de conexión en la nube proporcionan la configuración del buzón en línea (Autodiscover en implementaciones híbridas de Exchange).
Por ello, un problema de Autodiscover híbrido suele manifestarse como una ubicación incorrecta: el usuario puede iniciar sesión en principio, pero llega al punto de conexión local, recibe una redirección inesperada o recibe configuraciones para un buzón que ya no existe. DNS, SCP, directorios virtuales, certificados y atributos de destinatarios se comprueban en este orden.
Solo después de que el cliente haya llegado al servicio de buzón correcto tienen sentido las cuestiones de protocolo y permisos. Así, el diagnóstico sigue siendo comprensible: primero encontrar, después iniciar sesión y luego autorizar.
Libre/ocupado y otras funciones entre organizaciones
Una libreta de direcciones común no basta para las consultas de calendario. Libre/ocupado requiere relaciones de organización, Autodiscover accesible y una configuración de confianza u OAuth funcional. Exchange consulta información en el otro lado en lugar de copiar completamente los datos de calendario en su propio sistema (Uso compartido en implementaciones híbridas de Exchange).
El mismo patrón básico se aplica a otras funciones híbridas: un componente local realiza una solicitud, la contraparte la autentica, autoriza la operación y devuelve un resultado limitado. Por ello, durante la resolución de problemas se registran el buzón de origen, el buzón de destino, la dirección y el punto de conexión. «Libre/ocupado no funciona» es demasiado impreciso sin estos datos.
Para los expertos, los tokens y los URI de destino se vuelven relevantes. HCW configura relaciones entre organizaciones, pero los cambios de certificados, las modificaciones manuales o los puntos de conexión obsoletos pueden afectar a la operación posterior. La configuración de ambos lados siempre se exporta conjuntamente.
OAuth entre las organizaciones de Exchange
Una vez claro qué consultas entre organizaciones se realizan, se puede clasificar su autenticación. Exchange puede utilizar OAuth para que una organización acredite una llamada de servicio ante la otra. Esto afecta a funciones híbridas como disponibilidad entre organizaciones y determinadas operaciones de archivado, búsqueda o migración; el uso exacto depende de la versión y la configuración (Configurar la autenticación OAuth).
El flujo de tokens no sustituye a SMTP-TLS. OAuth protege llamadas de aplicaciones, mientras que el transporte de correo híbrido utiliza sus propios conectores y comprobaciones de certificados. Esta separación evita el salto que confunde en muchas explicaciones: primero se determina la función, luego su protocolo y solo después la autenticación.
Para los expertos, AuthConfig, AuthServer, PartnerApplication, Intra-Organization Connector y Organization Relationship forman parte de una visión de comprobación conjunta. Un objeto individual puede estar presente sintácticamente mientras el certificado, el realm o el URI de destino ya no coinciden con la contraparte.
Hybrid Modern Authentication es un tema independiente del cliente
Hybrid Modern Authentication, HMA, se aborda solo ahora porque no explica el transporte de correo ni la sincronización de destinatarios. HMA permite que los recursos locales compatibles de Exchange y Skype for Business utilicen Microsoft Entra ID para la autenticación moderna de clientes. El cliente obtiene un token de Entra y lo utiliza ante el servicio local (Descripción general de Hybrid modern authentication).
Por tanto, HMA amplía el acceso de clientes con una dependencia de la nube. La accesibilidad de Entra, las URL publicadas, los Service Principal Names registrados y la configuración local de Exchange deben coincidir. Un flujo de correo híbrido funcional no dice nada sobre esta ruta de tokens.
Por ello, los expertos tratan HMA en un runbook independiente con versiones compatibles, exclusiones, grupos de despliegue y plan de reversión. La función no se añade de forma incidental a una opción de enrutamiento.
Movimientos de buzones
La coexistencia se establece con frecuencia para mover buzones gradualmente. Un Remote Move copia datos del buzón mediante Mailbox Replication Service, mantiene los cambios sincronizados y cambia el buzón de forma controlada al lado de destino. Los atributos de destinatario y el enrutamiento se trasladan o ajustan en el proceso (Mover buzones entre entornos locales y Exchange Online).
Para administradores avanzados, el proceso consta de preparación, inicio, sincronización, finalización y comprobación posterior. Antes de finalizar, se comprueban el volumen de datos, elementos con errores, delegaciones, archivos, acceso de clientes y flujo de correo. Después de finalizar, Autodiscover, licencia, dirección de destino y el objeto local Remote Mailbox deben coincidir.
Los expertos planifican tamaños de lotes, rendimiento de red, limitación de MRS, límites de elementos defectuosos, objetos grandes y migración inversa. El valor de progreso técnico por sí solo no equivale a una aceptación; también se incluyen el acceso de usuarios, las delegaciones, los clientes móviles y las funciones entre organizaciones.
El flujo de correo híbrido sigue siendo una ruta independiente
Hybrid necesita SMTP entre la organización local y Exchange Online. Esta ruta de correo utiliza conectores, TLS y certificados. Es lo suficientemente importante como para un artículo propio, porque el correo de Internet, Centralized Mail Transport, las puertas de enlace de correo y los dominios compartidos forman varias variantes (Requisitos previos para implementaciones híbridas).
El artículo Flujo de correo híbrido comienza con un mensaje concreto y sigue cada salto. Solo allí se comparan Centralized Mail Transport, IP de salida, ubicación del filtrado y colas adicionales. Este artículo se concentra en identidad y coexistencia.
Seguridad y operación
Hybrid amplía los sistemas accesibles. Los puntos de conexión HTTPS y SMTP públicos, certificados, sincronización de Entra, cuentas con privilegios y objetos de confianza entre organizaciones deben inventariarse conjuntamente. HCW necesita permisos amplios en ambos lados; su uso y sus registros deben protegerse y archivarse de manera trazable (Hybrid Configuration Wizard).
En el día a día, cada función híbrida debe tener un responsable y una prueba: sincronización de destinatarios, libre/ocupado en ambas direcciones, Remote Move, Autodiscover y SMTP en ambas direcciones. Una prueba sintética periódica detecta certificados vencidos o puntos de conexión modificados silenciosamente antes que un proyecto de migración.
Ante incidencias, ayuda una línea temporal común. Los eventos de sincronización de Entra, el registro de HCW, los registros de eventos de Exchange, las pruebas de OAuth, el seguimiento de mensajes y Message Trace no se recopilan indiscriminadamente, sino que se asignan a la función afectada. Esto acorta el diagnóstico y evita que una prueba correcta de otra función se interprete como evidencia.
Copia de seguridad, reconstrucción y retirada
Los datos de los buzones se protegen en el lado donde se encuentran: bases de datos locales con recuperación local, buzones en la nube con funciones de Exchange Online y Purview. Además, la conexión debe poder restaurarse. Esto incluye el objeto local HybridConfiguration, certificados y claves privadas, configuración de conectores y organizaciones, reglas de sincronización de Entra y decisiones documentadas de HCW.
Una reconstrucción comienza con identidad y resolución de nombres, seguida de accesibilidad HTTPS y SMTP, configuración de HCW y pruebas funcionales. El asistente puede volver a crear la configuración, pero sin certificados, DNS y objetos de destinatarios adecuados no se obtiene un sistema global funcional.
Durante la retirada, primero se aclara qué funciones híbridas siguen utilizándose. Microsoft diferencia entre un servidor restante, herramientas de administración puras y la transferencia a la nube de la administración de atributos de Exchange. Solo después de esta decisión se eliminan de forma controlada conectores, relaciones de organización, puntos de conexión y servidores (Administrar destinatarios con Exchange Management Tools, Retirar después de la transferencia de Source of Authority).
Evolución técnica y límites
Hybrid surgió con Exchange Online como una forma de ampliar de manera controlada las organizaciones locales hacia el servicio en la nube. Las generaciones anteriores utilizaban en mayor medida Federation Trusts; las versiones más recientes de Exchange y los flujos de HCW usan OAuth e Intra-Organization Connectors para muchas funciones entre organizaciones (Crear una implementación híbrida).
El modelo es potente porque permite la migración y la coexistencia permanente. Es exigente porque deben operarse ambas organizaciones de Exchange y su conexión. Por ello, quien ya no tenga buzones locales después de una migración debe decidir conscientemente qué función de administración o coexistencia sigue justificando Hybrid.
Fuentes
- Microsoft Learn – Implementaciones híbridas de Exchange
- Microsoft Learn – Active Directory en Exchange Server
- Microsoft Learn – Destinatarios en Exchange Online
- Microsoft Learn – Requisitos previos para implementaciones híbridas
- Microsoft Learn – Hybrid Configuration Wizard
- Microsoft Learn – Crear una implementación híbrida
- Microsoft Learn – Enable-RemoteMailbox
- Microsoft Learn – Administrar destinatarios con Exchange Management Tools
- Microsoft Learn – Retirar después de la transferencia de Source of Authority
- Microsoft Learn – Servicio Autodiscover
- Microsoft Learn – Uso compartido en Exchange
- Microsoft Learn – Configurar la autenticación OAuth
- Microsoft Learn – Descripción general de Hybrid modern authentication
- Microsoft Learn – Mover buzones entre entornos locales y Exchange Online
- Microsoft Learn – Migración de buzones entre tenants
