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!! 😀

Buenos días a todos!!

Este primer post lo voy a dedicar a indagar un poco en las posibles configuraciones para la NO activación de una Lagged Copy en Exchange 2010.

Exchange 2010 dispone de la funcionalidad de copias de bases de datos retardadas (Lagged Copy). Con la finalidad de contingencia, este tipo de copia permite recuperar la base de datos en un momento concreto con hasta 14 días de antelación.

Su funcionamiento se basa en almacenar los ficheros .log de hasta 14 días anteriores, de forma que si es necesario realizar una recuperación de la base de datos, se pueden aplicar los .log que se quieran hasta el momento determinado (intentaré hablar más de este tema en otra entrada). Por tanto esta base de datos no se debería activar nunca, ya que en caso de que esto sucediera se aplicarían todos los .log pendientes a la base de datos antes de activarse, con lo cual:

– Se pierden todos los logs, y por tanto, la capacidad de recuperar esa BD en un estado anterior.
– El tiempo en aplicar los logs pendientes sobre la base de datos puede llegar a ser muy extenso (se queda en estado Mounting) y por tanto, los usuarios con buzones en esa base de datos no podrán acceder hasta que se hayan terminado de aplicar.

Para evitar este hecho, existen dos posibles configuraciones

– Evitar una base de datos concreta se pueda llegar a activar (configuración a nivel de base de datos)
– Evitar que un servidor pueda levantar ninguna base de datos (configuración a nivel de Mailbox Server)

La primera opción se realiza a través del siguiente comando (la BD no cambia a estado Suspended, cambia el parámetro ActivationSuspended de False a True)

Suspend-MailboxDatabaseCopy -Identity DB3\MBX2 -ActivationOnly

La segunda opción se realizar a través de este otro (cambia el parámetro de DatabaseCopyAutoActivationPolicy  de Unrestricted a Blocked)

Set-MailboxServer –Identity MBX2 –DatabaseCopyAutoActivationPolicy Blocked

A tener en cuenta:

Como ventaja – la primera opción nos permite mayor granularidad en la configuración de nuestras copias, ya que no es necesario que todas las Lagged se encuentren en el mismo servidor. Mediante la segunda opción, es necesario disponer de un servidor para que únicamente mantenga todas las copias Lagged.

Como inconvenientes – con la primera opción, si se realiza un Resume-MailboxDatabaseCopy o un Update-MailboxDatabaseCopy (porque el estado de la copia quede en Disconnected, Failed… el ContentIndex no sea correcto, etc.) se pierde la configuración de este parámetro, teniéndolo que volver a configurar. Así que es necesario e importante tenerlo monitorizado. Es más, incluso si en algún momento existe una caída de alguno de los nodos miembros del DAG (o cortes intermitentes de comunicación), Exchange puede llegar a intentar ejecutar un Reseed (Update-MailboxDatabaseCopy) provocando la pérdida del parámetro ActivationOnly.

Este último hecho no sucede con la segunda opción.

Cada parámetro tienes sus pros y sus contras, por lo que es importante tenerlo en cuenta para su configuración.

En caso de que os suceda que una Lagged Copy se intenta Activar (se quedará en estado Mounting), recomendaría detener el nodo a nivel de «Failover Cluster Manager» o reiniciarlo directamente, para forzar un balanceo de las bases de datos que se están intentando montar a uno de los servidores que mantenga una copia pasiva.

Espero que os sea de ayuda!!!

Hola a todos y bienvenidos!

Antes de empezar a meterle chicha a este Blog, me presento…

Mi nombre es Pedro, y llevo ya unos años en consultoría TI, básicamente en la parte de gestión e implantación de proyectos de infraestructura.
Han sido muchas cosas las que me han sucedido en este mundo, y muchas «ostias» dadas con prácticamente todo lo que se me ha puesto por delante. Lo bueno, es que al final de todas de todas se aprende! 😀

Esta es básicamente la finalidad, compartir estas experiencias con todos vosotros, y esperar a que os puedan ayudar en algun momento!

Espero que lo disfrutéis! 😉