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

Hola a todos,

Ayer Microsoft liberó para el público en general su versión Technical Preview de la nueva suite Office en su versión 2016.

Yo, como todo geek que se precie (algunos dirán ánsias) me la bajé y me faltó tiempo para instalarla.

Aunque eso de “instalarla” es una manera de hablar porque no es una instalación “de toda la vida” sino una generada en tiempo real por un script de PowerShell!!!!

Si esto ya se ve raro, la instalación como tal es muy Office 365… eso cuando te recuperas de ver el instalador como tal (que es lo que se ve debajo)

Llegados a este punto, lo primero que hay que hacer es escoger las opciones de instalación (siguiente pantalla) e instalarlo.

Después de instalar… nada ha cambiado… o sí

Las primeras ejecuciones de todos los nuevos programas de Office 2016 realizan pequeñas configuraciones y empiezan a funcionar… excepto – vaya novedad – Outlook 2016!!!!!

El caso es que me ha tocado “borrar” el perfil antiguo de Outlook 2013, lanzar una reparación del producto y configurar desde cero el nuevo perfil.

Y funciona.

Y Lync ya no es Lync… es Skype for Bussiness!!!

Saludos,

Marc

Hola,

Llevo tiempo en esto de las tecnologías y algo menos trabajando con Office 365. Durante este tiempo he colaborado directa o indirectamente en migraciones de buzones, desde Exchange 2007 a la reciente Exchange 2013.

Bien, pues la semana pasada me pasó algo que todavía no me había pasado: migrar un buzón a Exchange Online (de hecho, fue un lote de tres buzones) y perder uno de ellos.

Así, tal cual. En frío. Sin paños calientes.

La cara que se me quedó no difiere de ésta. Vamos, que fue mi primera reacción.

La segunda, algo más profesional, fue revisar tanto Exchange Online como mi Exchange On-premises.

En el primero, ni siquiera aparecía el batch de migración del usuario (Get-MigrationBatch). Evidentemente, un Get-MigrationUser y un Get-MoveRequest –Identity <Usuario>  no arrojaron luz, ni datos.

Tercera opción, abrir un caso de soporte con Office 365.

Desde aquí felicitar a César (mi técnico asignado) por la rápida respuesta y, sobretodo, por su profesionalidad en el tratamiento del problema.

Lo que hicimos: revisar todo el proceso de migración con sus pasos y sus resultados. A priori, la conclusión fue que el proceso había sido correcto pero algo había fallado en Office 365 en el momento de sincronizar los datos de mi Active Directory y su Active Directory.

Lo mejor, la solución del problema. Como por arte de magia, se recuperó el buzón de mi usuario con tres simples pasos (bueno, cuatro).

• Primer paso: asignar una licencia de Exchange Online al usuario en cuestión. Sabréis que aparece un mensaje de error diciendo que el usuario ha de migrarse previamente.
• Segundo paso: Revisar la dirección de e-mail del usuario y validar que aparecen las X.500 correspondientes a la organización
• Tercer paso: forzar una Full Sincronization desde DirSync.
• Cuarto paso: celebrarlo con una cerveza

Saludos,

Marc

Hola,

Después de configurar el servicio de Federación, vamos a por la parte pública instalando y configurando el Proxy.

Así que vamos al lío, al segundo servidor ubicado en la DMZ.

Implementación

Empezaremos instalado el rol de Remote Access.

Nota: Suponemos que el certificado digital está solicitado, emitido e instalado en el equipo

Iniciamos la instalación desde

Avanzamos con el asistente hasta la parte donde nos indica las funciones que se pueden ejecutar con el rol de Remote Access.

Escogemos el rol de Web Application Proxy.

Confirmamos. Y finalizamos la instalación

Configuración

Una vez instalado, procedemos a su configuración. Veréis que el proceso es bastante diferente de la versión 2.0, y por eso tendremos que estar atento a varios detalles.

Iniciamos el asistente.

Completamos los datos que nos solicita

• Nombre de la federación: sts.dominio.com
• Usuario: DominioDeActiveDirectory\Administrator <— Importante tiene que ser un usuario de Active Directory aunque ponga LOCAL ACCOUNT!!!!!
• Password: el que toque

Continuamos y seleccionamos el certificado adecuado

Confirmamos los pasos y finalizamos la configuración inicial.

