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,

Si hace unos días el cliente Twitter se actualizaba a la versión 2.0, poco han tardado en volverlo a actualizar. Aunque los cambios son menores, se ha cambiado el número de versión de la 2.0 a la 3.0 (3.0.0.20499) o al menos eso muestra mi teléfono porque en Windows Phone Store no hay indicios de nada sobre estos cambios

No hay mucha más información excepto la indicada en WPCentral

Saludos,

Marc

Hola,

Desde hoy martes, Microsoft ha reconocido mi actividad profesional con el título de “MAP 2013”

Desde este espacio, sólo dar las gracias por este diploma y nada, a seguir colaborando

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