Task Scheduler- Batch “Run whether user is logged on or not” not working
up vote
2
down vote
favorite
I've created a batch file (EnableDisable.bat
) that will disable a Windows Task Scheduler job (SampleJob
) on a local system, if a job with same name (SampleJob
) is already enabled and running on another remote system.
It seems that when the job is setup with the Run whether user is logged on or not
option checked along with Run with Highest privileges
that it just doesn't work and the reason is hard to determine and I'm not sure how to troubleshoot.
Batch File
for /f "tokens=1" %%j in ('schtasks /Query /S [servername] /TN "SampleJob" /NH ^| findstr "Ready ^| Running"') do schtasks /Change /Disable /TN "%%j"
Note: The remote system is referred to as [
servername
] and will be replaced by the actual remote server name where needed.
Windows Task Scheduler Job Configurations
- This batch file is configured as a Windows Task Scheduler job
Name:EnableDisableJob
Security Option:Run whether user is logged on or not
Run with Highest privileges
Observations
If I run the job with the Run only when user is logged on
it seems to work just fine without any issue. However, it seems like when I try to run it with the other option, and because that account is not logged on, it cannot run when that is the case.
Question
How do I troubleshoot this sort of issue and where should I start to begin that process?
windows batch batch-file scheduled-tasks windows-task-scheduler
add a comment |
up vote
2
down vote
favorite
I've created a batch file (EnableDisable.bat
) that will disable a Windows Task Scheduler job (SampleJob
) on a local system, if a job with same name (SampleJob
) is already enabled and running on another remote system.
It seems that when the job is setup with the Run whether user is logged on or not
option checked along with Run with Highest privileges
that it just doesn't work and the reason is hard to determine and I'm not sure how to troubleshoot.
Batch File
for /f "tokens=1" %%j in ('schtasks /Query /S [servername] /TN "SampleJob" /NH ^| findstr "Ready ^| Running"') do schtasks /Change /Disable /TN "%%j"
Note: The remote system is referred to as [
servername
] and will be replaced by the actual remote server name where needed.
Windows Task Scheduler Job Configurations
- This batch file is configured as a Windows Task Scheduler job
Name:EnableDisableJob
Security Option:Run whether user is logged on or not
Run with Highest privileges
Observations
If I run the job with the Run only when user is logged on
it seems to work just fine without any issue. However, it seems like when I try to run it with the other option, and because that account is not logged on, it cannot run when that is the case.
Question
How do I troubleshoot this sort of issue and where should I start to begin that process?
windows batch batch-file scheduled-tasks windows-task-scheduler
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I've created a batch file (EnableDisable.bat
) that will disable a Windows Task Scheduler job (SampleJob
) on a local system, if a job with same name (SampleJob
) is already enabled and running on another remote system.
It seems that when the job is setup with the Run whether user is logged on or not
option checked along with Run with Highest privileges
that it just doesn't work and the reason is hard to determine and I'm not sure how to troubleshoot.
Batch File
for /f "tokens=1" %%j in ('schtasks /Query /S [servername] /TN "SampleJob" /NH ^| findstr "Ready ^| Running"') do schtasks /Change /Disable /TN "%%j"
Note: The remote system is referred to as [
servername
] and will be replaced by the actual remote server name where needed.
Windows Task Scheduler Job Configurations
- This batch file is configured as a Windows Task Scheduler job
Name:EnableDisableJob
Security Option:Run whether user is logged on or not
Run with Highest privileges
Observations
If I run the job with the Run only when user is logged on
it seems to work just fine without any issue. However, it seems like when I try to run it with the other option, and because that account is not logged on, it cannot run when that is the case.
Question
How do I troubleshoot this sort of issue and where should I start to begin that process?
windows batch batch-file scheduled-tasks windows-task-scheduler
I've created a batch file (EnableDisable.bat
) that will disable a Windows Task Scheduler job (SampleJob
) on a local system, if a job with same name (SampleJob
) is already enabled and running on another remote system.
It seems that when the job is setup with the Run whether user is logged on or not
option checked along with Run with Highest privileges
that it just doesn't work and the reason is hard to determine and I'm not sure how to troubleshoot.
Batch File
for /f "tokens=1" %%j in ('schtasks /Query /S [servername] /TN "SampleJob" /NH ^| findstr "Ready ^| Running"') do schtasks /Change /Disable /TN "%%j"
Note: The remote system is referred to as [
servername
] and will be replaced by the actual remote server name where needed.
Windows Task Scheduler Job Configurations
- This batch file is configured as a Windows Task Scheduler job
Name:EnableDisableJob
Security Option:Run whether user is logged on or not
Run with Highest privileges
Observations
If I run the job with the Run only when user is logged on
it seems to work just fine without any issue. However, it seems like when I try to run it with the other option, and because that account is not logged on, it cannot run when that is the case.
Question
How do I troubleshoot this sort of issue and where should I start to begin that process?
windows batch batch-file scheduled-tasks windows-task-scheduler
windows batch batch-file scheduled-tasks windows-task-scheduler
edited Jul 1 at 7:22
Pimp Juice IT
22.7k113869
22.7k113869
asked Jun 28 at 11:36
t_venuga
204
204
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
To troubleshoot this here are a few things
- Logoff the machine you run this process as with the
User1
account
and then log onto the machine as theUser2
account and ensure a
profile gets built forUser2
. So theC:UsersUser2
folder should exist. - While you are logged onto that machine as
User2
run
the scheduled task or at least test it withRun only when user is logged on
andRun with highest privileges
and this should pop up the command
prompt window when it runs and show any errors, etc. which you wouldn't see running it with theRun whether user is logged on or not
option. If you see an "access denied" error or something of that nature, then there's a permission issue.
Permission Issue
You will want to ensure the user account you run the Task Scheduler scheduled job with the Run whether user is logged on or not
and Run with highest privileges
has access to. . .
- run command prompt (
cmd.exe
) from the machine you run the task on - run
schtasks
from the machine you run the task on - run
schtasks
remotely against the remote server you run the task against
Other Items
Make the
User2
account a local admin on the machine you run the task on temporarily and then logoff and back onto the machine and and try again to rule that out local machine permission issues.Compare the security differences with the
User1
andUser2
on remote
machine, domain security groups, etc. as well.
Further Resources
- Windows 10: Scheduled tasks with workstation lock/unlock not being triggered
add a comment |
up vote
0
down vote
All suggestions above from Pimp Juice IT are great. I'll mention one other thing here.
You have to make sure the user account running the task has Log on as batch job
user rights. Here's the doc from MS: link .
And here's a link on how to set this from Local Security Policy: link .
You can also do this via GPO.
Of course, as Pimp Juice IT suggested, if the user is already a Local Admin, they may already have this right.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
To troubleshoot this here are a few things
- Logoff the machine you run this process as with the
User1
account
and then log onto the machine as theUser2
account and ensure a
profile gets built forUser2
. So theC:UsersUser2
folder should exist. - While you are logged onto that machine as
User2
run
the scheduled task or at least test it withRun only when user is logged on
andRun with highest privileges
and this should pop up the command
prompt window when it runs and show any errors, etc. which you wouldn't see running it with theRun whether user is logged on or not
option. If you see an "access denied" error or something of that nature, then there's a permission issue.
Permission Issue
You will want to ensure the user account you run the Task Scheduler scheduled job with the Run whether user is logged on or not
and Run with highest privileges
has access to. . .
- run command prompt (
cmd.exe
) from the machine you run the task on - run
schtasks
from the machine you run the task on - run
schtasks
remotely against the remote server you run the task against
Other Items
Make the
User2
account a local admin on the machine you run the task on temporarily and then logoff and back onto the machine and and try again to rule that out local machine permission issues.Compare the security differences with the
User1
andUser2
on remote
machine, domain security groups, etc. as well.
Further Resources
- Windows 10: Scheduled tasks with workstation lock/unlock not being triggered
add a comment |
up vote
0
down vote
accepted
To troubleshoot this here are a few things
- Logoff the machine you run this process as with the
User1
account
and then log onto the machine as theUser2
account and ensure a
profile gets built forUser2
. So theC:UsersUser2
folder should exist. - While you are logged onto that machine as
User2
run
the scheduled task or at least test it withRun only when user is logged on
andRun with highest privileges
and this should pop up the command
prompt window when it runs and show any errors, etc. which you wouldn't see running it with theRun whether user is logged on or not
option. If you see an "access denied" error or something of that nature, then there's a permission issue.
Permission Issue
You will want to ensure the user account you run the Task Scheduler scheduled job with the Run whether user is logged on or not
and Run with highest privileges
has access to. . .
- run command prompt (
cmd.exe
) from the machine you run the task on - run
schtasks
from the machine you run the task on - run
schtasks
remotely against the remote server you run the task against
Other Items
Make the
User2
account a local admin on the machine you run the task on temporarily and then logoff and back onto the machine and and try again to rule that out local machine permission issues.Compare the security differences with the
User1
andUser2
on remote
machine, domain security groups, etc. as well.
Further Resources
- Windows 10: Scheduled tasks with workstation lock/unlock not being triggered
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
To troubleshoot this here are a few things
- Logoff the machine you run this process as with the
User1
account
and then log onto the machine as theUser2
account and ensure a
profile gets built forUser2
. So theC:UsersUser2
folder should exist. - While you are logged onto that machine as
User2
run
the scheduled task or at least test it withRun only when user is logged on
andRun with highest privileges
and this should pop up the command
prompt window when it runs and show any errors, etc. which you wouldn't see running it with theRun whether user is logged on or not
option. If you see an "access denied" error or something of that nature, then there's a permission issue.
Permission Issue
You will want to ensure the user account you run the Task Scheduler scheduled job with the Run whether user is logged on or not
and Run with highest privileges
has access to. . .
- run command prompt (
cmd.exe
) from the machine you run the task on - run
schtasks
from the machine you run the task on - run
schtasks
remotely against the remote server you run the task against
Other Items
Make the
User2
account a local admin on the machine you run the task on temporarily and then logoff and back onto the machine and and try again to rule that out local machine permission issues.Compare the security differences with the
User1
andUser2
on remote
machine, domain security groups, etc. as well.
Further Resources
- Windows 10: Scheduled tasks with workstation lock/unlock not being triggered
To troubleshoot this here are a few things
- Logoff the machine you run this process as with the
User1
account
and then log onto the machine as theUser2
account and ensure a
profile gets built forUser2
. So theC:UsersUser2
folder should exist. - While you are logged onto that machine as
User2
run
the scheduled task or at least test it withRun only when user is logged on
andRun with highest privileges
and this should pop up the command
prompt window when it runs and show any errors, etc. which you wouldn't see running it with theRun whether user is logged on or not
option. If you see an "access denied" error or something of that nature, then there's a permission issue.
Permission Issue
You will want to ensure the user account you run the Task Scheduler scheduled job with the Run whether user is logged on or not
and Run with highest privileges
has access to. . .
- run command prompt (
cmd.exe
) from the machine you run the task on - run
schtasks
from the machine you run the task on - run
schtasks
remotely against the remote server you run the task against
Other Items
Make the
User2
account a local admin on the machine you run the task on temporarily and then logoff and back onto the machine and and try again to rule that out local machine permission issues.Compare the security differences with the
User1
andUser2
on remote
machine, domain security groups, etc. as well.
Further Resources
- Windows 10: Scheduled tasks with workstation lock/unlock not being triggered
answered Jun 29 at 13:15
Pimp Juice IT
22.7k113869
22.7k113869
add a comment |
add a comment |
up vote
0
down vote
All suggestions above from Pimp Juice IT are great. I'll mention one other thing here.
You have to make sure the user account running the task has Log on as batch job
user rights. Here's the doc from MS: link .
And here's a link on how to set this from Local Security Policy: link .
You can also do this via GPO.
Of course, as Pimp Juice IT suggested, if the user is already a Local Admin, they may already have this right.
add a comment |
up vote
0
down vote
All suggestions above from Pimp Juice IT are great. I'll mention one other thing here.
You have to make sure the user account running the task has Log on as batch job
user rights. Here's the doc from MS: link .
And here's a link on how to set this from Local Security Policy: link .
You can also do this via GPO.
Of course, as Pimp Juice IT suggested, if the user is already a Local Admin, they may already have this right.
add a comment |
up vote
0
down vote
up vote
0
down vote
All suggestions above from Pimp Juice IT are great. I'll mention one other thing here.
You have to make sure the user account running the task has Log on as batch job
user rights. Here's the doc from MS: link .
And here's a link on how to set this from Local Security Policy: link .
You can also do this via GPO.
Of course, as Pimp Juice IT suggested, if the user is already a Local Admin, they may already have this right.
All suggestions above from Pimp Juice IT are great. I'll mention one other thing here.
You have to make sure the user account running the task has Log on as batch job
user rights. Here's the doc from MS: link .
And here's a link on how to set this from Local Security Policy: link .
You can also do this via GPO.
Of course, as Pimp Juice IT suggested, if the user is already a Local Admin, they may already have this right.
edited Nov 21 at 5:56
answered Nov 20 at 19:17
Adilio
12
12
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1334931%2ftask-scheduler-batch-run-whether-user-is-logged-on-or-not-not-working%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown