Error executing job: Access is denied

PowerShell Universal
1 
Product: PowerShell Universal
Version: 2.5.4 & 2.4.0
PowerShell Version: 5.1 & 7.1.4

I am having issues running a script with a “Run As” account. This is using an account which is an Admin on the box, and has also been given the “Log on as a batch job” user right. I can also see this on a non-admin account that was given the user right, but only after a permission is given that I will post about separately.
This was first noticed after the November patches from Microsoft was applied to our enterprise, however I cannot confirm if it was working before that.
The test server is now running version 2.5.4 after upgrading from 2.4.0 with no change. Our production server running 2.4.0 still is also seeing the same results.
When ran the job shows as failed, and when hovering over the failed the message shown is the “Error executing job: Access is denied.”. There are no errors shown from the job and the job produces no output. When looking at the log in “C:\ProgramData\PowerShellUniversal” I can see the call results in an exception as follows:
2021-11-17 15:10:00.181 -06:00 [INF] Error executing job 20378: Access is denied. at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.UpdateHasExited()
at System.Diagnostics.Process.get_HasExited()
at UniversalAutomation.Services.GrpcExecutionService.ExecuteScript(Job job, ExecutionEnvironment environment, executeScriptRequest request, ExecutionCallback executionCallback) in D:\a\universal\universal\src\Universal.Server\Services\Automation\GrpcExecutionService.cs:line 80
at UniversalAutomation.ExecutionService.ExecutePowerShell(Script script, IEnumerable`1 parameters, Job job, Schedule schedule, ExecutionCallback callback) in D:\a\universal\universal\src\Universal.Server\Services\Automation\ExecutionService.cs:line 617
at UniversalAutomation.ExecutionService.TryExecute(Job job, Schedule schedule) in D:\a\universal\universal\src\Universal.Server\Services\Automation\ExecutionService.cs:line 324
at UniversalAutomation.ExecutionService.Execute(Job job, Schedule schedule) in D:\a\universal\universal\src\Universal.Server\Services\Automation\ExecutionService.cs:line 244 System.ComponentModel.Win32Exception

2

This one is strange. What’s happening is that the service account no longer has access to the child process that it just started after it’s been elevated.

I have no idea what permissions you would have to set in order to avoid this. I’ve made a fix to the 2.6 code base to avoid this by putting some error handling around our “HasExited” check. If that check fails, it will no longer fail the job.

3

So if you just wrap the HasExited with a catch, will that then mean that it will not know if it finishes the job, and not be able to gather the output from the job? For the use case I am working on I don’t think I need the output or to know it’s done, but I’m sure we will need that in the future, just wondering if this means there will be a loss in functionality. Thanks.

4

It will still know because we make an RPC call after that check and wait for the result. The reason the HasExited check exists is because if the process exits before the RPC call is made, it was returning a less than helpful error. With HasExited, we can check the exit code and stuff. That said, I hardly ever see the process exit before that RPC call is made so it shouldn’t be an issue.

1 Like