Evento : SIMO Educación – Office 365 Híbrido: ven a la nube sin despegar los pies del suelo

Continuando con la agenda de eventos en el mes de Octubre. En esta ocasión,  Plain Concepts estará presente en  el salón de tecnología para la enseñanza SIMO Educación para poder hablar sobre una de las particularidades de Office 365 híbrido, el movimiento de buzonesde tu máquina local a Office 365 y viceversa .

¡Te esperamos en el stand de Microsoft!

  • Título: Office 365 Híbrido: ven a la nube sin despegar los pies del suelo
  • Fecha:  días 28,29 y 30 de Octubre de 2015
  • Hora:  
    • Miércoles 28 de Octubre de 16:00 a 16:20 CET
    • Jueves 29 de Octubre : 10:30 a 10:50 CET
    • Viernes 30 de Octubre : 15:30-15:50 CET
  • Ubicación: Stand de Microsoft – SIMO Educación : Parque Ferial Juan Carlos I – 28042  Madrid
  • Idioma: Español
  • Abstract: ¿Quieres moverte a la nube de forma gradual y a tu propio ritmo? ¡Te enseñamos como mediante un escenario híbrido con Exchange Server podemos mover buzones de tu máquina local a Office 365 y viceversa!
  • Registro :  Enlace de acceso
  • Ponentes:
    • Alfredo Tercero García – Enterprise Engineer

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.

Azure Site Recovery: Mobility Service en GNU/Linux

Quizá no hemos tenido todavía ocasión de hablar en este blog de Azure Site Recovery, la solución de recuperación de desastres ofrecida como servicio desde Microsoft Azure. Este servicio mantiene una sincronización de nuestra infraestructura on-premises, ya sean máquinas físicas, Amazon Web Services, Hyper-V o VMWare con Azure; y puede realizar una operación de failover y levantar todo el entorno en caso de desastre para seguir dando continuidad a nuestro negocio. La doble vertiente de lo que os acabo de contar, es que si estamos sincronizando nuestra infraestructura con Azure, podemos deducir fácilmente que este escenario es muy válido para realizar una migración a Azure de nuestra plataforma actual, beneficiándonos de RTOs y RPOs realmente bajos.

El tema que me ocupa hoy sobre Azure Disaster Recovery es hablaros de una casuística concreta, pero muy común en los entornos de protección o migración de VMWare, AWS o máquinas físicas a Azure: el soporte del Mobility Service en GNU/Linux. El Mobility Service es un agente que se instala en las máquinas a proteger o migrar desde Windows y GNU/Linux. Este agente se integra con el kernel de la máquina en cuestión e intercepta las llamadas de E/S de disco, enviándolas al Process Server para que sean comprimidas, cifradas y enviadas al Master Target Server en Azure.

Si miramos las distribuciones de GNU/Linux actualmente soportadas, veremos que las opciones no son especialmente amplias. Tenemos las siguientes:

  • CentOS 6.4, 6.5, 6.6 (amd64)
  • Oracle Enterprise Linux 6.4, 6.5 (amd64)
  • SUSE Linux Enterprise Server SP3 (amd64)

Hay distribuciones muy comunes en entornos productivos empresariales que quedan fuera de esta lista, como Redhat Enterprise Linux, o Debian y las basadas en la misma, como Ubuntu. Lo primero que se le viene a un sysadmin a la cabeza, es que, si conocemos bien la distribución en la que queremos implementar el servicio, basta con adaptar el paquete de instalación, sistema de paquetes y sus scripts para que se instale en nuestro sistema. Así podríamos usar alien para convertir los RPM en DEB y editar los scripts para adaptar el sistema de arranque y las rutas… Craso error…

Como he comentado al principio de este artículo, este agente se integra con el kernel de Linux, que como los más técnicos sabréis se trata de un kernel monolítico, con la estructura que podéis ver en la siguiente imagen, cortesía de Wikipedia:

image

