TL;DR

Move the world in this order: stop the old server, take one last backup of it, build the new server, restore that backup onto it, check the world, and only then give players the new address. Stopping first means nothing can be played on the old server after the backup that the new one doesn’t have. The world and the server’s settings are the only things the new machine can’t get from Steam, and the backup holds both. That holds for a Navezgane world. A random-gen world also keeps its terrain in GeneratedWorlds, which this method doesn’t move, and mods aren’t archived either.

On the old server, in an elevated PowerShell with Stop-GameServer from the part on starting and stopping the server defined:

$telnet = Read-Host 'Telnet password (Enter if none)' -AsSecureString
Stop-GameServer -Password $telnet
Start-ScheduledTask -TaskName 7DaysToDieServerS3Backup

Step 1 waits for the task, checks that the backup started after the stop, and turns off the old server’s tasks. On the new server, install the game and its prerequisites with the earlier parts. Then download the newest archive as SYSTEM, copy myserver.xml out of it, and run Restore-GameWorld from the part on restoring without merging. The game-specific parts are the save folder, the config file and the log lines that show the world loaded.

The step most likely to stop you is the download. The backup task wrote the archive with the credentials in SYSTEM’s profile, so the download has to run as SYSTEM too, and the backup user’s policy has to allow s3:GetObject. The CloudFormation template in the backup article creates a user whose policy does.

The backup article started from a goal: a server I can replace without a second thought. This part is the replacing: the migration of a dedicated server from one Windows machine to another, world and settings included. My server runs on Windows Server 2019, and I want it on 2025. I rehearsed the move on two Windows Server 2025 machines. The world was a new Navezgane that nobody had played, so what follows is the order and the commands, not a move with players in it.

1. Stop the old server and take the last backup

Do these on the old server, in this order. Stopping the server first closes the window in which a player could change the world after the backup. The backup then copies a world that nothing is writing to, which the backup article lists under “Saves are captured mid-write” as the case it can’t promise.

$task = '7DaysToDieServerS3Backup'
Disable-ScheduledTask -TaskName $task | Out-Null
while ((Get-ScheduledTask -TaskName $task).State -eq 'Running') { Start-Sleep -Seconds 5 }
$telnet = Read-Host 'Telnet password (Enter if none)' -AsSecureString
Stop-GameServer -Password $telnet
$stopped = Get-Date
$stopped = $stopped.AddTicks(-($stopped.Ticks % [TimeSpan]::TicksPerSecond))
Enable-ScheduledTask -TaskName $task | Out-Null
Start-ScheduledTask -TaskName $task
Start-Sleep -Seconds 5
while ((Get-ScheduledTask -TaskName $task).State -eq 'Running') {
    Start-Sleep -Seconds 1
}
$info = Get-ScheduledTaskInfo -TaskName $task
if ($info.LastRunTime -lt $stopped) {
    throw 'The backup that finished started before the server stopped. Run it again.'
}
$info.LastTaskResult
Disable-ScheduledTask -TaskName 7DaysToDieServer
Disable-ScheduledTask -TaskName $task

The password is read as a secure string, so it stays out of the console history. With no telnet password set, press Enter and nothing is sent. The last two lines turn off the old server’s tasks before anyone is told the new address. 7DaysToDieServer starts the server at every boot, so a reboot would otherwise bring the old world back where a player could still reach it. The backup task would write an archive of the old world with a newer name than any the new server makes. A restore that takes the newest archive would then pick it. Both tasks read Disabled afterwards.

Disabling the backup task first keeps its daily trigger from starting a run while the server stops, and the first loop waits out a run that had already begun, because starting a running task does nothing and a backup that began before the stop could hold a world that was still being written. The task is enabled again only to take this last backup. Task Scheduler records the last run time to the second, so $stopped is cut to the second too, and the check fails only for a run that started before the stop. If the daily time falls in this window, run the step again.

The result must be 0. The script reads the object back from S3 and compares its size before it exits 0, so a 0 means the archive is in the bucket. The newest log under backup-logs names it:

Upload successful: 1806071 bytes, STANDARD_IA

The backup took seven seconds here and the archive was 1.8 MB, because the world was new. Note the archive’s name, which is a timestamp. On a world people have played it is larger.

This step assumes the backup task from the backup article is already running on the old server, with its script archiving myserver.xml, as the configuration part says to change it. If the archive holds the shipped serverconfig.xml instead, your settings exist only on the old server, and step 4 has a way to copy them.

2. Build the new server

On the new server, in an elevated PowerShell, follow the earlier parts for what each owns:

1. Install SteamCMD and the server. It took about eight minutes here, which is most of the time the move takes.
2. Install the Visual C++ runtime from the configuration part, step 1, and open the firewall ports from its step 5. Skip its steps 2 to 4, because the settings come from the archive.
3. Install AWS Tools for all users, from step 1 of the backup article. The runtime and the AWS modules together took 25 seconds.
4. Write the backup user’s access key into SYSTEM’s profile, as step 2 of the backup article does, and the bucket name into C:\Scripts\backup-config.txt, as its step 3 does. The new server uses the same key as the old one.

This part moves a world on one of the maps the game ships, such as Navezgane. It doesn’t move a random-gen world: that one also needs its GeneratedWorlds folder, and Restore-GameWorld refuses an archive that holds one, so steps 3 and 4 stop there. For a random-gen world, copy Saves and GeneratedWorlds across by hand with both servers stopped instead; I didn’t test that. Don’t start the new server yet.

3. Download the latest archive as SYSTEM

The key is in SYSTEM’s profile, so the download runs as SYSTEM, the way the backup does. A scheduled task is the way the backup article runs something as SYSTEM. None of the earlier parts downloads an archive this way, so this step is new. Save this as C:\Scripts\Get-LatestBackup.ps1:

$ErrorActionPreference = 'Stop'
Import-Module AWS.Tools.S3
$bucket = (Get-Content 'C:\Scripts\backup-config.txt' -First 1).Trim()
$prefix = '7days-backups/'
$latest = Get-S3Object -BucketName $bucket -Prefix $prefix |
    Where-Object { $_.Key -match '7dtd-backup-[^/]+\.zip$' } |
    Sort-Object LastModified -Descending | Select-Object -First 1
if (-not $latest) { throw "No archive under $prefix in $bucket." }
New-Item -ItemType Directory -Path C:\backups -Force | Out-Null
$zip = Join-Path C:\backups (Split-Path $latest.Key -Leaf)
Read-S3Object -BucketName $bucket -Key $latest.Key -File $zip | Out-Null
$size = (Get-Item $zip).Length
if ($size -ne $latest.Size) { throw "Size mismatch: S3 $($latest.Size), local $size." }
"Downloaded $zip ($size bytes)"

It picks the archive that S3 says is newest, downloads it to C:\backups, and stops if the local size differs from the object’s. Then run it once as SYSTEM, wait for it and remove the task:

$command = '& C:\Scripts\Get-LatestBackup.ps1 *> C:\Scripts\get-latest.log'
$action = New-ScheduledTaskAction -Execute 'powershell.exe' `
    -Argument "-NoProfile -ExecutionPolicy Bypass -Command `"$command`""
Register-ScheduledTask -TaskName 'GetLatestBackup' -Action $action `
    -User 'SYSTEM' -RunLevel Highest | Out-Null
Start-ScheduledTask -TaskName 'GetLatestBackup'
Start-Sleep -Seconds 3
while ((Get-ScheduledTask -TaskName 'GetLatestBackup').State -eq 'Running') {
    Start-Sleep -Seconds 1
}
(Get-ScheduledTaskInfo -TaskName 'GetLatestBackup').LastTaskResult
Get-Content C:\Scripts\get-latest.log
Unregister-ScheduledTask -TaskName 'GetLatestBackup' -Confirm:$false

The result is 0 and the log reads:

Downloaded C:\backups\7dtd-backup-20261005-063440.zip (1806071 bytes)

The name is the one step 1 noted. The download took five seconds.

4. Copy the settings and restore the world saves

The restore function doesn’t touch settings: its archive’s serverconfig.xml or myserver.xml stays in the zip. A move needs them, so copy the settings file out of the archive first:

$zip = (Get-ChildItem C:\backups\7dtd-backup-*.zip |
    Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName
$unpacked = Join-Path $env:TEMP 'archive-config'
Expand-Archive -LiteralPath $zip -DestinationPath $unpacked -Force
Copy-Item (Join-Path $unpacked 'myserver.xml') C:\7DaysToDieServer\myserver.xml
Remove-Item $unpacked -Recurse

The copy from the archive had the same SHA-256 as the old server’s file, so the name, password, slots and UserDataFolder came across with it. UserDataFolder puts Saves beside the executable, and the restore function looks for it there. If the archive holds serverconfig.xml and not myserver.xml, it has the shipped settings: copy your myserver.xml from the old server by hand.

Then define Restore-GameWorld from the restore part and run it on the archive:

Restore-GameWorld -ArchivePath $zip

PS> Restore-GameWorld -ArchivePath $zip

Restored Saves from 7dtd-backup-20261005-063440.zip.

There was no old Saves on the new server, so the function printed no line about one, and it started nothing because no server was running. It finished in under a second. It compared every restored file with the archive by name and size before it returned.

5. Start the server and check the world

Register the task from step 1 of the part on starting at boot and start it with its step 3. The server was ready 54 seconds after the start here. Then read three things.

The log names the world and the game name from the settings you copied, and the world loading:

Select-String -Path C:\7DaysToDieServer\output_log.txt `
    -Pattern 'GamePref.GameName =', 'GamePref.GameWorld =', 'createWorld',
    'StartGame done'

Each log line starts with a timestamp, which is left out here.

GamePref.GameName = MyGame
GamePref.GameWorld = Navezgane
INF createWorld: Navezgane, Navezgane (src: GameData, DeviceLocal), MyGame, GameModeSurvival
INF createWorld() done
INF StartGame done

The build matches the old server’s, read on both machines:

