Scripts de PowerShell en Windows 11 para automatizar y asegurar tu equipo

W11 » Seguridad en Windows 11 » Scripts de PowerShell en Windows 11 para automatizar y asegurar tu equipo

Si usas Windows 11 a diario y todavía haces muchas tareas “a mano”, estás perdiendo tiempo del bueno. Gracias a scripts de PowerShell y archivos por lotes puedes automatizar desde el borrado de temporales hasta auditorías de seguridad completas, pasando por la actualización masiva de programas o la ejecución de tareas al arrancar el equipo.

La parte positiva es que no hace falta ser un gurú de la consola. Con unas cuantas ideas claras y ejemplos listos para copiar y pegar, es fácil montar tus propios scripts en PowerShell para Windows 11, integrarlos con directivas de grupo, usarlos en procesos de compilación y, sobre todo, hacerlo de forma segura para no cargarte el sistema en un descuido.

Qué son los scripts y archivos por lotes en Windows 11

En Windows conviven dos formas clásicas de automatización: los archivos por lotes (.bat/.cmd) y los scripts de PowerShell (.ps1). Ambos permiten encadenar comandos que se ejecutan uno detrás de otro, sin tener que escribirlos a mano cada vez en una ventana de consola.

Un archivo por lotes no es más que un documento de texto plano con comandos para el intérprete de comandos tradicional (cmd.exe). Al hacer doble clic sobre él, Windows abre una consola y ejecuta el contenido. PowerShell, por su parte, es mucho más potente: trabaja con cmdlets, objetos, funciones y módulos, y se ha convertido en el estándar moderno para la administración de Windows y servicios relacionados.

Crear un .bat es tan sencillo como abrir el Bloc de notas, escribir los comandos y guardarlo con la extensión .bat o .cmd. Para scripts de PowerShell, el proceso es similar, pero usando extensión .ps1 y ejecutándolos desde la consola de PowerShell o Terminal de Windows, o bien configurándolos para que se lancen automáticamente con otras herramientas (GPO, Programador de tareas, MSBuild, etc.).

En ambos casos, si el script necesita tocar partes sensibles del sistema (servicios, registro, carpetas protegidas…), tendrás que ejecutarlo con permisos de administrador (clic derecho > Ejecutar como administrador).

Ejemplos prácticos de archivos por lotes útiles en Windows 11

Aunque PowerShell es el protagonista en Windows 11, muchas tareas rápidas se siguen resolviendo muy bien con simples archivos por lotes. Lo bueno es que, además, pueden llamar a PowerShell desde dentro del propio .bat, combinando lo mejor de cada mundo.

Un archivo por lotes típico empieza con @echo off para que no se vayan mostrando todos los comandos por pantalla, y puede incluir mensajes al usuario con echo, pausas con pause y llamadas a ejecutables externos.

Uno de los usos más cómodos es automatizar tareas de mantenimiento: vaciar la papelera, limpiar temporales, lanzar varias aplicaciones de una sentada, hacer copias rápidas de seguridad o resetear la red cuando algo va mal. Todo eso lo puedes meter en pequeños scripts que ejecutarás siempre que lo necesites.

Por ejemplo, en lugar de ir carpeta a carpeta borrando basura, puedes crear un lote que llame a PowerShell para vaciar la papelera automáticamente, u otro que limpie la carpeta temporal del usuario con un par de órdenes bien escogidas.

Además, estos ficheros apenas ocupan espacio, por lo que puedes crear tantos .bat como quieras para distintas tareas sin preocuparte por el consumo de disco.

Scripts de PowerShell para auditoría y seguridad en Windows 11

Donde PowerShell se luce de verdad es en la administración y la seguridad. Con un único script puedes recopilar un informe completo del estado de un equipo con Windows 11: usuarios, servicios, firewall, políticas, cifrado, puertos abiertos… ideal para auditorías de configuración y cumplimiento.

Un enfoque muy habitual es crear un script grande que vaya ejecutando secciones independientes, cada una dedicada a un aspecto concreto del sistema. Por ejemplo, podrías organizar tu script para que revise, al menos, estos puntos:

