Archivo de la etiqueta: exchange

Uso de la API administrada de Exchange Web Services

En este artículo me gustaría hablar de la API administrada de Exchange Web Services.
La API gestionada o administrada de Exchange Web Services (EWS) permite el desarrollo, de una manera simple y completa, de aplicaciones cliente que hagan uso de los EWS. De este modo, gracias a esta API, se pueden acceder a los EWS en Office365, Exchange Online y las versiones de Exchange a partir de Exchange Server 2007 Service Pack 1.
Dicha API se puede utilizar mediante lenguaje de programación C# o directamente con Powershell.

Alguna de las cosas que se pueden hacer con esta API son:

  • Crear, enviar o responder mensajes de correo.
  • Buscar carpetas, mensajes, reuniones y tareas.
  • Gestionar elementos del calendario.
  • Utilizar el servicio de Autodiscover para una cuenta de correo, y obtener así la configuración del usuario y dominio inherentes a la misma, necesaria para establecer una conexión con el servidor Exchange.

Otros usos más avanzados incluirían sincronización, tratamiento de listas de distribución o conversaciones.

A modo de esbozo, cabe destacar que todos los métodos y tipos empleados en la API se enmarcan en tres namespaces:

  1. Microsoft.Exchange.WebServices.Auth.Validation: contiene tipos y métodos empleados para validar los tokens de identidad del usuario enviados desde un servidor Exchange. Solo aplicables a Exchange Online o Exchange Server 2013 en adelante. Este namespace está incluido en la API Microsoft.Exchange.WebServices.Auth.dll.
  2. Microsoft.Exchange.WebServices.Autodiscover: incluye tipos empleados en la comunicación con el servicio Autodiscover alojado en un servidor Exchange. Proporciona básicamente información de configuración a los clientes EWS, lo que habilita a estos a dirigirse al servicio URL apropiado. Al igual que el otro namespace, está incluido en la API Microsoft.Exchange.WebServices.dll.
  3. Microsoft.Exchange.WebServices.Data: proporciona la base de la funcionalidad de la API. Contiene tipos usados en la comunicación con un servidor Exchange a través de EWS.

Para utilizar la API se necesita de lo siguiente:

  • Una versión de dicha API. Se utilizará la versión 2.2 (última versión disponible en el momento de escribir este artículo). Requiere una instalación.
  • Un cuenta de correo en un servidor Exchange (cualquiera de las versiones anteriormente nombradas) con sus correspondientes credenciales.
  • La versión de .NET Framework debe ser igual o superior a la 3.5.

Para dar un pequeño sentido práctico a lo dicho, se muestra a continuación como se llevaría cabo la activación/desactivación del mensaje Out Of Office (OOF) tanto en Powershell como en C# utilizando la API (aquí se explicó como realizarlo en Powershell mediante cmdlet directo):

Y empleando C#, el modo de hacerlo sería el siguiente:

Como puede verse,  el uso de la API es directo en ambos casos.
Y esto es todo por ahora. Espero que este ejemplo, aunque sencillo, sirva para ilustrar la sencillez de uso de esta versátil e interesante API.

Activar administrativamente el Out of Office de un buzón en Microsoft Exchange

Me gustaría empezar mi andadura en este blog con un artículo que puede ser útil a la hora de establecer la disponibilidad o no de cualquier usuario. Esto se llevará a cabo mediante el mensaje “Out Of Office” (OOF). Dicha tarea se puede llevar a cabo de forma administrativa, por lo menos, de tres formas diferentes. Dos de estas maneras implicarán el uso de Powershell en Exchange, mientras que la tercera requerirá de un lenguaje de programación .NET, como C#. En este artículo hablaré de una de ellas, para la cual se empleará Powershell.

