Powershell Windows

Me encanta cómo un par de comandos bien elegidos pueden convertir horas de frustración en minutos de trabajo efectivo; por eso cuando hablo de PowerShell siempre empiezo por lo básico útil y luego voy hacia lo práctico.

Yo tiro mucho de «Get-Help» y «Get-Command» para entender qué hace cada cosa y qué parámetros tiene: «Get-Help Get-Process -Full» o «Get-Command -Name Service» son mis amigos cuando exploro un entorno desconocido. Aprender a usar «Get-ChildItem», «Set-Location», «Get-Content» y «Set-Content» te da control total sobre archivos y carpetas; no subestimes los alias como ls, cd o cat para moverte rápido. Para gestionar procesos y servicios uso «Get-Process», «Stop-Process», «Get-Service», «Start-Service» y «Stop-Service».

En tareas más de desarrollador, me apoyo en «Get-Member» para inspeccionar objetos, y en los cmdlets de filtrado y transformación: «Where-Object», «ForEach-Object», «Select-Object», «Sort-Object» y «Group-Object». Para input/output y persistencia aprendo «Export-Csv», «Import-Csv», «ConvertTo-Json» y «ConvertFrom-Json», además de «Out-File» y «Tee-Object» para debug. Si trabajas con APIs o descargas, «Invoke-RestMethod» e «Invoke-WebRequest» son imprescindibles.

No olvido temas operativos: «Get-Service», «Get-EventLog» o mejor aún «Get-WinEvent», «Test-Connection», «Test-NetConnection», y para automatización remota uso «New-PSSession», «Enter-PSSession» e «Invoke-Command». Por último, dominar el perfil (~/.config/powershell o $PROFILE), módulos con «Get-Module/Import-Module», y seguridad con «Get-ExecutionPolicy/Set-ExecutionPolicy» te hará la vida mucho más sencilla. En mi experiencia, combinar esos comandos con buenas funciones, manejo de errores (try/catch) y el uso del pipeline es la receta para ser realmente productivo con PowerShell.

Tengo que confesar que automatizar con PowerShell cambió mi forma de ver las tareas repetitivas.

Al principio me lancé con scripts sencillos: copias de seguridad de carpetas, rotación de logs y reinicios controlados de servicios. Aprendí rápido que lo bueno es diseñar funciones reutilizables con parámetros claros y mensajes de logging. Por ejemplo, una función que reciba origen, destino y un modo de verificación me permitió usarla en backups locales y en tareas que lanzaba por remoting. También empecé a guardar credenciales de forma segura con Get-Credential y a protegerlas en archivos cifrados o, mejor aún, con el Administrador de Credenciales de Windows o Azure Key Vault cuando trabajaba con recursos en la nube.

Para que fuera realmente automático, usé las tareas programadas de Windows y los trabajos programados de PowerShell: Register-ScheduledTask para integrarlo con el Programador de Tareas, o Register-ScheduledJob cuando quería algo que quedara integrado en el entorno de PowerShell. Aprendí a escribir scripts que sean idempotentes (que al ejecutarse varias veces no provoquen efectos indeseados), a añadir manejo de errores con Try/Catch y a registrar eventos en un archivo y en el Visor de Eventos. Cuando necesité paralelizar, empecé con Start-Job y terminé usando runspaces para procesos más eficientes.

Si quieres escalar, mirar hacia Desired State Configuration (DSC) o Azure Automation ayuda mucho: DSC te asegura que la configuración se mantenga y Azure Automation facilita la gestión centralizada y el runbook scheduling. Para mí la regla es empezar pequeño, probar localmente con -WhatIf, documentar y versionar en Git; poco a poco el ahorro de tiempo compensa el esfuerzo inicial y se vuelve adictivo.

Al final, automatizar con PowerShell es una mezcla de disciplina y creatividad: con buenas prácticas se evita mucho dolor y se gana tiempo que uno realmente disfruta dedicar a cosas más interesantes.

Me encanta automatizar tareas y los servicios de Windows son de esas cosas que termino tocando cada semana: con PowerShell puedes ver, detener, iniciar y configurar servicios de forma precisa y repetible.

Para listar servicios rápidos uso 'Get-Service' y lo combino con filtros: por ejemplo 'Get-Service Where-Object {$.Status -eq "Stopped"]}' me muestra todo lo que está detenido. Si quiero detalles más profundos, recurro a 'Get-CimInstance -ClassName Win32Service Select-Object Name,State,StartMode,PathName' porque ahí aparece el StartMode (Automático, Manual) y la ruta del ejecutable. Para manejar servicios uso 'Start-Service -Name "NombreServicio"', 'Stop-Service -Name "NombreServicio"' y 'Restart-Service -Name "NombreServicio" -Force' cuando hace falta forzar un reinicio.

