Archivo de la etiqueta: powershell

DiskSpd, el sucesor de SQLIO

A la hora de medir el rendimiento de una unidad de almacenamiento, una de las herramientas más útiles y fiables (en entornos Windows) era SQLIO. A pesar de lo que su nombre pueda indicar, esta herramienta no servía para medir la E/S generada por una consulta SQL, sino para obtener medidas de rendimiento de disco. Sin embargo, después de algunos años entre nosotros, se podían apreciar señales de que poco a poco se estaba quedando fuera de su tiempo.

Entra DiskSpd

Finalmente, y tras su última actualización a finales del 2015, SQLIO fue retirado, y reemplazado por una nueva herramienta: DiskSPD. Al igual que su predecesor, se utiliza para obtener métricas de rendimiento de unidades de almacenamiento, pero con un conjunto de utilidades adicionales que lo convierten en algo mucho más útil. Además, y para los aficionados al Software Libre, su código fuente está disponible para descarga en GitHub, con una licencia MIT.

Ahora bien, entre todas las funciones, hay una característica particularmente interesante para los que desarrollamos scripts PowerShell: DiskSPD puede volcar la salida en formato XML. Esto es importante, porque facilita enormemente el procesado masivo de datos obtenidos mediante la ejecución de tests de diskspd.

Dentro de la carpeta de GitHub, hay un conjunto de scripts denominados VMFleet, que permite hacer operaciones y tests de forma masiva en máquinas virtuales, pero para aquellas personas menos ambiciosas que se conforman con testear el rendimiento de una única unidad, acompaño el artículo con un par de pequeños scripts para ejecutar baterías de tests. Obviamente, se pueden personalizar los parámetros de DiskSpd para simular lo más fielmente posible la carga de trabajo del servidor destino, pero como ejemplo ilustrativo basta.

El primero, lanza n ejecuciones de diskspd, bajo un cierto set de parámetros y recopila la salida en una serie de archivos XML en una carpeta especificada. Con $iteraciones podemos especificar el número de repeticiones del experimento, que se guarda en la carpeta especificada con $tag (que además personaliza el nombre del fichero xml generado). El parámetro $threads se usa para especificar cuántos hilos de trabajo deseamos lanzar simultáneamente, con lo que podemos poner, por ejemplo, un hilo por core del sistema.

El segundo script toma los XML de dicha carpeta, y calcula la velocidad media (en MB/s) de rendimiento del disco en base a los datos recopilados. Teniendo en cuenta que el rendimiento de un sistema puede variar a lo largo del tiempo por múltiples circunstancias, lo más realista es realizar varios experimentos idénticos, y promediarlos.

Process-SpeedData se encarga de promediar la velocidad de lectura/escritura y mostrar en pantalla el resultado, a partir de los archivos XML generados por el script anterior, para ello simplemente se le pasa como parámetro la carpeta que se desea escanear, y el script leerá y promediará la información de todos los XML que encuentre en la misma.

Resumiendo…

Aunque SQLio nos ha acompañado durante años y sigue siendo igual de funcional que antes, ahora disponemos de una herramienta igual de potente, más flexible y que además es Open Source. La capacidad de generar la salida en formato XML aquí es una característica diferenciadora que permite incorporar muy fácilmente la salida de información en scripts PowerShell que procesen los datos de rendimiento generados (latencia de acceso, velocidades medias, etc).

Configurar un ILB con PowerShell en Azure Resource Manager

De acuerdo con la documentación de azure, tenemos no una ni dos, sino cuatro formas distintas de definir un balanceador interno de carga en Azure Resource Manager desde cero. Ahora bien, ¿qué sucede cuando ya se tiene infraestructura desplegada y se desea balancear?

Antes de nada… ¿qué es un balanceador interno?

Un ILB (siglas en inglés) proporciona balanceo de carga de red entre máquinas virtuales que residan en la misma red virtual de Azure. Este servicio permite la creación de servicios configurados en alta disponibilidad, de forma que, ante picos elevados de carga, el trabajo se distribuye equitativamente entre los miembros del grupo balanceado. Igualmente, en caso de que alguna máquina del grupo balanceado deje de funcionar, ya sea por tareas de mantenimiento, error de configuración, o fallo de la máquina virtual, el balanceador detecta que la máquina afectada ya no está disponible, y de forma dinámica redistribuye la carga entre el resto de máquinas virtuales del grupo balanceado.