Como se puede ver, la totalidad del sistema operativo opera en modo kernel. Como todo en la vida, los kernels monolíticos tienen ventajas e inconvenientes sobre otras arquitecturas de núcleos de sistemas operativos, como los microkernel y los kernel híbridos. En cualquier caso, una de las consecuencias de este modelo es que si vamos a desarrollar algún software que requeire trabajar a bajo nivel con el sistema, probablemente debamos implementarlo dentro del kernel, seguramente como un módulo del mismo. Si desarrollamos un módulo para el kernel de Linux y realizamos una compilación para una versión determinada del kernel, este binario sólo se puede incorporar en la versión exacta del kernel para el que ha sido compilado. Por ejemplo, imaginad que desarrollamos un módulo para la versión 3.2.0; esta sólo se podrá ejecutar en esta versión concreta del kernel y en ninguna otra.

Cuando examiné el contenido del paquete de instalación del Mobility Service pude ver lo siguiente:

image

Y si examinamos el script install_vx podemos ver lo siguiente:

image

Esto empieza a pintar a versiones muy concretas del kernel en distintas distribuciones… Me temo que como nos salgamos de esto no vamos a lograr que el servicio funcione. Si vamos un poco más allá y examinamos los contenidos del paquete InMageVx-8.4.0.0-1.x86_x64.rpm descubrimos los siguientes archivos:

image
Y aquí definitivamente nos encontramos con los módulos del kernel y la versión concreta para la que están preparados. Llegados este punto, la única forma de la que podríamos hacer funcionar el Mobility Service sería instalando en nuestra distribución la versión concreta del kernel para la que está soportado. Tened en cuenta que aunque llevásemos a cabo esta acción, estaríamos totalmente fuera del soporte que Microsoft da a la solución, por no mencionar que es toda una temeridad cambiarle el kernel a un sistema del cual pretendemos hacer un plan de Disaster Recovery o una migración con RPOs y RTOs cercanos a cero.

Así pues terminamos con las siguientes conclusiones:

  • El Mobility Service de Azure Disaster Recovery sólo puede instalarse en las versiones de GNU/Linux concretamente soportadas: CentOS, Oracle Linux y SUSE Enterprise Linux en sus versiones y arquitecturas concretas.
  • Puesto que la intercepción de la E/S de disco de la máquina se realiza a bajo nivel desde el mismo kernel, el driver del agente está implementado como módulo del mismo. No podemos adaptarlo a otras versiones del kernel porque sólo tenemos los binarios.
  • Las alternativas que Microsoft podría implementar para dar un soporte a más distribuciones sería:
    • Distribuir el código fuente del agente de forma que se compile durante la instalación. Esto haría el agente mucho más universal y no dependiente de versiones concretas del kernel.
    • Proveer de un buen número de binarios que soporte las versiones del kernel más comunes que se pueden encontrar a día de hoy.

De una forma u otra, esperamos que Microsoft de soporte a un rango más amplio de distribuciones de GNU/Linux para que este servicio tan potente se haga muy flexible. ¿Quieres aportar tu sugerencia? ¡Déjasela caer en el User Voice de Azure Site Recovery!

Happy migration!

Configurar SNMP en Linux

Una de las múltiples tareas básicas del administrador es obtener toda información precisa acerca de los diferentes elementos presentes en nuestra red.  Existen muchas herramientas que nos pueden facilitar la recolección y procesado de dicha información,  un ejemplo sería SCOM del que ya hablaré en futuros artículos, las cuales se sirven  de una tecnología llamada SNMP para obtener los datos necesarios.

SNMP (Simple Network Management Protocol) fue creado para obtener información de varios sistemas en de una manera consistente. Esta operación, será llevado por agentes instalados en los diferentes dispositivos con el objetivo de ofrecer toda la información posible  utilizando el protocolo SNMP, según demanda, a partir de un archivo conocido como MIB, en el cual se indica toda la información que podremos recoger y/o cambiar en el dispositivo.

