Intercambio de cola & A: Entornos híbridos

Configuración de implementaciones de Exchange híbrido con la funcionalidad de Office 365 puede ser confuso en el mejor, pero vale la pena el esfuerzo.

Henrik Walther

Coexistencia de híbrido

P. Actualmente nos estamos configurando una implementación híbrido basado en Exchange 2010. Nos estamos preparando para migrar los buzones de la organización de Exchange 2007 local a Exchange Online en Office 365. Estamos utilizando servidores basados en Exchange 2010 para el despliegue de híbrido, porque aún no hemos aumentamos a nuestro inquilino de Office 365.

Somos una gran empresa con los usuarios de Exchange con más de 30 diferentes dominios SMTP. Contamos con usuarios con muchos campos de dirección de correo electrónico primaria diferentes. Algunos utilizan alias@contoso.com, otros utilizan alias@fabrikam.com y así sucesivamente. Queremos convivencia al trabajar con Exchange Online y la organización de Exchange 2007 local para todos los usuarios.

¿Esto requeriría que cree un registro DNS de detección automática para todos los dominios SMTP, así como añadir la detección automática completamente calificado nombre de dominio (FQDN) del certificado de red (SAN) de área de almacenamiento estamos planeando utilizar en los servidores de Exchange 2010 híbrido?

**R.**Con mayores servidores híbridos, es decir, híbrido servidores Exchange 2010, es necesario crear un registro de detección automática en DNS para todos los dominios SMTP. Además, el certificado de SAN debe incluir todos los registros DNS detección automática utilizada en la lista de SAN. Por ejemplo, si usted utiliza tres dominios SMTP (contoso.com, fabrikam.com y wingtiptoys.com) en la organización de Exchange y quería configurar la coexistencia de los tres con Exchange Online en Office 365, necesitará crear los siguientes registros de detección automática de DNS:

• Autodiscover.contoso.com
• Autodiscover.fabrikam.com
• Autodiscover.wingtiptoys.com

También tendría que incluir estos registros en el certificado de SAN. Podría utilizar registros CNAME para el redireccionamiento de detección automática, pero que no cambiaría el hecho de que tienes que añadir todos los registros de detección automática del certificado de SAN. También, implementaciones de Exchange híbrido no soportan detección automática basada en el SRV redirección.

Con la característica de detección automática dominio, tienes la opción de configuración de uno de sus dominios SMTP como el dominio de detección automática. Al hacerlo, eliminas los siguientes requisitos:

• La necesidad de crear un registro de detección automática para todos los dominios SMTP en DNS, excepto el dominio que se define como el dominio de detección automática
• La necesidad de incluir el FQDN Autodiscover en todos los dominios SMTP para el certificado de SAN

Este hecho es una gran novedad del Exchange Server 2013. El grupo de producto de Exchange siempre introduce novedades en la versión más reciente, pero ahora y después también elegir al puerto de la parte posterior una característica a una versión anterior de Exchange. En cuanto a la función de dominio de detección automática, esto sucedió con el lanzamiento de Exchange 2010 SP3 RU1 (se puede descargar aquí). Sí, al aplicar RU1, puede utilizar la función de dominio de detección automática en una configuración híbrida basada en Exchange 2010. Para establecer el dominio de detección automática, utilice el siguiente comando:

Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

Entonces puedes ver el dominio de detección automática se ha creado al ejecutar el cmdlet Get-HybridConfiguration (ver figura 1).

Figura 1 ejecutar el cmdlet Get-HybridConfiguration para confirmar el dominio de detección automática se establece.

Faltantes de mensajes

P. Sólo hemos configurado un despliegue basado en Exchange 2010 híbrido para levantarse la coexistencia de intercambio y entre Exchange 2003 y Exchange Online en Office 365. Debido a requieren flujo de correo entre Exchange Online para ir a través de nuestros servidores de híbrido local Exchange 2010, elegimos la siguiente opción en el Asistente de configuración híbrida para configurar transporte centralizado: "Enrutar todos los mensajes de Internet enlazados a través de los servidores de intercambio local. Esto normalmente se hace por razones de cumplimiento de normas."

Hemos configurado el despliegue de híbrido por el libro. Vemos el Asistente de configuración de híbrido creado necesarias para recibir y enviar conector local y los conectores de entrada y de salida en Forefront Online Protection para intercambio (FOPE). El nombre de dominio que se utiliza para forzar el TLS de FOPE a los servidores de híbrido local es en el certificado de terceros en los servidores de híbrido. Esté bien configurada en "recibir para conector que acepta sesiones SMTP de las gamas de la FOPE IP".

