Hola a todos,

Repasando todo lo he escrito sobre Office 365, Exchange Online y la hibridación de entornos, veo que tengo bastantes artículos pero que están dispersos en el tiempo así que he decidido recopilar todos los enlaces en entra entrada para facilitar su búsqueda.

Empezamos listando los referidos al montaje de la infraestructura necesaria para federar nuestro AD y seguimos con la de migración desde un entorno On-Premises a uno cloud

• Migración a Office 365:
• Parte 1: Instalación y configuración de AD FS
• Parte 2: Migración desde Exchange On-premises a Exchange Online

Y finalizamos con la última serie, sobre tener un entorno híbrido

• Hibridación de un entorno On-premise
• Primeros en el proceso, divididos en la parte 1 y parte 2
• Qué cambios se producen en el proceso, aquí
• Un Edge Server en la organización, también con su parte 1 y su parte 2

Espero que os sirva

Saludos,

Marc

Hola,

Siguiendo con la última entrada, voy a proceder a explicar qué cambios implica hacer en la organización cuando se tiene un Edge Server en un entorno híbrido Exchange On-Premises <-> Exchange Online

El problema es que al necesitar que el Edge Server tenga Service Pack 3 para ser plenamente compatible con Exchange Online Protection (EOP), va a obligar a actualizar al menos un Hub Transport a este mismo Service Pack 3, o no se podrán usar las suscripciones de envío entre ambos sistemas. Por propia experiencia .

Empezaremos los cambios por el Edge Server, donde hemos de importar el certificado público que tengamos instalado en los HT – el que usaremos para la hibridación –  de modo que la comunicación por TLS entre ambos entornos, On-Premises y Tenant, funcione correctamente. Después de importarlo, lo habilitamos para el servicio SMTP

Una manera rápida de hacerlo, vía PowerShell

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path «c:\CertificadoEnLosHT.pfx» -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password -PrivateKeyExportable $true| Enable-ExchangeCertificate -Services SMTP

Importante: Ante la pregunta “Overwrite the existing default SMTP certificate dialog”, la respuesta tiene que ser No

Después de ejecutar el comando, miramos que esté correctamente asignado con un Get-ExchangeCertificate

Lanzamos de nuevo el proceso de hibridación como si no tuviéramos un servidor Edge, es decir, como expliqué en esta entrada sólo que al finalizar el proceso, se deben hacer algunos cambios a mano.

Lo primero que hay que hacer después de finalizar el proceso de hibridación es ir al nuevo send connector que crea el proceso, de nombre “Outbound to Office 365”, y editarlo para ir al apartado “Source Server”

Una vez en aquí, hemos de borrar y quitar los HT que el asistente nos añade (tampoco te da más opciones) y añadir nuestro servidor de Edge

Guardamos los cambios y forzamos la sincronización con el Edge vía PowerShell con Start-EgdeSynchronization

Esto forzará que en nuestro Edge aparezca un nuevo conector que refleja estos cambios en la organización.

Finalmente, de nuevo en el Edge Server, hemos de configurar el “Receive Connector” del Edge para soportar el protocolo Oorg de Outlook.com. Para ello, de nuevo desde PowerShell, ejecutamos

$SendConnector = Get-SendConnector «Outbound to Office 365»; $ReceiveConnector = Get-ReceiveConnector «<Nombre por defecto del conector>»; Set-ReceiveConnector -Identity $ReceiveConnector.Identity -TlsDomainCapabilities outlook.com:AcceptOorgProtocol –Fqdn $SendConnector.Fqdn

Si todo va bien, nuestra empresa podrá enviar y recibir e-mails hacia Office 365.

Saludos,

Marc

Hola a todos,

Llevo ya una serie de artículos hablando de Exchange 2010 híbrido (1, 2 y 3) pero en ninguno de ellos he planteado los pasos que hay que hacer para hibridarlo cuando se tiene un Egde Server que hace de servidor perimetral de envío y recepción del correo de la organización.

Quizás no es un rol muy usado quizás sí, el caso es que por una cosa u otra, no hay demasiada documentación en Español de cómo se ha de montar la arquitectura para dar soporte a este rol por lo que haré un par de entradas relativas al tema.

No sé si estáis al día pero Microsoft ha decidido renombrar el servicio cloud de Forefront Online Protection for Exchange (FOPE) a Exchange Online Protection (EOP) y no sólo es un cambio de nombre sino que obliga a ciertas cosas en un entorno con el rol de Edge Server. La más importante de ellas, que es necesario tener el Service Pack 3 de Exchange 2010 o en el mismo Edge o en el servidor de Hub Transport. Y mejor tenerlo en todos los equipos.

La documentación oficial es clara en este punto:

Understanding Edge Transport Servers in Exchange 2010 Hybrid Deployments

If you’ve deployed Exchange 2010 SP2 Edge Transport servers, you must upgrade the Edge Transport servers you want to use for hybrid transport to Exchange 2010 SP3

Pues aprovechando tal requisito, veremos en qué varía el proceso de hibridación respecto al mismo SIN este rol

El esquema a tratar, el que se muestra en el enlace del Technet

Y el proceso en cristiano, en la siguiente entrada

Saludos,

Marc

Hola,

