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!

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