Actualmente existen tres versiones de dicho protocolo :

  • V1 donde  la información es intercambiada a través de mensajes (PDU) entre dos clientes  cuya autenticación se realiza a partir de una cadena de caracteres conocida como community string  en texto plano. Es  la versión más utilizada por ser la más simple, con lo que la utilizaremos en este ejemplo.
  • V2 donde se incorporan nuevos mecanismos de seguridad y se facilita el manejo de información.
  • V3 donde se incorporan más mecanismos de seguridad como encriptación del mensaje así como refuerzo de su integridad además de mejorar los mecanismos de autenticación entre los clientes.

Ahora imaginemos que en nuestra infraestructura  queremos monitorizar un dispositivo de red con Linux instalado (por ejemplo Ubuntu 14.04). Normalmente, en Linux , SNMP no viene implementado ni configurado por defecto, con lo que para poder obtener toda la información que necesitamos, es necesario ejecutar una serie de pasos que se detallan a continuación.

El primer punto a realizar es instalar el demonio de SNMP.

Una vez instalado,   podremos consultar el archivo de configuración  en /etc/snmp/snmpd.conf  donde , para que el agente SNMP sea accesible en toda la red, deberemos cambiar la configuración de la community string , para facilitar la autenticación entre clientes sustituyendo la siguiente línea:

por la línea

donde <red> es la red donde está ubicado el dispositivo, restringiendo así el acceso a todos los ordenadores pertenecientes a nuestra red y public  es la clave de autenticación que podemos cambiar si así lo deseamos.

Por otro lado,  hay que hacer que el agente pueda escuchar las peticiones de otras máquinas para proveer información ya que por defecto, en la configuración, sólo atiende a peticiones de la propia máquina donde está instalado.  Igual que la operación anterior , debemos modifcar el archivo de configuración /etc/default/snmpd  cambiando la linea

por la línea

Finalmente,  deberemos de reiniciar el proceso demonio para que los cambios se hagan efectivos :

Y con ello, ya tendríamos configurado de forma correcta el protocolo SNMP en un dispositivo de red con Linux. Comentar que en futuros artículos, hablaré de la herramienta  SCOM, cómo monitorizar este tipo de dispositivo, así como reforzar la seguridad configurando SNMPv3.

¡Nos vemos!

Análisis de Paquetes con PowerShell

A veces, la única opción para localizar problemas en una aplicación o servicio consiste en analizar el tráfico de red, para comprobar que todo está funcionando correctamente.Una pequeña joya disponible para los aficionados a la Shell son los cmdlets de Captura de Paquetes de Eventos de Red (Network Event Packet Capture cmdlets). Están disponibles para Windows Server 2012R2 y Windows 8.1.

Captura de Paquetes

Con esos cmdlets es posible registrar todos los eventos de red que se producen en la máquina. Tan sólo hace falta alguna forma de guardarlos. Aquí entra en juego el “ETL Logging” (ETL por Event Trace Log), que viene a ser la tecnología que permite a Windows guardar todos los eventos del sistema, para luego poder consultarlos con el Visor de Eventos (tip: para abrirlo de la forma más rápida posible, usa el cuadro de diálogo “ejecutar”, y se escribe el nombre de la aplicación del visor de eventos: Win+R –> eventvwr).

¿Cómo lo hago?

En resumidas cuentas, para capturar los eventos de red, hay que crear una sesión del capturador, establecer un proveedor de logs, iniciar la sesión, hacer lo que haya que hacer con la red, parar la sesión, y finalmente… eliminar la sesión. El proceso paso a paso queda así:

  • En primer lugar es necesario abrir una sesión de Administrador de PowerShell. El motivo es que la captura de paquetes requiere de privilegios elevados. Puede parecer una molestia, pero es una buena práctica de seguridad.
  • Crear la sesión de captura de paquetes: new-neteventsession -name “sesion1”image
  • Hasta aquí todo fácil. Toca elegir un proveedor de logs, para guardar un registro del tráfico. Una manera sencilla de obtener una lista de proveedores de logs relacionados con la red es con el comando logman query providers | select-string tcp
    image Se obtienen tres proveedores, para elegir el primero se escribe: Add-NetEventProvider -Name “Microsoft-Windows-TCPIP” -SessionName “sesion1”
    image
  • Ya está todo listo, se puede empezar a capturar los paquetes. Para ello, se inicia la sesión de captura. Start-NetEventSession –Name “sesion1”
    image
  • Se puede obtener información sobre la sesión de captura de paquetes con el cmdlet Get-NetEventSession
    image
  • Una vez obtenida la información deseada, se detiene la captura con Stop-NetEventSession -Name sesion1
    image
  • Finalmente, una vez detenida la sesión, se puede eliminar de la Shell. Para variar, usaremos un pipe con el cmdlet Remove-NetEventSession. Como se ha visto en artículos anteriores, la primera parte del pipe/tubería obtiene todas las sesiones, y las pasa una a una a la segunda parte del pipe, que en este caso, se encarga de eliminar las sesiones.
    image

