Log on as a batch job

Question

Log on as a batch job

Hram Admin 170

Hello!

Consider the following situation: there's the Windows Server 2022 domain with ~10 servers with OS = Windows Server 2022; the domain account named ~ task is created to run scheduled tasks on all servers, this account is assigned the Log on as a batch job user right by means of the GPO that applies to the OU with the ~10 servers.

The result: this configuration has been working flawlessly for the last ~8 months except for the one server: after rebuilding the server (in fact that was just OS reinstalling and joining to the domain) it keeps "thinking" the task account does not have the Log on as a batch job user right, although the policy does get applied correctly:

???

Thank you in advance,
Michael Firsov

3 answers

Your answer

Answer 1

MotoX80 36,291

Given that your other servers are working, the most obvious reason would be that the computer account for the server isn't in the OU that you think it is, or that group policy isn't being applied for some reason.

You might want to start by running gpresult.exe from a command prompt and see if it matches the RSOP report in mmc. You should see the policy name listed as being applied. If not, try running "gpupdate /force". The OU should also be listed.

https://woshub.com/diagnose-group-policies-issues-with-gpresult/

Use a different tool like access check to see if it sees the right being granted.

https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk

accesschk.exe -a SeBatchLogonRight

One thing that I noticed in your images was that the user name is just listed as "task". (Right below the "When running the task" text.) I no longer have access to an AD environment, but I would have expected that to indicate "YourDomain\task". Does this server have a local account named task?

Hram Admin 170 Reputation points

2025-05-29T09:03:48.2666667+00:00
MotoX80, thank you very much for the very usefull documentation!

1 All server computer accounts are in the same OU

2 The single GPO (Task_Account) that assigns the SeBatchLogonRight user right to the domain\task account is applied to that OU and it does get successfully applied to the faulty server as well

3 "One thing that I noticed in your images was that the user name is just listed as "task". (Right below the "When running the task" text.) I no longer have access to an AD environment, but I would have expected that to indicate "YourDomain\task"." - so would I: I don't know why but Task Scheduler does really cuts off the domain name portion of the username (domain\task) after selecting the account (the domain account!) in the Change user or group window:

in any case this is exactly the same on all servers so I don't expect any issues here...

5 accesschk.exe -a SeBatchLogonRight