• Usuarios locales y pertenencia a grupos críticos como Administradores.
• Estado del firewall y reglas configuradas, tanto de Windows Defender Firewall como de otros proveedores.
• Windows Defender (antivirus): estado del servicio, firmas, protección en tiempo real.
• Actualizaciones instaladas y eventos de Windows Update recientes.
• Servicios automáticos y detección de servicios vulnerables o innecesarios (como Remote Registry).
• Conexiones de red activas, puertos en escucha y configuración DNS.
• BitLocker y estado del cifrado de las unidades.
• Políticas de contraseñas y bloqueo de cuentas.
• Configuración de UAC y RDP (Escritorio remoto).
• Tareas programadas, software instalado y elementos de inicio automático.
• Eventos de seguridad, especialmente inicios de sesión fallidos.
• Políticas de ejecución y registros de PowerShell.
• Configuración TLS/SSL y protocolos obsoletos como SMBv1.

La idea es que cada bloque de tu script lance los cmdlets adecuados (Get-LocalUser, Get-Service, Get-NetFirewallProfile, Get-BitLockerVolume, Get-SmbServerConfiguration, Get-ScheduledTask, Get-WinEvent, etc.) y vaya dejando la salida en un informe estructurado (por ejemplo, un fichero de texto, CSV o incluso HTML) para poder revisarlo con calma.

Con este enfoque, cada vez que quieras revisar un ordenador solo tendrás que ejecutar tu script de auditoría y, en cuestión de segundos, obtendrás un snapshot bastante completo de la postura de seguridad de ese Windows 11.

Ejecutar scripts de PowerShell al iniciar el equipo con GPO

Imagina un script sencillo que, cada vez que arranca un equipo, crea una carpeta y un archivo de texto con el nombre de la máquina y una marca de tiempo. Eso te permite saber fácilmente cuándo se ha iniciado ese equipo y verificar que la GPO se ha aplicado correctamente. El núcleo del script sería algo de este estilo:

$FolderParent = «C:\ScriptPowershell»
if (!(Test-Path $FolderParent)) { New-Item -ItemType Directory -Path $FolderParent -Force }
$computerName = $env:COMPUTERNAME
$timestamp = ::Parse((Get-Date -UFormat %s))
$fileName = «${computerName}_$timestamp.txt»
$filePath = Join-Path $FolderParent $fileName
New-Item -ItemType File -Path $filePath

Para usarlo en un dominio con Windows Server como controlador (por ejemplo, Windows Server 2025), el flujo típico es:

Primero copias el archivo .ps1 con el script al controlador de dominio. Luego abres la Consola de administración de directivas de grupo (GPMC), creas un nuevo objeto de directiva de grupo (GPO), lo nombras y lo editas.

Dentro del editor de GPO, vas a Configuración del equipo > Políticas > Configuración de Windows > Scripts y entras en las propiedades de Inicio. En la pestaña Scripts de PowerShell usas el botón “Mostrar archivos” para abrir la carpeta donde se almacenan los scripts de esa directiva (normalmente a través de la ruta UNC del SYSVOL; si no tienes permisos, puedes tirar de la ruta local C:\Windows\SYSVOL…). Ahí pegas tu .ps1.

Después, en la misma ventana de propiedades, haces clic en Agregar, eliges Explorar, seleccionas el script que acabas de pegar y lo confirmas. Puedes repetir el proceso si quieres que la misma GPO ejecute varios scripts de PowerShell al inicio. Al cerrar con Aplicar y Aceptar, tu directiva queda lista.

Por último, vinculas la GPO a la Unidad Organizativa (OU) que contiene los equipos a los que quieres aplicar el script. Botón derecho sobre la OU > Vincular un objeto de directiva de grupo existente > eliges tu GPO > Aceptar. Cuando reinicies un equipo de esa OU, el script se ejecutará automáticamente durante el arranque.

Para verificar que ha funcionado, basta con iniciar sesión tras el reinicio y comprobar que en C:\ScriptPowershell existe la carpeta con el archivo de texto generado. Si todo está bien, es que el script de PowerShell se ha ejecutado correctamente al iniciar Windows 11. Como buena práctica adicional, conviene firmar los scripts de producción para evitar manipulaciones maliciosas.

