I've scheduled 5 tasks on a Windows Server 2008 under a local administrator windows account. Each tasks starts a .NET application (console application).
After severals months of running as scheduled, the tasks have stopped running as scheduled all a sudden and now requires that I check "Run with Highest Privileges".
Everything runs fine after I make the modification; no binaries replaced, no known account modification have been made or notified to me.
The running windows local account is still a member of "Administrators" as I set it up months ago.
What could have been the reason requiring "Highest Privileges" all of sudden? Does it have to do with how UAC are managed on WinServer2008?
Thanks again for your reply,
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 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.
Recently we updated our systems to Office 2016. I have a scheduled task that reads information in an MS Access DB and then sends this information to a mail recipient via Outlook. All was fine until the upgrade.
The Scheduled task launches a .bat file which opens MS Access, calls a function, performs a task and then send the the information via email using outlook.
When I run the batch file manually by double clicking on it, it works as intended and sends the email. However, when I run through Task Scheduler it does not work. I know for certain that it opens the MS Access file and can read, but for some reason it fails to send the email. I have lowered all security setting to no avail.
The scheduled task runs with the highest privileges and all was fine before the upgrade.
Does anyone have any suggestions.
Outlook has security settings that will prevent an application from sending e-mail through it programmatically. It will use a popup dialog to ask for permission to send the e-mail. While I have successfully gotten rid of the popup and made Access send through Outlook while Outlook is open (both manually and as a scheduled task), it still fails when Outlook is not already open.
Your best bet, if you have the capability, is to leave Outlook open on the machine that runs the scheduled task. Otherwise you have to try to figure out what combination of policies and registry/outlook settings will make Outlook work the way you want it to.
Edit: My experience is with a windows domain/local exchange server environment.
We upgraded to Office 2016 a few weeks ago, and had been facing the same problem as you. Our batch file runs Access and triggers a macro that exports some data to a text file, and works fine when run manually. However, when run through Task Scheduler, everything seemed to run fine, but the text file was never updated. After trying for weeks with no success, I finally found the reason for the problem, and a solution.
In our case, the problem was that Access 2016 wants to be run as a foreground app. But when running as a Task Scheduler app (with the "run whether user is logged on or not" option checked), it views itself as a background app and therefore won't run. See Jim Dettman's answers here for a bit more on that: https://www.experts-exchange.com/questions/28988837/
Next, I found this post by Microsoft employee Blake Morrison where he discusses the changes in the latest version of Task Scheduler. One of his troubleshooting suggestions worked for us:
Try creating a new task, but select the Configure for: option to be
“Windows Server 2003, Windows XP, or Windows 2000” – this will create
an XP/2003 fashioned task
Unfortunately you probably have to do this as a new task - existing tasks don't seem to allow you to choose this option (it didn't show up in the dropdown menu for my existing task). So my settings for the new task are:
Running as an administrator account
"Run whether user is logged on or not" - checked
"Run with highest privileges" - checked
Configure For: Windows Server 2003, Windows XP, or Windows 2000
If I manually trigger the task, I see a command prompt open, then Access briefly opens and disappears (our macro has a Quit Access command at the end), and then the command prompt disappears. Output to our text file is written as expected. If I schedule it to run while I'm logged out of the machine, obviously I see nothing, but the text file is again written as expected, so I know it worked.
I have several scheduled tasks performing different jobs on windows server machine at my current work, but it looks like I'm living this company soon and I have worries about these jobs future after the time when my windows account will be disabled.
Will all gonna be okey with them?
These task's can be run even if you're not there but you have configured that the Task can run "Run whether the user is Logged in or not" or else it is not possible. you can still edit it even after creating it. but I'm not sure it will work even after deleting your account.
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