Un escenario básico se correspondería con el siguiente diagrama:

ilb

Se tienen dos máquinas que actúan como servidor Web, dos interfaces de red, el balanceador de carga, y una IP privada que es donde se van a recibir todas las peticiones de servicio.

Descripción del escenario propuesto:

Se tiene un servidor web linux, que está proporcionando un servicio, pero se desea cambiar la configuración “servidor único” por una configuración balanceada, para obtener los beneficios de reducir la carga del servicio en la máquina original, así como conseguir tener una infraestructura más resistente a fallos.

En este caso, una opción sencilla es desplegar una máquina idéntica a la máquina original, y configurar el balanceo de carga a posteriori.

Para asegurarse de que la segunda máquina es una copia idéntica de la primera, es posible utilizar un software como rsync.

Así pues, en este escenario tenemos ya dos máquinas virtuales, con sus correspondientes interfaces de red, y todo está ya funcionando. Sólo falta balancear el sistema.

Paso a paso

En primer lugar, toca iniciar sesión en Azure. En el ejemplo, mi cuenta sólo está adscrita a una suscripción de Azure. En caso de que estuviese dado de alta en más de una, habría que usar los cmdlets “Get-Azure-RmSubscription” y“Select-AzureRmSubscription” para determinar el ID de la subscripción que se desea utilizar, y así poder seleccionarla.

login_vm

Como las máquinas virtuales ya existen, pertenecen a una red virtual de Azure. En este caso, tendremos que averiguar en qué red están con el cmdlet “get-AzureRmVirtualNetwork”. Este cmdlet nos permite seleccionar la red virtual en la que están las máquinas virtuales, y así poder trabajar con sus subredes.

De esta forma, se puede crear la IP de frontend que va a definir el punto de entrada de las solicitudes del servicio balanceado. A continuación, se crea el backend que recibe el tráfico del frontend.

 

createFrontEndBackEnd

Una vez se ha creado todo lo necesario, se puede proceder a crear el balanceador de carga:

ilb-ps

Ahora es cuando empieza lo interesante: Se tienen las máquinas virtuales, las interfaces de red, y el balanceador de carga. Toca ir juntando las piezas para formar el puzzle.

Se obtiene la configuración de cada interfaz de red de las VM, y se le asigna el backend del balanceador de carga. A continuación, se guarda la configuración de la interfaz de red, y con esto se asigna dicha interfaz al balanceador de carga interno:

setInterface

Una vez asignadas ambas interfaces, el balanceador de carga interno estará listo para su uso.

Desde el portal de Azure se puede examinar la configuración del balanceador.

backend

Y finalmente llega la prueba de fuego: testear el servicio balanceado. Como las máquinas son servidores linux, la forma más sencilla de hacerlo es editar la página de inicio de Apache con versiones diferentes de la web, de forma que la respuesta que devuelve cada servidor sea diferente. En este caso, se ha optado por hacer que cada máquina devuelva “server1” o “server2” dependiendo de cuál de ellos está sirviendo la respuesta.

balanceado

En esta prueba, primero se hace una conexión en local al servidor, a ver de qué máquina se trata, y a continuación se hace una petición al ILB, para ver qué máquina nos está respondiendo. Se puede ver que, en cada caso, la respuesta la devuelve una máquina distinta, así que el balanceador funciona correctamente.

Al ser un servicio balanceado, en caso de que uno de los servidores deje de funcionar, la sonda se encargará de determinar en un intervalo máximo de 45 segundos que la máquina afectada no debe de seguir dando servicio (en el caso de que la máquina falle justo después de una sonda, ésta ha de fallar dos veces consecutivas para que el ILB deje de usarla para servir respuestas, en un intervalo de 15 segundos entre cada sondeo).

Conclusiones

De esta forma, se puede configurar un servicio balanceado usando PowerShell. Hay documentación que automatiza el proceso incluyendo la creación de servidores e interfaces de red. Actualmente, ése es un proceso muy interesante si tenemos en cuenta que actualmente hay una limitación muy importante en la configuración de los balanceadores de carga, y que se describe en la siguiente sección.

