Best Group or Permissions for Domain User to run Scheduled Task

I need to run a Scheduled Task as a domain user. For the sake of explanation, let's just say: DOMAIN/Scheduled_Tasks is the user.

I've created the Scheduled Task in question (just a simple, local Powershell script) and when this user (DOMAIN/Scheduled_Tasks) is in the local Administrator group, the Task runs as expected.

When I remove the user out of the local Administrator Group, the task bombs with:

Task Scheduler failed to start "***" task for user "DOMAIN\scheduled_tasks". Additional Data: Error Value: 2147942667.

Open in new window

Using local security policy, I've added this user to:

Security Settings -> Local Settings -> User Rights Assignment -> Allow Log On Locally
Security Settings -> Local Settings -> User Rights Assignment -> Log On As A Batch Job
Security Settings -> Local Settings -> User Rights Assignment -> Log On As A Service

What are some options here to get DOMAIN/Scheduled_Tasks to run a Task without adding that user to the Administrator Group?

TessandoIT AdministratorAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Patrick BogersDatacenter platform engineer LindowsCommented:

Does the schedule need elevated rights to run?
Login as that user and run the code in powershell, PS Will tell you what is wrong.

TessandoIT AdministratorAuthor Commented:
Thank you, Patrick. I logged in as DOMAIN/Scheduled_Tasks user and am able to run the Script itself, however the Scheduled Task fails with the same error code as I described.

