Automatización en PowerShell sin ser administrador

Si te estás preguntando cómo automatizar tareas en PowerShell sin ser administrador, no eres el único. Es un escenario muy habitual: tienes que lanzar scripts, programar limpiezas, generar informes o gestionar Microsoft 365, pero no cuentas con privilegios elevados en la máquina o simplemente no quieres usarlos por motivos de seguridad.

La buena noticia es que, conociendo bien las herramientas que ofrece Windows (PowerShell, el Programador de tareas y algunas opciones de línea de comandos), puedes montar un sistema de automatización bastante potente sin tocar la cuenta de administrador. Eso sí, hace falta entender bien en qué contexto se ejecutan los scripts, qué límites tienes sin privilegios elevados y cómo configurarlo todo para que no falle a la primera de cambio.

Ejecutar PowerShell sin derechos de administrador

Antes de meternos en automatización avanzada, conviene tener claro cómo abrir PowerShell sin elevar privilegios incluso cuando Windows parece empujarte siempre a «Ejecutar como administrador». En muchos entornos corporativos o compartidos, esto simplemente no es una opción.

Hay un truco muy útil basado en el comando runas que te permite iniciar una sesión de PowerShell con un nivel de confianza restringido, ideal para trabajar sin elevar permisos aunque tu usuario pueda hacerlo. Para ello, basta con seguir estos pasos básicos:

1. Abre el símbolo del sistema (cmd) en modo normal, sin usar «Ejecutar como administrador».

2. En la ventana de cmd, escribe este comando y pulsa Enter:

runas /trustlevel:0x20000 powershell

Con este comando se lanza una nueva sesión de PowerShell bajo un trust level más limitado, lo que te ayuda a evitar ciertos problemas cuando algo no funciona bien en consola elevada. Un ejemplo clásico es la instalación de herramientas de usuario como Spicetify: si intentas descargarla o configurarla desde una sesión de PowerShell con derechos de administrador, el proceso puede fallar, mientras que desde una sesión con permisos normales funciona sin pegas.

Este enfoque encaja muy bien con una filosofía de mínimo privilegio: solo elevas permisos cuando es estrictamente necesario y dejas la mayor parte de la automatización funcionando con el mismo contexto que usaría un usuario estándar o de trabajo diario.

PowerShell como base de la automatización moderna

PowerShell es mucho más que una simple consola azul: es un marco de automatización y lenguaje de scripting pensado para administrar sistemas Windows y, en sus versiones más recientes (PowerShell Core), también Linux y macOS. Trabaja con cmdlets (comandos especializados), objetos y tuberías, lo que permite construir tareas complejas a partir de piezas muy pequeñas y reutilizables.

La diferencia frente al símbolo del sistema clásico es abismal: con PowerShell puedes encadenar comandos, manipular objetos, consultar registros, servicios, IIS, SQL, Microsoft 365 y prácticamente cualquier producto de Microsoft o de terceros que tenga módulos compatibles. Esto lo convierte en una herramienta ideal para automatizar desde simples limpiezas de temporales hasta despliegues completos de aplicaciones web.

Es importante distinguir entre PowerShell (el entorno) y un script de PowerShell. El entorno es la consola o la terminal donde escribes comandos interactivos, mientras que un script es un archivo .ps1 que contiene una secuencia ordenada de instrucciones, condiciones, funciones y variables creada para ejecutar tareas repetitivas sin tener que escribirlo todo cada vez.

Estos scripts de PowerShell son la base sobre la que se apoyan muchas estrategias de automatización de TI: gestión masiva de usuarios, despliegue de actualizaciones, monitorización del sistema, generación de informes automáticos, tareas de limpieza periódicas, etc. Y, lo mejor, muchos de estos escenarios se pueden ejecutar sin acceso directo a una cuenta de administrador local, siempre que el script solo toque recursos a los que tu usuario ya tenga acceso.