A continuación, se adjunta un script que resume los pasos llevados a cabo para montar el servicio.

script

Limitaciones actuales

Ambas máquinas deben estar en el mismo grupo de disponibilidad. En el modo clásico, se pueden añadir o quitar libremente máquinas virtuales de un grupo, pero en modo Resource Manager, aún no hay soporte para ello. En caso de que ambas máquinas no estén en el mismo grupo de disponibilidad (Availability Set), aparecerá un mensaje de error similar a este:

different-availabilitySet

En el modo Service Manager de Azure, sí que es posible asignar una VM a un Availability Set sin ningún tipo de problema. Cabe esperar que en un futuro próximo esta funcionalidad también esté disponible en el modo Resource Manager.

Gestión, uso y aplicación de Azure Storage Queue

El Azure Queue storage es un servicio cuyo objetivo consiste en el almacenamiento de un gran número de mensajes, los cuales pueden ser accedidos desde cualquier lugar a través de llamadas autenticadas mediante HTTP o HTTPS. Para llevar a cabo este almacenamiento se emplea una estructura de datos basada en la cola.

Creación de una cola en Azure

El primer paso para poder utilizar una cola de empieza por la creación de una storage account. Este proceso no conlleva dificultad alguna y es bastante dirigido. Lo primero que hay que hacer es entrar en el portal de azure, y después pulsar en New > Data + Storage > Storage Account

azure storage account 1

A continuación nos solicitarán los diversos datos de la storage account, nombre, tipo de localización, etc. Un punto muy importante a tener en cuenta es la selección del modo de creación de la cuenta: modo clásico o modo RM (resource manager), ya que la gestión y uso de las colas de momento no es posible hacerla en Powershell en modo RM, pero sí en modo clásico.

Una vez creada la cuenta, aparte de las colas, contamos con servicios de ficheros, tablas y blobs.

azure storage account 2Y entre la información que nos ofrece el panel de nuestra storage account creada sobre las colas, todo lo necesario (nombre de la cuenta, claves de acceso y cadenas de conexión) para poder acceder a este recurso externamente.

azure storage account 3

Gestión de la storage account en Powershell

Hay que diferenciar aquí lo que se puede hacer en modo clásico o modo RM. En ambos modos, se pueden llevar a cabo las siguientes operaciones sobre la cuenta:

  • Creación.
  • Eliminación.

El modo RM permite además de otras cosas, por ejemplo, regenerar la storage key de una cuenta

Uso de las colas

En lo que se refiere al uso del servicio de las colas (creación, eliminación), así como las operaciones típicas sobre estas (inserción de un mensaje, extracción…), solo es posible hacerlo en modo clásico, puesto que en el modo RM no hay cmdlet disponibles de momento para ello. En los ejemplo se muestran los mismos.

Ejemplos

Como ejemplos sencillos de creación, inserción de un elemento, extracción del mismo y eliminación de una cola, tendríamos los siguientes:

En .NET, puede actuar indistintamente sobre una storage account creada en modo clásico o RM:

En Powershell, sólo se puede utilizar una cola creada de una storage account creada en modo clásico:

Y esto es todo por mi parte. Espero haber mostrado un poco este servicio y las posibilidades del mismo.

Mantén tu Azure PowerShell al día con PowerShell Get

Probablemente mientras estoy escribiendo estas líneas, un nuevo servicio o característica está apareciendo en Azure. Para mantenernos a la par con este ritmo tan frenético de evolución necesitamos tener las herramientas con las que operamos en Azure igualmente actualizadas. Mi compañero Manuel Marín dedica la mayoría de sus publicaciones a las herramientas de línea de comandos multiplataforma, disponibles para Windows, OSX y GNU/Linux; mientras que servidor se centra en PowerShell. Actualmente las herramientas de Azure para PowerShell se pueden instalar de dos formas:

  • Mediante Web Platform Installer, WebPI para los amigos. Se trata de una herramienta que nos permite instalar automáticamente componentes, en su gran mayoría para uso con IIS. En ocasiones encontramos paquetes individuales no relacionados necesariamente con el mundo web, como es el caso de las herramientas de administración de Azure a través de PowerShell. Esta forma de instalación es realmente intuitiva, amena y se hace mediante interfaz gráfica.
  • Desde la Galería de PowerShell, usando PowerShell Get. Esta forma de instalación es también trivial e incluso más rápida que la basada en WebPI, pero se realiza a través de línea de comandos desde la propia PowerShell. Nos vamos a centrar en este método, ya que es mucho más sencillo de mantener al día.

