Scheduled Task not working on new server

Gpg4win help-en
1

I’m new to this forum, so I’m sorry if I’m not posting this in the right place, but I’ve come across a problem I’ve been googling for a few days with no success.

We are migrating to new servers and I’m charged with the task of moving over a scheduled task that runs a batch decryption of pgp files once per night for processing. A batch script loops through a folder finding all files named .pgp or .gpg and performs this action:

gpg --passphrase-fd 0 --batch -o …%%~nxa%%~nF -d %%F <passwordfile.txt >> pgp_results_%yyyy%-%mm%-%dd%.txt 2>&1

The passphrase is stored in a text file in the same directory as the .bat script. (I know that’s bad practice; I’m just trying to get this to work.)

I’ve got the scheduled task set up using a service account. That account is an Administrator.

When I run the task on command, it works fine. When I let the task run at a scheduled time WHILE I’M LOGGED IN as that service account user, it works fine. When I schedule the task to run and then log off the box, the task still runs (because I’ve selected the radio button in Task Scheduler to Run whether user is logged in or not), but I get this result as the output of the above statement:

gpg: decryption failed: No secret key

I’m out of ideas. The new Windows server is 2012 R2. This process has been working with no issues for a while on our old server which is 2008 R2. I haven’t been able to find anything else that’s different with the setup between the two boxes.

Any suggestions or ideas would be greatly appreciated. Thanks!

2

Gpg4win version on old server is 2.1.0. On new server it is 2.2.1.

3

Just ideas:

  • To get more output you could try to use “-v” or “-vvv” or “–debug-all”.
  • Maybe there is a subtle security permission issue between the window server versions that changes something when you are logged in compared to when you are logged out.
  • You could try seeing if gpg-agent works and to preload the passphrase.
4

You could try something like gpg --list-secret-keys > foo.txt
to see if when this command is run by the scheduler in a service account it really has that key available.

Maybe you need to set --homedir in your command to point gnupg to the correct home directory with the secret key. I am not sure to which directory %APPDATA% expands for a scheduled service and weather this changed with windows server 2012. But this might be the problem.