Select-String -Pattern '"buildid"' `
    -Path C:\7DaysToDieServer\steamapps\appmanifest_294420.acf

Both read 24994542. If yours differ, Steam published a build between the two installs and the new server is the newer one. The update part covers how the server’s build is compared with the one Steam publishes. I didn’t test loading an older world on a newer build.

Then stop the new server with Stop-GameServer -Password $telnet, the function from step 4 of the start-at-boot part, with $telnet read as in step 1. It exited with code 0 in four seconds, the task read Ready with a last result of 0, and the log had SaveAndCleanupWorld. Run this on both machines, once the new server has stopped, and compare the two outputs:

$root = 'C:\7DaysToDieServer\Saves'
Get-ChildItem $root -Recurse -File | Where-Object Extension -ne '.bak' |
    Sort-Object FullName | ForEach-Object {
        '{0} {1} {2}' -f $_.FullName.Substring($root.Length), $_.Length,
            (Get-FileHash $_.FullName).Hash
    } | Out-File C:\saves-manifest.txt -Encoding ascii

Copy the old server’s file to the new one as C:\old-manifest.txt and run Compare-Object (Get-Content C:\old-manifest.txt) (Get-Content C:\saves-manifest.txt). No output means the two lists are identical, and here they were: 61 files, size for size and hash for hash. To see it report a difference, I changed one byte of sdcs_profiles.sdf on the new server and ran the command again. It printed that file’s line twice, once for each hash, with => on the new server’s line and <= on the old one’s, and printed nothing again once I put the byte back. The server had started and stopped on the new machine, and the old one had not run since its backup. The .bak files are left out because the server writes new ones when it starts, and the new machine’s differed from the old. On a world people played, I can’t say whether a start and a stop leaves every other hash alone.

6. Move the players and the backups

Start the new server again with Start-ScheduledTask -TaskName 7DaysToDieServer, and give players its address. Whether they can reach it depends on the network in front of it, which the configuration part leaves to you.

Then save the script and register the task on the new server with steps 4 and 5 of the backup article. Change the script’s $Config line to myserver.xml, as the configuration part says, or the new archives hold the shipped settings. Run the task once from the scheduler. Here it exited 0 and wrote a second archive, 1.8 MB, and a listing of the bucket as SYSTEM showed both archives.

The old server’s tasks have been off since step 1; leave it stopped. Deleting it is yours to do, after the new one has made good backups.

Check that the key reaches only its bucket

The key should reach one bucket and no other. As SYSTEM on the new server, a listing of a different bucket that exists, one the user’s policy doesn’t name, was refused. I tried one other bucket:

User: arn:aws:iam::<account>:user/<backup user> is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::<other bucket>" because no identity-based policy allows the s3:ListBucket action

A download of an archive in the right bucket succeeded with the same credentials, which is what step 3 did.

Common failures

Download fails with is not authorized to perform: s3:GetObject

User: arn:aws:iam::<account>:user/<backup user> is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::<bucket>/7days-backups/<archive>" because no identity-based policy allows the s3:GetObject action

The backup user’s policy lacks s3:GetObject. I removed it from the test user’s policy and ran the download as SYSTEM, and it failed this way while listing the bucket still worked. Add the permission, as the template in the backup article has it, and run step 3 again.

Backup on the old server fails with AWS Tools for PowerShell not available

ERROR: AWS Tools for PowerShell not available to this account: The specified module 'AWS.Tools.SecurityToken' was not loaded because no valid module file was found in any module directory.. Install AWS.Tools.S3 and AWS.Tools.SecurityToken with -Scope AllUsers

The task’s result was 1 and nothing reached S3. The old server had AWS.Tools.S3 and not AWS.Tools.SecurityToken; it is what step 1 of the backup article installs. Run step 1 of the backup article, which installs both for all users, and start the task again.

What I didn’t test

• A world people had played, or a client connecting to the new server, or the ports from outside the machine.
• A reboot of the new server, so the at-boot trigger is registered and not seen to fire.
• The old server’s backup task running after the move. Disable-ScheduledTask on both tasks was run, and both read Disabled.
• Steps 2 and 3 of the backup article on either machine. The access key was written into SYSTEM’s profile on both for me, and I took the bucket name from the stack’s output.

TL;DR

Register a scheduled task whose action is the server executable itself, with an at-startup trigger, the SYSTEM account and the execution time limit set to zero. Stop the server with its telnet shutdown command, which the server accepts on 127.0.0.1:8081 by default.

It is the only stop I found that finishes the shutdown. The process exited with code 0 and wrote every save file. Stop-ScheduledTask ended it in about a second with exit code 1067 and wrote about half of them. The default time limit is 72 hours, after which Task Scheduler stops the server the same abrupt way.

In an elevated PowerShell on the server, with your config file (myserver.xml here) in the install folder and UserDataFolder set in it:

$dir = 'C:\7DaysToDieServer'
$log = Join-Path $dir 'output_log.txt'
$flags = '-quit -batchmode -nographics -configfile=myserver.xml -dedicated'
$arguments = "-logfile `"$log`" $flags"
$action = New-ScheduledTaskAction -Execute (Join-Path $dir '7DaysToDieServer.exe') `
    -Argument $arguments -WorkingDirectory $dir
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) `
    -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName '7DaysToDieServer' -Action $action -Trigger $trigger `
    -Settings $settings -User 'SYSTEM' -RunLevel Highest

Then Start-ScheduledTask -TaskName 7DaysToDieServer starts it, and the Stop-GameServer function in step 4 stops it. The game-specific parts are the server’s flags, its ready line, and telnet as the way to stop it.

I didn’t restart the test server, so the at-startup trigger is confirmed to be registered, not confirmed to fire. Step 5 has the check to run after your first reboot.

The previous part left a server you start by hand. This part makes Windows start it when the machine boots, keep it running, and stop it without losing the world.

1. Register the task

The task runs the server executable directly. Nothing wraps it, so the task’s state says whether the server is running, and stopping the task stops the server.

The previous part’s UserDataFolder setting matters here. A task that runs as SYSTEM has no user profile of its own, and without that setting the server writes its world under the SYSTEM profile, at C:\Windows\System32\config\systemprofile\AppData\Roaming\7DaysToDie. Check that your myserver.xml has it set before you register the task.

This registers the task:

$dir = 'C:\7DaysToDieServer'
$log = Join-Path $dir 'output_log.txt'
$flags = '-quit -batchmode -nographics -configfile=myserver.xml -dedicated'
$arguments = "-logfile `"$log`" $flags"
$action = New-ScheduledTaskAction -Execute (Join-Path $dir '7DaysToDieServer.exe') `
    -Argument $arguments -WorkingDirectory $dir
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) `
    -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName '7DaysToDieServer' -Action $action -Trigger $trigger `
    -Settings $settings -User 'SYSTEM' -RunLevel Highest

What each part does:

• -WorkingDirectory sets the folder the server starts in. The server found myserver.xml next to its executable without it, so this is a precaution and not a requirement.
• -AtStartup runs the task when Windows starts, before anyone logs on.
• -User 'SYSTEM' with -RunLevel Highest runs it as the SYSTEM account, with no password to store. SYSTEM has machine-wide rights, so a flaw in the server or a mod it loads would have them too. If players you don’t trust can reach the server, register the task under a dedicated local account that can write only to the install folder. I didn’t test that.
• -ExecutionTimeLimit ([TimeSpan]::Zero) turns the time limit off. The next step shows why that is the setting to get right.
• -AllowStartIfOnBatteries and -DontStopIfGoingOnBatteries turn off two defaults that exist for laptops. Both are on by default, and a virtual machine has no battery, so these are harmless there.

Register-ScheduledTask prints an error if the name already exists, and leaves the first task as it was. Running the block twice is harmless. To change a task, remove it with Unregister-ScheduledTask -TaskName '7DaysToDieServer' -Confirm:$false and register it again.

Read the settings back:

PS> $task = Get-ScheduledTask -TaskName '7DaysToDieServer'
PS> $task.Settings.ExecutionTimeLimit

PT0S

PS> $task.Triggers[0].CimClass.CimClassName

MSFT_TaskBootTrigger

PS> $task.Principal.UserId

SYSTEM

PT0S is how Task Scheduler stores no limit.

2. Turn off the 72-hour execution time limit

A task registered with no settings read back PT72H. Task Scheduler ends a task that runs longer than its limit, and a game server is meant to run for weeks.

To see what it does to the server, I registered the same task with a limit of two minutes and started it. The server ran until the limit, and Task Scheduler then ended it, about 123 seconds after the start. The task went back to Ready with a last result of 267014, which is Task Scheduler’s code for a task that was terminated. The log shows the server beginning its shutdown, but the limit ends the process the same abrupt way Stop-ScheduledTask does in step 4, which is not a clean stop.

A longer limit only moves that moment. With PT72H the server would have been stopped three days after each start, and nothing would have restarted it. The -ExecutionTimeLimit ([TimeSpan]::Zero) in step 1 turns the limit off.

There is a second way to build this task, and I tested it too. The action starts a small script that launches the server detached, with Start-Process, and exits. The task then finishes in seconds, and the limit never applies. With a two-minute limit the server was still running after more than three minutes, the task itself had finished within seconds, and Stop-ScheduledTask left the server running. That design needs the telnet stop in step 4 anyway. I used the direct task because its state says whether the server is running.

3. Start the task and wait for the server

Start-ScheduledTask returns as soon as the task starts. The server takes about 40 seconds to be ready. This starts the task and waits for the server’s own ready line:

$log = 'C:\7DaysToDieServer\output_log.txt'
if (Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue) {
    throw 'A 7DaysToDieServer process is already running. Stop it first.'
}
Remove-Item -LiteralPath $log -ErrorAction SilentlyContinue
Start-ScheduledTask -TaskName '7DaysToDieServer'
$deadline = (Get-Date).AddMinutes(5)
$ready = $false
while (-not $ready -and (Get-Date) -lt $deadline) {
    $ready = (Test-Path $log) -and
        (Select-String -Path $log -Pattern 'StartGame done' -Quiet)
    if (-not $ready) { Start-Sleep -Seconds 2 }
}
if (-not $ready) { throw 'The server was not ready after five minutes.' }
$task = Get-ScheduledTask -TaskName '7DaysToDieServer'
'Task state: {0}; last result: {1}' -f $task.State,
    (Get-ScheduledTaskInfo -TaskName '7DaysToDieServer').LastTaskResult

It stops if a 7DaysToDieServer process is already running, however it was started. A task in the Ready state would start a second server on the same ports and folder if you had started the first one by hand. And Start-ScheduledTask on a running task does nothing and returns no error. It does set the last result to 2147946720, the refusal from the default one-instance rule, and a later read of the result would mislead. It deletes the old log first. The check looks for StartGame done, and a leftover log would satisfy it at once.

While the server runs, the output is:

Task state: Running; last result: 267009

A state of Running and a last result of 267009 mean the task is running. That is a status code and not an error.

4. Stop the server with the telnet shutdown command

The server has a telnet console, on 127.0.0.1:8081 by default, and its shutdown command is the stop that works. Setting TelnetPassword makes the console listen on every interface instead, so keep Windows Firewall and any cloud network security group closed to that port. This function sends the command, with the password first if there is one, and waits for the process to exit:

function Stop-GameServer {
    param([securestring]$Password, [int]$Port = 8081,
        [int]$TimeoutSeconds = 90)
    $server = @(Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue)
    if ($server.Count -ne 1) {
        throw "Expected one 7DaysToDieServer process, found $($server.Count)."
    }
    $null = $server[0].Handle
    $client = New-Object Net.Sockets.TcpClient('127.0.0.1', $Port)
    try {
        $stream = $client.GetStream()
        $stream.ReadTimeout = 2000
        $buffer = New-Object byte[] 4096
        $reply = {
            $text = ''
            $until = (Get-Date).AddSeconds(3)
            try {
                while ((Get-Date) -lt $until -and
                    ($count = $stream.Read($buffer, 0, $buffer.Length)) -gt 0) {
                    $text += [Text.Encoding]::ASCII.GetString($buffer, 0, $count)
                }
            }
            catch [IO.IOException] { }
            $text
        }
        $send = {
            param($line)
            $bytes = [Text.Encoding]::ASCII.GetBytes("$line`r`n")
            $stream.Write($bytes, 0, $bytes.Length)
        }
        if ($Password -and $Password.Length -gt 0) {
            & $send ([Net.NetworkCredential]::new('', $Password).Password)
            $login = & $reply
            if ($login -match 'Password incorrect') {
                throw 'The telnet password is missing or wrong.'
            }
            if ($login -notmatch 'Logon successful') {
                throw 'The server did not confirm the telnet login.'
            }
        }
        & $send 'shutdown'
        if ((& $reply) -match 'Password incorrect') {
            throw 'The telnet password is missing or wrong.'
        }
    }
    finally { $client.Close() }
    if (-not $server[0].WaitForExit($TimeoutSeconds * 1000)) {
        throw "The server was still running after $TimeoutSeconds seconds."
    }
    'Stopped, exit code {0}.' -f $server[0].ExitCode
}

It stops with an error and doesn’t touch the process in two cases. The telnet port refuses the connection, which is what TelnetEnabled set to false does. Or the server answers Password incorrect. It never forces the process to end. Run it as Stop-GameServer. With a telnet password, read it as a secure string so it stays out of your console history and any transcript:

$telnet = Read-Host 'Telnet password' -AsSecureString
Stop-GameServer -Password $telnet

The function turns it back into text only to send it. The game’s telnet console takes it unencrypted, one more reason to keep that port closed.

On the task’s server it stopped the process with exit code 0. The task went back to Ready with a last result of 0, because the process ended by itself. The server wrote 9 to 14 files under Saves and its log ran on to the end of its shutdown, after SaveAndCleanupWorld and Saving 0 of chunks, with 47 more lines. It took two to eight seconds.

With a telnet password set, I connected three ways and sent shutdown each time. With no password, or a wrong one, the server answered Password incorrect, please enter password: and kept running, and the function reports that at once. With the right password it stopped in two seconds, exit code 0, and the log held SaveAndCleanupWorld.

Each wrong attempt counts toward the server’s TelnetFailedLoginLimit, which was 10 on this server. The function sends the password first and reads the reply, for at most three seconds, and sends shutdown only after the server has said Logon successful, so a wrong password uses one attempt. Sent together, the shutdown after a wrong password would count as a second one. With the limit set to 3, a wrong password and then a missing one still left the right password working.

If the reply is late or says neither, the function stops with The server did not confirm the telnet login. The server also prints its log to a telnet connection, so a read that waited only for silence could go on as long as the server logged something every two seconds.

Why Stop-ScheduledTask isn’t a clean stop

Stop-ScheduledTask -TaskName '7DaysToDieServer' is the obvious stop for a task, and it ends the process, but not cleanly. I ran it twice on the task’s server:

• The process exited with code 1067 after about a second. 1067 is ERROR_PROCESS_ABORTED, “The process terminated unexpectedly”, and it is the exit code the process had both times Task Scheduler ended it here.
• The log began the shutdown, with SaveAndCleanupWorld and Stopping server, and then ended at Cleared queues. instead of running on for another 40 or so lines.
• It wrote three to five files under Saves, among them main.ttw, players.xml and decoration.7dt. The telnet stop also wrote vehicles.dat, power.dat, turrets.dat, drones.dat and blockLimits.dat, and none of those five were written in either Stop-ScheduledTask run.
• The task read Ready with a last result of 267014, Task Scheduler’s code for a terminated task.

I ran these on a new world with nobody connected, so I can’t say what the missing files hold in a world that people are playing. Their names suggest vehicles, power, turrets, drones and block limits. Use Stop-ScheduledTask as the fallback when telnet isn’t available.

Other ways to stop it: taskkill and the close request

With telnet off, I tried the other ways a script might stop the process. The first two behave differently when a console session started the server and when the task did, so the table has both:

The server runs with -batchmode -nographics, and the two polite requests had no effect on it. Stop-Process -Force is the last resort. After it, the server had logged no save, so whatever happened since the last save is gone.

5. Check the task after the first reboot

The at-startup trigger was registered and read back as a boot trigger, and the task starts on command. I didn’t restart the test server, so I haven’t seen the trigger fire. After your first reboot, check that it did:

Get-ScheduledTaskInfo -TaskName '7DaysToDieServer' |
    Select-Object LastRunTime, LastTaskResult
Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue

A LastRunTime near the boot time and a running process mean it worked. Stop the server with step 4 before you restart the machine on purpose. I haven’t tested what Windows does to the server when it shuts down with the task running, and if it ends the process the way Stop-ScheduledTask does, the save is only partial.

Nothing here restarts the server if it crashes. The task has no restart settings.

Common failures

Server stops by itself after three days

The task has the default 72-hour limit, or whatever limit you set. Read it with (Get-ScheduledTask -TaskName '7DaysToDieServer').Settings.ExecutionTimeLimit. If it isn’t PT0S, remove the task and register it again with step 1.

Task starts and the server isn’t running

The log in -logfile has the reason. Two causes seen on this server: a missing Visual C++ runtime, and a ServerPort outside 1024 to 65530.

Stop-GameServer says the connection was refused

Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it 127.0.0.1:8081"

Telnet is off, or on another port. Check TelnetEnabled and TelnetPort in myserver.xml. Until telnet works, Stop-ScheduledTask is the fallback, with the cost step 4 describes.

Last result 267014, or exit code 1067, after a stop

Task Scheduler uses it for a task that was ended from outside, which is what Stop-ScheduledTask and the time limit do. The process itself exits with 1067 when Task Scheduler ends it. A telnet stop leaves 0 for both. Step 4 shows what the difference cost.

TL;DR

Read the installed build number from steamapps\appmanifest_294420.acf, read the published one from SteamCMD’s app_info_print, and run app_update only when they differ.

Check the result by reading the installed build again, because SteamCMD can print Success! and exit with code 0 without changing the build. It did on a server installed from a branch, until -beta public was added to the command.

In PowerShell on the server, this reads both numbers. It prints the build you have, and the one Steam publishes on the public branch:

$manifest = 'C:\7DaysToDieServer\steamapps\appmanifest_294420.acf'
$installed = (Select-String -LiteralPath $manifest -Pattern '^\t"buildid"\s+"(\d+)"' |
    Select-Object -First 1).Matches[0].Groups[1].Value
$arguments = '+login', 'anonymous', '+app_info_update', '1',
    '+app_info_print', '294420', '+quit'
$info = (& 'C:\steamcmd\steamcmd.exe' $arguments 2>&1) -join "`n"
$pattern = '(?s)"branches"\s*\{.*?"public"\s*\{[^}]*?"buildid"\s+"(\d+)"'
$published = [regex]::Match($info, $pattern).Groups[1].Value
"installed $installed, published $published"

