Python 3.x Schedule Task with NT/SYSTEM or group managed service account (gmsa)

[KevinMorris2]

ESRI,

How do you create a scheduled task (Task Scheduler) on Windows Server 2019 that requires the use of either NT/System or a group managed service account (gmsa)? (These accounts do not have user account profiles). I am faced with increased IT security requirements for which we no longer are allowed to store credentials on the server for performing tasks and the use of ArcGIS Pro / Python 3.x in a concurrent licensing option (which we are provided) only appears to work for an account for which licensing is established and the user has opened ArcGIS Pro. When I first set up arcgis PRO on server with a standard service account, after configuring licensing I was able to get scripts to run in task scheduler. This makes sense as the full context of licensing and security access is available. However, I am forbidden to store credentials for this task, so the task must be run while the user is logged on and the login secession must be maintained for the service account. This is problematic as IT has also instigated a new automatic policy that requires servers to be rebooted weekly. When this automatic reboot happens, the login session is terminated and when the server (virtual) is brought back online, tasks no longer run.#

It would be extremely beneficial for ESRI to provide users a context on common pitfalls and how to utilize the full arcpy and arcgis libraries on servers that have checked out licenses (concurrent) for accounts that may not have user profiles.

Scripts typically use python arcpy and/or arcgis libraries (ArcGIS Pro 2.5.1 or 2.6.0)

Perhaps unrelated, I also notice a severe degradation (4-10x slower) of running python scripts through SQL Job agent now that I have upgraded from 2.x to 3.x.

Please note this thread is a variant of  Python 3.x Scheduled Task Fails . Review of this thread indicates that further clarification is needed.

[JoshuaBixby]

I see what you are getting at, and more clarification from Esri would be good, but there are a couple of statements that caught my attention.

Regarding:

how to utilize the full arcpy and arcgis libraries on servers that have checked out licenses (concurrent) for accounts that may not have user profiles.

If you mean "checked out" in the borrowed sense, I think the answer is don't.  A checked-out/borrowed license is user specific and must be stored locally, so trying to check-out/borrow licenses in a situation like you describe will cause issues.  One issue you already described where rebooting the server and having local profile information purged/wiped will cause the license to go away.

From a license management perspective, using a checked-out/borrowed license in your situation also causes issues because the license that is lost cannot be recycled back to the license server until the expiration period ends.  If the expiration period is 30 days and the license is lost after 7, you have a 21 day gap where the server thinks the license is deployed but it isn't.

Regarding:

concurrent licensing option (which we are provided) only appears to work for an account for which licensing is established and the user has opened ArcGIS Pro

Although what you describe is the most common way to configure concurrent-use licensing, i.e., a user opens up Pro and configures the license for concurrent-use, there are registry keys that can set licensing at the machine-level so that any user who newly opens ArcGIS Pro will inherit the settings.  See the registry settings in Localized and silent install options—ArcGIS Pro | Documentation documentation.

I operate Windows servers in a similar environment as you describe, and we successfully use ArcGIS Pro with service accounts.  That said, we license using Single-Use instead of Concurrent-Use, but I suspect Concurrent-use will work like Single-use if the registry keys are properly set.