Batch Files, Task Scheduler and PSTools – and a EULA?

Here’s an odd issue that one of our Support Engineers ran into with a customer recently that I thought would be interesting to share.  Systems Administrators use scheduled tasks to run batch files as a normal part of their job.  In this specific instance, our customer was using the PsService and PsTools utilities to perform some service queries on different servers.  The problem that he was running into was that the task never executed the query when run from Task Scheduler, but they ran fine when executed manually.

In these instances, the immediate assumption is that the problem must be due to permissions.  However, in this instance, the task was running in the context of a service account with administrative privileges.  Thus, the immediate culprit was ruled out.  When reproducing the problem, we noticed that when we ran the batch file manually that both PsService and PsTools have a EULA that has to be accepted before the tool(s) will execute:



The service account currently had no way to “click” the Agree button to allow the task to process.  However, all was not lost.  There were a couple of workarounds that we could use to get past this …

Workaround 1: Via the registry – using the REG ADD command in the custom script to ensure that the EULA was flagged as being accepted.  Below are the registry entries:


By using the REG ADD command, the entries are added for whichever user or service account runs the script on the fly.  However, this is a little inelegant – leading us to …

Workaround 2: Use the –accepteula switch when running the tools so that the EULA acceptance is not displayed when the script is launched via Task Scheduler.

As a cautionary note, this method may not work for every tool (SysInternal or otherwise).  Some tools may require both the registry entry and the –accepteula switch, some may not accept the switch at all.  Running the tool with the -? or –help switch from the command line will indicate which switches are understood by the tool  And, as always, we strongly encourage you to perform testing in a non-production environment.

And with that, we’ve come to the end of another post.  Until next time …

CC Hameed

Share this post :