How to Automate Tasks with Task Scheduler on Your MU Server

A MU Online server lives on routine: restarting processes to free memory, generating database backups, cleaning logs that bloat the disk, switching seasonal events on and off, and making sure everything comes back up after a VPS reboot. Doing this by hand works while you are online and remember to — and fails on exactly the weekend you traveled. The Windows Task Scheduler solves this for free, using what already comes installed with Windows Server. This tutorial shows a complete method: which MU tasks are worth automating, how to write them as robust scripts, how to schedule them correctly, and how to diagnose the number one source of headaches — the task that shows as "completed" but did nothing. All the paths, times, and service names here are examples and vary by provider/version of your emulator and of Windows.

Prerequisites

Before scheduling anything, you need a MU server that is already running to automate — there is no point scheduling the restart of a GameServer that is not yet running. If you are still building the foundation, start with how to create a MU Online server and come back here afterward. Assuming the server is live, you will need:

• Administrator access to the VPS's Windows Server (via RDP), because creating tasks that run without a session requires elevated privileges.
• The absolute paths of the server folders: where GameServer.exe, ConnectServer.exe, JoinServer.exe, and the logs folder live. Write them down — you will use them a lot.
• A grasp of basic PowerShell. You do not need to be an expert; the scripts below are commented and you just adapt the paths.
• Disk space reserved for backups and a defined retention policy (how many days to keep). Automation without retention fills the disk and takes the server down — the opposite of what you wanted.

> [!TIP] > Create a single D:\Scripts\ folder on the server and keep all your automation scripts there. Having everything in one place makes backup, versioning, and handing the server off to another admin much easier.

What is worth automating on a MU server

Not every task should be automated, and not every time slot is appropriate. The table below lists the most common automations on MU servers, with the typical frequency and suggested time. The values are examples and vary by provider/version and by your server's player profile.

The golden rule: automate what is repetitive, predictable, and low-risk. Restarts, backups, and cleanup are easy candidates. A database migration or an emulator version upgrade, on the other hand, should not be automated — those are operations that require a human eye and a decision point.

Step 1 — Write the GameServer restart script

Before scheduling, write the script. A scheduled task is just a trigger; the intelligence lives in the script it fires. This PowerShell example restarts the GameServer, with a warning, a check, and logging:

# Script: ReiniciarGameServer.ps1
# Restarts the GameServer in a controlled way, with logging.

param(
    [string]$GameServerDir  = "D:\MuServer\GameServer",
    [string]$GameServerExe  = "GameServer.exe",
    [string]$LogDir         = "D:\Scripts\Logs"
)

$LogFile = Join-Path $LogDir ("reinicio_{0}.log" -f (Get-Date -Format 'yyyyMM'))

function Write-Log {
    param([string]$Msg)
    $line = "[{0}] {1}" -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss'), $Msg
    Add-Content -Path $LogFile -Value $line
}

Write-Log "=== Starting controlled GameServer restart ==="

# 1 -> Kill the current process, if it is running
$proc = Get-Process -Name ($GameServerExe -replace '\.exe$','') -ErrorAction SilentlyContinue
if ($proc) {
    Write-Log "GameServer running (PID $($proc.Id)). Stopping..."
    Stop-Process -Id $proc.Id -Force
    Start-Sleep -Seconds 5
} else {
    Write-Log "GameServer was not running."
}

# 2 -> Bring the GameServer back up
$exePath = Join-Path $GameServerDir $GameServerExe
if (Test-Path $exePath) {
    Start-Process -FilePath $exePath -WorkingDirectory $GameServerDir
    Write-Log "GameServer started from $exePath"
} else {
    Write-Log "ERROR: executable not found at $exePath"
    exit 1
}

Write-Log "=== Restart complete ==="

Note three details that separate an amateur script from a professional one: the absolute path (never relative), the WorkingDirectory set explicitly (MU depends on files in its own folder), and the log with a timestamp. Without the log you are blind when something fails at 5 AM.

> [!WARNING] > Many MU emulators need the GameServer running in an interactive session (visible window), not as a service. If yours works that way, Start-Process works with the session open, but when you close RDP the window may close depending on the configuration. Test your emulator's behavior before trusting an unsupervised automatic restart.

Step 2 — Create the task in Task Scheduler (graphical interface)

With the script ready, schedule it. Open Task Scheduler (taskschd.msc) and follow along:

1. In the right pane, click Create Task (not "Create Basic Task" — the full one gives more control).
2. On the General tab: name it MU_Reinicio_GameServer, check Run whether user is logged on or not and Run with highest privileges.
3. On the Triggers tab: new trigger, Daily, time 05:00.
4. On the Actions tab: new action, Start a program. In the Program field: powershell.exe. In Arguments: -NonInteractive -ExecutionPolicy Bypass -File "D:\Scripts\ReiniciarGameServer.ps1". In the Start in field: D:\Scripts\.
5. On the Conditions tab: uncheck "Start the task only if the computer is on AC power" (a VPS runs 24/7).
6. On the Settings tab: check "Run task as soon as possible after a scheduled start is missed".

The Start in field in step 4 is the one most people forget and the one that most often causes the silent failure: without it, PowerShell runs from System32 and any relative path breaks.

Step 3 — Create tasks from the command line (schtasks)

For automation at scale, or to document task creation in a setup script, use schtasks. It is the same scheduler, without the clicks:

