Archivo de la etiqueta: csv

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!

Borrado de objetos fantasma del metaverso

Como ya hemos visto en una introducción a FIM/MIM, este producto es un poderoso sistema de sincronización de identidades. Para hacer su misión, guarda información de objetos de diversos tipos en el Metaverso, que actúa a la vez como origen y destino de información.

Para traer la información al Connector Space de un Management Agent (MA), se dispone de dos operaciones: full import y delta import. Estas operaciones, como su nombre indica, están pensadas para jugar dos roles en el proceso: En primer lugar traer todos los objetos, y luego detectar cambios en los mismos. Una vez finaliza cualquiera de estas operaciones, se hace una operación de sincronización (full sync/delta sync) y los cambios se escriben en el metaverso al tiempo que se reciben actualizaciones desde el metaverso, que luego haya que exportar.

En la mayoría de ocasiones, los MA que se configuran, disponen para la operación delta import de mecanismos que permiten detectar no sólo los cambios en el valor de los atributos, sino también si algún objeto se ha eliminado. Por otro lado, dada la naturaleza de los sistemas a los que se conectan los Management Agents, hay ocasiones en las que la eliminación de un objeto no se puede detectar porque el objeto ha desaparecido por completo del sistema origen, lo que impide la trazabilidad del evento. Esto implica, que existe un objeto en el metaverso que no debería existir : Un objeto fantasma.

Happy-Haunting-Ghost-Banner

Una forma de solucionar esta situación consiste en ejecutar una operación Full Import, lo que permite al Connector Space detectar todas las eliminaciones “fantasma”, y propagar los cambios al metaverso. Sin embargo, es posible encontrarse en una situación en la que el connector space tiene un tamaño de cientos de miles, o millones de registros, y completar una operación de Full import bajo dichas condiciones puede suponer varios días de trabajo. Dependiendo de la situación, esto no es una estrategia viable, ya que requiere una planificación cuidadosa, y una parada de servicio del sistema de sincronización, que durante varios días no va a actualizar la información de los sistemas conectados dentro de los intervalos habituales de tiempo.

Otra forma de resolver esta situación… es actuar de forma proactiva, y prohibir en los sistemas origen que se produzca el borrado físico de objetos, de forma que el problema nunca se produce, y por tanto, no hay que hacer nada más al respecto.

Afortunadamente, aunque ya sea porque no se puede cambiar la forma de trabajo o porque una operación de Full Import se prolongaría demasiado en el tiempo, se dispone de una tercera alternativa. Usar un Management Agent adicional que se encargue de hacer la limpieza. En esencia, lo que se hace es añadir los objetos a eliminar a este management agent, usando algún atributo que los identifique de forma unívoca, se les hace un JOIN, configurar una regla de eliminación, provocar una desconexión, y la desconexión lanzará un delete.

Creación de un Management Agent de CSV: “Delimited Text File”

El conector más sencillo que se puede usar para este propósito es el conector de CSV. Principalmente porque es posible alimentarlo con datos extraídos directamente del metaverso, además de por la sencillez con la que se puede configurar.

Lo primero es determinar qué objetos son los que se desea eliminar. En este caso, se acude a la pestaña “Metaverse Search”, y por motivos didácticos, se ordenan los objetos devueltos por el campo ObjectID para seleccionar algunos de ellos (los primeros). Hay que tener en cuenta que el ObjectID de los objetos existentes en el Metaverso es diferente del ObjectID de los objetos existentes en el Connector Space de cada MA, así que es importante coger el del Metaverso. Es importante en este paso fijarse en el número de objetos que pueblan el Metaverso: 4683.

MVCapture2

Lo más destacable de esta fase, es que se pueden elegir los campos que se desea obtener en la búsqueda del metaverso, seleccionar los objetos con el ratón, y copiarlos con Ctrl+C. Esto genera una copia en CSV en el portapapeles que se puede pegar a voluntad en el archivo de texto que se va a utilizar para el MA.

cleanupCSV

Ahora que ya se tiene el archivo CSV, y está definido el formato de los datos que se van a utilizar, es hora de pasar a crear y configurar el Management Agent de CSV. Como indica el título de esta sección, es el MA “Delimited Text File”. En las siguientes capturas de pantalla se van a especificar las principales opciones que hay que tener en cuenta a la hora de especificar los parámetros del MA, para que pueda ser usado con la finalidad deseada.