Automatizar la actualización de programas con PowerShell y winget

Otro escenario donde PowerShell brilla es en el mantenimiento del software instalado. Actualizar manualmente cada aplicación es una faena tremenda: abrir programa, buscar opción de actualización, descargar, instalar, reiniciar… y repetir el proceso varias veces. Además, es fácil dejar programas desactualizados y vulnerables por olvido; conviene revisar una lista de programas imprescindibles después de instalar Windows 11 para priorizar qué mantener siempre al día.

En Windows 11 dispones de winget (Windows Package Manager), el gestor de paquetes oficial de Microsoft, que se controla desde PowerShell o la Terminal de Windows. Funciona de forma parecida a los gestores de paquetes de Linux o macOS, permitiéndote buscar, instalar, actualizar y desinstalar aplicaciones desde la línea de comandos.

Ventajas clave de winget: viene integrado en Windows 11, no necesitas instalar nada adicional, es rápido, automatizable y usa repositorios verificados, por lo que resulta mucho más seguro que ir descargando instaladores al azar.

El flujo básico sería:

• Abrir PowerShell o Terminal como administrador (Inicio > buscar “PowerShell” o “Terminal” > clic derecho > Ejecutar como administrador).
• Listar las aplicaciones con actualización disponible ejecutando winget update.
• Actualizar todos los programas de golpe con winget update -h –all –include-unknown.
• Actualizar una sola aplicación si lo prefieres con winget update «Nombre del programa».

El parámetro -h o –silent hace que la actualización sea desatendida, sin diálogos molestos, y –all recorre todos los paquetes con nueva versión disponible. Con –include-unknown incluyes también aquellos cuyo número de versión no puede determinarse con precisión.

Si ejecutas, por ejemplo, un comando como winget upgrade -h –all, puedes ver algo parecido a un listado con nombre, identificador, versión instalada, versión disponible y origen. Es habitual encontrar ahí navegadores (Chrome, Firefox), utilidades (7-Zip, Cyberduck), clientes FTP (FileZilla), reproductores (VLC), IDEs y editores (Visual Studio Code, Postman), herramientas de SEO (como Screaming Frog SEO Spider), suites de videollamadas (Webex, Teams), PDFCreator, Node.js, WSL, etc.

Lo mejor viene cuando metes esto en un script de PowerShell muy simple, por ejemplo con una sola línea:

winget update -h –all –include-unknown

y programas su ejecución con el Programador de tareas de Windows para que se lance cada semana o cada vez que se enciende el equipo. De este modo, mantienes tu software actualizado prácticamente sin intervención manual, lo que mejora seguridad, estabilidad y ahorra un buen rato de mantenimiento.

Uso de scripts de PowerShell en procesos de compilación y despliegue (MSBuild)

En entornos de desarrollo profesional, los scripts de PowerShell no solo sirven para administrar PCs, sino también para integrarse en los procesos de compilación e implementación automática, incluso con contenedores como Docker en Windows 11.

Una práctica habitual es tener un proyecto controlado por MSBuild (por ejemplo, una solución con una app ASP.NET MVC, un servicio WCF y un proyecto de base de datos) y, al final del proceso de compilación y despliegue, ejecutar scripts de PowerShell que realicen tareas posteriores: crear directorios para subidas, limpiar carpetas de build, escribir en registros personalizados, generar orígenes de eventos, enviar correos avisando de un despliegue, crear cuentas de usuario o configurar replicaciones entre instancias de SQL Server.

Imagina un script sencillo llamado LogDeploy.ps1 que define una función LogDeployment y escribe en un archivo de log algo como “Deployed package to TESTWEB1 on 02/11/2012 09:28:18”. El script acepta dos parámetros: la ruta del archivo de registro y el nombre del destino de despliegue. Al llamarlo desde MSBuild tras publicar un paquete, te deja trazas claras de dónde y cuándo se ha desplegado.