Dado que nos vamos a centrar en el método de la Galería de PowerShell, conviene no mezclar ambos métodos de instalación. Así que en el caso de que hayamos instalado las herramientas mediante WebPI, las desinstalaremos convenientemente desde Programs and Features. Una vez desinstalado procedemos con PowerShell.

La Galería de PowerShell

La Galería de PowerShell no es ni más ni menos que un repositorio central de scripts y módulos de PowerShell, disponibles para descargarse al estilo apt-get desde nuestra línea de comandos. Para poder descargar estos elementos, se vale a su vez de un módulo llamado PowerShellGet. ¿Cómo lo obtenemos? Dependerá de nuestra versión de Windows:

  • Windows 10 / Windows Server 2016. No es necesario hacer nada, ya tienes todo lo necesario.
  • Windows 7 SP1 / Windows Server 2008 R2 SP1 , Windows 8.1 / Windows Server 2012 (R2). Hay dos opciones:

image

Instalando los módulos de Azure

Teniendo ya nuestro PowerShellGet preparado –recuerda que si estás en Windows 10, ¡no tenías que hacer nada!-, instalar las herramientas de Azure es completamente trivial. Basta con ejecutar este script como administrador del sistema:

Esto nos debería dar una salida por pantalla pantalla similar a la siguiente:

image

¿Hecho? Empezar a trabajar con Azure desde PowerShell será tan sencillo como:

Actualizando o desinstalando módulos

Y esto es lo mejor, ya que mantener al día nuestra herramienta se vuelve realmente trivial:

Y la desinstalación:

Sabiendo esto, es incluso posible programar una tarea que vele por que nuestras herramientas se mantengan actualizadas ejecutando los cmdlets necesarios en los momentos adecuados.

¡Happy PowerShell y Azure!

Enlace relacionado: Cómo instalar y configurar Azure PowerShell

Monitorizar eventos con PowerShell

En una entrada anterior de este blog, se describía un sencillo sistema con el que monitorizar el espacio libre en los discos de un sistema. Esto ayuda a prevenir problemas como que un servidor de máquinas virtuales se quede sin espacio prematuramente, lo que provoca un bloqueo total de todos los sistemas virtualizados.

Montar un sistema de notificaciones push para un sencillo script que vigila el espacio libre en disco puede parecer un poco overkill para la situación, así que… ¿Por qué no intentar exprimirlo un poco mas? Siguiendo en la línea de monitorizar de un servidor hay una parte que es especialmente útil, sobre todo para diagnosticar problemas: El visor de eventos.

Se abre el telón: Get-EventLog

Este pequeño cmdlet se encarga de leer los eventos del sistema, permitiendo además capacidades de filtrado para poder obtener aquellos que sean de interés para el usuario. La forma más básica de usarlo es invocándolo con el parámetro “-list” ,  que devuelve un listado de todos los logs que se pueden consultar.

Para consultar un log en concreto, se usa “Get-EventLog –LogName <nombreLog>”, donde nombreLog puede ser, por ejemplo “Application” o cualquier otro valor devuelto por la opción “-list”. Además de consultar un log determinado, se puede filtrar de varias formas diferentes, como por ejemplo con el parámetro “-newest <cifra>”, para recoger los últimos cifra eventos registrados en el sistema, o el parámetro “-entrytype <tipo>” para filtrar la respuesta por los siguientes tipos: Error, FailureAudit, Information, SuccessAudit o Warning. Cada uno de estos tipos se corresponde con los tipos que se pueden encontrar en el Visor de Eventos.

Juntando las piezas

Se tiene un sistema para enviar notificaciones, se tiene algo que se desea monitorizar, se tiene una forma de acceder a lo que se quiere vigilar, y se tiene un temporizador con el que invocar todo automáticamente. Con estas cuatro piezas, ya es posible montar un sistema que vigile los eventos generados en el sistema. En este caso, el script solicita los eventos de error guardados en el log “Application”, que se hayan generado en la última hora.