A pesar de todo esto, nunca salen de e-mails enviados desde Exchange Online en Office 365 a destinatarios en las organizaciones de intercambio local (así como destinatarios externos). Cuando se utiliza el mensaje de seguimiento en el centro de administración de la FOPE, vemos el siguiente error:

"Dirección IP de destino primario 451 4.4.0 respondido con: 'Error de validación del certificado de 454 4.7.5.' Intento failover a host alternativo, pero no tuvo éxito."

Realmente estamos atascados aquí. ¿Nos preguntamos si usted tiene alguna idea sobre cómo solucionar esto más?

**R.**En realidad, he visto este mensaje de error en un escenario de implementación de Exchange 2010 híbrido. Cuando la configuración de una configuración híbrida usando el Asistente de configuración de híbrido, una de las cosas crea es recibir un nuevo conector denominado "entrada de Office 365" en cada servidor de transporte híbrido (ver figura 2).

Figura 2 Asistente para la configuración de híbrido crea la nueva entrada de conector de recepción oficina 365.

Este conector se encuentra a sólo aceptar las sesiones SMTP entrantes de un conjunto específico de intervalos de direcciones IP, que están asociados con el servicio de la FOPE usado en Office 365 (ver figura 3).

Figura 3 sólo la entrada de Office 365 conector de recepción recibe mensajes de un conjunto específico de direcciones IP.

Recibir este conector también se establecerá en el FQDN que coincide con el FQDN en el certificado utilizado para el despliegue de híbrido (ver figura 4).

Figura 4 la entrada de configuración de Office 365 conector de recepción coincide con el FQDN en el certificado de híbrido.

Esto también se encuentra en el certificado para que coincida con el FQDN en el conector de salida de la FOPE, así que usted puede utilizar obligado TLS. Todo esto fue establecido por el libro, como explicas que hizo, pero sigue generando el mismo mensaje de error que recibiste mensajes salientes de Exchange Online.

Al tiempo que miraba el registro del Protocolo para el conector de recepción en los servidores de híbrido, vi algo extraño. Las sesiones SMTP entrantes de la FOPE iban por defecto recibir conector. Porque se extiende la IP correcta y otras opciones eran correctos en el Office 365 recibir conector, este no hecho tiene sentido. Entonces, me di cuenta de que aunque las sesiones SMTP entrantes se presentaron como FOPE, la dirección IP de origen era una dirección IP privada. Resulta que era una dirección IP virtual (VIP) en un equilibrador de carga que distribuyen las sesiones SMTP entrantes a través de los servidores híbridos Exchange 2010.

He añadido el privado VIP a la lista de rangos IP de servidor remoto en el Office 365 recibir conector. A continuación, los mensajes fueron entregados con éxito. Si usas un equilibrador de carga para SMTP, verifique si usted está tratando con el mismo problema.

La tecla derecha

P. Ya hemos configurado sólo dos servidores de híbridos Exchange Server 2013. ¿Nos preguntamos si podemos utilizar una tecla de edición Exchange Server 2013 híbrido para estos servidores como podemos con servidores de Exchange 2010 híbridos?

**R.**Cosas todavía están siendo resuelto ahora mismo cuando se trata de la clave del producto utilizado para licencias correctamente Exchange Server 2013 como un servidor híbrido. Así que por ahora, sólo tiene que utilizar Exchange Server 2013 en modo de prueba. Cuando caduque la prueba, no tiene ningún impacto acerca de su implantación de híbrido. Sólo resultará en pantallas de nag extra.

Henrik Walther es un maestro certificado de Microsoft: Exchange 2007 y Exchange MVP con más de 18 años de experiencia en el negocio de ti. Trabaja como Consultor en el equipo de nube Office 365 con Microsoft servicios Dinamarca y como un escritor técnico para Biblioso Corp. (una empresa estadounidense especializada en gestión servicios de documentación y localización). Tiene más de 14 años de experiencia escribiendo libros, artículos, columnas, white papers y boletines.

Contenido relacionado

• Intercambio de cola & A: Soluciones viables

• Intercambio de cola & A: Administración de la migración

• Intercambio de cola & A: Intercambio está siempre cambiando