{"id":334,"date":"2026-01-27T02:00:11","date_gmt":"2026-01-27T02:00:11","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=334"},"modified":"2026-08-03T22:36:07","modified_gmt":"2026-08-03T22:36:07","slug":"how-to-download-olympic-coin-on-windows-vps","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/how-to-download-olympic-coin-on-windows-vps\/","title":{"rendered":"Task Scheduler on a Windows VPS: Automate Backups, Log Cleanups, and Maintenance"},"content":{"rendered":"

Windows Task Scheduler is the built-in cron of Windows Server, and it is one of the most under-used tools on a Windows VPS. Backup jobs, log rotation, database snapshots, and health checks all belong in scheduled tasks \u2014 yet most admins either run them by hand over RDP or forget them until something breaks. This guide shows how to create reliable, restart-proof scheduled tasks with PowerShell, check their results, and avoid the five mistakes that make scheduled tasks fail silently.<\/p>\n

Everything here works on any Windows Server edition and costs nothing extra \u2014 you just need a box that stays on 24\/7, which is exactly what a VPS is for. If you are still choosing a host, our comparison table of Windows VPS providers<\/a> shows which plans include enough SSD space for the backup retention you will want once automation is running.<\/p>\n

The two ways to create tasks<\/h2>\n

You can click through taskschd.msc over RDP, but for reproducible setup the PowerShell ScheduledTasks module is better: the same commands work on Server Core, in provisioning scripts, and in your deployment pipeline. Both tools write to the same underlying task store.<\/p>\n

Create a daily task that runs as SYSTEM<\/h2>\n

This is the pattern to memorize. A task needs an action (what to run), a trigger (when), and a principal (which account):<\/p>\n

$action    = New-ScheduledTaskAction -Execute \"powershell.exe\" `\n              -Argument \"-NoProfile -ExecutionPolicy Bypass -File C:\\scripts\\backup.ps1\"\n$trigger   = New-ScheduledTaskTrigger -Daily -At 02:00\n$principal = New-ScheduledTaskPrincipal -UserId \"SYSTEM\" -LogonType ServiceAccount -RunLevel Highest\n\nRegister-ScheduledTask -TaskName \"Nightly Backup\" `\n  -Action $action -Trigger $trigger -Principal $principal `\n  -Description \"Site and database backup\" -Force<\/code><\/pre>\n
Running as SYSTEM with LogonType ServiceAccount is the key: the task runs whether or not anyone is logged into an RDP session, and it survives password changes. The schtasks.exe equivalent of the same job is:<\/p>\n
schtasks \/Create \/TN \"Nightly Backup\" \/TR \"powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\\scripts\\backup.ps1\" \/SC DAILY \/ST 02:00 \/RU SYSTEM \/RL HIGHEST \/F<\/code><\/pre>\n
Run a task every 30 minutes<\/h2>\n
For health checks or queue processors, use a repeating trigger:<\/p>\n
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) `\n  -RepetitionInterval (New-TimeSpan -Minutes 30) `\n  -RepetitionDuration (New-TimeSpan -Days 3650)\nRegister-ScheduledTask -TaskName \"Health Check\" `\n  -Action $action -Trigger $trigger -Principal $principal -Force<\/code><\/pre>\n
A task can also fire at startup (New-ScheduledTaskTrigger -AtStartup) \u2014 handy for services that need a kick after a reboot \u2014 or at user logon. Combine several triggers by passing an array: $trigger = @(New-ScheduledTaskTrigger -Daily -At 02:00, (New-ScheduledTaskTrigger -Daily -At 14:00)). And to see every task on the box, including the ones Windows registers for itself:<\/p>\n
Get-ScheduledTask | Select-Object TaskName, State, `\n  @{n=\"Next\";e={(Get-ScheduledTaskInfo $_).NextRunTime}} | Format-Table -AutoSize<\/code><\/pre>\n
Check whether a task actually ran<\/h2>\n
The most common complaint is \u201cthe task did not run\u201d. The real status is one command away:<\/p>\n
Get-ScheduledTaskInfo -TaskName \"Nightly Backup\" |\n  Select-Object LastRunTime, LastTaskResult, NextRunTime<\/code><\/pre>\n
LastTaskResult 0 (0x0) means the task completed successfully. Common nonzero values: 0x41303 means it has not run yet, 0x41301 means it is currently running, and 267011 usually means the trigger fired but the program was not found \u2014 check your paths. If a PowerShell script fails, wrap it in Start-Transcript so the failure is visible in a log:<\/p>\n
Start-Transcript -Path \"C:\\logs\\tasks.log\" -Append\ntry { & \"C:\\scripts\\backup.ps1\" } catch { Write-Error $_ }\nStop-Transcript<\/code><\/pre>\n
Four jobs worth automating on day one<\/h2>\n