The game-specific parts are the app ID, 294420, and the file that holds the build number. Step 4 has the whole update as one function.

The previous parts installed the server, configured it, and made it start at boot and stop cleanly. This part keeps it current without restarting it for nothing. A server that runs app_update every morning restarts on the days when Steam has published nothing, and its players lose the session for no reason.

1. Read the installed build from appmanifest_294420.acf

SteamCMD records what it installed in steamapps\appmanifest_294420.acf, inside the server’s folder. The file is Valve’s KeyValues text, and the installed build is the top-level buildid line:

PS> $manifest = 'C:\7DaysToDieServer\steamapps\appmanifest_294420.acf'
PS> Select-String -Path $manifest -Pattern 'buildid' | ForEach-Object Line

    "buildid"        "24994542"
    "TargetBuildID"        "24994542"

TargetBuildID is a different key. The pattern in the next function has quotes around buildid, so it doesn’t match that line. It also requires one leading tab, which makes it the top-level key and not one nested deeper. The first function reads the number and returns nothing when the file or the line is missing. The second reads the branch the install came from, which the manifest records as BetaKey, and gives public when there is none:

function Get-InstalledBuild {
    param([string]$ServerDir = 'C:\7DaysToDieServer', [string]$AppId = '294420')
    $manifest = Join-Path $ServerDir "steamapps\appmanifest_$AppId.acf"
    if (-not (Test-Path -LiteralPath $manifest)) { return }
    $match = Select-String -LiteralPath $manifest -Pattern '^\t"buildid"\s+"(\d+)"' |
        Select-Object -First 1
    if ($match) { $match.Matches[0].Groups[1].Value }
}

function Get-InstalledBranch {
    param([string]$ServerDir = 'C:\7DaysToDieServer', [string]$AppId = '294420')
    $manifest = Join-Path $ServerDir "steamapps\appmanifest_$AppId.acf"
    if (-not (Test-Path -LiteralPath $manifest)) { return 'public' }
    $match = Select-String -LiteralPath $manifest -Pattern '"BetaKey"\s+"([^"]+)"' |
        Select-Object -First 1
    if ($match) { $match.Matches[0].Groups[1].Value } else { 'public' }
}

2. Read the published build from app_info_print