El cmdlet que nos permitirá establecer el mensaje OOF es ‘Set-MailBoxAutoReplyConfiguration‘. Dicho cmdlet se encuentra disponible para Exchange Server 2010, 2013 y Online, y cuenta con una serie de parámetros que se explicarán a continuación:

  • Identity: el correo o alias del usuario a establecer el OOF.
  • AutoReplyState: activa/desactiva el mensaje. Valores: ‘Enabled’, ‘Disabled’, ‘Scheduled’.
  • ExternalAudience: a quien va dirigido el mensaje. Valores: ‘None, ‘Known’, ‘All’.
  • InternalMessage: el mensaje OOF a nivel interno de la empresa. También se puede indicar un archivo de texto o html (longitud máxima de 100KB).
  • ExternalMessage: el mensaje a nivel externo. Análogo al anterior.
  • StartDate: fecha de inicio a partir de la cual se activa el mensaje OOF. Parámetro solo necesario en caso de que se indique en el parámetro AutoReplyState el valor ‘Scheduled’.
  • EndDate: fecha en la que se desactiva el mensaje. Este parámetro solo es necesario en el mismo caso que el anterior.

La mejor forma de ilustrar todo lo anterior es mediante un ejemplo práctico. Partiendo de la base de que se haya realizado una conexión a Exchange (como indica Antonio en este post) , supongamos que se quiere establecer el mensaje “Out Of Office” del usuario ‘usuario@empresa.com”, estando activo dicho mensaje desde las 9:00h del dia 1/08/2015 hasta las 9:00 del dia 1/09/2015:

Y ésto es todo por ahora. Como se puede ver, este método es bastante directo y su aplicación no conlleva demasiada dificultad.

Conexión remota con PowerShell a Exchange Server 2010/2013

¡Hola a todos!

Hoy hablaremos de PowerShell, conexiones remotas a Exchange, y cómo podemos automatizar estas conexiones para usar en scripts que no requieren intervención por parte del usuario. ¿Suena interesante? Pues sigamos adelante!

Primero veamos cómo podemos conectarnos con PowerShell a un sistema remoto. En este caso, vamos a conectar con un servidor Exchange ficticio llamado “mi.sitio.es”.

Muy fácil, tres líneas de código, introducimos nuestras credenciales en un diálogo pop-up, y tenemos una shell conectada al servidor Exchange, para ejecutar comandos como Get-Mailbox o Get-DistributionGroup. Éste es el procedimiento estándar para conectar con Exchange, y se puede encontrar en miles de artículos por Internet. El problema, es que requiere una sesión interactiva, porque nos pide las credenciales en un diálogo.

Como esto es demasiado fácil, y en ocasiones molesto (especialmente la parte de escribir nuestras credenciales), vamos a escalar la dificultad, y automatizar el proceso para que no haga falta introducir las credenciales en una sesión interactiva. Esto se consigue creando un objeto del tipo PSCredential.

Obviamente, esto nos plantea un dilema práctico. Por muy compleja y segura que sea la password de nuestra cuenta (MiP4ssw0rdEsMuy.Segur0), si la pegamos como texto plano en un script no va a servir de nada. Especialmente si más de una persona tiene acceso al lugar donde el script esté guardado.

Esto se puede solucionar guardando la contraseña en un contenedor especial llamado “SecureString”, que se cifra con nuestras credenciales de Windows. En la práctica, esto significa que, el script quedaría entonces ligado a nuestra cuenta en una máquina en concreto. Si cambiamos de máquina o de usuario, tenemos que generar una nueva representación del SecureString. Útil para maximizar la seguridad del despliegue de un script, aunque es importante tener en cuenta que la seguridad que ofrece no es de nivel militar, pero sí es lo suficientemente buena para el “usuario estándar”.

Ahora bien, ¿cómo podemos generar un SecureString para almacenar nuestra contraseña, de forma segura y fiable? Podemos usar una función como la siguiente:

Nótese que esta función nos va a convertir cualquier cadena que le pasemos a un securestring, ya sea pasando el texto como un parámetro (mala idea), o leyendo el texto con el Read-Host –AsSecureString. Obviamente, podemos usar la función tal cual, “Copipegándola” en la shell, y ya podemos usarla con total normalidad.

El resultado final nos deja con un script de conexión tal como el siguiente:

Estas tres líneas las podemos incluir en un script .ps1 de PowerShell, y a continuación usar todos los cmdlets de Exchange que necesitemos para nuestros propósitos.

 

¡Y eso es todo por el momento! Espero que esta técnica os sea provechosa para aumentar la productividad y, sobre todo, happy scripting!