El resultado

Ejecutar este script, genera la siguiente salida en PowerShell (el resultado obviamente cambiará en función del momento y del equipo utilizado).

resultShell

Y como no podía ser de otra forma, slack recibe la notificación directamente desde el script PowerShell. En entornos en los que sea necesario vigilar específicamente una aplicación se pueden hacer filtrados adicionales, no ya a nivel de consulta de Get-EventLog, sino utilizando el famoso Where-Object para filtrar, por ejemplo, por una subcadena del mensaje de error que resulte de especial interés.

slack

Finalmente, y al igual que el script de monitorización de discos del que ya hablamos antes, se puede crear una tarea programada periódica que compruebe el registro de eventos en busca de errores.

Conclusiones

Como se ha visto en el código, se pueden pedir los eventos para la última hora, o para cualquier intervalo de tiempo. Teniendo en cuenta que consultar el registro de eventos puede ser una operación costosa (dependiendo del número de eventos se esté consultando), sería deseable que el intervalo mínimo de consulta de eventos sea una hora, en vez de unos pocos minutos, cuando se está consultando un log que tenga un tamaño apreciable.

Una alternativa interesante consiste en programar un trigger de la tarea programada para que se dispare con un evento, en vez de a un intervalo prefijado. De esta forma, si se tiene conocimiento sobre el tipo de evento que se quiere vigilar, se puede obtener la notificación push prácticamente en el momento en el que se lanza el evento. Esto se puede ver más claramente en la siguiente captura de pantalla. Aunque en este caso, cabe la posibilidad de usar un script mucho más específico, que mande la notificación push adecuada, sin tener que entrar a leer los eventos del registro, filtrarlos, y generar el mensaje automatizado.

newTrigger

PowerShell: Disco duro libre y notificaciones PUSH

Un nuevo año, una nueva semana, y un nuevo artículo sobre PowerShell. En el artículo anterior se hablaba sobre un sistema que enviaba mensajes de email cuando un website de una lista no estaba online. Eso está bien para casos en los que se necesita un informe de estado periódico. Pero si lo que interesa es actuar sobre una emergencia… que está ocurriendo en este mismo instante, tal vez sea necesario tomar una aproximación más inmediata.

En el script de hoy, el objetivo es saber si una máquina de la granja de servidores de la empresa se está quedando sin espacio libre en disco. Para ello se hará uso de una consulta WMI, el programador de tareas de Windows y un servicio PUSH de notificaciones a teléfonos móviles.

El código

Paso a Paso

Acceso a información de discos locales

Desde powershell, esto se puede ver fácilmente con el siguiente comando: “gwmi win32_volume -Filter ‘drivetype = 3’”, que devuelve una lista detallada de parámetros para cada uno de los discos del sistema. Esto constituye la primera pieza del puzzle que toca resolver.

get-drives

El DriveType indica el tipo de disco que se desea consultar. En este caso, el DriveType = 3 hace un filtrado para mostrar únicamente los discos duros locales. Para cada uno de los discos que devuelve, se quiere procesar los que tengan una capacidad superior a 0 para descartar cualquier unidad de CD/DVD que pudiera haber pasado el filtro.

Entran en escena los servicios PUSH

Hay multitud de proveedores de servicios PUSH, como PushOver, Slack, PushBullet, NotifyMyAndroid… Cada uno tiene sus ventajas e inconvenientes: Los hay con diferentes modelos de licenciamiento, desde licencia por plataforma en la que se instale, hasta la compra de paquetes de mensajes cuando se llega al límite máximo de mensajes mensuales.

De todos los nombrados anteriormente, hay uno que tiene cliente móvil para las tres grandes plataformas (Android, IOS y Windows Phone) y que además tiene la segunda pieza necesaria: una API REST con la que poder enviar notificaciones: Slack

De la API, que incluye funciones para infinidad de tareas, la parte interesante es la que envía un mensaje al chat. Por limpieza y reusabilidad del código, esta parte se ha separado en una función aparte llamada “Send-SlackMessage” que acepta como parámetros el canal al que se desea enviar el mensaje, el nombre de usuario que aparece como “agente publicador”, y el mensaje en sí. Esta función se puede sacar del código y utilizar como notificador en cualquier otro script PowerShell, como procesos que tardan horas en completar, o cualquier otra situación en la que se considere que sea necesario recibir notificaciones.