Para integrarlo, lo primero es incluir el .ps1 en la solución (por ejemplo, en una carpeta “Publicar” o “Deployment”) y, muy importante, añadirlo al control de código fuente. No hace falta que se implemente junto al sitio web; basta con que esté disponible en el servidor de compilación como parte del código.

Desde MSBuild, ejecutar un script de PowerShell se reduce a invocar powershell.exe con la opción -command (o -file) y pasarle las instrucciones adecuadas. Por ejemplo:

powershell.exe -command «& { C:\LogDeploy.ps1 ‘C:\DeployLogs\log.txt’ ‘TESTWEB1’ }»

Si la ruta tiene espacios, se suele usar el patrón &’C:\Ruta Con Espacios\LogDeploy.ps1′ para evitar problemas con las comillas. Además, conviene incluir los modificadores -NonInteractive (para que no aparezcan prompts interactivos) y -ExecutionPolicy (para ajustar la directiva de ejecución a Unrestricted, RemoteSigned o AllSigned según tus políticas).

Cuando este comando se incrusta en un archivo de proyecto MSBuild, hay que escapar los caracteres XML reservados (comillas, ampersands, etc.). Una forma típica es meterlo dentro de una tarea Exec en un Target personalizado, sustituyendo comillas dobles por ", comillas simples por ' y el símbolo & por &.

Con esto consigues que, durante el proceso de build, MSBuild lance el script de PowerShell y ejecute la lógica que necesites, ya sea en el propio servidor de compilación o en máquinas remotas a través de Invoke-Command y WinRM.

Ejecutar scripts de PowerShell de forma remota con WinRM

PowerShell incluye de serie capacidades de administración remota basadas en WinRM (Windows Remote Management). Gracias a eso, puedes ejecutar scripts en uno o varios equipos remotos sin copiarles el archivo previamente, obteniendo la salida de vuelta en tu consola local.

En una ventana de PowerShell, el cmdlet clave es Invoke-Command, que acepta un nombre de equipo (o varios) y un bloque de script. Algo como:

Invoke-Command -ComputerName ‘SERVIDOR1’ -ScriptBlock { &»C:\Ruta Con Espacios\LogDeploy.ps1″ ‘C:\Ruta Con Espacios\log.txt’ ‘TESTWEB1’ }

Si quisieras lanzarlo desde un símbolo de sistema clásico, tendrías que invocar powershell.exe con -command y pasarle ese Invoke-Command dentro. Y si lo haces desde MSBuild, de nuevo, toca escapar caracteres XML y usar -NonInteractive y -ExecutionPolicy para que todo vaya fino.

La ventaja de este enfoque es que puedes orquestar despliegues o cambios de configuración en varios servidores desde un único punto, sin necesidad de ir máquina a máquina, lo que encaja muy bien con pipelines de integración y entrega continua.

Riesgos y buenas prácticas al usar scripts y archivos por lotes

La otra cara de la automatización es que un script mal escrito o malintencionado puede hacer un estropicio en segundos. Comandos como del, erase o rd /s /q en un .bat, o Remove-Item -Recurse -Force en PowerShell, pueden borrar mucho más de la cuenta si te equivocas de ruta o tienes una variable mal definida.

El problema se agrava cuando ejecutas scripts con privilegios de administrador. En ese caso, cualquier acción sobre el registro, servicios o carpetas del sistema tiene efecto inmediato y sin restricciones. Si, además, te bajas scripts de Internet y los ejecutas como administrador sin revisarlos, básicamente estás regalando el control del equipo a un desconocido.

Otro riesgo habitual es que un script aparentemente inocente (por ejemplo, uno que promete limpiar archivos temporales) esconda descargas silenciosas, aperturas de puertos o ejecución de otros scripts en segundo plano, a menudo a través de llamadas a PowerShell dentro de un .bat largo y enrevesado.

Para minimizar riesgos, es recomendable:

• Ejecutar solo scripts creados por ti o procedentes de fuentes totalmente fiables.
• Revisar siempre el contenido de un .bat o .ps1 antes de lanzarlo, especialmente si llegó por correo o desde webs no oficiales.
• Restringir la directiva de ejecución de PowerShell (ExecutionPolicy) a RemoteSigned o AllSigned, firmando tus scripts de producción.
• Evitar comandos destructivos sin comprobaciones previas (por ejemplo, mostrar primero qué se va a borrar antes de ejecutar el borrado real).
• Registrar las acciones importantes (creación de archivos, cambios de configuración, etc.) en logs para tener trazabilidad.

Problemas típicos al ejecutar scripts y cómo solucionarlos

Al empezar con scripts en Windows 11, es muy habitual encontrarse con pequeños fallos de ejecución que, por suerte, suelen tener arreglo sencillo si sabes dónde mirar.

Un clásico es el archivo .bat que se abre y se cierra en un suspiro. Esto pasa porque el script termina y la ventana de consola se cierra inmediatamente. La forma más simple de verlo venir es añadir un pause al final del archivo por lotes, o ejecutar el .bat desde una consola ya abierta (cmd o PowerShell), de modo que la ventana no desaparezca y puedas leer los mensajes de error.

Otro error recurrente es el conocido mensaje de “no se reconoce como un comando interno o externo”. Normalmente significa que el programa que intentas llamar no está en el PATH del sistema o que la ruta al ejecutable es incorrecta. La solución suele ser usar la ruta completa al programa, entre comillas si contiene espacios.

También son muy frecuentes los problemas de sintaxis por rutas con espacios. En .bat y en PowerShell casi siempre conviene rodear las rutas con comillas: «C:\Program Files\Carpeta». De lo contrario, el intérprete puede interpretar “Program” y “Files” como argumentos distintos.

Por último, si aparece “Acceso denegado”, lo habitual es que el script esté intentando escribir en carpetas protegidas (Program Files, Windows, etc.) o modificar algo que requiere permisos elevados. En esos casos, hay que ejecutar el script como administrador o cambiar las rutas y operaciones para que trabajen en ubicaciones donde el usuario tenga permisos.

En el caso concreto de PowerShell, además, puedes toparte con limitaciones de la directiva de ejecución (ExecutionPolicy). Si el sistema está en Restricted o bloquea scripts descargados, tendrás que ajustar la política (por ejemplo, a RemoteSigned) o firmar tus scripts para que Windows permita su ejecución.

FAQs rápidas sobre archivos por lotes y scripts de PowerShell

Mucha gente se hace las mismas preguntas al empezar a automatizar cosas en Windows 11, tanto con .bat como con .ps1.

¿Es seguro ejecutar archivos .bat en mi ordenador? En general, sí, siempre que los hayas creado tú o vengas de una fuente de absoluta confianza. Lo que no deberías hacer es ejecutar .bat desconocidos enviados por correo o descargados de webs aleatorias.

¿Necesito algún programa especial para crearlos? No. Para archivos por lotes basta con el Bloc de notas que viene con Windows. Para scripts de PowerShell también puedes usar el Bloc de notas, aunque es mucho más cómodo trabajar con editores como Visual Studio Code o el propio ISE si lo tienes disponible.

¿Cómo ejecuto un script que necesita permisos de administrador? En el caso de .bat, clic derecho sobre el archivo y “Ejecutar como administrador”. En PowerShell, abre la consola o Terminal “Como administrador” y ejecuta desde allí el script o el comando que lo llama.

¿Puedo combinar archivos por lotes y PowerShell? Sí, sin problema. Es muy frecuente tener un .bat que invoca comandos de PowerShell mediante powershell.exe -command, o al revés, scripts de PowerShell que lanzan herramientas clásicas de consola o scripts .cmd. Lo importante es entender bien qué hace cada segmento para no generar conflictos.

La clave para sacarle partido a los scripts en Windows 11 está en empezar por tareas sencillas del día a día (limpieza, actualizaciones, pequeños informes) e ir poco a poco añadiendo piezas más complejas como auditorías completas, despliegues automatizados o ejecución remota. Con un poco de práctica, pasarás de hacer clics repetitivos a tener tu sistema y tus servidores funcionando casi en piloto automático.