Configurar el entorno de PowerShell y las políticas de ejecución

Para que la automatización funcione sin sobresaltos, hay que tener controlado cómo se comporta la ExecutionPolicy de PowerShell. Esta política define qué scripts se pueden ejecutar y desde dónde, y suele ser el primer escollo con el que se topa cualquiera que empieza a automatizar.

Las políticas de ejecución más habituales son:

• Restricted: es la configuración predeterminada en muchas instalaciones. Solo se permiten comandos interactivos; los scripts .ps1 se bloquean. Es la opción más segura pero, a efectos prácticos, impide cualquier automatización basada en scripts.
• AllSigned: solo se pueden ejecutar scripts firmados digitalmente por un editor de confianza. Es adecuada para entornos donde se quiere control estricto sobre el código que corre en los equipos.
• RemoteSigned: los scripts descargados de Internet o ubicaciones remotas deben estar firmados, pero los scripts locales sin firma sí se pueden ejecutar. Es una política bastante equilibrada y muy habitual en entornos corporativos.
• Unrestricted: permite la ejecución de cualquier script, esté firmado o no. No se recomienda para producción porque expone el sistema a un riesgo elevado.

Puedes consultar tu política actual con:

Get-ExecutionPolicy

Y modificarla (si tu cuenta tiene permisos para ello) usando Set-ExecutionPolicy, por ejemplo:

Set-ExecutionPolicy RemoteSigned

Si no eres administrador, es posible que no puedas cambiar la política a nivel de máquina, pero sí podrías ajustarla a nivel de usuario o de proceso, según la configuración de tu organización. En cualquier caso, a la hora de planear automatización sin privilegios elevados, asume que la política de ejecución es una restricción de seguridad más con la que debes convivir y diseña tus scripts en consecuencia.

Crear y editar scripts de PowerShell de forma cómoda

Aunque puedes escribir scripts en cualquier editor de texto, resulta mucho más cómodo usar herramientas con resaltado de sintaxis y ayudas al desarrollo, sobre todo cuando los scripts crecen y empiezan a incluir funciones, módulos y lógica compleja.

Las opciones más comunes para trabajar con scripts de PowerShell son:

• Visual Studio Code (VS Code): hoy en día es la opción recomendada por Microsoft. Es gratuito, ligero y, con la extensión oficial de PowerShell instalada, ofrece autocompletado (IntelliSense), depuración paso a paso, snippets, integración con Git y terminal integrado.
• PowerShell ISE: es el entorno integrado clásico que viene con Windows PowerShell 5.1 y versiones anteriores. Aunque se considera heredado frente a VS Code, todavía es muy utilizado en muchos entornos.
• Bloc de notas u otros editores simples: válidos para scripts pequeños o rápidos, aunque pierdes muchas ayudas que facilitan la vida cuando el código se complica.

En todos los casos, el flujo básico es similar: creas un nuevo archivo, escribes el código de PowerShell, lo guardas con la extensión .ps1 y luego lo ejecutas desde una consola. Por ejemplo, si guardas el script en C:\Scripts\MiScript.ps1, puedes lanzarlo desde PowerShell haciendo:

& "C:\Scripts\MiScript.ps1"

Para que todo esto encaje con la automatización, tendrás que pensar en cómo se llamará ese script de forma programada sin usar privilegios de administrador, algo que veremos más adelante con el Programador de tareas.

Automatizar con el Programador de tareas de Windows y PowerShell

El Programador de tareas de Windows es la pieza que te permite disparar scripts de PowerShell de forma automática según horarios, eventos o condiciones del sistema. Aunque muchas guías lo usan para tareas con privilegios de administrador, también es perfectamente válido para automatización en contexto de usuario estándar, siempre que la tarea se configure con la cuenta adecuada.

La biblioteca del Programador de tareas organiza todas las tareas en carpetas y, para cada una, ofrece varias pestañas clave:

• General: nombre, descripción, cuenta con la que se ejecuta y opciones de seguridad (por ejemplo, si se ejecuta aunque el usuario no haya iniciado sesión).
• Triggers (Desencadenadores): determina cuándo se lanza la tarea: al iniciar sesión, al encender el equipo, cada día, a una hora concreta, al producirse un evento, etc.
• Actions (Acciones): define lo que hace la tarea cuando se dispara, normalmente iniciar un programa, que en este caso será powershell.exe con los argumentos apropiados.
• Conditions (Condiciones): permite afinar cuándo se ejecuta: solo si el equipo está enchufado, si está inactivo un tiempo, si la red cumple ciertas características, etc.
• Settings (Configuración): ajustes adicionales como permitir ejecución bajo demanda, reintentos si falla, detener si dura demasiado, comportamiento si ya está en marcha, etc.
• History (Historial): registra las ejecuciones, errores y advertencias, muy útil para depurar cuando algo no se ejecuta como debería.

Para lanzar un script de PowerShell desde el Programador de tareas, el patrón típico en la pestaña Acciones es:

• Program/script: powershell.exe
• Add arguments: algo del estilo -File C:\Scripts\MiScript.ps1, añadiendo si hace falta más parámetros como -ExecutionPolicy Bypass o -NoExit según tus necesidades.
• Start in: opcional, directorio donde está el script si dependes de rutas relativas.

Al usar la cuenta de usuario estándar como cuenta de ejecución de la tarea (en la pestaña General), el script se ejecutará con los mismos permisos que tienes tú cuando inicias sesión, lo que encaja perfectamente con la premisa de automatizar sin ser administrador. Eso sí, si el script requiere tocar partes del sistema reservadas a administradores, fallará, así que es crucial diseñar cada tarea pensando en el contexto de seguridad disponible.

Ventajas de automatizar con Task Scheduler y PowerShell

Combinar el Programador de tareas con scripts de PowerShell ofrece un paquete de beneficios muy interesante incluso sin usar privilegios elevados. Algunas ventajas clave son:

• Ahorro de tiempo: tareas repetitivas como limpiezas, informes o exportaciones de datos se ejecutan solas mientras tú estás a otra cosa o incluso con la sesión cerrada (si la tarea está configurada para ello).
• Consistencia: el script hace siempre exactamente lo mismo, en el mismo orden, sin despistes, lo que reduce el margen de error humano.
• Fiabilidad: puedes programar rutinas regulares (diarias, semanales, mensuales) que mantienen el sistema o tus datos en buen estado, incluso sin intervenir de forma manual.
• Eficiencia de recursos: es fácil planificar scripts para horas de baja carga, evitando impactos de rendimiento en horas punta.
• Flexibilidad: los disparadores basados en tiempo, inicio de sesión, inicio del sistema o eventos permiten automatizaciones muy adaptadas a tu entorno.
• Manejo de errores: puedes configurar reintentos, registrar salidas de PowerShell, enviar correos o escribir eventos específicos cuando algo falla.
• Seguridad: al ejecutar scripts con cuentas de usuario acotadas, reduces el riesgo de que un error de script provoque daños serios en el sistema. Solo cuando sea absolutamente necesario deberías recurrir a tareas que usen cuentas con permisos más amplios.

Para automatización avanzada en redes grandes, PowerShell da todavía más juego: con tareas programadas bien diseñadas puedes encadenar flujos de trabajo complejos, orquestar tareas en diferentes máquinas y responder automáticamente a sucesos concretos.

Ejemplos prácticos de automatización con PowerShell

Una vez tienes claro el marco, lo que realmente marca la diferencia son los scripts concretos que pongas en marcha. Estos son algunos escenarios muy habituales donde PowerShell brilla, tanto en equipos individuales como en entornos más grandes.

Gestión de Microsoft 365 con PowerShell