La parte más importante, y de la que depende que todo esto pueda funcionar, es el token de cliente. En este caso, desde la web de Slack se puede solicitar un token de usuario desde el que enviar notificaciones de una forma muy sencilla y automatizada, sin necesidad de tener que implementar ningún tipo de esquema de autenticación.

¿Por algún motivo el token queda expuesto y empiezan a llegar mensajes de spam? Simplemente se genera un nuevo token, y listo.

get-token

Programando tareas

Nada de esto tendría sentido si no hay una forma de hacer una comprobación periódica del estado del disco. Esto se puede lograr muy fácilmente con el Task Scheduler de Windows. En primer lugar se programa el trigger para que se ejecute diariamente cada 10 minutos.

new-task

Y en segundo lugar se especifica la acción a realizar. En este caso, lanzar una PowerShell –file “nombreFichero.ps1”, que es donde está guardado el script que acompaña a este artículo.

new-task2

Comprobación y Conclusiones

Finalmente, toca comprobar que todo ha funcionado correctamente, y que la notificación se ha recibido en los diferentes medios (Android, Windows Phone, PC,…)

message

Screenshot_Android   Screenshot_WP

Como se puede ver, aunque Slack proporciona clientes para todas las plataformas la interfaz de usuario y la organización de los mensajes cambia dependiendo de la plataforma.

En conclusión, mediante el uso de sistemas de mensajería Push, se pueden enviar notificaciones a canales específicos lo que permite avisar a un equipo completo de trabajo de que algo está pasando con los servidores, al tiempo que la bandeja de entrada de correo electrónico se puede mantener algo más limpia de mensajes. Esto puede permitir una interacción más ágil entre los miembros de un equipo para coordinarse en la resolución del problema.

Comprobar disponibilidad de websites con PowerShell

En ocasiones, para un administrador de sistemas, resulta imprescindible saber si un determinado sitio web está levantado o no. Esta necesidad aumenta aún más, si cabe, si el administrador tiene a su cargo una elevada cantidad de sitios que monitorizar. Una solución rápida puede ser, por ejemplo, lanzar un comando ping para saber si un servidor responde a una cierta dirección. Pero esto no nos da información sobre si una cierta URL está activa o funcionando correctamente.

Para este tipo de situaciones, hace falta hacer procesamiento a un nivel más alto que simplemente “comprobar que la máquina responde”. Y aquí es donde PowerShell viene a ayudar, automatizando el proceso y proporcionando acceso a funciones de alto nivel que proporcionan información adicional.

El Código

Paso a paso…

En primer lugar, nos pide las credenciales de nuestra cuenta de correo. En este caso, las de un servidor de correo ficticio llamado “unsmtp.plainconcepts.com”. Para los que tengan Office365, también funciona con estas credenciales.

credentials

A continuación, se crea un array vacío en el que se van a guardar una serie de objetos a partir del cual se generará un informe. Justo después se define un array de URLs en el que se tiene una serie de sitios web a consultar. Importar la lista de URLs desde un archivo CSV es mucho más conveniente, pero a efectos de script demo, se decidió prescindir de esa parte para que el script funcione “tal cual” sin dependencia de otros archivos.

Para cada elemento de la lista de URIs, se hace una llamada al sitio web con invoke-webRequest. Esto hace que PowerShell conecte con el sitio web, en caso de éxito, nos muestra en pantalla un mensaje “el host está online”, y guarda un objeto en el listado con el que se va a generar el informe. En caso de error se captura la excepción correspondiente y se discrimina por código de error, siendo los más interesantes son el 404 y el 500. Si se desea completar el script, se puede consultar la lista completa de códigos de estado HTTP y añadir los manejadores que se considere necesarios.

psOutput

En penúltimo lugar, una vez procesados todos los elementos de la lista de sitios, toca procesar el listado de objetos para generar un informe de estado en formato CSV. Este informe se guarda en la carpeta temporal del usuario, donde no moleste.