Una vez se han completado todos estos pasos, se tiene un archivo de log con la información de red capturada, pero falta por responder una pregunta esencial: ¿Cómo visualizar/analizar estos datos? Como se comentó al principio es posible emplear el visor de Eventos de Windows para leerlos.

image

Para ello, se usa el menú Acción, Abrir Log guardado, y se abre el archivo de log que se ha creado durante la sesión de captura de paquetes. En este caso, el archivo en cuestión es C:Windowssystem32configsystemprofileAppDataLocalNetEventTrace.etl

image

Una vez abierto, nos aparece una nueva sección en la aplicación llamada “Saved Logs”, en la que se encuentra el archivo que se acaba de abrir

Capture

Conclusión

PowerShell ofrece herramientas de monitorización de red, que se pueden integrar en un script, por ejemplo, para analizar si una determinada aplicación se está comportando de la forma debida, o incluirlo dentro de rutinas de mantenimiento para detectar tráfico a direcciones o puertos sospechosos.

Bonus

La Shell también ofrece un cmdlet para leer archivos de log ETL, Get-WinEvent. Esto proporciona capacidades de filtrado de cadenas adicional, que no se tiene en la aplicación del visor de Eventos.

image

Por ejemplo, y sin ir más lejos, una vez que se tiene la variable $log con la ejecución de la línea mostrada en la captura anterior, se puede lanzar el siguiente comando: $log.message | Select-String -SimpleMatch ‘fail’ , lo que mostraría una lista de errores de conexión.

Hasta siempre

Este es uno de esos post que cuesta mucho escribir. Han sido más de tres años formando parte de un equipo espectacular, y dentro de una empresa en la que siempre me he sentido como en casa.

La semana pasada fue la última (de momento) como empleado de Plain Concepts, y como miembro activo del equipo de Enterprise/IT. Atrás dejo muchos findes con mi compañero y amigo Carlos, trasteando con lo último, montando soluciones pioneras, y disfrutando como un niño pequeño. Muchos despliegues y soluciones implementadas en Plain (siempre en Producción, por supuesto) y también, muchos eventos en los que nos hemos convertido en una pareja de profesionales bastante famosilla Sonrisa. Siempre quedarán para el recuerdo el “Milán como la goma de borrar, pero no como el hijo de Shakira”, o la imagen de Julio Iglesias “enchufándosela” a Amazon y Azure por igual.

Guardaré con especial recuerdo muchos momentos, pero sobre todo nuestro “Desayuno de Infraestructura”. Subirme al escenario con el resto de mi compañeros, en la sede de Microsoft ante un auditorio abarrotado, marcan un hito en mi carrera profesional. Elena, Alfredo, Antonio, Manolo… tenéis que seguir dando guerra.

Ahora toca empezar caminos y retos nuevos. La vida da muchísimas vueltas, y uno nunca sabe donde va a acabar en unos años, pero creo que es importante mantenerse activo y aprovechar las buenas oportunidades que puedan surgir.

Les deseo lo mejor a mis compañeros y amigos del equipo de Enterprise/IT, aunque estoy convencido de que les irá genial. Además, les seguiré viendo a menudo y todavía participaremos juntos en algún sarao más como el próximo Hel10 World!

No es un hasta nunca, es un hasta siempre.

GRACIAS

Alberto