(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa

Como agendar um script PowerShell no Task Scheduler

João Barros 14 de July de 2026 5 min de leitura

Agendar um script PowerShell no Task Scheduler é a forma mais simples de pôr uma rotina a correr sozinha: exportar um CSV todas as manhãs, limpar logs ao domingo ou chamar uma API de hora a hora. Não precisa de infraestrutura extra — o Agendador de Tarefas já vem no Windows. O que se segue é o passo a passo completo, incluindo o erro clássico que faz a tarefa parecer que correu mas sem produzir nada.

Pré-requisitos

  • Windows 10/11 ou Windows Server, com o Agendador de Tarefas (Task Scheduler).
  • Um script .ps1 já testado à mão na consola.
  • Permissões de administrador (necessárias para tarefas que correm sem sessão iniciada).
  • Windows PowerShell 5.1 (powershell.exe) ou PowerShell 7 (pwsh.exe).

Passo 1: Preparar o script para correr sem ninguém a ver

Um script que funciona na sua consola pode falhar em silêncio quando é agendado: corre noutra pasta de trabalho, sem perfil carregado e sem ninguém para responder a perguntas. Duas regras salvam-lhe horas de depuração — use sempre caminhos absolutos e escreva um log.

# C:\Scripts\ExportarVendas.ps1
$ErrorActionPreference = 'Stop'
$log = 'C:\Scripts\logs\exportar-vendas.log'
New-Item -ItemType Directory -Path (Split-Path $log) -Force | Out-Null

try {
    "$(Get-Date -Format s) - inicio" | Add-Content $log

    $dados = Import-Csv 'C:\Dados\vendas.csv'
    $dados | Where-Object { [decimal]$_.Total -gt 100 } |
        Export-Csv 'C:\Dados\vendas_top.csv' -NoTypeInformation -Encoding UTF8

    "$(Get-Date -Format s) - OK ($($dados.Count) linhas)" | Add-Content $log
    exit 0
}
catch {
    "$(Get-Date -Format s) - ERRO: $($_.Exception.Message)" | Add-Content $log
    exit 1
}

Repare no exit 0 e exit 1: é assim que o script comunica sucesso ou falha ao Task Scheduler, que os mostra na coluna Last Run Result.

Passo 2: Criar a tarefa na interface gráfica

Abra o Agendador de Tarefas (taskschd.msc) e escolha Create Task — não Create Basic Task, porque esta última não deixa configurar as opções que interessam.

  1. General: dê um nome à tarefa, marque Run whether user is logged on or not e Run with highest privileges.
  2. Triggers → New → Daily, às 07:00.
  3. Actions → New → Start a program:
    • Program/script: powershell.exe
    • Add arguments: -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\ExportarVendas.ps1"
    • Start in: C:\Scripts
O caminho do .ps1 vai sempre dentro de -File e entre aspas. Se o colocar diretamente no campo Program/script, o Windows tenta abri-lo no editor em vez de o executar.

Passo 3: Criar a mesma tarefa por PowerShell

Se quiser repetir isto em dez servidores, faça-o por código. O módulo ScheduledTasks já vem instalado no Windows.

$acao = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\ExportarVendas.ps1"' -WorkingDirectory 'C:\Scripts'

$gatilho = New-ScheduledTaskTrigger -Daily -At 07:00

$definicoes = New-ScheduledTaskSettingsSet -StartWhenAvailable -MultipleInstances IgnoreNew -ExecutionTimeLimit (New-TimeSpan -Hours 1)

$params = @{
    TaskName = 'Exportar Vendas'
    TaskPath = '\bConcepts\'
    Action   = $acao
    Trigger  = $gatilho
    Settings = $definicoes
    User     = 'SYSTEM'
    RunLevel = 'Highest'
    Force    = $true
}

Register-ScheduledTask @params

A conta SYSTEM corre sempre, sem password e sem sessão iniciada — ideal quando o script só toca em ficheiros locais. Se precisar de aceder a uma partilha de rede ou a uma base de dados com autenticação integrada, registe a tarefa com uma conta de serviço do domínio (-User 'DOMINIO\svc_dados' -Password '...') e dê-lhe permissões nesses recursos.

Para PowerShell 7, troque o executável por 'C:\Program Files\PowerShell\7\pwsh.exe'; os argumentos são os mesmos.

Passo 4: Evitar o erro de Execution Policy

O erro mais reportado é este: a tarefa acaba em segundos, o log fica vazio e no Event Viewer aparece File cannot be loaded because running scripts is disabled on this system. A causa é a Execution Policy da máquina.

O parâmetro -ExecutionPolicy Bypass resolve o problema apenas para aquele processo — não altera a política do computador nem baixa a segurança global. Já -NoProfile impede que o perfil do utilizador (que pode nem existir na conta de serviço) seja carregado e mude variáveis ou a pasta atual.

Passo 5: Testar sem esperar pelo horário

Não fique à espera das 07:00 para saber se funciona. Force uma execução imediata:

Start-ScheduledTask -TaskName 'Exportar Vendas' -TaskPath '\bConcepts\'

Verificar o resultado

Confirme os três sinais habituais — o código de saída, o log do script e o ficheiro produzido:

Get-ScheduledTaskInfo -TaskName 'Exportar Vendas' -TaskPath '\bConcepts\' |
    Select-Object LastRunTime, LastTaskResult, NextRunTime

Get-Content 'C:\Scripts\logs\exportar-vendas.log' -Tail 5

Como interpretar o LastTaskResult:

  • 0 — sucesso (o script fez exit 0).
  • 1 — o script apanhou um erro e fez exit 1: veja o log.
  • 0x41301 — a tarefa ainda está a correr.
  • 0x41303 — a tarefa nunca foi executada.

Se precisar de mais detalhe, o histórico do próprio agendador está no registo de eventos Microsoft-Windows-TaskScheduler/Operational.

Conclusão

Com um script bem preparado (caminhos absolutos, log e códigos de saída) e uma tarefa registada por código, tem uma automação fiável e replicável em qualquer servidor Windows. O passo seguinte natural é parametrizar o script, enviar um email quando o LastTaskResult for diferente de zero e, quando a rotina tiver de correr fora da rede local, mudá-la para um Azure Automation Runbook. Uma última dica: se a tarefa corre no seu portátil, marque Wake the computer to run this task — de que serve o agendamento se a máquina estava suspensa?