I had the same problem - built a model that works fine, exported to python script which ran fine - but could not seem to get it to run as scheduled task and pulled my hair out for two days before I got it to work on my machine. There were many posts offering various solutions and I tried all of them to no avail. I tried running the script through a batch file, I tried changing the "start in" location, I tried running cmd as the program with various options in the arguments list. I guess all of these things were worth trying as they did seem to solve the problem for some people, but not others - namely me!
This finally worked for me (in addition to a fifth of whiskey):
I used this snippet to be sure I had the correct path to python.exe, as there are several instances of the file on my machine:
import sys
import platform
import imp
print("Python EXE : " + sys.executable)
print("Architecture : " + platform.architecture()[0])
print("Path to arcpy : " + imp.find_module("arcpy")[1])
raw_input("\n\nPress ENTER to quit")
I created a basic task with task scheduler.
Then under the "task actions" tab, I used the following:
Program/Script:
My full path to python.exe:
C:\Python27\ArcGIS10.3\python.exe
Add Arguments:
The full path to my script - in my case:
C:\Users\wwbill22\Documents\ArcGIS\PyScripts\runModel.py
(note that you will need to enclose in double quotes if your path contains spaces).
Finally, my task runs as scheduled.
I should note that under general task properties I have NOT checked "Run with Highest Privileges" NOR have I selected "Run whether user is logged on or not"
If I try to use either of those options I get the familiar 0x1 error. Which is unfortunate, but I can live with leaving the user logged on.
I also found out as I researched this issue that I did not have to export the model to a python script to schedule it as a task. Since my model was saved in a toolbox, I could simply write a script to import the toolbox and call the model directly. This has the added value of not having to update my script if I decide to edit my model tool in the future. Didn't have a bearing on my task scheduler issue but I thought it was interesting nonetheless.
Here is the script I used to achieve that:
import arcpy
# Import custom toolbox
arcpy.ImportToolbox("L:/GIS/Toolboxes/Collin_Tools.tbx")
try:
# Run tool in the custom toolbox. The tool is identified by
# the tool name and the toolbox alias.
arcpy.Model3_collintools()
except arcpy.ExecuteError:
print(arcpy.GetMessages(2))
Hope this helps someone else out!
This made my day, after an hour search. I wasnt inputting the path to python.exe, only path to the file I wanted to run inside the program/script section.
OK I finally got it to work.
I was having similar kind of problem and spent an entire day trying several different approaches mentioned in this thread and other non-gis forum. None of the solutions worked for me. I had written a script which ran fine when I ran it as a scheduled task when I was logged in. However, it would always fail when set to run whether the user is logged on or not. I was getting 0X1 error.
My script is set to output current date and time in the beginning when it runs along with other python messages after various arcpy functions get executed.
I realized that despite being logged off, the script would still print the current date and stop working from that point on before arcpy functions were being called(There were no error messages being output on the logfile except the date). I then realized that it is not that the task scheduler is not finding the file as seemed to be the case with lot of people with that 0X1 error code.
I also have other python scripts that had been running fine as scheduled tasks without having to be logged on.
In my case, I found out that it is the arccatalog generated path that the script was referring to ran into permissions issue when being executed. So I ended up creating copy of database and arcgis online connections in Arccatalog to a local folder in my hard drive and pointed my variables to that location instead.
Changed code that works.
arcpy.env.workspace = "C:\\GIS_Data\\sdeconn\\dbconn.sde"
mytable = "GISData.dbo.my_tbl"
World_GeocodeServer = "C:\\GIS_Data\\sdeconn\\arcgis_geocode.ags\\World.GeocodeServer"
output_table = "GISData.DBO.Batch_Geocode"
geographytable = "GISData.dbo.GEOGRAPHY"
arcpy.env.overwriteOutput = True
Previous code that did not work
mytable = "Database Connections\\dbconn.sde\\GISData.dbo.my_tbl"
World_GeocodeServer = "GIS Servers\\arcgis_geocode\\World.GeocodeServer"
output_table = "Database Connections\\dbconn.sde\\GISData.DBO.Batch_Geocode"
geographytable = "Database Connections\\dbconn.sde\\GISData.dbo.GEOGRAPHY"
arcpy.env.overwriteOutput = True
On the task scheduler side, I just created a basic task and pointed it to my script. Left the start in and argument values blank. The login info I provided is an administrator account for the server. I am on Windows server 2012 but the task is running as Windows Vista/Windows Server 2008(default setting on my system)
Everything works now without having to be logged on. Hope this will be helpful to someone.
Additional tidbit- When logged on as myself, my script ran fine without the "database.DBO." prefix on the table names. The task-scheduler account, however, would throw errors if this prefix wasn't included when accessing the SDE tables from the script. Probably won't help anyone, but I wasted a few hours before this finally occurred to me.
for future reference: this issue will also occur if you're accessing files from network dives.
be sure to use UNC paths not the mapped network drive.
If your scheduled task completes successfully (code 0x0), but nothing seems to happen as the result of your code, the cause may be how you are using relative paths in your script. Yes, you may have enter fully qualified paths to python.exe and your script (and maybe filled the "start in" item too) when configuring the scheduled task BUT the scheduled task itself starts from C:\win32 and certain relative path syntax that work in an IDE (e.g., IDLE, pyCharm, etc.) will not work as a scheduled task. For example, a script containing a relative path of /pathToItem works just fine in IDLE. However, if you print out the path (to a txt file) that is created from when executed from Task Scheduler you can see that the script is actually looking for the resource in C:\win32\pathToItem. Obviously, this isn't going to work. Changing the relative path to ./pathToItem is a simple fix that may allow your script to truly execute successfully from Task Scheduler.