Entre el Cloud y el Infierno

Casi después de 3 años de la última entrada, me he dignado a volver a escribir… Os explicaría los 1000 cambios desde entonces, pero como entiendo que el que entra aquí no es para saber de mi vida sino para algo que tenga que ver con el titulo de la entrada, vamos al lío!

Una petición que hacen muchos clientes es que cuando disponen de un entorno híbrido entre su Exchange OnPremise (2010/2013) – Exchange Online y un usuario con buzón en la nube se valida en OWA (OnPremise), se le abra el buzón automáticamente sin que le aparezca la pantalla intermedia para hacer click en el link del OWA de Office 365 (https://mail.office365.com/cliente.com).

Buscando por internet encontramos el siguiente link (http://www.stevieg.org/2012/04/enabling-silent-owa-redirection-for-office-365-hybrid/) donde se especifica como modificar el casredirect.aspx de Exchange 2010 para que se haga este redirect de forma automática. El tema esta en que ese cambio no aplica en Exchange 2013… 🙁

Con una moral desmesurada me puse a indagar en los ficheros de OWA para 2013 en busca del cambio necesario. Cabe comentar que la moral me duró lo que dura un gato en un barrio chino… 🙁

Así que al darme cuenta que no tenía ni idea de lo que estaba viendo, pedí ayuda a uno de los grandes (@fernandoescolar) y en 20 minutos lo tenía(mos)!!!

El cambio pasa por añadir al fichero

el siguiente código (justo antes del </body>)

Espero que os sea de ayuda!

Después de estar un tiempo desaparecido en combate, vuelvo con una entrada sobre el evento IGNITE London 2013 (http://bit.ly/QUxhXd) al que he tenido la oportunidad de asistir. En este Ignite se ha hablado de las últimas novedades sobre Exchange 2013, Office y Office 365. En los próximos Posts intentaré explicar a alto nivel las últimas novedades y temas más interesantes que han surgido.

Hoy para empezar haré una pequeña introducción sobre el proyecto Napa.  Napa Cloud App es un proyecto enfocado a desarrolladores y, pese a que no es mi fuerte, me parece lo suficientemente interesante como para mencionarlo.

Para probarlo es necesario disponer de un tenant Office 365 Preview, y tener un Site Collection de tipo Development (existe una plantilla especifica desde la administración de Sharepoint).

Una vez creado, mediante el icono de «Build Your App«, se accede al repositorio de aplicaciones de Sharepoint donde aparecerá «Napa» (es importante seleccionar idioma Inglés en la parte superior derecha). Cuando lo tengamos disponible, al acceder pedirá para qué producto se desea desarrollar (Sharepoint, Excel…) y el nombre del proyecto que se le quiera asignar. En este ejemplo se ha seleccionado Sharepoint.

Y voila! Así de fácil se le muestra al desarrollador una especie de «Visual Studio on the Web» el cual ofrece múltiples funciones, muchas propias de Visual Studio. Entre sus ventajas se encuentra por ejemplo, evitar la necesidad de disponer de ninguna herramienta de desarrollo adicional en el equipo, y el correspondiente ahorro en licencia.

Desde esta misma interfaz se permite el empaquetado y despliegue de la aplicación sobre el Site de Development.

Una vez desplegada la aplicación sobre el Site de Development, se podrá publicar a otros sites, o incluso en la Office Store.

Para terminar, dejo un pantallazo de la aplicación obtenida.

Saludetes!

Continuamos dando guerra con Office 365… Bueno, más bien con ADFS.

Con la finalidad de mejorar la integración entre nuestra infraestructura «On-Premise» y los servicios que podamos tener alojados en la nube, tales como Azure y/o Office 365, Microsoft dispone del producto Active Directory Federation Services (ADFS) ya en la versión 2.0. ADFS nos permite federar nuestro Active Directory con nuestro tenant en el cloud, de forma que los usuarios accederán a servicios externos, autenticandose previamente «en casa».

Gracias a esto se obtienen mayores ventajas y funcionalidades, tales como:

– Single Sign-On (SSO)
– Customización de la web de login
– Seguridad

No voy a hacer especial énfasis en su instalación y configuración, ya que esta bastante bien documentado en Technet
http://technet.microsoft.com/es-us/library/jj151794.aspx

ADFS puede llegar a integrarse con otros productos (Exchange 2010, Sharepoint…) y otros no Microsoft. En los siguientes enlaces se especifican estos productos, así como los procedimientos de implementación.

http://technet.microsoft.com/es-es/library/adfs2-step-by-step-guides%28WS.10%29.aspx
http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx

Concretamente en la  implementación de ADFS con Office 365, también es necesario DirSync, basado en MIIS,  para la sincronización de identidades con el Cloud (no sincroniza el password). De forma opcional, y en caso de que sea necesario, ADFS Proxy 2.0 (el rol de este servicio puede ser asumido por TMG) para el acceso a la autenticación desde fuera de la organización.

Pues bien, una vez configurada la federación, accederemos al servicio a través de la URL configurada.

En el siguiente enlace se explica de forma muy detallada, como modificar esta página de login para darle un aspecto más «corporativo»

http://blogs.technet.com/b/stevenha/archive/2012/11/12/customizing-the-adfs-forms-based-login-page.aspx

Finalmente, y haciendo referencia la titulo del post, una vez se ha accedido al servicio correspondiente y hacer Logout, por defecto, el usuario será redirigido a la web de https://portal.microsoftonline.com en lugar de a la web de ADFS… 🙁

Para modificar este comportamiento, y redirigir la acción de logout a la web de ADFS:

1. Localilizar la página de logout (por defecto en C:\inetpub\adfs\ls\SignOut.aspx)

2. Editar el fichero SignOut.aspx para insertar el siguiente código, justo antes de la etiqueta de cierre </asp:Content> (casi al final del fichero), introduciendo la URL de la web que queremos que aparezca al hacer Logout (en este caso la propia del adfs)

3. Ejecutar iisreset desde cmd.

Salut!! 😛

En determinadas ocasiones puede surgir la necesidad de ejecutar tareas de forma periódica en nuestro tenant de Office 365, tales como la asignación de licencias, operaciones sobre buzones/usuarios, etc…

El principal inconveniente que nos podemos encontrar, es poder tener la capacidad de autenticarnos de forma segura en Office 365. Si os habéis encontrado en esta tesitura, espero que esta entrada os ayude en algo 😉

La idea es crear un fichero (cifrado) con el password del usuario que utilizaremos para validarnos, y posteriormente utilizarlo en un script para conectarnos sin necesidad de introducir ninguna validación.

Para crear este fichero, utilizaremos el siguiente comando.

read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt

Al ejecutarlo, se deberá introducir el password del usuario.

-convert-securestring: convierte un SecureString (System.Security.SecureString) en un EncryptedStandardString (System.String) y nos permite almacenarlo en un fichero para su posterior uso.

Si accedemos al contenido del fichero…

Posteriormente utilizaremos este fichero para validarnos en Office 365.

A continuación, creamos un script en PowerShell con el siguiente contenido (p.e o365.ps1)

Este script esta disponible en el siguiente repositorio de GitHub (aún me estoy familiarizando con esto del blog y no he conseguido pegarlo como tal… 🙁 )

(https://github.com/Tokiota/AutologonO365/blob/master/o365.ps1)

Finalmente, creamos un acceso directo con la siguiente ruta, o programamos una Schedule Task
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -Command «. ‘o365.ps1′»

El script que se ejecuta (GetMsolUserReport.ps1) forma parte de un repositorio de scripts facilitados por Microsoft para la ayuda en la gestión de Office 365. (Office 365 Helper Scripts – http://www.microsoft.com/en-us/download/confirmation.aspx?id=29568 ).

Existen algunos interesantes:

– GetMsolUserReport: se obtiene información tanto a nivel de usuario, como de buzón (licencia, tamaño del buzón…)
– AssignLicenseByDG: utilizado para asignar licencias. Útil cuando se migran buzones desde Exchange OnPremise, ya que al buzón no se le asigna ninguna licencia de forma automática en Office 365 🙁

Por último, comentar que de momento no se permite la gestión de Sharepoint Online/Lync Online a través de PowerShell. Sí que existe «Sharepoint Online Management Shell» pero solo soportado para Office 365 Preview (espero poder dedicarle una entrada un día de estos)

http://www.microsoft.com/en-us/download/details.aspx?id=30359

Saludetes!! 😀