app_info_print prints everything Steam has on the app, about 560 lines for this server. The part that matters is branches, which has one entry per branch, each with its own buildid:

        "branches"
        {
            "public"
            {
                "buildid"        "24994542"
                "timeupdated"        "1788196235"
                "timebuildupdated"        "1787927331"
            }
            "v3.2.0"
            {
                "buildid"        "24994542"
                "description"        "Version 3.2.0 Stable"
                "timeupdated"        "1788195715"
                "timebuildupdated"        "1787927331"
            }
            "latest_experimental"
            {
                "buildid"        "25661908"
                "description"        "Unstable build"
                "timeupdated"        "1790898315"

+app_info_update 1 makes SteamCMD fetch fresh data before it prints, and the whole lookup took about three seconds here. Take the buildid of the branch you run, which is public unless you chose a beta. The same text holds a public entry under each depot, with a gid and no buildid. A search from the first public therefore depends on where the sections happen to sit. The pattern here starts at branches:

function Get-PublishedBuild {
    param(
        [string]$SteamCmd = 'C:\steamcmd\steamcmd.exe',
        [string]$AppId = '294420',
        [string]$Branch = 'public'
    )
    if (-not (Test-Path -LiteralPath $SteamCmd)) { return }
    $arguments = '+login', 'anonymous', '+app_info_update', '1',
        '+app_info_print', $AppId, '+quit'
    $text = (& $SteamCmd $arguments 2>&1) -join "`n"
    $pattern = '(?s)"branches"\s*\{.*?"' + [regex]::Escape($Branch) +
        '"\s*\{[^}]*?"buildid"\s+"(\d+)"'
    $match = [regex]::Match($text, $pattern)
    if ($match.Success) { $match.Groups[1].Value }
}

It returns nothing when SteamCMD isn’t where you said, or when the text has no such branch, which is what a failed connection to Steam gives too. A branch that doesn’t exist, nonexistent here, gave an empty result. Branch names are case-sensitive, and a branch that needs a password isn’t covered.

3. Compare the two builds, and treat a missing number as unknown

Run both functions:

PS> Get-InstalledBuild

24994542

PS> Get-PublishedBuild

24994542

Equal numbers mean there is nothing to do. When either is empty, you don’t know, and the safe answer is to stop and say so, not to guess. The next function does that.

4. Update only when they differ

This function does the whole job. When the builds match and the install is already on the branch you want, it returns at once and touches nothing, so a running server keeps running. When they differ it stops the server if one is running, runs app_update, reads the installed build again to check, and starts the server if it was running:

function Update-GameServer {
    param(
        [string]$ServerDir = 'C:\7DaysToDieServer',
        [string]$SteamCmd = 'C:\steamcmd\steamcmd.exe',
        [string]$AppId = '294420',
        [string]$Branch,
        [scriptblock]$StopServer = { Stop-GameServer },
        [scriptblock]$StartServer = {
            Start-ScheduledTask -TaskName '7DaysToDieServer' -ErrorAction Stop
        }
    )
    if (Test-Path -LiteralPath $ServerDir) {
        $ServerDir = (Resolve-Path -LiteralPath $ServerDir).ProviderPath
    }
    if (-not $Branch) {
        $Branch = Get-InstalledBranch -ServerDir $ServerDir -AppId $AppId
    }
    $installed = Get-InstalledBuild -ServerDir $ServerDir -AppId $AppId
    $published = Get-PublishedBuild -SteamCmd $SteamCmd -AppId $AppId -Branch $Branch
    "Installed build: $(if ($installed) { $installed } else { 'unknown' })"
    "Published build: $(if ($published) { $published } else { 'unknown' })"
    if (-not $installed -or -not $published) {
        throw 'Could not read both builds. Nothing was changed.'
    }
    $installedBranch = Get-InstalledBranch -ServerDir $ServerDir -AppId $AppId
    $sameBuild = $installed -eq $published
    if ($sameBuild -and $installedBranch -eq $Branch) {
        return 'Already on the published build. Nothing to do.'
    }
    $exe = Join-Path $ServerDir '7DaysToDieServer.exe'
    $wasRunning = [bool](Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue |
        Where-Object { $_.Path -eq $exe })
    $restart = $wasRunning
    if ($restart) { & $StopServer }
    $arguments = '+force_install_dir', $ServerDir, '+login', 'anonymous',
        '+app_update', $AppId, '-beta', $Branch, 'validate', '+quit'
    foreach ($attempt in 1, 2) {
        $null = & $SteamCmd $arguments 2>&1
        $after = Get-InstalledBuild -ServerDir $ServerDir -AppId $AppId
        $now = Get-InstalledBranch -ServerDir $ServerDir -AppId $AppId
        $onBranch = $now -eq $Branch
        if ($after -eq $published -and $onBranch) { break }
        # Steam may have published another build since the first lookup.
        $published = Get-PublishedBuild -SteamCmd $SteamCmd -AppId $AppId `
            -Branch $Branch
        if ($after -eq $published -and $onBranch) { break }
    }
    $note = if ($restart) { ' The server was left stopped.' }
    if (-not $after -or -not $published -or $after -ne $published) {
        $shown = if ($after) { $after } else { 'unknown' }
        $wanted = if ($published) { $published } else { 'unknown' }
        throw "Update failed: installed build is $shown, expected $wanted.$note"
    }
    $afterBranch = Get-InstalledBranch -ServerDir $ServerDir -AppId $AppId
    if ($afterBranch -ne $Branch) {
        throw "Update failed: the install is on branch $afterBranch, not $Branch.$note"
    }
    if ($restart) {
        & $StartServer
        $deadline = (Get-Date).AddSeconds(60)
        do {
            $running = Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue
            $started = [bool]($running | Where-Object { $_.Path -eq $exe })
            if (-not $started) { Start-Sleep -Seconds 2 }
        } until ($started -or (Get-Date) -gt $deadline)
        if (-not $started) {
            throw "Updated to build $after, but the server did not start."
        }
    }
    if ($sameBuild) { return "Switched to branch $Branch. The build is $after." }
    "Updated to build $after."
}

Run it as Update-GameServer. Stop-GameServer is the function from the previous part, so define it first, and the default start command is that part’s scheduled task. Change either with -StopServer and -StartServer. With a telnet password, read it once and pass it through -StopServer: $telnet = Read-Host 'Telnet password' -AsSecureString, then Update-GameServer -StopServer { Stop-GameServer -Password $telnet }.

What it does around the update:

• It resolves -ServerDir to a full path first, so a relative path such as .\old-server finds the running server too.
• Without -Branch it uses the branch the manifest records, so a server on a beta stays on it. Passing -Branch moves a server to another one.
• Two branches can have the same build. Then the function runs app_update and says Switched to branch .... It still stops and starts a running server, because a build published in the meantime would change the files under it.
• It runs app_update a second time if the first leaves the wrong build or the wrong branch. Moving from public to an older branch printed Success! and changed nothing until the second run.
• A failed update stops the function with an error and leaves the server stopped on purpose, because a half-updated install that starts and reports success is worse.
• If the build doesn’t match, it asks Steam for the published build once more before it gives up, because Steam can publish a newer build between the first lookup and the update.
• After the update it waits up to a minute for the server process, since Start-ScheduledTask only submits the request, and stops with an error if none appears.
• A build number it can’t read, before or after the update, counts as a failed update too, and the message says unknown for it.

On a server that is current, with the server running:

PS> Update-GameServer

Installed build: 24994542
Published build: 24994542
Already on the published build. Nothing to do.

The server’s process ID didn’t change, and the manifest wasn’t touched.

Real update from branch v3.1.0 to public

To test an update that has something to download, I installed the previous stable version into a separate folder with -beta v3.1.0. That is build 24436799. I started its server and ran the function against it:

PS> Update-GameServer -ServerDir C:\scratch\old-server -Branch public `
>     -StartServer { <start command for that folder> }

Installed build: 24436799
Published build: 24994542
Stopped, exit code 0.
Updated to build 24994542.

The old server was stopped over telnet and exited with code 0. The update downloaded about 8.4 GB in a little over two minutes, and the server started again on the new build. The stop line comes from the previous part’s function.

Plain app_update exits 0 and the build doesn’t change

The command I started with was the plain app_update 294420 validate, which is what an install script usually has. On the v3.1.0 install it printed Success! App '294420' fully installed., exited with code 0, and left the build at 24436799. On this install SteamCMD had recorded the branch in the manifest as BetaKey, and a plain app_update stayed on it. The manifest read v3.1.0 before, and public after -beta public.

Running -beta public on a server that was already on public changed nothing: the build stayed current.

Staying on its own branch is right for a server that should stay on one, which is why -Branch defaults to the manifest’s BetaKey. It also means the exit code and the Success! line say nothing about whether the build you wanted landed. The function therefore reads the installed build again and compares it with the published one.

validate restores the shipped config

validate checks every file against Steam’s copy and restores any shipped file you edited. It put serverconfig.xml back to the shipped version when part 2 ran it, and again here. If you run the server from myserver.xml, as part 3 does, an update leaves your settings alone.

Common failures

Update failed: installed build is not the published one

Update failed: installed build is 24436799, expected 24994542. The server was left stopped.

The function ran app_update and the installed build didn’t become the published one. I couldn’t make a real update fail, so I got this message by wrapping SteamCMD in a script that answers app_update with an error. Read what SteamCMD prints by running its command yourself, with the arguments from the function. If the server was running, it stays stopped. Start it again once you have the installed build right, or after you decide to run on the old one.

Update reports success and the build is the old one

The manifest’s BetaKey still names the branch the install came from, so a plain app_update stays on it. Pass -beta with the branch you want, which the function does through -Branch, and read the installed build again.

Could not read both builds

The function stopped before changing anything, and a mistyped -Branch ends up here too. The installed build is unknown when the manifest file is missing, which happens when -ServerDir is wrong. The published build is unknown when SteamCMD isn’t where you said, can’t reach Steam, or has no such branch. Check with Get-PublishedBuild -Branch <name> and read the printed text.

Update landed and the server didn’t start

The update itself finished, and the function says so: Updated to build <build>, but the server did not start. Look at the task’s last result with Get-ScheduledTaskInfo and at the server’s log.

Update-GameServer starts the server only if one was running when it began. A server that was stopped stays stopped, and gives no such error.

What I didn’t test

I didn’t see Steam publish a new build on public while this was running, so the update tested here was a move from an older branch to the current public build. I didn’t test a branch that needs a password, or a path to SteamCMD that has spaces in it. It exercises the same download, stop and start steps, but a routine patch is smaller. The article doesn’t schedule the check. And the stop and start commands are the previous parts’, which I ran separately.

TL;DR

Stop the server, rename the live Saves folder, and move the archive’s Saves into its place. Do not copy the archive over the live folder. A copy that merges, such as xcopy /E /I /Y, replaces the files that are in both and leaves every file that exists only in the live folder. A restore meant to undo damage then keeps part of the damage. In testing, a stray file added to the live world survived an xcopy /E /I /Y restore, and was gone after the rename-and-move.

The function later in the article does the whole restore. The commands it is made of, run on the stopped server, stop at the first error. They also check that the archive has a Saves folder with files in it, and no GeneratedWorlds folder, before they touch the live one:

$dir = 'C:\7DaysToDieServer'
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$live = Join-Path $dir 'Saves'
$staging = Join-Path $dir "Saves.restoring-$stamp"
Expand-Archive -LiteralPath 'C:\backups\7dtd-backup-20260925-142839.zip' `
    -DestinationPath $staging -ErrorAction Stop
$saves = Join-Path $staging 'Saves'
$files = $null
if (Test-Path -LiteralPath $saves -PathType Container) {
    $files = Get-ChildItem -LiteralPath $saves -Recurse -File `
        -ErrorAction SilentlyContinue
}
if (-not $files) {
    throw 'The archive holds no files under Saves.'
}
if (Test-Path -LiteralPath (Join-Path $staging 'GeneratedWorlds')) {
    throw 'The archive holds GeneratedWorlds. Restore both folders by hand.'
}
Rename-Item -LiteralPath $live -NewName "Saves.before-restore-$stamp" -ErrorAction Stop
Move-Item -LiteralPath (Join-Path $staging 'Saves') -Destination $live -ErrorAction Stop
Remove-Item -LiteralPath $staging -Recurse

The old world stays beside the new one as Saves.before-restore-<stamp>. If the commands stop on an error, they leave a Saves.restoring-<stamp> folder to delete. The function also checks the archive before it stops anything, and checks the restored files against the archive before it starts the server again. If that check fails, it undoes the restore. The game-specific parts are the Saves folder and the archive’s layout.

The previous parts install, configure and update the server. This part is the one you hope not to need: getting the world back from a backup. The backup itself is the S3 backup article, and this part starts from one of its zip files. Its Restore a backup section has the Read-S3Object download.

1. See why xcopy /E merges instead of restoring

Each archive the S3 backup article makes is a zip of the Saves folder and serverconfig.xml. On Windows PowerShell 5.1, Compress-Archive writes the entry names with backslashes, such as Saves\W\G\main.ttw.

To see the problem, I made a small folder shaped like a world, with main.ttw and players.xml in it, and archived it with Compress-Archive. Then I damaged the folder: I changed players.xml and added a file, corrupt.dat, that the archive doesn’t have. Then I restored by copying:

PS> Expand-Archive C:\demo\b.zip -DestinationPath C:\demo\x
PS> xcopy C:\demo\x\Saves C:\demo\srv\Saves /E /I /Y | Out-Null
PS> Get-ChildItem C:\demo\srv\Saves -Recurse -File | ForEach-Object Name

corrupt.dat
main.ttw
players.xml

players.xml is back to the archive’s copy, because it exists in both places. corrupt.dat is still there, because the archive has no copy to replace it with. The restore undid some of the damage and kept the rest, and nothing says so. A new file in a world’s folder is a small example. What it stands for is anything the server wrote after the backup: a file that was damaged, one a newer game version added, one left by a crashed save.

2. Rename the live world folder aside and move the archive’s in

This function stops the server if it is running, swaps the folders, checks the result, and starts the server again if it was running:

function Restore-GameWorld {
    param(
        [Parameter(Mandatory)][string]$ArchivePath,
        [string]$ServerDir = 'C:\7DaysToDieServer',
        [scriptblock]$StopServer = { Stop-GameServer },
        [scriptblock]$StartServer = {
            Start-ScheduledTask -TaskName '7DaysToDieServer' -ErrorAction Stop
        }
    )
    Add-Type -AssemblyName System.IO.Compression.FileSystem
    $zip = [IO.Compression.ZipFile]::OpenRead($ArchivePath)
    try {
        $expected = @{}
        $hasTerrain = $false
        foreach ($entry in $zip.Entries) {
            $name = $entry.FullName.Replace('/', '\')
            if ($name -like 'GeneratedWorlds\*') { $hasTerrain = $true }
            if ($name -like 'Saves\*' -and $entry.Name) {
                $expected[$name] = $entry.Length
            }
        }
    }
    finally { $zip.Dispose() }
    if ($hasTerrain) {
        throw ('The archive holds GeneratedWorlds, which this function does not ' +
            'restore. Restore both folders by hand, with the server stopped.')
    }
    if ($expected.Count -eq 0) {
        $leaf = Split-Path $ArchivePath -Leaf
        throw "The archive holds no files under Saves: $leaf"
    }
    $exe = Join-Path $ServerDir '7DaysToDieServer.exe'
    $running = @(Get-Process 7DaysToDieServer -ErrorAction SilentlyContinue)
    $mine = @($running | Where-Object { $_.Path -eq $exe })
    $wasRunning = $mine.Count -gt 0
    if ($running.Count -gt $mine.Count) {
        throw ('A 7DaysToDieServer process is running from another folder. ' +
            'Stop it first.')
    }
    $stamp = Get-Date -Format 'yyyyMMdd-HHmmss-fff'
    $asideName = "Saves.before-restore-$stamp"
    $live = Join-Path $ServerDir 'Saves'
    $aside = Join-Path $ServerDir $asideName
    $staging = Join-Path $ServerDir "Saves.restoring-$stamp"
    if ($wasRunning) { & $StopServer }
    try {
        Expand-Archive -LiteralPath $ArchivePath -DestinationPath $staging `
            -ErrorAction Stop
    }
    catch {
        Remove-Item -LiteralPath $staging -Recurse -Force -ErrorAction SilentlyContinue
        if ($wasRunning) { & $StartServer }
        throw ('Could not unpack the archive, so nothing was restored: ' +
            $_.Exception.Message)
    }
    $hadLive = Test-Path -LiteralPath $live
    if ($hadLive) {
        try {
            Rename-Item -LiteralPath $live -NewName $asideName -ErrorAction Stop
        }
        catch {
            Remove-Item -LiteralPath $staging -Recurse -Force `
                -ErrorAction SilentlyContinue
            if ($wasRunning) { & $StartServer }
            throw ('Could not move the live Saves aside, so nothing was restored: ' +
                $_.Exception.Message)
        }
    }
    $restored = Join-Path $staging 'Saves'
    $actual = @{}
    try {
        Move-Item -LiteralPath $restored -Destination $live -ErrorAction Stop
        $walk = {
            param($folder, $prefix)
            foreach ($item in Get-ChildItem -LiteralPath $folder -Force) {
                $name = "$prefix\$($item.Name)"
                if ($item.PSIsContainer) { & $walk $item.FullName $name }
                else { $actual[$name] = $item.Length }
            }
        }
        & $walk $live 'Saves'
        $missing = @($expected.Keys | Where-Object { $actual[$_] -ne $expected[$_] })
        $extra = @($actual.Keys | Where-Object { -not $expected.ContainsKey($_) })
        if ($missing + $extra) {
            $list = ($missing + $extra) -join ', '
            throw "The restored Saves doesn't match the archive: $list"
        }
    }
    catch {
        $message = $_.Exception.Message
        try {
            if (Test-Path -LiteralPath $live) {
                $failed = "Saves.failed-restore-$stamp"
                Rename-Item -LiteralPath $live -NewName $failed -ErrorAction Stop
            }
            if ($hadLive) {
                Rename-Item -LiteralPath $aside -NewName 'Saves' -ErrorAction Stop
            }
        }
        catch {
            throw ("The restore failed ($message) and could not be undone: " +
                "$($_.Exception.Message) The old world is at $aside, and the " +
                'server was not started.')
        }
        Remove-Item -LiteralPath $staging -Recurse -Force -ErrorAction SilentlyContinue
        if ($wasRunning) { & $StartServer }
        throw "The restore was undone. $message"
    }
    try { Remove-Item -LiteralPath $staging -Recurse -Force -ErrorAction Stop }
    catch { Write-Warning "Could not remove ${staging}: $($_.Exception.Message)" }
    if ($wasRunning) { & $StartServer }
    "Restored Saves from $(Split-Path $ArchivePath -Leaf)."
    if ($hadLive) { "The old Saves is at $aside." }
}

Run it as Restore-GameWorld -ArchivePath C:\backups\7dtd-backup-20260925-142839.zip. Stop-GameServer is the function from the part on stopping the server, so define it first. With a telnet password, read it once and pass it through -StopServer: $telnet = Read-Host 'Telnet password' -AsSecureString, then Restore-GameWorld -ArchivePath <zip> -StopServer { Stop-GameServer -Password $telnet }. The default start command is that part’s scheduled task, which throws if the task is missing or can’t start. The function expects Saves beside 7DaysToDieServer.exe, which is where UserDataFolder puts it in the earlier part on configuring the server.

What each part is for:

• It reads the archive’s file list first and stops if there are no files under Saves, before the server is touched. Windows PowerShell 5.1 leaves an empty folder out of a zip, so a backup of an empty Saves holds no world files. So does an archive that another tool made from the configuration alone. The S3 backup script stops when Saves is missing, so it doesn’t write one. Restoring one of those would remove your world and put nothing back.
• It stops with an error if any 7DaysToDieServer process is running from another folder. That holds even while the server in -ServerDir is running too, because it can only stop the one that lives in -ServerDir.
• It unpacks into a folder beside Saves, on the same drive, so that moving it into place is a rename and not a copy. If the archive can’t be unpacked, as happened with an entry whose path was too long, it removes the partial copy and stops before anything is moved. It starts the server again if it had stopped it.
• It treats removing its own unpacked folder, after a good restore, as housekeeping: if that fails, it warns and still starts the server, and you delete the Saves.restoring-<stamp> folder later.
• It renames the live folder with a stamp that includes milliseconds, and never deletes it. Every restore leaves its own displaced folder, even two in the same second.
• If the live folder can’t be renamed, it removes the unpacked copy as best it can and stops with an error. Nothing was restored, and nothing was lost. If the function had stopped the server, it starts it again before it reports the error, because the old world is untouched.
• It compares the restored folder with the archive, by file name and size, before the server starts. It builds the names from the items in each folder, not from full paths, because the same folder can come back as RUSTAD~1 or RustAdmin and a prefix cut by length then goes wrong. The server rewrites files as soon as it starts, so this is the only moment the comparison means anything. If the comparison fails, the function renames the restored folder to Saves.failed-restore-<stamp>, puts the old folder back, and starts the server again if it had stopped it. Putting the old folder back can fail too, for example because another process has a file in the restored folder open. Then the function says where the old world is and does not start the server.

The comparison catches missing and extra files and files of the wrong size. It doesn’t catch a damaged archive. A zip with one byte flipped in the middle of a file passed it, and so did Expand-Archive. Keep more than one backup. On the real server, with it running and corrupt.dat in the live world, the output was:

PS> Restore-GameWorld -ArchivePath $zip

Stopped, exit code 0.
Restored Saves from 7dtd-backup-20260925-142839.zip.
The old Saves is at C:\7DaysToDieServer\Saves.before-restore-20261003-170512-418.

The server was stopped over telnet, the old folder was renamed, and the new one had exactly the archive’s files. corrupt.dat was in Saves.before-restore-* and not in Saves. The server started again and logged its ready line.

What the function doesn’t restore

The archive’s serverconfig.xml stays in the zip and isn’t copied anywhere, so your myserver.xml and its settings stay as they are. A random-gen world also keeps its terrain in GeneratedWorlds, beside Saves. The S3 backup article tells you to add that folder to the archive yourself. The script it publishes archives only Saves and serverconfig.xml, so a backup made with it can’t bring back a random-gen world’s terrain. Change the backup first. This function restores Saves only. If the archive holds GeneratedWorlds, the function stops with an error, because it would otherwise restart the server on a restored save with the old terrain. Restore both folders by hand, with the server stopped.

Restore with the server stopped

The function only stops and starts the server when one is running. On a stopped server it swaps the folders and leaves the server stopped. Start it yourself afterwards, and look at the log for StartGame done.

Common failures

Live folder can’t be moved aside

Could not move the live Saves aside, so nothing was restored: Access to the path 'C:\7DaysToDieServer\Saves' is denied.

A file in the live folder is open. I reproduced it by holding one open from another process: the rename was denied, the function removed its unpacked copy, the live world was untouched, and no Saves.before-restore-* folder was created. Close whatever has the file open, which is usually the server, and run it again.

Archive has no world files

The archive holds no files under Saves: 7dtd-backup-config-only.zip

The archive has no world files in it. With the server running, the function stopped before touching it: the process kept its ID and the live Saves was unchanged. Pick an older archive.

Old world folders fill the disk

The old and new worlds sit side by side until you delete the old one. A new Navezgane world was 17.2 MB, and a played one is larger. Delete Saves.before-restore-* folders by hand once you have checked the restored world.

What I didn’t test

I didn’t download an archive from S3. The archive in the tests came from the same Compress-Archive call the backup script uses. I didn’t restore a world someone had played in, so the damage in the tests is a changed file and an extra file. And I didn’t test a restore that fails in the middle of the final move, which I couldn’t cause.

TL;DR

Unpack SteamCMD to C:\steamcmd, then install the server with one command that looks the app up first. The examples install 7 Days to Die, whose app ID is 294420. The app ID, the install folder, the server executable’s name and whether the game accepts +login anonymous are the game-specific parts, and the size you expect changes with them.

In PowerShell on the server:

New-Item -ItemType Directory -Path C:\steamcmd -Force | Out-Null
Invoke-WebRequest -Uri 'https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip' `
    -OutFile C:\steamcmd\steamcmd.zip -UseBasicParsing
Expand-Archive -Path C:\steamcmd\steamcmd.zip -DestinationPath C:\steamcmd -Force
Remove-Item C:\steamcmd\steamcmd.zip

C:\steamcmd\steamcmd.exe +force_install_dir "C:\7DaysToDieServer" +login anonymous `
    +app_info_print 294420 +app_update 294420 validate +quit

The install worked when the output contains Success! App '294420' fully installed. and C:\7DaysToDieServer\7DaysToDieServer.exe exists. Don’t go by the exit code. A fresh SteamCMD exits 7 on its first run, install or not.

Don’t run that command with validate later on a server whose serverconfig.xml you’ve edited, because validate restores the shipped file. Step 4 has the details.

If the output ends in ERROR! Failed to install app '294420' (Missing configuration) or Error! App '294420' state is 0x602 after update job., run the same command again. Both cleared on the second run in testing. Missing configuration is the one most likely to stop you, and +app_info_print prevents it on a fresh SteamCMD.

The install is one command, which is why the ways it misleads you on a fresh machine are easy to miss. The first run of SteamCMD updates itself and exits 7, including a run that installs the server. The first install on a fresh SteamCMD fails unless SteamCMD has already fetched the app’s record. A download of 16 GB can end with one corrupt file, and a rerun repairs it. An install path on a drive that doesn’t exist gets a Success! line and an install in the wrong folder. This part installs SteamCMD and the 7 Days to Die server and says how to tell a good install from a bad one. Finding the app ID for another game is the first part of this series.

1. Download and unpack steamcmd.zip

Run this in PowerShell on the server. It creates C:\steamcmd, downloads Valve’s steamcmd.zip into it, unpacks it and deletes the zip. The zip holds one file, steamcmd.exe, so there is no installer to run. -UseBasicParsing stops Invoke-WebRequest from parsing the download as a web page. Microsoft’s documentation (opens in a new tab) says Windows PowerShell requires it where Internet Explorer isn’t installed, and that after a December 2025 security update Invoke-WebRequest asks for confirmation without it, which stalls an unattended script.

New-Item -ItemType Directory -Path C:\steamcmd -Force | Out-Null
Invoke-WebRequest -Uri 'https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip' `
    -OutFile C:\steamcmd\steamcmd.zip -UseBasicParsing
Expand-Archive -Path C:\steamcmd\steamcmd.zip -DestinationPath C:\steamcmd -Force
Remove-Item C:\steamcmd\steamcmd.zip

SteamCMD fetches the rest of itself the first time it runs, and that run exits 7. Step 3 and the exit code section say how to check an install without the exit code.

2. Install the server with app_update

This writes about 16.5 GB under C:\7DaysToDieServer and downloads about that much, so the drive needs 17 GB free. Check that the drive exists and has the room: Get-PSDrive C | Select-Object Used, Free. The command, with each argument explained:

C:\steamcmd\steamcmd.exe +force_install_dir "C:\7DaysToDieServer" +login anonymous `
    +app_info_print 294420 +app_update 294420 validate +quit

Keep the quotes around the folder. Without them, a path with a space splits at the space. I ran a small app with +force_install_dir C:\scratch\p2 space\lit, and SteamCMD installed it into C:\scratch\p2, exited with code 0 and printed no warning. With the path in quotes it installed where I told it to.

On a fresh SteamCMD the first part of the output is SteamCMD updating itself. A complete download and install took about five to six minutes on this server. Near the end of a successful run the output reads as follows, and a few lines of shutdown messages follow it. The progress numbers differ from run to run:

 Update state (0x101) committing, progress: 88.23 (15671513734 / 17761385525)
 Update state (0x0) unknown, progress: 0.00 (0 / 0)
Success! App '294420' fully installed.

3. Confirm the install

Check three things: the Success! line from step 2, the executable at the path you chose, and the manifest SteamCMD writes for the app. A path SteamCMD can’t use isn’t an error, as one of the failures shows, so look at the path and don’t rely on the Success! line alone. The last two checks are:

PS> Test-Path C:\7DaysToDieServer\7DaysToDieServer.exe

True

PS> Select-String -Path C:\7DaysToDieServer\steamapps\appmanifest_294420.acf `
>     -Pattern '"(StateFlags|buildid)"' |
>     ForEach-Object { $_.Line.Trim() -replace '\t+', '  ' }

"StateFlags"  "4"
"buildid"  "24994542"

StateFlags is 4 after a complete install. A failed install leaves a different value: the failed install in the 0x602 section left 1538. buildid is the build you installed. A later part uses it to decide whether Steam has published a newer one.

4. Run it again on an installed server

The same command works on a server that is already installed. A later part uses it to update. With validate it checks every file, which took from roughly 80 to 150 seconds for about 17,500 files here, and ends with the same fully installed line:

C:\steamcmd\steamcmd.exe +force_install_dir "C:\7DaysToDieServer" +login anonymous `
    +app_update 294420 validate +quit

Without validate it doesn’t check every file. On an up-to-date server it did nothing, took a few seconds and ended Success! App '294420' already up to date.

validate also restores every file to the version Valve ships, including serverconfig.xml. I changed ServerName and ServerMaxPlayerCount in that file and ran the command with validate. Both were back to the shipped values, and the file matched the shipped original. The same command without validate left my edit alone. A copy of the file under another name, and a note file that isn’t part of the install, survived validate. So keep your settings in a copy and start the server with -configfile= naming it. The next part does that.

Common failures

Missing configuration on the first install

ERROR! Failed to install app '294420' (Missing configuration)

A fresh SteamCMD fails the first install before it downloads anything, and the same command succeeds when you run it again. I ran two or three trials of each case on a fresh SteamCMD with Core Keeper’s server (app 1963720), which is a small download:

• The install as the first run exited 7 with the error.
• The install after one +quit run, or two, exited 8 with the error.
• The install with +app_info_update 1 added exited 8 with the error.
• The install in the same command as a lookup of a different app, +app_info_print 440, exited 8 with the error.
• The install in the same command as a lookup of the app itself, +app_info_print 1963720, succeeded every time.
• The install after an earlier run that signed in, +login anonymous +quit, succeeded every time.
• The install after an earlier run that looked up an app, the same one or a different one, succeeded every time.

So the first install fails unless SteamCMD has already signed in anonymously in an earlier run, or the same command looks up the app being installed. The 7 Days to Die server failed on a SteamCMD that had run +quit twice, and succeeded with +app_info_print 294420 in the same command. Either put the lookup before +app_update as in step 2, or run C:\steamcmd\steamcmd.exe +login anonymous +quit once before the install. I don’t know why either works.

Success! but the files are in the wrong folder

An install path that SteamCMD can’t use isn’t an error. With no drive Z: on the machine, this command printed Success! App '1963720' fully installed. and exited 0:

C:\steamcmd\steamcmd.exe +force_install_dir "Z:\nope" +login anonymous `
    +app_update 1963720 +quit

Nothing was created on Z:. The server went under the SteamCMD folder, in steamapps\common\Core Keeper Dedicated Server, with its manifest and executable. That happened in three of three trials. A folder that doesn’t exist yet on a drive that does, such as C:\7DaysToDieServer, is created. Check that the drive exists with Test-Path Z:\, and check that the executable exists at the path you chose.

state is 0x602 after update job at the end of the download

Error! App '294420' state is 0x602 after update job.

The last progress line was 98.59%, and SteamCMD then rejected the files it had staged. logs\content_log.txt under the SteamCMD folder says why: Staged file validation failed (0 missing, 1 corrupt, 0 unreadable) (Corrupt update files). The server’s folder had no 7DaysToDieServer.exe and the manifest read StateFlags 1538. Run the same install command again. In my run the second one finished in 21 seconds with fully installed. It happened once in my first three complete installs from a fresh SteamCMD.

Exit code 7 and other codes that mislead

The exit code of steamcmd.exe doesn’t say whether the install worked:

• The first run of a fresh SteamCMD exits 7. When that run also installs the server the output contains Success!, and when the install fails it exits 7 as well.
• A refused install, for example No subscription, exits 8.
• A command SteamCMD doesn’t know, for example +no_such_command, prints Command not found: no_such_command and exits 0.
• An install path on a drive that doesn’t exist exits 0 and prints Success!, as the previous section shows.

Look for a Success! line in the output, and check that the executable exists at the path you chose. A Success! line is followed by a few lines of shutdown messages, so test for it with Select-String and not as the last line. A script that tests only $LASTEXITCODE calls a good first install a failure and a mistyped command a success.

No subscription

ERROR! Failed to install app '223350' (No subscription)

That’s DayZ’s server, app 223350. The install was refused for an anonymous login. The ID is the game’s, or the server isn’t available anonymously, or no app has that ID. The first part of this series tells them apart.

TL;DR

A dedicated server is usually its own Steam app with its own app ID. Pass the server’s ID to SteamCMD’s +app_update, not the game’s: +app_update 294420 installs the 7 Days to Die server, and the game’s 251570 is refused. The one exception among the 25 servers listed here is Counter-Strike 2, where the ID I checked, 730, is the game’s own app. App ID for each of 25 dedicated servers lists the ones I checked.

Confirm an ID before you install it by asking SteamCMD for its record and reading name, type and parent:

PS> & C:\steamcmd\steamcmd.exe +login anonymous +app_info_print 294420 +quit |
>     Select-String -Pattern '^\t\t"(name|type|parent)"\t' |
>     ForEach-Object { $_.Line.Trim() -replace '\t+', '  ' }

"name"  "7 Days to Die Dedicated Server"
"type"  "Tool"
"parent"  "251570"

name should say it’s a server. A parent, when the record has one, is the game’s ID, and seven of the servers in the table have none, so a missing parent isn’t a reason to reject a candidate. The thing most likely to stop you is that anonymous login can’t install every server: DayZ’s and Arma 3’s answered No subscription.

The scripts that run my 7 Days to Die server pass SteamCMD one number, 294420. The game has a number too, 251570, in the address of its store page, and an anonymous install of it fails with No subscription. I wrote this part first because every later part in this series hands the server’s ID to SteamCMD, and a reader running another game has to find theirs.

App ID for each of 25 dedicated servers

I checked each row on 2026-10-03, on Windows Server 2025, with the commands in this article.

The columns:

• Anonymous install: Install begins means SteamCMD printed its first Update state line and I stopped it. Refused means the install was refused with No subscription. No install ran to the end, and I didn’t try a login.
• Name Steam returns: what app_info_print printed as name for the ID.
• Game’s ID: the record’s parent. I looked up each one, and each returned that game’s name. Seven servers have none.

Two rows need a second look. Counter-Strike 2’s ID is the game’s own app: its type is Game and its name doesn’t contain Server. Rust’s record calls it a dedicated server but gives it the type Game, so don’t filter on type.

1. Find a candidate ID

Look for the ID in the game’s own server documentation, or search SteamDB in a browser. Treat what you find as a candidate until the next step confirms it.

The store won’t lead you to it. The game’s ID is in the address of the game’s store page: store.steampowered.com/app/251570/ is 7 Days to Die. The server has no page of its own. When I requested store.steampowered.com/app/294420/ from a script, the store answered with its front page, and the store’s api/storesearch endpoint returned no result for 7 days to die dedicated server. SteamDB answered a script with 403, and Valve’s Developer Community wiki answered with a “Making sure you’re not a bot!” page instead of an article, so I haven’t checked what either lists.

2. Confirm the ID from its record

This step needs steamcmd.exe. Part 2 installs it, and the commands here assume C:\steamcmd. For the lookup alone, https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip unpacks to steamcmd.exe, and the command works on its first run, though that run exits with code 7. The command is the one in the answer block, with your candidate in place of 294420. It reads the record and changes nothing.

Read the three lines:

• name is the one to trust. 24 of the 25 names in the table contain Server. The exception is Counter-Strike 2, which is the game.
• parent is the game’s ID, when the server has one.
• type is Tool for 23 of the 25 and Game for two, so a Game isn’t proof you have the wrong app. Rust’s record reads:

PS> & C:\steamcmd\steamcmd.exe +login anonymous +app_info_print 258550 +quit |
>     Select-String -Pattern '^\t\t"(name|type|parent)"\t' |
>     ForEach-Object { $_.Line.Trim() -replace '\t+', '  ' }

"name"  "Rust Dedicated Server"
"type"  "Game"

3. Check that anonymous login can install it

A real install downloads the whole server, which for some games is tens of gigabytes, and you only need to know whether it starts. Run the install once into an empty folder you can delete, here C:\steam-check, and stop it when SteamCMD answers:

& C:\steamcmd\steamcmd.exe +force_install_dir "C:\steam-check" `
    +login anonymous +app_update 294420

Keep the quotes around the folder, because a path with a space splits at the space. Watch the console. One of two things comes first:

• A line that starts Update state, such as Update state (0x61) downloading, progress: 0.00 (0 / 6103829589). The install has begun, so anonymous login can install the server. Press Ctrl+C.
• ERROR! Failed to install app '233780' (No subscription). Anonymous login can’t install it. SteamCMD waits at its Steam> prompt, so type quit.

Then delete the folder:

Remove-Item -LiteralPath '\\?\C:\steam-check' -Recurse -Force

The \\?\ prefix costs nothing and is there for long paths. Remove-Item in Windows PowerShell 5.1 stops at 260 characters, and some games nest folders deeper than that. An install stopped in its first seconds rarely gets that far, but if you let one run longer, the prefix is what deletes it.

Stopping SteamCMD this way can make its next start print Looks like steam didn't shutdown cleanly, scheduling immediate update check. Nothing is wrong.

Common failures

No subscription when you install

ERROR! Failed to install app '233780' (No subscription)

An anonymous login isn’t allowed to install that app. Three cases give the same message:

• The ID is the game’s. Step 3 gives it for 251570, 7 Days to Die.
• The server isn’t available to an anonymous login. The DayZ and Arma 3 servers answered this way. I didn’t test whether a login works.
• The ID doesn’t exist. Step 3 gives it for 999999999.

Read the ID’s record to tell them apart:

& C:\steamcmd\steamcmd.exe +login anonymous +app_info_print <app-id> +quit |
    Select-String -Pattern '^\t\t"(name|type|parent)"\t'

A name without Server in it, with type Game, is the game. A name that says server means anonymous login can’t install it. No lines at all means the lookup returned no record. Either no app has that ID, or SteamCMD couldn’t reach Steam. To tell them apart, run the lookup again without the Select-String line, so SteamCMD’s own output shows. A missing app still prints Waiting for user info...OK. A failed connection prints FAILED (No Connection) after retrying for a couple of minutes.

TL;DR

Install the Visual C++ runtime, set the server’s name, password and port in a copy of serverconfig.xml that you start the server from, and start the server once. The copy matters: a later validate restores the shipped file. Read the ports it listens on, then open exactly those in Windows Firewall. With the default ServerPort of 26900, the server listens on TCP 26900, and on UDP 26900 and 26902, which is ServerPort and ServerPort + 2. The server’s own message about a bad port also names ServerPort + 1, so the rules open UDP 26900 to 26902. The port numbers and the config file are the game-specific parts.

In an elevated PowerShell on the server, once the server runs:

New-NetFirewallRule -DisplayName '7DaysToDie-26900-TCP' -Direction Inbound `
    -Action Allow -Protocol TCP -LocalPort 26900
New-NetFirewallRule -DisplayName '7DaysToDie-26900-UDP' -Direction Inbound `
    -Action Allow -Protocol UDP -LocalPort 26900-26902

Run those once. Step 5 has a version that replaces a rule of the same name, so a rule you customized under that name is overwritten. Windows Firewall blocks inbound traffic until a rule allows it, and a network security group or router in front of the server is a separate firewall that these rules don’t open. If the server runs but players can’t join, these rules are the first check, and the group or router’s port forwarding for the same ports is the second.

The thing most likely to stop you comes before any of that. On a clean Windows Server the server exits within seconds of starting, with [EOS] Native library or one of its dependencies not found in its log, because the Visual C++ runtime isn’t installed. Step 1 installs it.

The first part of this series found the server’s app ID, and the second installed it. The install leaves a server that can’t start on a clean machine, and one that reads a config file with placeholder values. This part fixes both, and ends with the ports a player needs.

1. Install the C++ runtime

The server needs Microsoft’s Visual C++ runtime, and a clean Windows Server doesn’t have it. SteamCMD puts the installer in the server’s folder, under _CommonRedist\vcredist\2022, but nothing ran it here. The install script beside it, installscript.vdf, names a command that runs it, and the registry value that script checks, under HKLM\Software\Valve\Steam\Apps\CommonRedist\vcredist\2022, didn’t exist. The folder comes from a second app that the install fetches, Steamworks Common Redistributables, app 228980.

Run this in an elevated PowerShell on the server. It compares the registered x64 Visual C++ v14 runtime with the installer in the server’s folder. If the registered one is missing or older, it checks that Microsoft Corporation signed the installer and runs it without prompts or a restart. Then it reads the registry again to confirm the runtime is current:

$key = 'HKLM:\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\X64'
$installer = 'C:\7DaysToDieServer\_CommonRedist\vcredist\2022\VC_redist.x64.exe'
$have = Get-ItemProperty $key -ErrorAction SilentlyContinue
$registered = if ($have.Installed -eq 1) { [version]$have.Version.TrimStart('v') }
$bundled = [version](Get-Item $installer).VersionInfo.ProductVersion
if ($registered -ge $bundled) {
    'The runtime is already installed.'
}
else {
    $signature = Get-AuthenticodeSignature $installer
    $signer = $signature.SignerCertificate.GetNameInfo('SimpleName', $false)
    if ($signature.Status -ne 'Valid' -or $signer -ne 'Microsoft Corporation') {
        throw "Unexpected signature: $($signature.Status), signed by '$signer'"
    }
    $run = Start-Process $installer -ArgumentList '/install', '/quiet', '/norestart' `
        -Wait -PassThru
    "Installer exit code: $($run.ExitCode)"
    $now = Get-ItemProperty $key -ErrorAction SilentlyContinue
    $current = if ($now.Installed -eq 1) { [version]$now.Version.TrimStart('v') }
    if (-not ($current -ge $bundled)) {
        throw 'The runtime is still missing or older after the installer ran.'
    }
    if ($run.ExitCode -eq 3010) { 'The installer asks for a restart.' }
}

/install /quiet /norestart are options listed on Microsoft’s page on the redistributable packages (opens in a new tab). That page also says a package isn’t installed when a more recent version is on the machine, and returns an error, so the script compares versions first. A Status of Valid only says that some trusted publisher signed the file. That is why the script also checks the name on the certificate. The exit code was 0 here, with no restart pending. With /quiet the installer shows no error message, so the exit code and the second registry read are the only signs that it failed. An exit code of 3010 means a restart is needed.

The installer in the server’s folder is byte for byte the file Microsoft’s permalink serves. That permalink, https://aka.ms/vc14/vc_redist.x64.exe, is the one Microsoft’s list of the latest supported Visual C++ Redistributable downloads (opens in a new tab) gives for the x64 package. Download from it if your server folder has no _CommonRedist.

2. Set the server’s name, password, port and slots

The server reads serverconfig.xml in its install folder. It is a flat list of <property name="..." value="..."/> lines, each with a comment after it, and it ships with placeholder values. Don’t edit that file in place. The previous part showed app_update with validate restoring it to the shipped version, and the server takes any file name through -configfile=. Make a copy under your own name and edit the copy. This creates it beside the original:

Copy-Item C:\7DaysToDieServer\serverconfig.xml C:\7DaysToDieServer\myserver.xml

The settings to change first:

This function changes one value and leaves the rest of the file as it was:

function Set-ServerProperty {
    param(
        [Parameter(Mandatory)][string]$Path,
        [Parameter(Mandatory)][string]$Name,
        [Parameter(Mandatory)][AllowEmptyString()][string]$Value
    )

    # XML turns a line break inside an attribute into a space.
    if ($Value -match '[\r\n]') { throw "The value can't contain a line break." }

    # A property that is commented out, like UserDataFolder in the shipped
    # file, isn't a node, so a text edit would change the comment and
    # nothing else.
    $original = [IO.File]::ReadAllText($Path)
    if (-not ([xml]$original).SelectSingleNode("//property[@name='$Name']")) {
        throw "No active property named $Name in $Path."
    }

    # Replace the value in the text, so the rest of the file stays as it was.
    $pattern = '(<property\s+name="' + [regex]::Escape($Name) + '"\s+value=")[^"]*(")'
    if ([regex]::Matches($original, $pattern).Count -ne 1) {
        throw "Expected one double-quoted $Name line in $Path. Edit it by hand."
    }
    $escaped = [Security.SecurityElement]::Escape($Value)
    $text = [regex]::Replace($original, $pattern, {
        param($m) $m.Groups[1].Value + $escaped + $m.Groups[2].Value
    })
    $hasBom = [IO.File]::ReadAllBytes($Path)[0] -eq 0xEF
    [IO.File]::WriteAllText($Path, $text, [Text.UTF8Encoding]::new($hasBom))
}

Run it on a stopped server, with your own values:

$config = 'C:\7DaysToDieServer\myserver.xml'
Set-ServerProperty -Path $config -Name ServerName -Value 'Example Server'
Set-ServerProperty -Path $config -Name ServerPassword -Value '<password>'
Set-ServerProperty -Path $config -Name ServerMaxPlayerCount -Value 4

It changes one line per call and keeps the file’s line endings and its comments. -Value '' clears a value, for example to remove the password again. It stops with an error and leaves the file alone when it can’t find exactly one double-quoted line for the name, or when the value holds a line break. Saving the file through PowerShell’s [xml] type is shorter, but it rewrites the layout. The comments that trail each property move to lines of their own, and a line-by-line comparison shows about 260 changed lines for one new value.

3. Set UserDataFolder to choose where the saves go

By default the server writes its world under the profile of the account that runs it: %APPDATA%\7DaysToDie\Saves for the account that ran it here. Started as SYSTEM by a scheduled task, it wrote to C:\Windows\System32\config\systemprofile\AppData\Roaming\7DaysToDie\Saves instead. UserDataFolder sets one place whichever account starts it. The shipped file has it commented out, and so does your copy, which is why Set-ServerProperty can’t change it. Replace the comment with an active property, pointing at the install folder so that Saves sits beside your config file:

$config = 'C:\7DaysToDieServer\myserver.xml'
$find = "//property[@name='UserDataFolder']"
$text = [IO.File]::ReadAllText($config)
if (([xml]$text).SelectSingleNode($find)) {
    throw 'UserDataFolder is already set. Use Set-ServerProperty.'
}
$pattern = '<!--\s*<property name="UserDataFolder"[^>]*>\s*-->'
$active = '<property name="UserDataFolder" value="C:\7DaysToDieServer"/>'
$text = $text -replace $pattern, $active
if (-not ([xml]$text).SelectSingleNode($find)) {
    throw 'The commented UserDataFolder line from the shipped file was not found.'
}
[IO.File]::WriteAllText($config, $text)

This works on a copy of the shipped file. On a file that was edited, it stops with an error and writes nothing, either because UserDataFolder is already active or because the comment no longer matches. The server creates the folders it needs. After a first run it holds Saves, with serveradmin.xml beside the world, plus RfsCache and titlestorage. A new Navezgane world was 17.2 MB. The backup in the published S3 article looks for Saves beside the install’s config, which is where this puts it. That script archives serverconfig.xml, so change its $Config line to myserver.xml, or the archive holds the shipped settings and not yours.

4. Start the server and read its ports

This starts the server detached, with the flags a dedicated server needs, and waits for the game’s own ready message. It writes a log in the install folder and doesn’t change the config:

$dir = 'C:\7DaysToDieServer'
$log = Join-Path $dir 'output_log.txt'
if (Test-Path -LiteralPath $log) { Remove-Item -LiteralPath $log -ErrorAction Stop }
$server = Start-Process (Join-Path $dir '7DaysToDieServer.exe') -WorkingDirectory $dir `
    -PassThru -ArgumentList '-logfile', $log, '-quit', '-batchmode', '-nographics',
    '-configfile=myserver.xml', '-dedicated'
$null = $server.Handle
$ready = {
    (Test-Path $log) -and (Select-String -Path $log -Pattern 'StartGame done' -Quiet)
}
$deadline = (Get-Date).AddMinutes(5)
while (-not $server.HasExited -and -not (& $ready) -and (Get-Date) -lt $deadline) {
    Start-Sleep -Seconds 2
}
if ($server.HasExited) {
    throw "The server exited with code $($server.ExitCode). Read $log."
}
if (-not (& $ready)) { throw "The server wasn't ready after five minutes. Read $log." }

It deletes the old log first, so that a StartGame done from an earlier run can’t pass for this one. It stops if it can’t delete it, for example because an earlier server still has it open. It stops with an error if the server exits or isn’t ready after five minutes. It took about 40 seconds here. Then list every port the process listens on:

$tcp = Get-NetTCPConnection -State Listen -OwningProcess $server.Id |
    ForEach-Object { 'tcp {0}:{1}' -f $_.LocalAddress, $_.LocalPort }
$udp = Get-NetUDPEndpoint -OwningProcess $server.Id |
    ForEach-Object { 'udp {0}:{1}' -f $_.LocalAddress, $_.LocalPort }
$tcp + $udp | Sort-Object

On the default config the output was:

tcp 0.0.0.0:26900
tcp 127.0.0.1:49532
tcp 127.0.0.1:8081
udp :::26902
udp 0.0.0.0:11000
udp 0.0.0.0:26900
udp 0.0.0.0:26902
udp 0.0.0.0:57573

The game’s ports are the ones on ServerPort: TCP 26900, UDP 26900, and UDP 26902. The rest aren’t game ports:

• Telnet is on 127.0.0.1:8081, reachable only from the server itself.
• The server’s LAN announcer is on udp 0.0.0.0:11000. Its log line reads [LANMasterServerAnnouncer] listening on 11000 and multicast group 239.192.0.1.
• The high ports change on every start, and Windows chooses them.

I didn’t connect a player, so this says what the server listens on, not which of those ports a client uses. Nothing listened on UDP 26901 or 26903. The server’s own error message for a port it can’t use lists TCP and UDP on ServerPort, and UDP on ServerPort + 1 and ServerPort + 2, as the ports that must be free. The rules in step 5 open UDP 26900 to 26902 for that reason, though nothing listened on 26901.

Stop the server before you carry on. Its telnet port accepts shutdown from the server itself when no telnet password is set. The server saved its world, logged SaveAndCleanupWorld and exited with code 0 in four seconds:

$telnet = New-Object Net.Sockets.TcpClient('127.0.0.1', 8081)
$stream = $telnet.GetStream()
$bytes = [Text.Encoding]::ASCII.GetBytes("shutdown`r`n")
$stream.Write($bytes, 0, $bytes.Length)
if (-not $server.WaitForExit(90000)) {
    throw 'The server was still running after 90 seconds.'
}

The snippet throws if the server is still running after 90 seconds. It sends no password, so it works only while no telnet password is set. The next part covers stopping it from a script that falls back to other methods.

5. Open the ports in the Windows firewall

Windows Firewall blocks inbound traffic on every profile unless a rule allows it. On this server Get-NetFirewallProfile read NotConfigured for the default, which doesn’t say what applies. The active store does:

PS> Get-NetFirewallProfile -PolicyStore ActiveStore |
>     Select-Object Name, DefaultInboundAction

Name    DefaultInboundAction
----    --------------------
Domain                 Block
Private                Block
Public                 Block

This adds one TCP rule and one UDP rule, and replaces any rule that already has the same name, so a stale rule can’t block players. It changes the firewall of this machine and nothing else:

$rules = @(
    @{ Name = '7DaysToDie-26900-TCP'; Protocol = 'TCP'; Port = '26900' }
    @{ Name = '7DaysToDie-26900-UDP'; Protocol = 'UDP'; Port = '26900-26902' }
)
foreach ($rule in $rules) {
    Get-NetFirewallRule -DisplayName $rule.Name -ErrorAction SilentlyContinue |
        Remove-NetFirewallRule
    New-NetFirewallRule -DisplayName $rule.Name -Direction Inbound -Action Allow `
        -Protocol $rule.Protocol -LocalPort $rule.Port | Out-Null
}

Read them back:

PS> Get-NetFirewallRule -DisplayName '7DaysToDie-*' | ForEach-Object {
>     $port = $_ | Get-NetFirewallPortFilter
>     '{0,-22} {1} {2}  enabled={3} action={4}' -f $_.DisplayName, $port.Protocol,
>         ($port.LocalPort -join ','), $_.Enabled, $_.Action
> }

7DaysToDie-26900-TCP   TCP 26900  enabled=True action=Allow
7DaysToDie-26900-UDP   UDP 26900-26902  enabled=True action=Allow

Each rule applies on every network profile and to every source address, because nothing in the loop narrows either. If you change ServerPort, the ports move with it. With ServerPort set to 26910 the server listened on TCP 26910 and on UDP 26910 and 26912, so the rules need the new numbers.

Ports to leave closed

Don’t open 8081 or 8080 to the internet. Telnet is a way to run server commands. Without a telnet password the server listens for it on 127.0.0.1 only. With TelnetPassword set, it listened on every interface, and enabling the web dashboard with WebDashboardEnabled opened TCP 8080 on every interface too. Both are for the server’s own use, or for a rule limited with -RemoteAddress to your own address.

A firewall rule on the server doesn’t open a cloud network security group or a router. If players can’t connect with the rules above in place, those are the next places to look. I didn’t test inbound connections from outside, so this article stops at the server’s own firewall.

Common failures

Server exits seconds after starting with an EOS error

The server’s log, in the file you passed as -logfile, holds the cause. These are three lines from it, in the order they appear, without their timestamps:

Plugins: Failed to load 'C:/7DaysToDieServer/7DaysToDieServer_Data/Plugins\x86_64/BacktraceCrashpadWindows.dll' because one or more of its dependencies could not be loaded.
ERR [EOS] Native library or one of its dependencies not found (e.g. no Microsoft Visual C Redistributables 2022)
InvalidOperationException: GamePrefs is being accessed before it is ready.

The process exited with code 0 and listened on no port. I reproduced it by uninstalling the runtime, and the server started again once step 1 reinstalled it. vcruntime140.dll and msvcp140.dll were missing from System32. SteamCMD had put the installer in _CommonRedist but not run it. The log also holds ERROR: Shader ... not supported on this GPU lines. A server with no GPU prints them on a healthy start too, so they aren’t the cause. Search the log for EOS.

Server exits seconds after starting with an invalid port

ERR NET: Starting server protocols failed: Invalid ServerPort 65534, must be within 1024 and 65530
ERR Make sure all required ports are unused: 65534/TCP, 65534/UDP, 65535/UDP, 65536/UDP

ServerPort must be from 1024 to 65530. With 65534, and with 1000, the server exited after about ten seconds with code 0, and 65530 started normally. The second line is the server’s own list of the ports it needs free: ServerPort for TCP and UDP, then UDP on the next two.

Set-ServerProperty says No active property named

No active property named UserDataFolder in C:\7DaysToDieServer\myserver.xml.

Either the name is misspelled, or the property is commented out, as UserDataFolder is in the shipped file. Use the replacement in step 3 for a commented-out property. If the line uses single quotes, or the name appears twice, it stops with Expected one double-quoted <name> line and doesn’t write.

Two rules with the same name

New-NetFirewallRule doesn’t refuse a name that exists. Running it twice made two rules named the same, which is why step 5 removes a rule of that name before it adds one. To remove the extra rules and start again:

Get-NetFirewallRule -DisplayName '7DaysToDie-*' | Remove-NetFirewallRule

TL;DR

$LASTEXITCODE is not the success status of the last PowerShell cmdlet. Use it for a native executable such as aws.exe, and capture it immediately:

aws --version
$Code = $LASTEXITCODE
if ($Code -ne 0) { throw "AWS CLI exited with code $Code" }

For a cmdlet, use PowerShell error handling:

Get-Item -LiteralPath 'C:\Data\settings.json' -ErrorAction Stop

-ErrorAction Stop turns a cmdlet’s non-terminating error into a terminating one, which stops the script or reaches an enclosing catch.

While working on a backup script for my 7 Days to Die game server, I thought it would be good to share this.

You replace an AWS CLI command with a PowerShell cmdlet and keep the success check. The cmdlet prints an error. The script announces success anyway.

The check still runs. It’s reading the result of a different operation.

Reproduce a failed command with exit code zero

Run this in PowerShell on Windows:

cmd.exe /d /c exit 0
Write-Error 'Demonstration: the upload failed' -ErrorAction Continue
"Native exit code: $LASTEXITCODE"

The error appears, followed by:

Native exit code: 0

The zero came from cmd.exe. Write-Error did not update it. The explicit Continue makes this demonstration non-terminating even if your session normally uses a stricter error preference.

The reverse is just as misleading:

cmd.exe /d /c exit 7
Get-Date | Out-Null
"Native exit code: $LASTEXITCODE"

This prints 7 even though Get-Date succeeded. These examples illustrate why a value left in the variable is not evidence about a later cmdlet.

Microsoft defines the variable for native programs and PowerShell scripts; script behavior also depends on invocation and the exit keyword. Ordinary cmdlet success or failure does not make it a universal status register. See about_Automatic_Variables (opens in a new tab).

For native commands, check each result at the boundary

This example assumes AWS CLI is installed, the source exists, and the active AWS identity can access your chosen bucket:

$Source = 'C:\Data\exports'
$Destination = 's3://YOUR-BUCKET/exports/'

$null = Get-Command aws -CommandType Application -ErrorAction Stop
aws s3 sync $Source $Destination
$Code = $LASTEXITCODE

if ($Code -ne 0) {
    throw "S3 sync did not complete cleanly; AWS CLI exit code $Code"
}

'Export transfer completed'

Replace YOUR-BUCKET before running it. AWS documents nonzero outcomes including failed S3 transfers and skipped files. A skipped file is enough to reject a backup run as incomplete; inspect the command output for the cause. See the AWS CLI return-code reference (opens in a new tab).

Capture and handle each result before moving on.

Also distinguish a process failure from a launch failure. If aws is not found, no AWS CLI process returned an exit code, and the check reads whatever an earlier native command left. The Get-Command line stops the script before that can happen.

Why try/catch sometimes misses a cmdlet error

PowerShell can report an error while continuing execution. For example:

try {
    Write-Error 'Demonstration failure' -ErrorAction Continue
    'Still inside try'
}
catch {
    'Caught the error'
}

The error is displayed and Still inside try prints. The catch block isn’t entered. Change that one invocation to -ErrorAction Stop and the catch block runs instead.

Some errors already terminate execution; they don’t need this promotion. -ErrorAction Stop makes the intended behavior explicit for cmdlet errors that would otherwise continue. Microsoft’s try/catch documentation (opens in a new tab) explains which errors those blocks handle.

Catch a Write-S3Object failure with -ErrorAction Stop

With AWS.Tools.S3 installed and AWS access configured, use this for an intentional upload of one existing file:

Import-Module AWS.Tools.S3 -ErrorAction Stop

try {
    Write-S3Object -BucketName 'YOUR-BUCKET' `
        -File 'C:\Data\exports\report.json' `
        -Key 'exports/report.json' `
        -ErrorAction Stop

    'Upload completed'
}
catch {
    Write-Warning ("Upload failed: {0}" -f $_.Exception.Message)
    throw
}

The success message is reachable only after the upload returns normally. The bare throw propagates the caught error to the caller. Logging and then continuing would hide the failure from whatever invoked the script.

If you have no context to add and no recovery to attempt, remove the try/catch and keep -ErrorAction Stop. A catch block that only rethrows isn’t required.

$PSNativeCommandUseErrorActionPreference in PowerShell 7

PowerShell 7.4 added $PSNativeCommandUseErrorActionPreference. When it’s $true, nonzero native exit codes produce PowerShell errors governed by $ErrorActionPreference; with Stop, those can reach catch. The default is $false. Microsoft documents it in about_Preference_Variables (opens in a new tab).

That doesn’t make -ErrorAction Stop a parameter for aws.exe. Passed to a native program, it’s an argument for that program to interpret. Explicit exit-code checks remain useful for scripts spanning Windows PowerShell 5.1 and PowerShell 7, and for tools whose nonzero codes have special meanings.

If native error promotion is enabled with Stop, execution can leave the native invocation before the following explicit check. Either path must preserve the failure; don’t catch it and then print success.

Common failures

LASTEXITCODE is empty or stale. There may be no relevant native result in the session. Choose the error mechanism for the operation you actually ran.

Can I replace it with $? everywhere? $? describes the last command’s execution status and is overwritten by the next command. It isn’t a durable record of a multi-step job. Structured error handling is clearer for cmdlets.

The task still reports success. Check whether a wrapper catches and suppresses the error, then exits normally. At the outer script boundary, preserve a failure through an unhandled terminating error or an intentional nonzero exit code.

A script needs to remember whether the work succeeded. That starts by listening to the failure signal the command actually provides.

TL;DR

A batch label does not create a function body that cmd.exe skips. Execution runs straight through the label unless you redirect it.

Put the main work first, end it with exit /b, and place subroutines below it:

@echo off
setlocal EnableExtensions
call :timestamp
echo [%stamp%] Work starts here
exit /b 0

:timestamp
set "stamp=%DATE% %TIME%"
goto :eof

call :timestamp creates a return point. goto :eof returns from that call. Reached in the main batch context, it ends the batch instead.

You add a timestamp helper to a working batch file. The helper looks reasonable. The next run prints almost nothing, and the real work never starts.

It’s tempting to debug the timestamp expression. First check whether the script ever reaches the line that calls it.

Minimal reproduction: the call never happens

Save this as fall-through.cmd:

@echo off
echo Starting script

:timestamp
echo Inside timestamp
set "stamp=%DATE% %TIME%"
goto :eof

call :timestamp
echo [%stamp%] Doing the work

Run it from an existing Command Prompt so the output stays visible:

C:\scripts> cmd /d /e:on /c fall-through.cmd
Starting script
Inside timestamp

C:\scripts>

That output is the clue: the helper ran even though the call below it was never reached. Execution arrived there by reading downward.

A label marks a location. It doesn’t surround or hide the commands beneath it. The goto :eof then ends the current batch context, so both remaining lines are unreachable on this path. Microsoft’s goto reference (opens in a new tab) documents the special end-of-file target; you don’t need to define an :eof label.

End the main path with exit /b before the subroutines

Here is the complete repaired example:

@echo off
setlocal EnableExtensions

echo Starting script
call :timestamp
echo [%stamp%] Doing the work
exit /b 0

:timestamp
echo Inside timestamp
set "stamp=%DATE% %TIME%"
goto :eof