...no more ideas :(((

And this server did not experience such problem before the OS reinstallation!!!

Answer 2

MotoX80 36,291

Any accounts in "Deny batch logon" setting?

Any related events in the Security event log? You may need to tweak your audit policy to capture failure events.

Hram Admin 170 Reputation points

2025-06-02T08:22:51.41+00:00

Any accounts in "Deny batch logon" setting? - yes, there are several accounts with "Deny..." but they are completely different accounts, and I don't see any events that could be of any help ... :(
MotoX80 36,291 Reputation points

2025-06-02T16:38:37.4566667+00:00
I have no idea.

Open local security policy and add that account to "logon as a service".

Then run accesschk.exe and see if that account is listed under both rights. Also see if you can launch cmd.exe with that account.

accesschk.exe -nobanner -a SeBatchLogonRight accesschk.exe -nobanner -a SeServiceLogonRight runas.exe /user:YourDomain\task cmd.exe

Update: I had another thought, and I see that you have "run with highest privilege" checked. Is that account a member of the Administrators group. Try unchecking that.

Also try unchecking the "do not store password" option.
Hram Admin 170 Reputation points

2025-06-03T07:26:14.17+00:00

Any accounts in "Deny batch logon" setting? - yes, there are several accounts with "Deny..." but they are completely different accounts, and I don't see any events that could be of any help ... :(
MotoX80 36,291 Reputation points

2025-06-03T11:18:11.4233333+00:00

You already commented with this same text yesterday. Did you see my reply?
Hram Admin 170 Reputation points

2025-06-05T09:22:49.48+00:00

oh, sorry, my page hangs a couple of times... I'll check and post back later - thanks you once again!
Hram Admin 170 Reputation points

2025-06-06T07:56:54.74+00:00

Update: I had another thought, and I see that you have "run with highest privilege" checked. Is that account a member of the Administrators group. Try unchecking that. - no change

Also try unchecking the "do not store password" option. - no change,

"accesschk.exe -nobanner -a SeBatchLogonRight accesschk.exe -nobanner -a SeServiceLogonRight runas.exe /user:YourDomain\task cmd.exe" - can't do it since the only way the task account can be used is as an account for a scheduled job: all other uses (logon as a service, local logon ... are prohibited for this account).

...will try to gather addition information...
MotoX80 36,291 Reputation points

2025-06-06T12:23:44.4266667+00:00
If you've added that account to the "deny local logon" right in your Group Policy, then that's still a valid test.

runas.exe /user:YourDomain\task cmd.exe

You should then get this error message. That will tell you that Group Policy is being correctly applied and your account is being correctly restricted by it.
Hram Admin 170 Reputation points

2025-06-11T07:19:49.83+00:00

...absolutely correctly applied:

The main problem is that I don't see ANY problems in those GPOs ... mind blowing :(((
MotoX80 36,291 Reputation points

2025-06-11T20:02:35.9233333+00:00

I still have no idea.

Are you sure that you are typing in the correct domain name?

Have you rebooted recently?

Do all your servers have the same Windows update patches applied?

Try a different account.

Move the server to a different OU. Add a different policy.

Build a new VM with the same OS level and see if it too has the same problem.

Find a coworker and sit him down next to you and show him everything that you are doing. Show him the group policy. Show him the user and what groups it belongs to and any logon restrictions. There has to be something.
Hram Admin 170 Reputation points

2025-06-18T07:36:02.8833333+00:00

MotoX80, thank you for you suggestions - in progress :)
Hram Admin 170 Reputation points

2025-06-19T10:56:35.2733333+00:00

Uptades = ok

Build a new VM with the same OS level and see if it too has the same problem. - did it: the new VM with WinServer2022, the same OU, the same policies applied - works perfect (task account does have the right to logon as a batch job).

Will keep investigating...
MotoX80 36,291 Reputation points

2025-06-19T12:00:20.7166667+00:00

Well, that's special.

I had more thoughts....

Delete that scheduled task and recreate it. Or define a second task and see if that has the same issue. (To see if the problem is with the task.)

Move the server's computer account to another OU, one where that policy isn't applied. Run gpupdate and gpresult to verify that the policy isn't applied. Run accesschk to verify that your account is not listed in logon as batch.

Then use the local security policy tool to add that account to logon as batch. Run accesschk to verify that the account has the right. Then update the scheduled task with that account. See if you can run the task. (To see if the problem is with the policy.)

If you can run the task, then move the server's computer account back to original OU. Run gpupdate and gpresult to verify that the policy gets re-applied. Run accesschk to verify that your account is still listed in logon as batch. Run the task and see what happens.

Answer 3

Dear Team,

Based on the rsop.msc result you've provided, the GPO named Account_Task is correctly applying the "Log on as a batch job" right to the ~task account. When this happens, but the permission still doesn't work, the cause is almost always a conflicting "Deny" policy.

Here is the straight answer for how to fix this:

The most likely problem is that the ~task account, or a group it belongs to, is being explicitly forbidden this right by the "Deny log on as a batch job" policy, which always overrides the "Allow" policy.

Follow these steps on the problematic server to resolve the issue:

Step 1: Check the "Deny" Policy

Open the Local Security Policy editor by running secpol.msc.

Navigate to Local Policies > User Rights Assignment.

Find and double-click the policy named "Deny log on as a batch job".

Examine the list of users and groups. If you see the ~task account or a group it is a member of (like Domain Users or Authenticated Users), that is the source of your problem.

Step 2: Fix the "Deny" Policy

If you find an entry: The best practice is to not edit the local policy directly. Instead, find which GPO is applying this "Deny" setting.

Run rsop.msc again, just as you did before.

  Look at the "Deny log on as a batch job" policy in the list and check its __Source GPO__.
  
     Edit that GPO in the __Group Policy Management Console__ on your domain controller to remove the conflicting account or group.

Step 3: Force Policy Update and Reboot

After you have removed the conflict from the GPO, run the following commands in an elevated Command Prompt on the problematic server to ensure the changes take effect immediately:

Bash

gpupdate /force
shutdown /r /t 0

A reboot is often necessary for user rights assignments to be fully updated and recognized by the system. After the server reboots, the Task Scheduler will recognize the permission correctly.Based on the rsop.msc result you've provided, the GPO named Account_Task is correctly applying the "Log on as a batch job" right to the ~task account. When this happens, but the permission still doesn't work, the cause is almost always a conflicting "Deny" policy.

Here is the straight answer for how to fix this:

The most likely problem is that the ~task account, or a group it belongs to, is being explicitly forbidden this right by the "Deny log on as a batch job" policy, which always overrides the "Allow" policy.

Follow these steps on the problematic server to resolve the issue:

Step 1: Check the "Deny" Policy

Open the Local Security Policy editor by running secpol.msc.

Navigate to Local Policies > User Rights Assignment.

Find and double-click the policy named "Deny log on as a batch job".

Examine the list of users and groups. If you see the ~task account or a group it is a member of (like Domain Users or Authenticated Users), that is the source of your problem.

Step 2: Fix the "Deny" Policy

If you find an entry: The best practice is to not edit the local policy directly. Instead, find which GPO is applying this "Deny" setting.

Run rsop.msc again, just as you did before.

  Look at the "Deny log on as a batch job" policy in the list and check its __Source GPO__.
  
     Edit that GPO in the __Group Policy Management Console__ on your domain controller to remove the conflicting account or group.

Step 3: Force Policy Update and Reboot

After you have removed the conflict from the GPO, run the following commands in an elevated Command Prompt on the problematic server to ensure the changes take effect immediately:

Bash

gpupdate /force
shutdown /r /t 0

A reboot is often necessary for user rights assignments to be fully updated and recognized by the system. After the server reboots, the Task Scheduler will recognize the permission correctly.

Best Regards,

Share via

Log on as a batch job

3 answers

Your answer