En primer lugar, seleccionar un archivo CSV que contiene el formato de los datos que el MA va a importar. Se puede definir el mismo archivo que se ha creado previamente.

template

A continuación, toca configurar algunos parámetros del CSV para asegurarse de que el MA lo lee correctamente: Separadores de atributos, cómo definir los nombres de atributos…

format

En esta pantalla se define el anchor y el tipo de dato de los atributos, además de indicar si son multivaluados (array) o no. El anchor es equivalente a la clave primaria, indentificando de forma inequívoca e irrepetible al objeto. De esta forma todos los atributos de los objetos quedan perfectamente definidos.

attributes

Toca definir las reglas de JOIN. En este caso, el join se hace en base al ObjectID. Este atributo es siempre único para cada objeto creado, tanto en el connector space como en el metaverso. Dado que lo que se desea es unir los objetos del Connector Space del MA de CSV con su equivalente en el metaverso, este ObjectID es el mismo existente en el metaverso. Así, se establece el enlace correcto entre objetos, y no es necesario crear un CSV grande con multitud de campos que permitan hacer el Join.

joinRule

Es de vital importancia especificar que el comportamiento de deprovisionamiento sea “Make them disconnectors”. Esta parte juega un papel importantísimo, a posteriori, porque se especifica en las reglas de borrado de los objetos del metaverso que un elemento se borre cuando uno de sus enlaces en el Connector Space del MA de CSV pase al estado “disconnector”.

DeprovisioningCSV

A continuación, se guarda la configuración del Management Agent, y se procede a modificar la política de eliminación de objetos tipo “Person” del Metaverso. En esta pantalla, hay dos opciones: O se elimina el objeto cuando el último conector se desconecta (ignorando los conectores de ciertos Management Agents), o bien eliminar cuando un conector de alguno de los Management Agents elegidos se desconecta. Se elige esta última opción y se marca el conector de limpieza (llamado CleanUp) en este caso. Se han ocultado los nombres de los otros MAs que hay desplegados en esta implementación de MIM porque no son relevantes para el caso que nos ocupa.

DeletionRule2

Con esto, ya se está listo para empezar el proceso de eliminación. Lo primero que hay que hacer es poblar el Connector Space con los objetos necesarios. Para ello, hay que configurar los perfiles de ejecución de “Full Import” y “Full Sync” para el MA de limpieza. A la hora de configurar el Full Import, se pide la localización física del archivo CSV que contiene los datos a importar. Este CSV debe residir en una carpeta específica, creada dentro de la estructura de carpetas del MIM en el momento de guardar el Management Agent.

ConfigureFullImportCSV

Una vez creados los perfiles de Full Import y Full Sync, toca ejecutarlos:

Se puede observar que como resultado del Full Import, se han añadido 15 objetos, que son los que se habían añadido al CSV originalmente. Esto se puede comprobar haciendo una búsqueda en el Connector Space, o simplemente clicando sobre el enlace “Adds” que aparece en la ventana de resultados.

FullImportCSV2

La consecuencia del Full Sync, con la regla de JOIN especificada anteriormente, es que se ejecuta la operación JOIN sobre los objetos del Connector Space, que pasan a su vez a estar enlazados con los objetos que ya residían en el metaverso y que se desean eliminar.

FullSyncCSV2

Ahora llega la parte interesante. Para eliminar los objetos del metaverso hay que convertir en desconectores los que tenemos en el Connector Space del MA de limpieza. La forma más sencilla de conseguirlo es borrando el Connector Space del MA de limpieza y haciendo un Full Sync. Al hacerlo, automáticamente los objetos desconectados eliminarán los correspondientes objetos del Metaverso, limpiando de forma efectiva los datos basura que no se habían eliminado de forma adecuada.

 

Conclusión

Como se puede ver en la siguiente captura, en el Metaverso quedan 4668 objetos, de los 4683 que había originalmente. Los 15 objetos que han sido gestionados con el MA de CSV para la operación de limpieza han desaparecido por completo del Metaverso, y ya no aparecerán en subsecuentes operaciones de sincronización en los otros MA que habían contribuido estos datos. Una operación sencilla, que ha permitido eliminar objetos que de otra forma no hubiesen desaparecido del Metaverso si no se realizan las operaciones de Full Import/Full Sync en el MA que creó los objetos.

