I've been working for hours on this one.
I have a scheduled task that is set up to be run by a non-admin account.
What is does:
Start a service at a specific time everyday.
Command:
NET START <service>
Configuration:
Runs everyday at 6 PM
Run with highest privileges
Non-administrative account has the following access levels
Remote Desktop User
Log on as Batch Job
Log on as Service
Access to start/stop the service in ACL
Read/execute access to CMD.exe and NET.exe
Access to start/stop the task scheduler service
Access to the tasks directory in C:\Windows\System32\Tasks
The Problem:
Scheduled task runs but does not start service as intended. When temporarily granted admin access to account, scheduled task executes as intended.
Investigation Notes:
Interestingly, if the account itself remotes into the box it CAN start/stop the service manually.
The scheduled task completes with no errors whatsoever (even in eventvwr) but the service itself does not start.
When the account is given admin access, the scheduled task runs as expected.
I'm looking into the possibility that there might be additional permissions involved to be able to execute 'NET START' but I've had little luck finding any information on that.
Any help would be really appreciated.
you must check : "execute with highest privileges" in the Generel Tab
Related
There is a scheduled task that executes a script. It was running fine until one day it started to fail with 'Task Scheduler failed to start "Task" task for user "domain account". Additional Data: Error Value: 2147944309.' It failed on a Friday, ran on a Saturday, then began failing daily after that. My research on this found that 2147944309 means the account is either disabled or locked out. I double checked the account and it was neither. Server is Windows 2012. It's an RDS server so it reboots every morning. After it reboots a warning message shows in history for the task "Task Scheduler did not launch task "Task" as it missed its schedule. Consider using the configuration option to start the task when available, if schedule is missed."
What I was able to determine:
account is not locked or disabled
account is in the administrator group on the server
permissions are correct on the script
set it to run with highest privileges
able to manually kick off the task
the task is in a folder under Task Scheduler Library
created a test task to run notepad under the same account in the folder. It did not run
created a test task in a test folder under Task Scheduler Library to run notepad under the same account. It did not run
created a test task directly Task Scheduler Library to run notepad under the same account. It ran
moved the task under directly under Task Scheduler Library.
The scheduled task kicked off for four days in a row and then began failing with the same error. Yesterday, I set the option to restart every minute three times if it fails. It didn't execute a second or third time after failing. Any ideas what the heck is going with this?
I am trying to run the Test Compelete Scripts on a virtual machine through Azure DevOps pipeline.
When I run the Azure Devops pipeline release. Execution starts in VM. But when I check the logs I see that the user action in the Test scripts are not performed.
Eg: My application is launched, and next steps when I have to select a radio button execution fails and also in
TE log I can see "User session is disconnected and also I can see that it is not able to identify the object)
You typically get this error when the test is run from a scheduled task with the Run whether user is logged on or not option. The error occurs because in this case the test is run in a non-interactive session and cannot interact with the GUI.
To resolve the problem, do the following:
Modify properties of the scheduled task to use the Run only when the
user is logged on option and specify the user account under which
the task will be run.
Make sure that the specified user is logged into the system when the
task is triggered.
Here is the document you can refer to.
I am working on a TFS CI build pipeline. The build includes execution of functional UI tests (Run Functional Tests) and the required accompanying preparatory test agent deployment step (Deploy Test Agent).
This build executed successfully in the past but spontaneously stopped working recently.
I initially ran into difficulty with the DTA task executing hanging:
Task 'SetupTestMachineForUiTests' on machine '[testVM]:5985' is taking time. Please Wait
I had encountered this issue with this build task before albeit intermittently. However, this time the step would not complete no matter how many times it executed. Eventually (~20 minutes), the step crashed out with the following error:
Task 'SetupTestMachineForUiTests' for machine [testVM]:5985's Error :
System.Exception: Stopping test machine setup as it exceeded maximum number of reboots. If you are running test agent in interactive mode, please make sure that autologon is enabled and no legal notice is displayed on logon in test machines.
Unfortunately, the DTA task only writes logs to the usual location on the test VM when the DTAExecutionHost.exe is manually closed on the server after the step has failed. The logs offer no clue as to what the problem might be.
One of the prerequisites for the DTA step to execute successfully is that AutoLogon is enabled on the test VM; I had done this with a simple PowerShell script, executed prior to the DTA task. In order to confirm that the test VM registry values had been correctly assigned (to enable auto logon, disable legal notice, screensaver etc) during my PowerShell script execution, I added a further PowerShell debug script to the build to output each relevant registry value to the build console (all are correctly assigned).
However, when I went to test remote login on the test VM, using the test username, the user creds are accepted but the following warning message shows:
To sign in remotely, you need the right to sign in through Remote Desktop Services. By default members of the Administrators group have this right. If the group you're in does not have the right, or if the right has been removed from the Administrators group, you need to be granted the right manually.
I believe this is the problem. However, the solution has so far eluded me.
I double- and triple- checked; the test user has been added to the
Remote Desktop Users group (also Administrators group).
I've also confirmed that both Administrators and Remote Desktop Users groups
have been granted 'Allow log on through Remote Desktop Services' user
rights.
In testing, I forced successful execution of the build by substituting my own username instead of the test user into the build definition (my user name is also added to RDU and Admin user groups on the server but I can successfully remote onto the box with my own creds); this build executed successfully.
I also inspected the other (possibly, probably) related user groups:
Srv_SeDenyInteractiveLogonRight (test user is absent)
Srv_SeDenyRemoteInteractiveLogonRight (test user is absent)
Srv_SeInteractiveLogonRight (test user present)
I've been fighting with this problem for days now; it's now become a major headache. I'd be very grateful for any insights that might help find a resolution.
Thanks for looking.
The problem was that the account had been added to the AD domain 'DenyInteractiveLogon' group. Adding the account to the local 'Remote Desktop User' and/or the 'Srv_SeInteractiveLogonRight' groups had no effect.
Removing the user account from the domain group resolved the problem.
I am looking for a way to run a job on a schedule and also alert the user to that running job. Specifically, I am using PowerShell to manage a computer lab scenario, and between sessions I want to refresh the environment, clean off the desktop, reset shortcuts pinned to the task bar for the next session, etc. But I want to warn anyone sitting at the machine that this is about to happen. However, my scripts that use Balloontips very successfully as regular scripts don't work as scheduled jobs. They run, and I have verified they run as the user in question, by creating a Scheduled Job that rights a text file to the user desktop. But Balloon Tips don't actually appear. Is there some secret to getting this to work, or is this a form of "interaction" that a scheduled job just can't do?
I also tried an alternative approach, launching the browser with a web page warning of the impending cleanup. That also didn't work. Suggesting some limits to what can be done as a Scheduled Job.
I would much rather go the very "integrated with the OS" route of the balloon tips, but for the life of me it seems like that just isn't an option. So, any other suggestions for providing user info by way of a scheduled job?
Since this runs in Session 0 where GUI interaction doesn't exist you must resort to some other mechanism.
You say this happens between sessions. You could show your ballon via another "notification script" that is executed from within your ScheduledJob. You have options here. For example:
Add entry to registry Run key that will self delete on run. Shows popup when user logs in (session change ? ). Entry executes posh script which parameters you could craft, i.e. (powershell -File notify.ps1 -ArgumentList "Operation bla bla..")
Add ScheduledTask that doesn't run in Session 0 (regular task). You need to do that only once. Every next time you run this job to show notification to the user from within main script via schtasks run or ScheduledTasks module depending on your system.
Add a ScheduledTask that check periodically EventLog for the input of your main script. The task would start on logon and subscribe to event log notifications. I don't like this as the script must run non-stop.
I've been working on a system in which task scheduler is used to run few applications every night. Recently i've noticed that the tasks which i scheduled are not running and it is giving the following error message
the scheduled task did not run because an incorrect password or user name was entered
Recently i've changed the system password. Is that the reason for the task scheduler failure?
Should i change the password in the task scheduler too?
Yes you should change the password in Task Scheduler to match the password of the account it's executing code under.
If it can run with a less privileged account, I would take the opportunity to create an account with least privileges needed to complete it's work and setup Task Scheduler to use that restricted account.