Python Script not running through Task Scheduler on Windows Server 2008

[JennaBernabe1]

I have a python script I am trying to schedule on a server that's operating on Windows Server 2008.  I'm able to get the script to run manually from that server, but when I create a task to start it, there are no results. On the task scheduler window, the task shows that it's running, but there are no outputs or any other indication that it's actually running.

Since the script runs fine when I manually start it, I'm assuming that the problem is within a setting on Task Scheduler or the server itself.  I'm a novice working with scripts and task scheduler, so there might be something I'm overlooking..

Any insight to this problem is appreciated!

[MichaelVolz]

Brian:

Can you provide a screenshot of the Edit Action page you have setup in Task Scheduler?

Also do you have the Task set to 1.) Run whether is logged on or not

2.) Run with highest privileges (even if the user is an Administrator on the server)

[collindegueurce]

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!

[AlexLife]

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.

[Anish_Adhikari]

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.

[MikeHelten]

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.

[Lake_Worth_BeachAdmin]

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.

The Definition of Universal Naming Convention (UNC) 

[bspivey]

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. 

[JeffreyWilkerson]

Adding this as it might help.  I had about 5 Python scripts working under Task Scheduler for over a year and then, nothing.  They were being run from MS batch files that identified the location of Python and the script file with nothing else in them, and if I ran that batch file they would work.  The Task Scheduler tasks were starting, and then stopping after 5 seconds or thereabouts, but no errors or strange logs anywhere.  I had logging in my Python files that weren't being hit, so something was stopping it early on.  Finally decided to dummy down my Python file until they did work through the Task Scheduler and found that the library 'pyodbc' that I used to call SQL Server was not loading.  Still trying to figure out why that library isn't being opened in Task Scheduler but I at least I found something that was causing the problem.  I will update if I find out more.

[JeffreyWilkerson]

After I posted the last reply I continued to have issues.  I would fix the code, get it set up to run in Task Scheduler and then after 2 to 4 days the Tasks would stop running.  The Task Scheduler code was not returning a code of 0, which indicates the task ran without error, but I couldn't track down any of the errors on the internet.  I found some code on the internet (not sure where and I apologize to whomever I'm not crediting it with) that was for a MS batch file to run until the code became 0, but the task started and ran the the script a number of times (21 in my case) without ever achieving a code of 0.  

SET log_file=d:\Projects\Ridership\Logs\RailLog%date%_%time%.txt

ECHO ######################################################################### >> %log_file%
ECHO Batch start %date% Time: %time% >> %log_file%

SET /A _counter=1
SET /A _max_tries=21
SET /A _wait_seconds=2

:LOOP

IF %_counter%==%_max_tries% (
ECHO GOTO END - max tries of [%_max_tries%] reached. >> %log_file%
GOTO :END
)

ECHO Attempt: [%_counter%] >> %log_file%

ECHO Error level before python: [%errorlevel%] >> %log_file%

:: Use the python exe to run our batch script.
:: Use full path to both python exe and python script.
"d:\python3\envs\arcgispro2_8-py3\pythonw.exe" d:\Projects\Ridership\DilaxDailyRailDownload.py

ECHO Error level after python: [%errorlevel%] >> %log_file%

:: Check the python return code. If success then exit Else pause and try again.
IF %errorlevel%==0 (
ECHO GOTO END - success >> %log_file%
GOTO :END
)
ELSE (
ECHO Wait for some time. >> %log_file%
TIMEOUT %_wait_seconds% > NUL
)

ECHO After pause %date% Time: %time% >> %log_file%

:: Increment the counter.
SET /A _counter=%_counter%+1

GOTO :LOOP

:END
ECHO Batch end %date% Time: %time% >> %log_file%

I feel like I tried everything. Making sure the paths worked, changing the location of the ArcGIS Pro Python library to something more general, checking the validity of the System account used to run the code, and anything else I could find. 

In final desperation I decided to go back to the ArcGIS 2.7 Python, as it seems like all of this started after I chose to upgrade it all to Pro and Python 3.x.  After uninstalling Pro and all of the Python libraries associated with it, and reinstalling ArcGIS Desktop 10.8.2 with Python 2.7 (and making some minor changes to the Python files to reflect running them in 2.7), everything started to work again and I haven't had any issues with the Task Scheduler for over a month now. 

I firmly believe that the problem lies in using the ArcGIS Pro Python as the tool to run the code through Task Scheduler.  I don't think it's in the libraries, but it must have something to do with the licensing of arcpy through Pro.  That's the only thing that seems like it would explain why it works sometimes, and then just quits working, and with error codes that Microsoft doesn't understand.  When the problem first started occurring, it seemed like I could log into ArcGIS Pro and then things would work.  In fact, an Esri tech working with me on a remote session also verified that seemed like what was happening, but then, after a while, that didn't even resolve the situation.

At this point, I'm happy.  I can sleep at night.  I don't go to work and spend 8+ hours chasing ghosts that just end up with nothing to show for it.  Yet, I know that I will eventually have to move away from 2.7 as Desktop will someday be deprecated. My only thought at this point is to generate a stand alone license for Pro (not use ArcGIS Online for its licensing) and set up Python 3.x on the server using that.  But until I 'have' to move away from 2.7, I'm content. May you someday achieve peace on this subject as well.