# Creates the daily restart task at 05:00, running as SYSTEM
schtasks /Create `
  /TN "MU_Reinicio_GameServer" `
  /TR "powershell.exe -NonInteractive -ExecutionPolicy Bypass -File D:\Scripts\ReiniciarGameServer.ps1" `
  /SC DAILY `
  /ST 05:00 `
  /RU "SYSTEM" `
  /RL HIGHEST `
  /F

# Creates a task that brings all servers up when Windows starts
schtasks /Create `
  /TN "MU_Subir_ServidoresBoot" `
  /TR "powershell.exe -NonInteractive -ExecutionPolicy Bypass -File D:\Scripts\SubirTudo.ps1" `
  /SC ONSTART `
  /RU "SYSTEM" `
  /RL HIGHEST `
  /F

# Lists all the MU tasks created
schtasks /Query /TN "MU_Reinicio_GameServer" /V /FO LIST

The MU_Subir_ServidoresBoot task with /SC ONSTART is one of the most valuable: if the VPS reboots on its own in the early hours (a forced update, a datacenter power outage), your servers come back on their own, in the right order, without you waking up.

Step 4 — Master script that brings the servers up in the correct order

MU has a startup order: first the database must be up, then DataServer/ConnectServer, then JoinServer, and lastly the GameServers. Bringing everything up at once, out of order, causes connection errors. A master script solves this:

# Script: SubirTudo.ps1
# Brings the MU components up in the correct order, with a wait between them.

$base = "D:\MuServer"
$LogFile = "D:\Scripts\Logs\boot_$(Get-Date -Format 'yyyyMM').log"

function Log($m){ Add-Content $LogFile "[$(Get-Date -f 'yyyy-MM-dd HH:mm:ss')] $m" }
function Subir($nome, $pasta, $exe){
    $p = Join-Path $base "$pasta\$exe"
    if(Test-Path $p){
        Start-Process -FilePath $p -WorkingDirectory (Join-Path $base $pasta)
        Log "$nome started."
    } else { Log "ERROR: $nome not found at $p" }
}

Log "=== MU server BOOT ==="

# 1 -> Wait for SQL Server to be ready (example: fixed wait)
Log "Waiting for the database..."
Start-Sleep -Seconds 30

Subir "DataServer"    "DataServer"    "DataServer.exe";    Start-Sleep 8
Subir "ConnectServer" "ConnectServer" "ConnectServer.exe"; Start-Sleep 5
Subir "JoinServer"    "JoinServer"    "JoinServer.exe";    Start-Sleep 5
Subir "GameServer"    "GameServer"    "GameServer.exe"

Log "=== BOOT complete ==="

The wait times (Start-Sleep) are examples and vary by provider/version and by the VPS hardware. On a slower server, increase them. The ideal approach, instead of a fixed wait, is to check whether the previous component's port already responds before bringing up the next one — but the fixed wait already handles most cases.

Step 5 — Watchdog task (the server crashed, bring it back up)

A task that runs every few minutes and checks whether the GameServer is alive turns an early-hours crash into a 3-minute hiccup instead of hours of downtime:

# Script: VigiaGameServer.ps1 - schedule with a repeat every 5 min
$nome = "GameServer"
$proc = Get-Process -Name $nome -ErrorAction SilentlyContinue
if(-not $proc){
    Add-Content "D:\Scripts\Logs\vigia.log" "[$(Get-Date -f 'HH:mm:ss')] GameServer crashed. Bringing it up..."
    Start-Process "D:\MuServer\GameServer\GameServer.exe" -WorkingDirectory "D:\MuServer\GameServer"
}

To schedule the repeat: on the Triggers tab, create a daily trigger and, under "Advanced settings", check Repeat task every 5 minutes for a duration of "Indefinitely".

> [!TIP] > A watchdog is great, but watch out for the side effect: if the GameServer is stuck in a crash loop, the watchdog will resurrect it every 5 minutes indefinitely, masking the real problem. Add a restart counter to the log and set up an alert if it climbs too much within an hour.

Common errors and fixes

The champion error is the first one in the table. Whenever a task "works" but nothing happens, the first reflex should be: absolute path? "Start in" filled? Account with permission on the folder? Ninety percent of cases die right there.

Operational best practices

Automation without observability is a time bomb. Three habits prevent most disasters:

1. Every script writes a log with date and time. When something fails at 5 AM, the log is the only witness.
2. Every task sends an alert on failure. A Send-MailMessage or a Discord webhook in the error block warns you before the player complains.
3. Review the history weekly. Five minutes looking at the tasks' result codes reveals problems before they become outages.

And test each task manually before trusting it: in Task Scheduler, right-click the task, Run. If it runs fine on demand but fails at its scheduled time, the problem is in the trigger or the account — not the script.

Launch checklist

• Absolute paths for GameServer, ConnectServer, JoinServer, and logs written down
• D:\Scripts\ folder created with all scripts versioned
• Restart script tested manually and generating a log
• Daily restart task created, with "Start in" filled
• Boot task (ONSTART) bringing the servers up in the correct order
• Backup task scheduled and integrated with the retention policy
• Watchdog task every 5 min with a restart counter
• AC power condition unchecked on all tasks
• "Run as soon as possible if the schedule is missed" checked where it makes sense
• Task Scheduler history enabled
• Failure alerts (email or Discord) configured in the critical scripts
• VPS clock and time zone verified
• Each task run manually ("Run") and validated before launch

With these tasks in place, your MU server starts to look after itself most of the time: it restarts cleanly, runs backups, comes back up after a reboot, and warns you when something goes wrong. You stop being a hostage to "I hope nobody needs me at 3 in the morning" and gain the scarcest asset of anyone who runs a server: sleep.

Frequently asked questions