En el ámbito de Microsoft 365, PowerShell se ha convertido en la herramienta de referencia para administrar usuarios, licencias y servicios en bloque. Con los módulos adecuados, puedes conectarte a tu tenant y automatizar una buena parte del trabajo diario, como migrar perfiles de usuario y Office. Para empezar suele emplearse el módulo clásico de MSOnline (aunque hoy en día se tiende más al módulo Microsoft Graph y al módulo de Exchange Online moderno). El flujo básico sería:

1. Instalar los módulos necesarios (por ejemplo, desde una sesión de PowerShell con permisos para instalar módulos):
   Install-Module -Name PowerShellGet -Force -AllowClobber
Install-Module -Name MSOnline
2. Conectar con el servicio usando tus credenciales de administrador de Microsoft 365:
   Connect-MsolService

A partir de ahí, puedes automatizar tareas como:

• Alta masiva de usuarios a partir de un CSV, asignándoles contraseñas y propiedades de perfil.
• Cambios de pertenencia a grupos basados en reglas (por ejemplo, mover usuarios a grupos de seguridad concretos).
• Desactivación automática de cuentas inactivas según criterios como la última fecha de cambio de contraseña o de inicio de sesión.
• Generación de informes periódicos sobre actividad de usuarios, licencias en uso o estado de seguridad.

Estos scripts se pueden lanzar de forma manual desde una consola con permisos adecuados en Microsoft 365 o integrarse en tareas programadas en un servidor de administración. Aunque la gestión del tenant requiere una cuenta con permisos altos en la nube, el equipo desde el que ejecutas el script no necesita necesariamente cuenta de administrador local, siempre que pueda instalar módulos y conectar con los servicios remotos.

Automatización de mantenimiento local

En máquinas Windows convencionales, incluso con una cuenta estándar puedes crear scripts para:

• Respaldar carpetas de usuario mediante copias y sincronización a otra unidad o a una ubicación de red donde tengas acceso.
• Limpiar archivos temporales y bloatware en tus rutas de perfil, caches de aplicaciones o logs que no requieran permisos de administrador.
• Registrar uso de disco, CPU o memoria desde el punto de vista de tu cuenta, generando informes en un directorio donde puedas escribir.
• Revisar procesos propios o servicios de usuario que no requieran elevar privilegios para consultar su estado.

Estos scripts, combinados con el Programador de tareas ejecutándose con tu usuario, permiten montar una rutina de mantenimiento y monitorización básica muy apañada incluso cuando el departamento de IT no te da acceso de administrador.

Automatización remota con Splashtop y otros sistemas

En entornos donde se trabaja de forma remota, herramientas como Splashtop añaden otra capa interesante. Este tipo de soluciones proporciona acceso remoto seguro a equipos y, en algunos casos, capacidades específicas para:

• Lanzar símbolos del sistema o consolas de PowerShell remotas sin necesidad de iniciar una sesión de escritorio completa.
• Ejecutar scripts de PowerShell en varios endpoints a la vez, con controles de auditoría y programación centralizada.
• Aplicar políticas, desplegar parches o scripts de corrección en grupos de equipos de forma desatendida.

Splashtop AEM, por ejemplo, está orientado precisamente a gestionar y automatizar tareas en flotas grandes de dispositivos, integrando muy bien la ejecución de scripts de PowerShell dentro de su plataforma. Según cómo se configure, puedes aprovechar estas capacidades incluso si tu cuenta local no es administrador, delegando parte del control en el sistema de gestión remoto.

Scripts de PowerShell para IIS, bases de datos y Web Deploy

En servidores que alojan aplicaciones web en IIS, la versión 2.1 de Web Deploy incluye un conjunto de scripts de PowerShell que facilitan muchísimo la preparación de sitios para publicación mediante Web Deploy. Aunque aquí sí se requiere normalmente ser administrador del servidor para la configuración inicial, conviene conocerlos porque forman parte de muchas infraestructuras de despliegue automatizado.

