Service installation has queued backups until user logs in interactively

Hi there, first time poster here.

I am running 2.1.1.0_experimental_2025-07-17. I have Duplicati installed as a server service following the instructions here Migrating from User to Service install on Windows . I use Duplicati.CommandLine.ServerUtil.exe with the –wait param to run the backups via Windows Task Scheduler, running with elevated credentials (though as I understand it, since Duplicati is installed as a service it should not need this). My databases are in C:\ProgramData\Duplicati\Data which System has full access to.

I did originally have an issue with the 15 minute access token expiring but @kenkendk got me straightened away with a workaround fix (ServerUtil --wait fails after 15 minutes · Issue #5904 · duplicati/duplicati · GitHub).

ISSUE: Backups have been working fine until 3 days ago Wed 8/15, which may correlate with the Windows 11 patch being installed. Now, it seems each day that my scheduled backups are queued until I physically log into Windows, at which point the job immediately starts running (evidenced by the output log that looks like this:

[8/15/2025 9:19:32 AM]: Backup is queued ...
[8/15/2025 9:19:37 AM]: Backup is queued ...
[8/15/2025 9:19:42 AM]: Backup is queued ...
[8/15/2025 9:19:47 AM]: Backup is running ...
[8/15/2025 9:19:52 AM]: Backup is running ...
[8/15/2025 9:19:57 AM]: Backup is running ...

the Duplicati Service is set to automatic and Logs in as Local System Account, however “Allow service to interact with desktop” is unchecked (I would not have explicitly changed this setting).

I prefer to run the backups via Task Scheduler and powershell script that would bring my PC out of sleep, sit at the login screen, and run the backups, then put the PC back to sleep. I use Task Scheduler and ServerUtil.exe vs the build-in Duplicati scheduler because I run post-backup rclone and prefer this to running a post-backup script (which last I checked runs whenever you do any Duplicati activities such as listing files).

This morning the backup worked fine. I had changed the Task Scheduler task to “Run whether user is logged on or not” (wasn’t set like this previously), provided my login password and now it works again. Will continue to monitor for a few days.

oddly, this morning it did it again today, whole backup was waiting for an interactive login before it would start. I’m not sure now what the pattern is as there was no Windows patch this time.

There are a number of points there that could leave some status when they are reached. Task Scheduler, for example, has some default data and a button (at right) to get events:

PowerShell can presumably log whatever you want to code into the script, but to avoid having to wait for another failure, looking at Task Manager history now might be helpful.

sounded good until it didn’t:

On next failure you could test login to different account (preferably one that is an admin because you might want to elevate) to look over the status of software that awaits login.

The trick is knowing in advance whether it’s stuck. Did you set any backup notifications? Possibly clue is obvious, where system has woken up and is sitting without progressing.

For example, right-click Properties on ServerUtil shows access time, Task Manager has process information where you can assume it’s the recent run, or look with a better tool.

Watching interaction between ServerUtil and Server is harder. One method is to use the other account as elevated admin to run Sysinternals Process Monitor to monitor Server.

Wireshark on loopback interface port 8200 would work too, but is best with network skill.