Python Schedule task not running because of arcpy.

[TiagoRibeiro]

Hi everyone,

I have this really simple Python script, that basically copies a file:

import os, shutil, time
originalSDDraft = "C:\\Esri\\test.sddraft"
localtime = time.localtime(time.time())
filesPath = os.path.dirname(originalSDDraft)
sddraftFile = filesPath + '\\' + str(localtime.tm_min) + str(localtime.tm_sec) + os.path.basename(originalSDDraft).replace('.sddraft','_copy.sddraft')
if os.path.isfile(sddraftFile):
   os.remove(sddraftFile)
shutil.copy(originalSDDraft,sddraftFile)

When I run it on a Windows Server 2008 R2 64Bit both through command line and as a scheduled task, it does what it's suppose to do.
When I import the arcpy module, then the "fun" begins. I'm only able to run it as a schedule task if:

• "Run only when user is logged on" is selected.


• The user has administrator privileges.

Does any one knows why by just importing the arcpy module the script stops to work as a scheduled task with the option "Run whether user is logged on or not" selected?
Any help would be appreciated!
Thanks,

Tiago

[MichaelVolz]

Tim:

You wriote "I'm trying the 'Run with highest privledges' option selected which seems to have a positive impact (combined with run if user is logged in or not). It's allowed me to run my scripts, but it may only be possible because my service running account is in the local admin group."

Is there an issue with the service running account being in the local admin group?  I have had my server that runs scheduled tasks set up this way for years without incident.

[RhettZufelt]

of course, with the "new" security after XP, you need to make sure your group policy allows it.

I have to remain logged in for my scheduled task to work as the GroupPolicy is set to:
Network access: Do not allow storage of passwords and credentials for network authentication.

If this is set, you are not allowed to run when not logged in (you can, but very limited and local resources only, no network access).  My workaround is to remain logged in, at least, until I can get IT to change the policy for that box.

R_

[curtvprice]

Modifying to use arcgisscripting I'll lose all of the performance benefits I've gained with faster cursors and some new tools.  That's an unfortunate answer from them.

arcgisscripting is still there - arcpy is just a handier way to do things, and it gives you intellisense. For example to get at the 10.1 cursors, this seems to get you there. With some help from tech support you can probably rewrite your script to use arcgisscripting.

>>> import arcgisscripting
>>> gp = arcgisscripting.create(10.1)
>>> from arcgisscripting import da
>>> dir(da)
['Domain', 'Editor', 'ExtendTable', 'FeatureClassToNumPyArray', 'InsertCursor', 'ListDomains', 'ListReplicas', 'ListSubtypes', 'List
Versions', 'NumPyArrayToFeatureClass', 'NumPyArrayToTable', 'Replica', 'SearchCursor', 'TableToNumPyArray', 'UpdateCursor', 'Version
', 'Walk', '__doc__', '__name__', '__package__']

Interestingly, arcpy.mapping ( a main thing we would want to do in a background task, say for a map that refreshes on a schedule ) does not seem accessible this way:

>>> from arcgisscripting import mapping
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name mapping

[PF1]

Tim: 

You wriote "I'm trying the 'Run with highest privledges' option selected which seems to have a positive impact (combined with run if user is logged in or not). It's allowed me to run my scripts, but it may only be possible because my service running account is in the local admin group." 

Is there an issue with the service running account being in the local admin group? I have had my server that runs scheduled tasks set up this way for years without incident.

This completely solved our problem. The key was 'Run with the highest privileges' setting. The headless service account is not part of our local Administrators group. See picture below. We are running ArcGIS Desktop 10.1 SP1 advanced (with concurrent licenses setup on a remote license server)

The arcgisscripting.create() option is not viable as we are using some of the 10.0 and 10.1 capabilities (like the da module and other script tools)

Appreciate the post on this. It saved us a lot of time!