Un par de cuidados: necesitas permisos elevados, así que ejecuta PowerShell como administrador o lanza comandos remotamente con credenciales. Para máquinas remotas prefiero 'Invoke-Command -ComputerName "Host" -ScriptBlock { Get-Service -Name "Nombre" }' o establecer una sesión CIM con 'New-CimSession' si uso PowerShell Core. Antes de cambiar el tipo de inicio hago 'Get-CimInstance -ClassName Win32Service -Filter "Name='Nombre'" Select StartMode' y para modificarlo uso 'Set-Service -Name "Nombre" -StartupType Automatic'. También uso 'Test-Path' y registro con 'Start-Transcript' o redirigiendo salidas a archivos con 'Out-File' para tener trazabilidad. Al final, es cuestión de probar en un entorno controlado y aplicar scripts con cautela; cuando todo está pulido, la sensación de control es genial y me evita problemas a la hora de desplegar cambios.

En mi equipo suelo proponer una colección base de scripts que cubran mantenimiento, seguridad y despliegue porque eso hace que la vida de todos sea más fácil y predecible.

Para empezar, recomiendo scripts de inventario que recojan información de hardware, software y parches instalados (por ejemplo, funciones que llamen a Get-CimInstance, Get-HotFix y consultas al registro). Estos scripts nos sirven para auditorías rápidas y para alimentar dashboards. Luego, un conjunto de scripts de parcheo y actualización utilizando el módulo 'PSWindowsUpdate' o wrappers que llamen a Windows Update/WSUS, siempre con un modo de simulación y logs detallados para poder retroceder si algo falla.

Otro bloque crítico son los scripts de aprovisionamiento y desaprovisionamiento: creación de cuentas, asignación de grupos, creación de carpetas con permisos, instalación de agentes (monitoring, backup) y distribución de configuraciones. Complemento esto con scripts idempotentes basados en parámetros, buen manejo de errores, logging en EventLog o archivos centrales y validaciones con Pester. Finalmente, recomiendo tener un pipeline (Git + CI) que analice (PSScriptAnalyzer), pruebe (Pester) y firme los scripts antes de desplegarlos; esto reduce riesgos y mantiene todo trazable. Al final, la idea es que cualquier script que entre a producción sea predecible, probado y auditable, y eso se nota en menos llamadas a soporte y más confianza al automatizar tareas rutinarias.

Llevo bastante tiempo afinando auditorías en Windows con PowerShell y te cuento la forma en que suelo abordarlo porque funciona bien en entornos reales.

Primero establezco la base: activo las políticas de auditoría adecuadas. Desde una consola elevada uso auditpol para verificar y activar subcategorías clave, por ejemplo: auditpol /get /category: y luego auditpol /set /subcategory:"File System" /success:enable /failure:enable. Complemento eso habilitando SACLs sobre carpetas y archivos críticos con la interfaz de seguridad (propiedades > seguridad avanzada) o con PowerShell: $acl = Get-Acl C:\RUTA; $rule = New-Object System.Security.AccessControl.FileSystemAuditRule("USUARIO","Write","Success"); $acl.AddAuditRule($rule); Set-Acl C:\RUTA $acl.

Para leer y analizar eventos uso Get-WinEvent con filtros: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddDays(-7)} Format-List . También recojo eventos específicos de PowerShell (Id 4104) y procesos (4688) desde los logs correspondientes: Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 100. Cuando necesito historial de cambios en contenido uso Get-FileHash antes y después y comparo con Compare-Object, p. ej. $before = Get-ChildItem -Recurse C:\RUTA Get-FileHash; $before Export-Csv before.csv; repetir y comparar.

Para notificaciones en tiempo real uso FileSystemWatcher: $fsw = New-Object IO.FileSystemWatcher 'C:\RUTA' -Property @{IncludeSubdirectories=$true; NotifyFilter='FileName, LastWrite'}; Register-ObjectEvent $fsw Changed -Action { Write-Output "Cambio detectado: $($Event.SourceEventArgs.FullPath)" }. Finalmente centralizo todo con Windows Event Forwarding o con Sysmon+SIEM para conservar y correlacionar. En lo personal, me gusta combinar logs de seguridad y snapshots de hash: así se detecta tanto acceso como modificación real de contenido, y la trazabilidad queda clara para auditorías o investigaciones pequeñas.

Me he dado cuenta de que usar PowerShell transforma lo que antes eran tareas propensas a error en procesos mucho más predecibles y confiables.

En mi experiencia, el mayor error que evita un técnico es el fallo humano por operaciones repetitivas: copiar y pegar rutas, borrar carpetas a mano o ejecutar comandos en la máquina equivocada. Con scripts bien escritos puedo automatizar, validar y volver a ejecutar con seguridad; por ejemplo, uso Test-Path antes de Remove-Item, y aprovecho -WhatIf y -Confirm para simular acciones peligrosas. Eso evita borrar archivos por accidente o aplicar cambios incompletos.

Otro conjunto grande de errores viene de tratar la salida como texto plano. PowerShell trabaja con objetos, así que evito parsear cadenas con regex cuando puedo usar Select-Object, Where-Object o propiedades directas. También priorizo el manejo de errores: establezco -ErrorAction Stop y afronto Try/Catch/Finally para que los fallos no queden silenciados. Además cuido las codificaciones al volcar archivos (Out-File, Set-Content con -Encoding) y uso Start-Transcript para auditar sesiones.

Al final me deja más tiempo para pensar en la arquitectura y menos para apagar incendios provocados por comandos manuales; la tranquilidad de poder reproducir una tarea y comprobar el resultado me parece la mayor ganancia al usar PowerShell.