En esta entrada voy a hablar un poco más en profundidad de los cambios que ocurren después de la ejecución del Asistente de Hibridación, tal como hemos visto en las anteriores entradas, 1 y 2

Los apartados u objetos modificados son:

• Federation Trust
• Organization Relationships
• Remote Domains
• Accepted Domains
• E-mail Address Policies
• Send Connectors
• Receive Connectors

Así que vamos a entrar más en detalle

Cambios a nivel de configuración de la Organización

Federation Trust

En el apartado Federation Trust se crea una entrada en nuestro Exchange On-Premises de manera que sirva para securizar las conexiones entre éste y Exchange Online.

Como se puede observar, se usa un certificado digital para realizar todo el proceso

Organization Relationships

El siguiente objeto permite preguntar a nuestro Exchange por la disponibilidad de los usuarios de modo que se puedan agendar eventos y que sean visibles por todos los usuarios, tanto si están On-Premises como en el Tenant (el Cloud)

Remote Domains

En Remote Domains, se añaden los dominios de correo tanto del Tenant como el propio dominio local de la empresa

Este cambio es lógico ya que tenemos nuestro dominio de correo no sólo en local, sino “compartido” con el del cloud.

Accepted Domains

También se produce otro cambio en los Dominios Aceptados apareciendo como propio, el dominio de correo con la dirección de servicio, que tiene el formato <nombreCuentaOffice365>.mail.onmicrosoft.com

Este cambio es lógico ya que tenemos nuestro dominio de correo no sólo en local, sino “compartido” con el del cloud.

E-mail Address Policies

Más cambios, el asistente de hibridación añade la dirección de correo de servicio dentro de las E-Mail Address Policies de modo que todo usuario acabará teniendo la suya propia de trabajo y la de servicio del cloud, en el formato visto antes, <nombreCuentaOffice365>.mail.onmicrosoft.com

Send Connectors

El último cambio que se produce a nivel de Organización, es la creación de un Send Connector que enlaza nuestra Exchange On-Premises con nuestro Tenant, de manera que se establece un flujo de correo saliente hacia los buzones migrados al cloud.

Cambios a nivel de configuración de los Servidores

Finalmente, hay un último cambio que se produce en todos aquellos servidores de CAS y/o HT que añadimos como parte de la infraestructura de hibridación

Receive Connectors

Si a nivel de Organización se crea un conector de envío, a nivel de servidor, se crea un conector de Recepción, respetando el resto de conectores que se tengan.

Y su detalle donde se pueden apreciar que se han añadido todas las IPs del cloud autorizadas para poder recibir correo.

Y hasta aquí todo por hoy. Próximamente, cómo mover buzones tanto usando la parte gráfica como PowerShell

Saludos,

Marc

Os dejé con cara de… bueno, esa cara , en mi anterior entrada.

No pasa nada, continuemos. Después de que entendemos los cambios en la organización comentados procederemos a la ejecución del asistente de configuración de la hibridación el cual provocará:

• La creación del objeto Hybrid Configuration
• Solicitará credenciales de conexión 
• La definición de los Accepted Domains
• La confirmación de que somos propietarios de los Accepted Domain
• La selección de nuestros servidores On-Premise
• La definición de los Mail Flow Settings
• Hará que seleccionemos los certificados adecuados para el Mail Flow
• Y deberemos monitorizar y completar el proceso iniciado por el asistente

Lo ejecutamos, y lo finalizamos.

Comprobamos que se han creado los objetos y se han realizado los cambios esperados y procedemos a configurar correctamente esos nuevos objetos, según el listado que encabeza esta entrada

Lo siguiente, configurar las propiedades de la hibridación, en “Manage Hybrid Configuration”, en la parte izquierda de la consola

Si ejecutamos en nuevo asistente, nos informa de los cambios a realizar

Procedemos, y vamos completando los campos que nos solicite

Proporcionamos las credenciales

Lo primero, proporcionar credenciales tanto locales como en el Tenant con privilegios para hacer cambios en ambas infraestructuras

Escogemos los Accepted Domains

Añadimos los dominios que queremos hibridar

Confirmación de los Accepted Domains

Para que el sistema Exchange del cloud acepte el dominio a hibridar, es necesario validarlo.  Por tanto, es necesario crear un registro TXT en el  DNS público de la empresa con valor que es muestra la siguiente captura de pantalla.

Marcamos la opción de “Check to confirm that the TXT records have been created in públic DNS for the domains above” y continuamos.

Selección de los servidores On-premise

El siguiente paso es escoger los servidores de CAS y HT que participarán en la hibridación.

También proporcionamos la IP pública de acceso a nuestros servicios así como el nombre, también público

Definición de los Mail Flow Settings y Certificados

Paso siguiente, escoger un certificado público para securizar el correo, y decidir el enrutamiento del correo, es decir, si entrará por nuestros HT o por Internet hacia el cloud

Finalizando el Asistente

Llegados aquí, sólo debemos finalizar el asistente y dejar que trabaje un poco.

El resultado, si se hace por PowerShell, es el siguiente

Y esto es todo. En otra entrada, repasaremos más a fondo cada uno de los cambios que realiza el proceso y moveremos un buzón.

Saludos,

Marc