endResult

Bonus

Una alternativa diferente de conseguir la limpieza pasa por utilizar el conector de SQL, esto se puede consultar en la url https://konab.com/using-cleanup-ma-fim-2010/

Alta disponibilidad en VDI de Windows Server

Cada vez es más común utilizar infraestructuras de escritorios remotos para utilizar como ordenadores principales. Este puede ser el caso de una organización que en vez de comprar un número elevado de equipos, compran unos servidores que ofrezcan este servicio y unos clientes para acceder a este. En este artículo vamos a mostrar cómo establecer alta disponibilidad en los hosts que ofrecen las máquinas virtuales, que son el principal punto de fallo.

Infraestructura

Lo primero que vamos a hacer es definir la infraestructura. Para ello necesitaremos 4 máquinas (mínimo), todas ellas con Windows Server. Dos de ellas serán servidores “simples”, que harán los roles de RD Licensing, RD Connection Broker y RD Web Access. Los otros dos servidores serán más potentes, y albergarán las máquinas virtuales mediante el rol de RD Virtual Host. A parte, necesitaremos un espacio de almacenamiento compartido por estos últimos servidores.

La alta disponibilidad de los Virtual Host la ofreceremos gracias a la posibilidad de crear en Windows Server un Failover Cluster. A este Cluster le añadiremos el espacio de almacenamiento compartido como Cluster Shared Volume (CSV). Las interfaces de red recomendadas en estos servidores son cuatro: una para los clientes, una para las migraciones en caso de fallo, una para el heartbeat (comprobará si los servidores están caídos) y otra para el CSV.

El mapa de red será el siguiente:

clip_image001

Remote Desktop Services

Se va a hacer una instalación estándar de los roles de Remote Desktop Services. Podéis seguir esta guía. Las opciones a elegir en el asistente son:

  • Instalación de Remote Desktop Services.
  • Standard deployment.
  • Virtual machine-based deployment.
  • Elegir RD Connection Broker.
  • Elegir RD Web Access (puede ser el mismo que RD Connection Broker).
  • Elegir RD Virtualization Host (seleccionamos los dos).
  • Instalar.

El asistente se encargará de instalar los roles y herramientas necesarias en cada máquina.

Failover Cluster

Lo siguiente es configurar el Cluster. Para ello, desde el asistente de instalación de roles y características de Windows Server, seleccionamos Failover Clustering en características.

clip_image002

Esta característica hay que instalarla en todas las máquinas que harán de RD Virtual Host. Podéis seguir esta guía para configurarlo. Una vez acabado, deberéis agregar el disco compartido al Cluster como Cluster Shared Volume, que previamente deberéis haber añadido a cada servidor.

clip_image003

Una vez completado esto, y configurado las redes, tanto en el Cluster para el cliente, heartbeat y CSV, en Hyper-V para la migración, y un switch virtual para las máquinas de Hyper-V, ya podemos crear la colección de escritorios virtuales.

Virtual Desktop Infraestructure

La creación de escritorios virtuales la podemos hacer con los parámetros que necesitemos. En el momento de elegir el almacenamiento, debemos elegir la opción de Cluster Shared Volume, que será una carpeta montada dentro del disco duro de cada nodo del cluster.

clip_image004

Tras esto, podemos finalizar el asistente y crear las máquinas. Estas se unirán automáticamente al Failover Cluster, por lo que a partir de ese momento ya nos beneficiaremos de todas las ventajas: tendremos las opciones de un Cluster, como la migración y alta disponibilidad, y el acceso mediante escritorio remoto.

clip_image005

Si, además, queremos que por defecto las máquinas virtuales pertenezcan a un nodo (si este está operativo) deberemos marcarlo en el clúster, junto con el rollback. Además, podremos desplegar las actualizaciones en los virtual host con la ayuda del clúster para asegurarnos de que los usuarios no se vean afectados.

Como veis, gracias a las opciones de VDI y Failover Cluster de Windows Server, conseguiremos desplegar un servicio de escritorio remoto en alta disponibilidad ante fallos.