Persistent COM Surrogates running Python scripts calling Pro and Location Sharing via Task Scheduler

[IngridHogle]

When I use Task Scheduler to run a Python script that references an APRX containing our Tracks layer from Location Sharing (Enterprise), and I am NOT logged in, a persistent COM Surrogate is created. I have a script I want to run every 5 minutes but cannot because these COM Surrogates build up and create problems.

I am looking for suggestions to avoid this issue!

Here are our specs:

• ArcGIS Enterprise 11.3 with up-to-date patching
• ArcGIS Pro 3.3.6 or ArcGIS Pro 3.5.2 (same result)
• ArcGIS Pro Named User license, online or offline, or ArcGIS Pro Advanced Single Use license
• Task Scheduler running with highest privileges, whether or not user is logged in
• Task Scheduler referencing C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\python.exe, pythonw.exe, or C:\Program Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat all have the same result
• User account running Task Scheduler scripts is admin on the machine 
• Multi-user, Windows 10 Azure Virtual Desktop running the scripts via Task Scheduler
• COM Surrogate details: C:\Windows\System32\dllhost.exe

The script in question creates polylines from Tracks collected that day and appends them to a referenced feature service. These allow users to see each other's tracks in the field, updated every 5 minutes, which is useful for ensuring complete coverage for our monitoring work. (Tracklines are automatically created from Tracks in AGOL, but sadly this functionality does not exist for Enterprise.) I can just stay logged into the AVD machine at all times to prevent COM Surrogate issues, but I have been told this is not a sustainable solution.

[TonyAlmeida]

Have you tried using ArcGis Pro's built in scheduler? do you have to reference the aprx?

I think ArcGIS Pyton API can  query & append without touching an APRX.

ArcGIS Python API

 

[HaydenWelch]

Is this happening with a Python script? If so have you looked into killing the interpreter after it runs? Could be that you haven't properly cleaned up the environment and since there isn't a user process to kill those locks.

[IngridHogle · Accepted solution]

Thank you, @TonyAlmeida and @HaydenWelch , for your suggestions. Our IT folks migrated us to a new, Windows 11 Azure virtual desktop (AVD) machine, we moved the automated scripts to this machine, and the problem went away! Phew!

I've been advised that the problem was likely something unique to the computers on which we were running these (Windows 10 AVD and an AVD Windows 2022 Server machine). I've been told that other customers are able to run Task Scheduler python scripts calling arcpy without this issue...and we did so for over a year before this started happening. It's a mystery, but all's well that ends well.