I'm using Data Interop to pull data from a SQL database and overwrite a service in ArcGIS Online, all being done in Amazon Web Services on an ec2 instance (the database is in RDS). I created the Data Interop workspace, made a tool in Pro, and scheduled it to run. It runs successfully so long as I'm logged into the instance, but it won't run when I log out. I know I can change that to "run whether user is logged in or not" in Task Scheduler, but security best practice dictates using a service account to run it, so it can run continuously and without my credentials.
I have a service account set up, with local admin privileges and "logon as a service" capabilities, and I modified the Task Scheduler task to use that account to run, with highest privileges, whether user is logged on or not, configured for Windows 2022. Task Scheduler says it succeeds, but returns a 0x2 code, indicating some missing privileges or inability to find a file. Also, there's no record in Pro GP history or in the tool log of the tool running at all under this configuration (each run is logged when run with my user account), and the task "completes" in a few seconds, whereas it takes about 2 minutes when run successfully under my user account. I set explicit Read/Execute privileges for the service account on the Python environment python.exe location, the GP tool script location, and the Data Interop connections location, thinking that the account needed permission to read from those locations, but it didn't solve it. The Pro project file is stored under my user account location, but the service account should have permissions to access that all.
The only thing I can think is that somehow the service account can't run the GP tool Python script, or can't access the connections I have stored in the Data Interop workspace, because it seems like a permissions issue, but I don't know how to troubleshoot or determine what it does/doesn't have access to.
Any advice on how to make this actually run correctly?
For followers: Product team for Data Interop have recommended a test embedding the service account owner credentials into the SQL Server reader.
Hi Bruce,
Thanks for the update. I embedded the SQL Server user credentials in the reader, but the Windows Task is still not running successfully using the machine's service account. I'm seeing the same behavior as before. The task kicks off and finishes within a few seconds, reporting that it completed successfully, but returning a (0x2) code.