I'm trying to run a .vbs file as a scheduled task through Windows Task Scheduler. Under the 'General' tab, when I select "Run only when user is logged on", the script executes as expected.
However, when I select "Run whether user is logged on or not", and enter the appropriate credentials, the task runs at the scheduled time, but the script does not actually run. I've already tried running the script under wscript.exe as well as cscript.exe, but no luck with either.
EDIT: Even if I am logged in when the task begins, the script will still not run under the "logged in or out" setting.
Additional info: The purpose of this scheduled task is to run before I arrive at work. I've already configured my BIOS to startup at a predetermined time (06:00), and set the Task Scheduler to run at 06:27. I've successfully tested the BIOS startup, as well as the script itself (including using the Task Scheduler to run it). Therefore, the only weak link I can find is the option to "Run whether the user is logged on or not".
I'm running Windows 7 Enterprise.
Any help would be appreciated!
This is because normally it would run the script using the shell handler, which by default is wscript.exe. When there's no desktop environment (because no-one is logged-in) it would fail and abort script execution (or rather, not run the script in the first place).
To fix this, instead of running the .vbs file directly, change it to run cscript.exe (the command-line script runtime program) with the script's filename passed as the first argument. Also be sure to ensure you don't have any InputBox or MessageBox calls (instead use WScript.Echo to return messages to the user: wscript displays message-boxes, but cscript will write it to the console.
Related
I am trying to create a scheduled task to run a batch file. I know that my batch file runs fine, because I have no problem running it manually. However, when the task calls it, it says that it's running, but it's not. The reason I know that it's not running is because it calls a python script, and the python script sends an email saying that the process has started. And I'm not receiving that email.The python process doesn't take too long (maybe 5 minutes at most), and the task keeps saying that it's "Running" after an hour.
I have the current settings with "Run whether user is logged on or not" (doesn't seem to work at all if I have it as "Run only when user us logged on", because the status never changes from "Ready" even if I tell it to run). I also have the setting with "Run with highest privileges", and just the name of the batch file under "Program/script" and the path to the batch file under "Start in". I also want to note, that I have the user account as "DOMAIN\Administrator".
However, I've tried other ways of calling it. I've tried putting the entire path with the batch file under "Program/script" (G:\GOM3_Update\FeatureServices\copies\test.bat), or putting the path to the python program, and then putting the path to the python script as an argument, but that doesn't seem to work either.
I'm not sure if this issue is caused by some major security settings with windows 10, or something minor in the task scheduler settings.
Here are my current settings:
Full path of the Start in is: "G:\GOM3_Update\FeatureServices\copies\"
The batch file:
"C:\Users\Administrator.DOMAIN\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone\python.exe" "G:\GOM3_Update\FeatureServices\copies\database.py"
I would include a full path to batch file here:
From my personal experience it is usually the environment problem, aka things like current working directory etc..
Also, make sure to click the refresh button in the right pane of Task Scheduler because it is known for not updating the status of task unless you manually refresh. You may see it change from 'running' to 'ready' sooner if you do that.
The reason why I feel like your screen is not refreshing is because normally Task Scheduler does not allow any scheduled task to execute for longer that 1 hour and you said yours was still saying 'running' after an hour.
What does the exit code and messages say under tasks history?
Exit code 0 means no errors captured by Task Scheduler.
Another idea is to log the start of batch script (inside batch) to a log file before you do anything. And do the same for python file. This will help you narrow down the problem.
I struggled with this one also a lot, changing the User Account
AND Group. User Account alone was not enough for me.
This helped for me:
And then clicking on the Locations...you'll have to choose "WINSTADM"
I have a ClickOnce application that we start on Log on and recurring. After I install the application the tasks work fine, but if I reboot the machine the scripts run but they fail to start my application. I added logging to the BAT file and I know it is executed, but calling the rundll32 line produces no result and generates no errors.
If I manually run the script, from explorer, it works and task scheduler executions start working as well. Also, if I manually run the clickonce shortcut the scripts start executing from the Task Scheduler. Is there someway to verify that dfshim is loaded, or load it before executing it? What am I missing? I tried clearing the cache and that seemed to fix it on one machine, but it seems like a coincidence because it did not fix it on another machine.
VBS Script Called first(Called By Task Scheduler):
Set WshShell = WScript.CreateObject("WScript.Shell")
obj = WshShell.Run("C:\Users\brnapolitano\AppData\Roaming\FirstAmerican\TaskScheduler\AppReferenceInvoke.bat", 0)
set WshShell = Nothing
BAT Script Called Second(Called by VBS above):
rundll32.exe dfshim.dll,ShOpenVerbShortcut
C:\Users\brnapolitano\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\FastLocalService\FastLocalService.appref-ms
I would like to make this a script fix, but if that's not possible, I will try adding it to the startup and see if that resolves my issue.
I found the answer(linked below). I am still in the process of testing, but it seems to work. dfsvc needs to be run, if not active, before running the command to start the shortcut.
ClickOnce app not starting from the scheduler
It's not clear from your post what is happening after reboot. After the reboot are you trying to run the scheduled task after logon or before logon? If the latter, your vbs and bat files are most likely running under a different security context than what you think it is. That could also be the case after logon depending on the settings in your scheduled task.
See Task Scheduler is not supporting option "Run with highest Privilege" and "Run weather user is logged on or not"
My EXE is executing perfectly fine when I am executing it by double click on it, but it is not executing when I am trying to run it via Schedule Task.
I am running schedule task on a local machine as administrator. I have already set the following settings into the "Security Options" of the Schedule Task.
Run only when user is logged in (I am logged in when schedule task is running)
Run with highest privileges check box is checked
In my case, it didn't worked because of the start in location of the program.
Set the [Start in] (optional) properties of the scheduled task with the path where the exe file is exist.
The default [Start in] value is C:/Windows/System32
Depending on which Windows OS you're running this on, your EXE may have in fact started and is running in the background, with the user interface completely hidden. Depending on the EXE you are trying to run, it may be sitting there, hidden, waiting for user input that it will never get. If your EXE doesn't require any user input (something that just runs and then closes when it completes), then you might just check to see if the job is actually done.
A trick I have used to verify this is to create a small batch program like this:
#echo off
echo myEXE Scheduled Task Started %DATE% %TIME% >>c:\myEXE.log
myEXE.exe
echo myEXE Scheduled Task Completed %DATE% %TIME% >>c:\myEXE.log
Have your scheduled task call this batch script instead of myEXE directly. This will generate a text file (myEXE.log) that you can check to verify when the scheduled task kicked off, and then when (and whether) the EXE finished.
Just for kicks (and to test what I'm talking about) you can add these lines at the end of the batch script.
pause
echo Batch Script Finished %DATE% %TIME% >>c:\myEXE.log
If you never see the cmd window waiting for you to Press any key to continue... then you'll also never see the last line in your log file (myEXE.log)
Windows Task Scheduler is a strange beast of a program. It's not really a CRON like task scheduler and it's not a Quartz based program, other than relying on internal clock system.datetime, which has been known to have "issues" of its own.
Nevertheless, it can sometimes trip over itself (unproven, but from personal observations), when it comes to permissions of a task and who created it vs what account is used to run it.
I found the following steps gives me a "clean" task schedule every time, and the task runs every time:
Always run Task Scheduler as Administrator. If you don't have admin rights to do this, then you should even be here!
Don't create a Basic Task. Go straight to Create Task, and under your own admin account (doesn't have to be God Admin!).
When filling in the task wizard, don't provide a trigger UNTIL you've tested the task first. Also, make sure you've allowed the task to run whether you're logged in or not! That catches me sometimes.
Don't worry about Settings, for now. Accept the default
Save/OK
Close Task Scheduler
Restart it again, and again as Admin
Run the task you've created.
If all goes well, it ran! Do a CMD run of the EXE using #Wes's suggestion to be sure.
Now, place a Trigger of your choice
Change the Account to your proper task admin account, or a generic account with admin rights specifically created to run tasks. We call ours admin.tasks
Save everything and you should be ok from here.
I have a batch file which is set to run as a Scheduled Task on Windows Server 2012.
When I run the batch file by hand from the command line, it works. When I right-click on my task in Task Scheduler and manually run it, it still works fine.
But, if I let the task run according to the schedule set for it... then it seems to work sometimes, but not others.
I have already set the task to run as a given user; I have set its 'Start in' directory correctly; I have tried giving it highest privileges. None of that helps.
The basic answer is that the batch file for the task is running, and that the last step of the task is returning 0x0. If the task is apparently 'not doing anything', it is because some earlier step of the task is failing silently
Why? In my case, and I think this could easily effect other people, the answer is that the batch file for a scheduled task sees different environment variables depending on whether the user it runs as is currently logged in or not.
More Detail:
In particular, if the task is set to run as Administrator, then while Administrator is logged in the task sees one set of variables (whether it is run manually or on the schedule), but when Administrator is not logged in, it sees a different set of variables.
This can be very hard to debug - basically, you need to put in a lot of logging!
When you are running a batch file as a Scheduled Task on Windows Server 2012, it only sees shared environment variables. It does not see the user specific environment variables for the user you have set it to run as, unless the user in question is currently logged in.
You can see the problem in action by putting SET > test.txt into a batch file on its own, and running it as a task in different circumstances (manually; on a schedule when logged in; on a schedule when not logged in).
UPDATE:
From more detailed testing, it seems that when the user which the task is set to run as is not logged in, the variables USERDNSDOMAIN,
USERDOMAIN and USERNAME do get set correctly for that user anyway. The variable USERPROFILE gets set incorrectly to the value for the Windows default user (i.e. C:\Users\Default). Everything else gets set incorrectly to the set of shared environment variables only (note that this is obviously not the correct set for the specified user, and is also not even the correct set for the Windows default user, which should get its user specific environment variables from HKEY_USERS\.Default\Environment).
Note:
This is not the same issue as windows 7 task scheduler doesn't use updated path , and in fact changes to any shared environment variables, including PATH, do get seen straight away (on the tests I did, on Windows 2012 R2), with no restart of any process.
I have a VBScript which basically calls some Informatica CLI commands. These commands will take a long time to execute and the script runs in a Windows 2003 server.
cscript //B //Nologo <script> params...
Actually, I am calling this script from a .NET Winforms application. The idea is, even when form is closed, the script continues to run. It works fine, as long as user is logged on, i.e. even when winform is closed, the script runs as a (user) process and execute the command.
The problem is however when the user logs off (or) remote system (MSTSC) times out, the (cscript) process is killed.
Is there anyway this can be run as a system process so that even when user logs off, the script continues to run?
(Please note that running the .NET EXE as a Windows service is a last option, which is currently not viable..)
Only way I know to do this is a pretty dirty hack so you should at least consider the .NET service approach... Visual Studio offers great tools which allow you to make a Windows service very easily.
What you can do if that is really not an option is using the task scheduler. As long as you do not need user interactivity you can say a task should be "Run whether a user is logged on or not". If you do this you are allowed to use "SYSTEM" as the account to run the task with. So you can create your task executing your script without any trigger, and then manually trigger the task from the program.
There is no nice way to do this from C# but you can just execute schtasks /run /tn <taskname> or do a quick google search for some of the wrappers people wrote for this. The script will run (invisibly) in the background and survive user logoff if started that way.