Finalmente, se envía por correo con send-mailMessage. Se puede enviar al propio usuario, o adjuntar una copia a otra persona.

email

informePreview

Conclusión

Como se puede ver, las partes más importantes de este script son la consulta a cada URL, que posibilita obtener información detallada del estado de cada una, y el envío del informe de estado en formato CSV por correo electrónico. Este script se puede añadir a una tarea programada que se ejecute diariamente (en caso de necesitar un informe diario), o modificarlo para que la tarea programada se pueda ejecutar con mayor frecuencia, pero modificando la parte de envío de informe por correo electrónico, para que el informe sólo se genere con los hosts que tengan problemas, y el email sólo se envíe cuando se genere el archivo CSV de informe.

¡Las posibilidades son ilimitadas!

Comandos útiles en Powershell

Me gustaría hablar en este post de algunos comandos que, ya sea por necesidad o simplemente por curiosidad, uno se va encontrando por el camino. Son los siguientes:

Envío de mensajes de correo con archivos adjuntos (solo para Powershell v5)
Una funcionalidad interesante es la posibilidad de que un script pueda enviar un mensaje de correo electrónico con uno o más archivos adjuntos.
Cabe destacar que este cmdlet solo está disponible para Powershell v5. Los parámetros básicos que hay que indicarle son bastante intuitivos:

 

Creación de un trabajo o job en el planificador de tareas
Si bien esto se puede realizar directamente con el interfaz gráfico del propio planificador de tareas, la posibilidad de creación o eliminación dinámica de un job mediante Powershell puede ser bastante útil, sobre todo en el caso de integrarla en un script.
La ejecución de un job requiere de cuatro elementos principales:
a) El elemento que se va a lanzar, que puede ser un ejecutable, un batch o un script.
b) Los argumentos que empleará dicho elemento, separados por comas.
c) El disparador o ‘trigger’, evento que actúa de detonante en la ejecución del job. Por ejemplo, una hora concreta de un dia determinado.
d) Las opciones adicionales del propio job.

Algo a señalar es que, si hay que eliminar un job existente y éste ha sido creado con el anterior comando, es recomendable hacerlo con este otro:

ya que si bien es posible hacerlo con el interfaz gráfico del planificador de tareas, posteriormente al utilizar comandos Powershell relacionados con esto, por ejemplo Get-ScheduledJob, se puede producir un mensaje de error.

Alerta sonora
Un complemento a una alerta visual (como un mensaje o aviso), puede ser la emisión de algún tipo de sonido. Esto puede ser interesante a la hora de introducir algún tipo de alerta sonora para indicar algún evento relevante, como por ejemplo que se ha encontrado algo o la misma finalización de un script.

En su forma más simple, se puede indicar el código de control correspondiente a la alerta, mediante el siguiente comando:

Esto puede servir para indicar un tipo de evento, pero es bastante limitado. Sin embargo, es posible reproducir sonidos del sistema o incluso archivos con extensión .wav. No hace falta decir que esta última forma es que la que gana en versatilidad al resto

 

Uso de un puerto serie
Aunque de por sí el puerto serie en sí puede estar en desuso, sin embargo nunca ha dejado de utilizarse. Así, por ejemplo, se emplea para comunicarse con microcontroladores diversos. La conexión se puede llevar a cabo mediante una conexión física y empleando, al menos, las tres señales mínimas (TxD, RxD, GND) sin control de flujo, o incluso una conexión inalámbrica empleando Bluetooth. Bluetooth suporta múltiples perfiles, y uno de ellos es el SPP (Serial Profile Port), el cual a efectos prácticos lo hace comportarse como un puerto serie estándar.

 

Y esto es todo por ahora. Espero que alguien pueda sacar provecho de alguno de estos cmdlet para dotar de más funcionalidad a algún script de Powershell.

Un gran terminal para Windows: ConEmu

Para muchos profesionales de infraestructura, la línea de comandos es una herramienta básica que nos permite en muchas ocasiones interactuar con el sistema más rápido que como lo haríamos con una interfaz gráfica. Además la línea de comandos suele tener capacidades muy potentes como por ejemplo hacer pipe entre distintos programas o scripts de automatización de tareas. Para hablar de la línea de comandos en el mundo UNIX nos solemos referir al Terminal, mientras que en Windows acostumbra a llamarse Símbolo del sistema o bien PowerShell en función de cuál ejecutemos; o bien Consola de forma genérica en ambos mundos. Sin embargo, esta comparación poco afortunada…

