Is anyone able to run a script through Windows Task scheduler using ArcGIS Pro? As a test I have an extremely simple script (just copying a feature) that runs fine within ArcGIS Pro.
arcpy.management.CopyFeatures("C:\CityScripts\ScheduledTasks\SafewatchCameras\Data\General.gdb\SafewatchCameras", "C:\CityScripts\ScheduledTasks\SafewatchCameras\Data\General.gdb\SafewatchCamerastemp2", None, None, None, None)
I setup the Task Scheduler as recommended by the ArcGIS Pro help and while the Task completes successfully nothing happens with the script.
Put in a call to ESRI tech support but they said it was a Windows issue and therefore couldn't work on it.
It's great that you were able to determine that it's the Windows Server OS that is the issue. It would appear then that organizations planning to upgrade their Windows Server environments to using Pro based python 3.x scripts will need to upgrade their servers to Windows Server 2016. I don't think ESRI has this in their documentation as a dependency.
Make sure that the account the job is running under has a named user account with AGOL or if it is a service account then configure your batch server as a Concurrent Use license. This will eliminate the licensing issues on the batch server.
I use Windows Task Scheduler to call Powershell to call Python. (Not ArcGIS Pro workflow, but I believe you can adapt it.
-ExecutionPolicy Bypass -File "\\somepathhere\GIS\Scripts\ORACLE_TO_SQL\oracle_to_sql.ps1"
I would suggest that you add a ton of random logging to a text file in the same directory to be sure it works!
In case someone else stumbles across this thread, we are running our ArcGIS Pro, Python 3.x scripts on a Windows Server 2008 R2 machine (same machine that runs our ArcGIS Desktop/Python 2.x scripts) and it appears that you need to do a few things to be successful with running ArcGIS Pro/Python 3.x scripts:
1) Install latest version of ArcGIS Pro on the server where you're running the scripts. We're currently running ArcGIS Pro 2.3.3 at the time of this writing.
2) "Allow License Borrowing" on your ArcGIS License Server Administrator
3) On the server where you're running the scripts, log in as the user who will run the scripts, open up ArcGIS Pro, logged in as the user who will be calling this scheduled task, and go to backstage>>Licensing...and check the "Authorize ArcGIS Pro to work offline" option. Otherwise, you have to have ArcGIS Pro set to sign in as a user automatically that is the same name as a named user in ArcGIS Online (we don't have Portal).
One thing to note, that makes your scripts not work (and could make you think something else is going on), is if your ArcGIS Pro Python Package Manager is pointing to the default environment and/or your Python environment doesn't have particular libraries installed that you may be referencing in your script. So make sure you've got all those libraries installed on whatever environment you've chose in ArcGIS Pro!
Would you know in the scenario where you had concurrent use Pro licenses (instead of Named User licenses) if you would not need to borrow a license and just have the Windows Scheduled Task setup like it worked with ArcMap?
The scenario i've described is one where we're using the concurrent licensing. You just have to make sure you do step #3 in my above message (i.e. authorize ArcGIS Pro to work offline).
For Windows Scheduled Task, we use this for the Program/Script value: "C:\Program Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat" and then the path to the script (UNC if on a server).
If this still doesn't get you going, let me know.
I am just looking for some clarification on your last note in a previous reply "One thing to note, that makes your scripts not work (and could make you think something else is going on), is if your ArcGIS Pro Python Package Manager is pointing to the default environment".
Does this mean you need to clone the python environment on the Windows Server running the scheduled tasks even if you don't need any modules that are not in the default python environment?
Not sure. All my scripts use some non-default packages (e.g. pyodbc), so I just have to clone the environment (yes, on the server that's running the script). I would suspect you needn't clone the environment if you aren't using non-standard modules, but I guess there's one way to find out! ;>)