Powershell incluye una serie de cmdlets que nos pueden ayudar a visualizar los eventos en un entorno de línea de comandos. Nos interesan los comandos get-eventlog y get-winevent, que obtienen los eventos registrados que podríamos ver desde el visor de eventos de forma gráfica, pero con opciones que nos permite filtrar y buscar entre las distintas fuentes de eventos (no sólo de sistema, también de seguridad, aplicaciones o eventos de hardware), ordenando, clasificando o limitando el resultado de nuestra búsqueda.

Una de las ventajas que ofrece respecto de la interfaz gráfica es la capacidad de poder hacer una búsqueda granular de eventos, sin la necesidad de navegar por las carpetas en las que se clasifican los eventos. Con un solo comando podríamos obtener todos los eventos que cumplan con una serie de condiciones, sin tener que realizar una “vista” en el visor de eventos, en las que los filtros podrían llegar a ser complejos de configurar.

La otra ventaja se desprende de la naturaleza de los cmdlets de powershell, y es la escalabilidad del comando. Mientras que la herramienta gráfica nos muestra los eventos de un equipo (el local, e incluso puede conectarse a otros, si tenemos los permisos necesarios), el “output” se limita exclusivamente a los eventos de una máquina, mientras que un cmdlet de powershell se puede lanzar a múltiples máquinas a través de un invoke-command, recibiendo la respuesta de todas ellas.

Este ejemplo nos serviría para sacar los últimos 5 eventos de error de sistema, en donde se especifique que un servicio pudiera fallar.
Get-EventLog -LogName System -EntryType Error -Newest 5 -Message *failed* | format-list *

Sin embargo, get-eventlog y get-winevent, pese a obtener, en principio, la misma información, no poseen las mismas opciones ni capacidades, siendo, get-eventlog un comando más antiguo y get-winevent, su sucesor: el primero, intuitivo y con opciones que filtran la búsqueda en el registro de eventos con eficacia. El segundo es un comando potente, que llega hasta registros de eventos imposibles de ver con get-eventlog. A cambio, sus opciones de filtrado son limitadas y se requieren “pipelines” posteriores para filtrar la salida de datos o limitar las líneas del array resultante.

Usar get-winevent para poder extraer la misma información que con el ejemplo de get-eventlog daría como resultado algo así:
>get-winevent -LogName System | where-object {$_.Message -match «failed» -and $_.LevelDisplayName -eq «Error»} | select-object -last «5» | format-list *

La dificultad más inmediata que plantea get-winevent radica en que, a diferencia de get-eventlog, no permite “tabular” para navegar entre las distintas carpetas de eventos, y hay que conocer de antemano la ruta exacta para poder acceder a los eventos que buscamos, siendo la interfaz gráfica del Visor de Eventos, la forma más asequible para conocer estas rutas.

Una dificultad añadida es que estos comandos no están disponibles en el set de cmdlets de Windows Nano Server.

La recomendación final para usar estos dos cmdlets y poder sacar partido de ellos es:

Utilizar get-eventlog para explorar los eventos principales de sistema o seguridad tanto en el equipo local como remoto, pudiendo tener la búsqueda guardada en forma de script, y aprovechando la escalabilidad del comando para obtener información de eventos de varios equipos con un solo comando.

En caso de buscar eventos específicos, guardados en carpetas a las que get-eventlog no pueda llegar, usar el Visor de Eventos para explorar la ruta en la que se guardan los eventos que nos interesan, y perfilar una búsqueda usando get-winevent como cmdlet para obtener información detallada de esos eventos, pudiendo, una vez más, guardar esa búsqueda en forma de script de PowerShell.

No acostumbrarse en exceso a la facilidad de get-eventlog, aunque su uso sea recomendable, sobre todo al principio: es probable que, en versiones futuras de PowerShell, este comando quede obsoleto, quedando get-winevent como única opción.

 

Autor: Gabriel Piuzzi

Curso: Microsoft MCSA Windows Server + Microsoft MCSE Cloud Platform & Infrastructure

Centro: Tajamar

Año académico: 2017-2018

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.