Thanks for the suggestion.
You need to describe how you created the task. I assume you used GP preferences. It will be no problem to create a task to run only when that user is logged on (that is a task option - "run only when user is logged on". So is that user ever logged on, or is it a separate user that does not log on (if so: why use a separate user?)?
Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

Shaun VermaakTechnical SpecialistCommented:
Can you post the Powershell?
TessandoIT AdministratorAuthor Commented:
Yes, McKnife - I left out some important details:

  • Run whether user is logged in or not
  • Run with highest privileges
  • Configure for Windows Server 2016

Of course, I successfully enter in the password for DOMAIN/Scheduled_Tasks

When I created this, I was logged in as my own (Domain Administrative) account. And, like I mentioned before, this works when DOMAIN/Scheduled_Tasks is in the local administrative group.  

"run with highest privileges" -? Why would you need that and how should that work if the user is no admin?
TessandoIT AdministratorAuthor Commented:
Per Shaun's suggestion, here's the Powershell script. It's just an example, I have many different .NET applications I need to setup using this DOMAIN/Scheduled_Tasks user so this is just a test:

Send-MailMessage -SMTPServer localhost -Port 587 -To -From -Subject "Paneer Test Mail" -Body "This is a test mail sent from SERVER at $((Get-Date).ToString())"

Open in new window

This script in all other contexts.

Patrick BogersDatacenter platform engineer LindowsCommented:
Hi again,

If the user can run the script but the task scheduler is not i get the feeling the job is not correct.
Did you define in the task where it should execute?
Shaun VermaakTechnical SpecialistCommented:
What do you have in command and argument?
David Johnson, CD, MVPRetiredCommented:
remove Run with highest privileges if it is a standard user
TessandoIT AdministratorAuthor Commented:
Here is the action:

Action to run the Powershell script
Many of the errors related to Error Value: 2147942667 have to do with quotes. I've seemed to isolate this to being permissions related. Once that DOMAIN/Scheduled_Tasks user is out of the local Administrator group, this doesn't work and gives an error.
Shaun VermaakTechnical SpecialistCommented:
Remove startup folder and move ps1
File to command with a -file. End result should be only command
Look, the case is clear already:

If the user has no additional privileges, the checkbox "run with highest privileges" is useless. But nevertheless, that is not the problem.
The problem rather seems to be that the "logon as batch job" privileges was set, but did not apply yet or was overridden by another (domain) GPO. Are you able to verify that? Can be done fast using rsop.msc
Patrick BogersDatacenter platform engineer LindowsCommented:

I would try several thing, create a folder e.g. C:\scripts and copy the ps1 file here.
Modify the job and try again.

Still not working i would change the argument to
-ExecutionPolicy Bypass -File C:\Users\blablabla\scheduled-task.ps1

And try again
TessandoIT AdministratorAuthor Commented:
Per McKnife:

I've removed "run with highest privileges".

When I run the rsop.msc with a query for the user (DOMAIN/Scheduled_Tasks) it does show "Log on as Batch Job" as being undefined, so I think that you are correct that it didn't automatically propagate. Here's what I see:

Is this fixable?

Thank you for all your great suggestions.
Tom CieslikIT EngineerCommented:
Did you try add user to local POWER USERS group ?
TessandoIT AdministratorAuthor Commented:
Hey Tom - Yes, I did add that user into the local Power Users group and got the same results. Thanks!
Tom CieslikIT EngineerCommented:
When you open additional task properties you should see option to run task as a different user.
Just put domain admin as task owner

Did you try that ?
TessandoIT AdministratorAuthor Commented:
Thank Tom. Yes, I do see that. And this particular Scheduled Task runs successfully as both a Domain Administrator and as a Local Administrator. This issue, and why I believe it's permissions related, is that my user of DOMAIN/Scheduled_Tasks was in the local administrator group it ran the Scheduled Task successfully but upon removing that user from the local group, the Scheduled Task fails.

Thanks for confirming that.
Tom CieslikIT EngineerCommented:
I understand but why you preventing yourself from running task as different user ?
This will not compromise your security
Power users are deprecated since 10 years. No effect whatsoever.
Running tasks as administrator cannot be compromised unless you choose a task action (=script) in a user writable location.

Tessandro, please open secpol.msc again and verify if that policy (logon as batch job) is set.
If so, open an elevated command prompt (right click cmd.exe, select "run as administrator") and launch

Open in new window

Afterwards, on the same command prompt, launch
gpresult /h %temp%\res.html /f & %temp%\res.html

Open in new window

and look at the output - did it apply?
TessandoIT AdministratorAuthor Commented:
Here's the properties of Log On As Batch Job, showing the domain user of Scheduled_Tasks:

I did so both "gpupdate" and "gpresult", with the result being successful. In the res.html page that came up I don' t see a distinct area where "Log On As Batch Job" was changed. Here's where it showed successful:

Thanks again.
Before further analysis: be so kind and answer the question of my first comment:
is it a separate user that does not log on (if so: why use a separate user)?
TessandoIT AdministratorAuthor Commented:
Ah, sorry McKnife, I missed that one. Yes, this is a separate user that does not log on to the machine via RDP and such. This is a business requirement by DevOps.

It also occurred to me that you might be talking about doing the "gpupdate" as the user itself (DOMAIN/Scheduled_Tasks) so I went ahead and did that as well.

When I look at the results I can neither confirm or deny that anything changed for Log On As Batch Job, but the gpupdate was indeed successful.

Ok. Do me a favor and create another task (manually):
action: notepad
executor: your DOMAIN/Scheduled_Tasks
trigger: once: (one minute in the future from creation)
option "run with highest privileges" unchecked

Then wait that minute and afterwards look at task history - succeeded?
TessandoIT AdministratorAuthor Commented:
Thank you, McKnife - It succeeded in that it started (and is currently running). In this case I constructed this while logged in as DOMAIN/Scheduled_tasks user. Does that make a difference?

That does not make a diff, no.
Please substitute notepad for that pshell command, now.
TessandoIT AdministratorAuthor Commented:
It failed almost immediately with the same results as before:

Task Scheduler failed to launch action "powershell.exe" in instance "{c240bc73-a583-4514-b71a-43d081369bd0}" of task "\testnotepad". Additional Data: Error Value: 2147942667.

Open in new window

Task Scheduler failed to start "\testnotepad" task for user "DOMAIN\scheduled_tasks". Additional Data: Error Value: 2147942667.

Open in new window

Would it make sense to re-add the Scheduled Task user to "Log On As Batch" locally or would that just muck things up?
Re-add? Why, the screenshot shows it's still there. You cannot add it twice and that's unnecessary.
So it's about the task action, after all.

It's quite simply a syntax error:
Instead of that sendmail... make it:
powershell.exe Send-MailMessage -SMTPServer localhost -Port 587 -To -From -Subject "Paneer Test Mail" -Body "This is a test mail sent from SERVER at $((Get-Date).ToString())"
TessandoIT AdministratorAuthor Commented:
Okay, I replaced the Action with your script above.

I then re-ran the Scheduled Task and got the same error. However, from my Administrator login (via RDP) I got a different error this time, in the form of a pop-up inside windows:

So, while it's equally as vague, it's something different but still aligning with Permission being the core issue.
You make this thing much bigger than it is. I can run the same task without errors with an executing account (non-admin) that has been  assigned "log on as batch job" - so you can definitely do the same.

(Anybody can do this: start task scheduler as admin, create a task with that action "powershell.exe send-mailmessage..." and a defined executor B that is also a weak user but has the privilege to logon as batch job. Start that task manually and it runs. Trigger it at some point in time and it runs)

To make progress, please logon as that scheduler user open an elevated command line (right click, run as administrator) and launch
whoami /all
and you'll see if that user really has the privilege "SeBatchLogonRight" which is needed.
TessandoIT AdministratorAuthor Commented:
Thanks McKnife - I did that, logging into the machine as DOMAIN/Scheduled_Tasks and did 'whoami /all' from an elevated command prompt and do not see "Log On As Batch" listed. Here's what I get -> Logged in as DOMAIN/Scheduled_Tasks:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\System32>whoami /all


User Name                SID
======================== ============================================
********\scheduled_tasks S-1-5-21-515580095-2840579698-675601723-1108


Group Name                             Type             SID                                          Attributes         
====================================== ================ ============================================ ==================================================
Everyone                               Well-known group S-1-1-0                                      Mandatory group, Enabled by default, Enabled group
BUILTIN\Power Users                    Alias            S-1-5-32-547                                 Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Desktop Users           Alias            S-1-5-32-555                                 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                          Alias            S-1-5-32-545                                 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON  Well-known group S-1-5-14                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\INTERACTIVE               Well-known group S-1-5-4                                      Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users       Well-known group S-1-5-11                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization         Well-known group S-1-5-15                                     Mandatory group, Enabled by default, Enabled group
LOCAL                                  Well-known group S-1-2-0                                      Mandatory group, Enabled by default, Enabled group
********\AMA_Reporting_Admin           Group            S-1-5-21-515580095-2840579698-675601723-1166 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label            S-1-16-8192                                                     


Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled


User claims unknown.

Kerberos support for Dynamic Access Control on this device has been disabled.


Open in new window

So, I then created a new user (DOMAIN/Task_Scheduler), soup-to-nuts and re-created the Scheduled Task. I had it launch a few minutes into the future and I'm still getting the same error. Sorry, but this isn't working as expected for me. Could this be something different in Windows Server 2016?
Just work on giving him that privilege. No difference on 2016, at least not in theory.
Will reproduce this on 2016 as soon as I find the time.

Others, please reproduce this, too.
TessandoIT AdministratorAuthor Commented:
Thanks McKnife for your quick response. When you say to give that user privilege are you referring to just putting that user into the Log On As Batch local security policy? Here's where I put it:

Otherwise are there any other locations where this user needs to be (e.g. "Log On As Service", etc).

You did it right, no doubt. No idea why whoami does not list it. Confirm with an admin account that the privilege is there on an elevated command prompt in order to rule out that whoami is buggy.
Ok, it looks as though whoami /all is a little buggy after all. It doesn't list all privileges but only some.
Please download accesscheck from here and execute the following on an elevated command line:
accesschk.exe -q -a SeBatchLogonRight

Open in new window

That will list all users and groups that have this privilege.
TessandoIT AdministratorAuthor Commented:
Here's the results, with the user showing as in that Security Policy:

C:\Users\me\Desktop\AccessChk>accesschk.exe -q -a SeBatchLogonRight

Accesschk v6.10 - Reports effective permissions for securable objects
Copyright (C) 2006-2016 Mark Russinovich
Sysinternals -

        BUILTIN\Performance Log Users
        BUILTIN\Backup Operators


Open in new window

The user that I'd like to use is DOMAIN\scheduled_tasks. Thanks!
Ok, fine, the user has the needed privilege. I have no idea what gpresult and rsop are doing wrong, but I could even reproduce this: entitle a user to that privilege using a GPO - those two don't list the priv entitlement in their results -  that has to be another bug.
Could you please export that task and upload the xml file? (Please note, your password will not be exposed that way).
TessandoIT AdministratorAuthor Commented:
Thank you McKnife. Below is the export of the Scheduled Task:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="">
    <Description>Test scheduled task</Description>
    <URI>\Amazon\Test Scheduled Task</URI>
    <Principal id="Author">
  <Actions Context="Author">

Open in new window

Thanks again!
Shaun VermaakTechnical SpecialistCommented:
Still recommend that you change this...

Open in new window

      <Command>Powershell.exe -file "C:\Users\me\Desktop\scheduled-task.ps1"</Command>

Open in new window

Let me guess: the path "C:\Users\me\Desktop" is not accessible by your taskuser. That would be the reason for your error code (if you make him admin, of course it is accessible).
It all works here, if I make that path accessible.
TessandoIT AdministratorAuthor Commented:
Great guess, thanks McKnife. I changed the permission on the actual Powershell file for DOMAIN/Scheduled_Tasks from "Modify" to "Full Control" and unfortunately I got the same error. Thanks for the suggestion.
On the file alone won't do. Move it to another folder that is accessible by all.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
TessandoIT AdministratorAuthor Commented:
Thank you for your help and for hanging in there with me. I moved the Powershell script in question to the D: drive of the server in question and specifically assigned DOMAIN/Scheduled_Tasks "Modify" permissions. The script instantly ran successfully. Thanks again!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.