Maybe this is an too early question, as there is no public code and still in development, but I would like to mention this:
Have you considered the user context (permissions) in that a script is running. If it is the same than the UA has been started, there can be situations where a script needs another user context than others.
I am looking at the Windows Scheduled Task feature to define the user context.
Maybe it makes sense to add a UserContext property or something like that.
An more specific example would come in place if the UA logged in user can just start or see specific scripts (UA permission concept).
An example that came to my mind is that a script is doing something in O365 that requires global admin permissions but the company IT doesnt want to give an admin constantly global admin permissions.
A service account with global admin is okay in order that its required for automation.
That is one example that is the case in the company I am working at.
I agree that this needs to be implemented but it isn’t part of the upcoming beta. It’s defintiely something we are thinking about.
One concept we were considering would be to use JEA to provide the delegated administration. That way we wouldn’t be managing it completely by ourselves and would be using a pre-existing PowerShell concept to configure it.
So the idea would be that UA helps with the use and deployment of JEA endpoints that all you to run scripts as other users but we do it through the JEA system.
I am looking forward to the addition of User Context. Without this we can’t really go away from Task Scheduler. I would echo the ability to run scripts with a variety of service accounts. I’ll keep my eye out for this feature.