Cuando hablamos de una Consola debemos distinguir entre dos elementos distintos que trabajan de forma conjunta:

  • El emulador de terminal o consola. Es el programa que nos proporciona interacción con el intérprete. La ventana que rodea al área de la linea de comandos, así como los distintos elementos y controles de la misma son parte del emulador de terminal o consola.
    • Ejemplos de emuladores de consola (Windows): conhost.exe, ConEmu, cmder
    • Ejemplos de emuladores de terminal (Mac): Terminal, iTerm
    • Ejemplos de emuladores de terminal (Linux): xterm, gTerm, konsole, rxvt, Eterm
  • Intérprete de línea de comandos. En la consola constituye la shell, y es el componente que nos relaciona con la máquina. De ella depende la sintaxis de los comandos que escribimos y las facilidades que se dan al usuario, como el autocompletado con el tabulador, coloreado, historial de comandos, etc…
    • Ejemplos de intérpretes para Windows: cmd.exe, PowerShell, 4NT, command.com
    • Ejemplos de intérpretes para UNIX: bash, zsh, csh

Un desconocido que usamos todos los días: conhost.exe

Centrándonos en Windows, si símplemente ejecutas una nueva ventana de PowerShell o Símbolo del sistema, el emulador que estás utilizando es –sin duda- conhost.exe.

image

Lamentablemente, conhost.exe sufre de la misma historia que Notepad: desde Windows NT 3.1 el programa no ha cambiado prácticamente nada y nos ofrece la mismas capacidades incluso en Windows 8.1, que he decir que son bastante pobres con respecto a los modernos terminales que encontramos en GNU/Linux. Sin embargo, PowerShell volvió a traer el foco a la consola en los entornos Microsoft y en Windows 10 / Windows Server 2016 se han introducido finalmente mejoras, tal y como se aprecia en la nueva ventana de Propiedades:

image

Entre las novedades más destacadas encontramos:

  • Selección de texto línea a línea, en lugar de por bloques como iba siendo hasta Windows 8.1 / 2012 R2.
  • Filtrado al pegar texto en la consola.
  • Redimensionar la consola provoca un reajuste del texto para evitar el scroll horizontal.
  • Se puede cambiar la opacidad de la ventana.

Microsoft da un listado completo de todas las nuevas características aquí.

ConEmu

ConEmu es un emulador de terminal o consola para Windows de código abierto que me ha sorprendido muy gratamente por su cantidad de características, situándose incluso por encima de los terminales más avanzados de UNIX. Un emulador de terminal de estas características constituye el compañero ideal de PowerShell junto con las utilidades que he ido comentado en el blog bajo la serie PowerShell Utilities Series. Es por ello que se ha convertido en mi primera opción como terminal para plataformas Microsoft. ConEmu tiene el siguiente aspecto:

image

¿Qué nos ofrece ConEmu con respecto a la consola tradicional, conhost.exe? Lo más llamativo es:

  • Redimensionado realizando ajuste de línea en el texto para evitar el scroll horizontal.
  • Tabulaciones para poder tener abiertas múltiples consolas en la misma ventana.
  • Integración con ciertas aplicaciones que no son una consola, como PuTTY (a pesar de lo que pudiéramos pensar, PuTTY no es una aplicación de consola) o Notepad.
  • Integración con las Jumplist de Windows 7 en adelante, permitiéndonos ver en la barra de tareas el progreso de la ejecución de una tarea PowerShell.
  • Búsqueda de texto integrada en el terminal.
  • Barra de estado con multitud de elementos de información del sistema.
  • Modo Quake
  • Macros
  • Cambio de opacidad de la ventana.

Se puede ver un listado completo de las características aquí. A continuación se puede otro ejemplo de ConEmu con PuTTY integrado en una pestaña:

image

Así que ya sabéis, si sois amantes de la consola y usuarios de Windows, ConEmu sea seguramente una visita obligada para darle una buena probada. ¡Espero que os resulte muy útil!

Happy command line!

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.