Los scripts principales son:

• SetupSiteForPublish.ps1: crea o configura un sitio de IIS, un usuario de despliegue no administrador y un archivo de perfil de publicación (.publishsettings).
• CreateSqlDatabase.ps1: crea una base de datos SQL Server, un inicio de sesión y un usuario con permisos db_owner, y añade la cadena de conexión al archivo de publicación.
• CreateMySqlDatabase.ps1: hace lo mismo pero para MySQL, creando base de datos y usuario con permisos sobre ella.
• AddDelegationRules.ps1: configura reglas de delegación en IIS para permitir que Web Deploy funcione correctamente en entornos delegados.

El script SetupSiteForPublish, por ejemplo, es capaz de montar de golpe un sitio llamado WDeploySite en un puerto disponible (entre 8080 y 8200), crear un grupo de aplicaciones asociado y generar un usuario local no administrador (WDeploySiteuser) con permisos sobre el directorio físico del sitio y los permisos necesarios en IIS. Toda la información se guarda en un archivo .publishsettings que pueden consumir herramientas como WebMatrix o Visual Studio.

Los scripts de bases de datos añaden a este perfil las cadenas de conexión de SQL Server o MySQL, creando también logins y usuarios específicos con contraseñas (que pueden generarse automáticamente o definirse a mano en la llamada al script). Aunque estas herramientas se diseñaron pensando en despliegues con privilegios, su filosofía encaja con la idea de dar a cada aplicación y cada proceso el mínimo acceso necesario, separando claramente cuentas administrativas y cuentas de publicación.

Buenas prácticas de seguridad y rendimiento en scripts de PowerShell

Cualquier estrategia de automatización, y más aún cuando se hace sin privilegios de administrador, debe apoyarse en una serie de buenas prácticas de seguridad y rendimiento para evitar problemas a medio plazo.

Algunos consejos fundamentales son:

• Diseñar scripts con el principio de mínimo privilegio: que cada script solo toque los recursos estrictamente necesarios, y que la cuenta que lo ejecuta (usuario estándar, cuenta de servicio, etc.) tenga únicamente los permisos imprescindibles.
• Firmar scripts sensibles y usar políticas de ejecución que obliguen a la firma al menos para scripts descargados de Internet o compartidos en la red de la empresa.
• Proteger credenciales e información sensible, evitando almacenarlas en texto plano dentro de los scripts y recurriendo a almacenes seguros, variables de entorno cifradas o soluciones para sincronizar y cifrar copias en la nube cuando proceda.
• Implementar manejo de errores robusto: usar bloques try/catch, registrar errores en logs y, si es posible, enviar alertas cuando algo crítico falle.
• Optimizar el rendimiento: reutilizar funciones y módulos, minimizar bucles innecesarios, trabajar con cmdlets nativos siempre que sea posible y probar diferentes enfoques para reducir tiempos de ejecución.
• Monitorear y auditar tareas programadas: revisar periódicamente el historial del Programador de tareas, los registros de eventos y los archivos de log generados por los scripts para detectar comportamientos anómalos o fallos recurrentes.
• Probar siempre en entornos de desarrollo o pruebas antes de implantar una nueva tarea o script en producción, sobre todo si interactúa con sistemas críticos o datos delicados.

Con todo esto en mente, se puede montar un ecosistema de automatización en PowerShell muy capaz, apoyado en tareas programadas y herramientas remotas, donde solo una pequeña parte de la infraestructura requiera cuentas altamente privilegiadas y el resto funcione con usuarios estándar o de servicio muy acotados. Planificando bien los contextos de ejecución, el diseño de scripts y la gestión de permisos, es perfectamente viable automatizar gran parte del trabajo diario en Windows y Microsoft 365 sin depender constantemente de la cuenta de administrador.

Artículo relacionado:

Cómo desinstalar aplicaciones preinstaladas y bloatware con PowerShell en Windows 10 y 11

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.