De cómo ser IT Pro y no morir en el intento

Hola a todos,

En un proyecto de migración de Exchange 2010 a 2013 + Office 365 en el que llevo unas tres semanas, se nos presentó la disyuntiva de seguir publicando los nuevos servicios de Exchange 2013 a través de un TMG existente en la arquitectura o si de mover esos servicios a un Web Application Proxy que se montó para federar el entorno.

En un primer momento, se optó por seguir com TMG pero después de bastantes problemas para hacer funcionar Outlook Anywhere, se decidió dar un salto y migrarlo todo hacia WAP.

He de decir que la documentación en Technet que explique cómo publicar los servicios de Exchang en WAP se reduce a un mísero artículo por lo que el cambio se ha hecho un poco a ciegas.

El artículo en cuestión es:

Using Application Proxy to Provide Access to SharePoint Server and Exchange Server https://technet.microsoft.com/en-us/library/dn528827.aspx

Y como veréis, es escueto.

Qué necesitamos:

• Un certificado SAN o wildcard para publicar los servicios
• Un servidor en DMZ con el rol de Remote Acces y Wep Application Proxy. Este equipo puede estar o no en dominio. Como se usa para la federación con Office 365, estará fuera.
• Tener claras las URLs de los servicios de Exchange
• Una zona “split DNS” para hacer coincidir los nombres públicos con los internos de Exchange
• Autenticación Pass-through (se puede usa Claims pero no es el objeto de esta entrada)

No explicaré como publicar una web en un servidor WAP puesto que no tiene secreto pero sí indicaré los nombres de los servicios. El dominio a usar será “dominio.com” (original donde los haya) y las URLs, tanto internas como externas serán las mismas.

• OWA: https://webmail.dominio.com/owa/
• ECP: https://webmail.dominio.com/ecp/
• EWS: https://webmail.dominio.com/ews/
• OAB: https://webmail.dominio.com/OAB/
• EAS: https://webmail.dominio.com/Microsoft-Server-ActiveSync/ 
• Autodiscover: https://autodiscover.dominio.com/autodiscover 
• Outlook Anywhere: https://webmail.dominio.com/rpc 

Notad que al final de cada URL hay una barra inclinada /. Es obligatoria.

Y ya está. Así de sencillo.

Podemos ver que, por ejemplo, el OWA funciona

Así que hasta otra

Marc

Hola de nuevo,

No sé si es muy normal lo que os voy a contar pero, oye, pasar os puede pasar. Y como no he encontrado nada por Internet ni medio decente sobre el tema… pues me he liado yo solo.

Por necesidades de un cliente, he tenido que migrar un servidor AD FS 3.0 (ya sabéis, sobre Windows Server 2012 R2 Update) de un CPD a otro CPD, que está a unos 100 Kms.

Como un vMotion (o Live Migration) no era posible, se decidió tirar por el camino del medio, esto es, instalar otro servidor en el CPD destino y mover la federación.

Bien, los pasos son sencillos pero… han tenido algunos efectos, llamémosles, imprevistos.

Pasos seguidos

• Montar el nuevo servidor de AD FS 3.0, junto con su Windows Update y demás
• Exportar el certificado de la federación desde el servidor viejo al nuevo
• Modificar el fichero host del AD FS Proxy (Web Application Proxy o WAP, para ser exactos) para que apunte al nuevo AD FS
• Ejecutar un Update-MSOLFederatedDomain y…
• Revisar que en el Visor de sucesos esté todo bien (aparentemente), tal como se ve a continuación

Los errores

El caso es que todo ha ido bien hasta pasadas unas 12 horas… de tal modo que tanto en el nuevo AD FS como en el WAP, el Visor de sucesos se ha llenado de errores como los que siguen

AD FS

WAP

Y la solución

Recuerdo que en la versión 2.0/2.1 de AD FS Proxy, re-ejecutando el Wizard de configuración, estas cosas se arreglaban. Pero claro, en la era de Powershell hay que tirar de comandos de teletexto así que… la cosa se arregla de esta manera

• Primero, buscar el thumbprint del certificado de la federación, dentro de la MMC de Certificados.
• Seguidamente, ejecutar estos cmdlet con los valores adecuados:

$federationServiceCreds = Get-Credential

Install-WebApplicationProxy -FederationServiceTrustCredential $federationServiceCreds -CertificateThumbprint ‘Thumbprint‘ –FederationServiceName ‘nombreDeLaFederacion’

Si todo va bien, veremos un mensaje como el que sigue.

Y ya está arreglado? No, sólo hemos hecho el 50% del trabajo.

El último paso, volver a publicar la federación en nuesto WAP.

Revisamos el visor de sucesos de ambos equipos y hemos de encontrarnos con mensajes del estilo

AD FS

WAP

Ahora sí hemos acabado.

Saludos,

Marc

Hola a todos,

No sé si os ha pasado que alguna vez, implementando un entorno híbrido Exchange 2013 – Exchange Online, se os ha complicado la cosa y os habéis acordado de todos los Santos y Patronos de la Informática.

Pues bien, si eso es pasa de nuevo, podéis usar esta herramienta de Microsoft que ayuda a dar luz sobre los problemas de hibridación con Exchange

https://aka.ms/hcwcheck

Accedéis al link, os validáis con una cuenta con permisos y os dejáis guiar.

Saludos,

Marc

Hola de nuevo,

Si ayer era el 70-346, hoy a caído el 70-347 Enabling Office 365 Services. Es decir, que combinados ambos, tengo un MCSA en Office 365.

Y no está nada mal el poder actualizar el MCITP para acabar el año con muy buen sabor de boca

Saludos,

Marc

Hola a todos,

Aprovechando que Microsoft regalaba los exámenes de certificación para el MCSA de Office 365 (yo ya tenía un MCITP en esta tecnología), he realizado hoy el 70-346: Managing Office 365 Identities and Requirements

La verdad es que si te dedicas a implementaciones de esta tecnología, es un examen relativamente fácil de sacarte.

Para el MCSA, queda el 70-347: Enabling Office 365 Services. Y este, que no me dedico a la administración de servicios… creo que no será tan sencillo.

Os tengo informados.

Saludos,

Marc