Finalizamos el asistente y… siguiente paso!!!

Publicación

Finalmente, el tercer y último paso: publicar el servicio Web como Proxy de la Federación.

Este procedimiento se realiza desde la consola de Remote Access Management Console y pulsando sobre Publish, que nos abre un tercer asistente.

Como método de pre-autenticación, y dado que el objetivo es Office 365, escogemos Pass-through

Completamos los datos que nos solicita

• Nombre: Servicio de Proxy de Federación
• Url de acceso externo: https://sts.dominio.com
• Certificado: el que toque
• Url del servicio de Federación: https://sts.dominio.com (esta url tiene que ser resoluble desde el proxy, añadiendo en el fichero host el nombre y la IP del servidor de Federación)

Confirmamos los datos y, si son correctos, los publicamos.

Para validar su funcionamiento, vamos a https://sts.dominio.com/adfs/ls/idpinitiatedsignon.htm

Si la página carga, es que funciona sin problemas.

Y esto es todo en cuanto a la instalación de AD FS 3.0 para usar con Office 365

Nota: El alta de la empresa en Office 365, su configuración, la conversión del dominio o dominios como federados y resto de pasos, no han variado y se siguen haciendo como hace 2 años por lo que me remito al artículo original para acabar las configuraciones.

Saludos,

Marc

De nuevo por aquí,

Como decía ayer, vamos a actualizar conocimientos implementando un entorno de AD FS – AD FS Proxy (aunque no se llame así de forma oficial, ni se instale igual!!!!) con la versión 3.0 del producto.

Requisitos

Los requisitos para llevar a cabo correctamente la implementación de AD FS 3.0, sin usar alta disponibilidad, son los siguientes

• Un equipo Windows Server 2012 R2 Update 1 en la LAN, unido al dominio, para el rol de AD FS
• Un equipo Windows Server 2012 R2 Update 1 en la DMZ, fuera del dominio, para el rol de Remote Acces (Web Proxy)
• Definir el nombre de la federación con Office 365. Típicamente, sts.dominio.com
• Creación de una cuenta ADFSService de dominio con permisos de administrador y caducidad de contraseña para el servicio de Federación. O la creación de una Managed Account siempre que el nivel funcional del dominio sea Server 2012.
• Un certificado público con el nombre de la federación. Este certificado se instalará en ambas máquinas.

Implementación

Empezaremos instalado AD FS 3.0 en el servidor interno.

Nota: Suponemos que el certificado digital está solicitado, emitido e instalado en el equipo

Iniciamos la instalación desde

Del asistente de instalación de roles de Server 2012 R2, escogeremos el rol de Active Directory Federation Services

Después de avanzar un poco en la instalación, se nos indican los requisitos a cumplir para instalar ese rol.

Avanzamos y esperamos que lo instale

Cerramos el asistente y… abrimos un segundo asistente !!!!

Configuración

Tengo la costumbre de generar farms pero es que con este asistente no puedes crear un AD FS standalone como en versiones anteriores así que marcamos la primera opción y continuamos.

Indicamos una cuenta con permisos suficientes para realizar la configuración, que en este caso es la creada en los Requisitos.

Escogemos el certificado a usar para la federación (previamente importado), que debe coincidir con el nombre a publicar y también qué nombre mostrará el portal cuando un usuario quiera hacer login.

Indicamos una cuenta con la que se gestionará el servicio (la creada en los Requisitos)

Siguiente paso: decidir dónde se almacenarán los datos del servicio de Federación. Para el ejemplo, usaremos un SQL Local.

Avanzamos en el asistente, verificamos las opciones y proseguimos con el check previo de requisitos.

Proseguimos con la instalación y cerramos el asistente.

Hasta aquí la primera parte. Mañana (o el lunes), la segunda y última parte.

Saludos,

Marc

Hola,

Las cosas en esta vida cambian y evolucionan. Tanto en la tecnología como en lo personal.

En lo personal, uno engorda y le salen canas (o eso dicen )

En la tecnología, hace ya más de dos años explicaba cómo federar Office 365 con nuestro Directorio Activo usando la versión 2.0. de Active Directory Federation Services.

Creo que ya es hora de actualizar esos conceptos y usar la versión 3.0 de ADFS junto con Windows Server 2012 R2 Update 1.

Pues los próximos dos artículos irán sobre precisamente esto.

Saludos,

Marc