Remote powershell script works in Powershell, but not from Designer

Is User Account Control (UAC) disabled?

It was enabled on both source and destination servers. Tried disabling it, no luck.

Did you check the PowerShell script on the server using the user account the Job Service is running with?

Yes, and it works like a charm. It's only when the job is triggered from Object browser i get the error access denied. Maybe that has something to do with the error?

So, the script was started by the Job Service and it worked. But if you are running the script in the ObjectBrowser it does not. Are you on the machine running the Job Server with the Object Browser?

The process with the Parametervalue which creates the script, then sends the value of the script to a script component has server selection "direct:jobserver", so i know the service / Job is running on the correct server which has WINRM and trustedhosts.

Maybe the script component is running from another instance / Server?

Now, you have me confused. I am lost about where and when the error occurs, what the exact error message is and what the Object Browser has to do with it.

Sorry I was unclear in the last comment. I was just thinking out loud.

I'll try to explain it again:
- I have a process which generates the powershellscript in ParameterValue0 (using "thescript.Appenline(powershellcode)") and passes this to a script component 

- The same code directly in Powershell from the server that is our jobserver works fine. I can only run the remote powershellscript from that spesific jobserver, as there are FW openings etc implemented.

- I run the script from this server in Powershell and it works as it should.

Then to the part where I get confused:

- When i generate the Event named Event1 from Object browser, it's being processed in the jobqueue. The result is a Frozen process with the error message, access to the remote server <IP> is denied. 

The error occurs when running the script from One Identity. But concidering the error message, the script is triggered and I get the response from the REMOTE computer, but with access denied. This made me think that maybe the script component is triggered from another server in One Identity and not the job server.

So my question is: When running a scriptcomponent, is it being sent from the Jobserver or another server, like SQL?

Hope this makes it more clear?

Sorry I was unclear in the last comment. I was just thinking out loud.

I'll try to explain it again:
- I have a process which generates the powershellscript in ParameterValue0 (using "thescript.Appenline(powershellcode)") and passes this to a script component 

- The same code directly in Powershell from the server that is our jobserver works fine. I can only run the remote powershellscript from that spesific jobserver, as there are FW openings etc implemented.

- I run the script from this server in Powershell and it works as it should.

Then to the part where I get confused:

- When i generate the Event named Event1 from Object browser, it's being processed in the jobqueue. The result is a Frozen process with the error message, access to the remote server <IP> is denied. 

The error occurs when running the script from One Identity. But concidering the error message, the script is triggered and I get the response from the REMOTE computer, but with access denied. This made me think that maybe the script component is triggered from another server in One Identity and not the job server.

So my question is: When running a scriptcomponent, is it being sent from the Jobserver or another server, like SQL?

Hope this makes it more clear?

What execution server do you have configured at the process step for the PowerShell execution?

You can check the queue name used in JobQueue Info for your process chain.

The jobserver described. Direct:\Jobserver 

So, the JobServer listening to the queue name \Jobserver will fetch the process step for execution.

But you surely have checked the Job Service Log if the job server in question has executed your PowerShell, did you not?

Yes.

The only reason  I can think of then is that the service account user is either not allowed to run the PowerShell script correctly, or the executed script is not 100% the same as the one you have tested.

Either way, I think the options to help you further here in the community are exhausted.