I have an instance of Powershell Universal spun up here.
I find that no matter what i seem to do, i cannot get any scripts to execute whatsoever.
I can have the application pool running as EITHER a service account or localSystem. Both result in the same issue. Additionally, i can execute the script with either the default credentials OR a vault credential. This is also the same. It is always the same error:
[INF] Error executing job 20: Did not receive port from client process. at UniversalAutomation.ExecutionService.ExecutePowerShell(Script script, IEnumerable`1 parameters, Job job, Schedule schedule, Int32 port, ExecutionCallback callback) in D:\a\universal\universal\src\UniversalAutomation\Services\ExecutionService.cs:line 369
at UniversalAutomation.ExecutionService.TryExecute(Job job, Schedule schedule) in D:\a\universal\universal\src\UniversalAutomation\Services\ExecutionService.cs:line 273
at UniversalAutomation.ExecutionService.Execute(Job job, Schedule schedule) in D:\a\universal\universal\src\UniversalAutomation\Services\ExecutionService.cs:line 138 System.Exception (7641744a)
Any thoughts? I’m just trying to get this up and running here. My test script is quite literally:
What version of Windows are you running on?
If you run outside of IIS, do you experience the same issue?
Server 2019 Standard.
I haven’t tried running it outside of IIS.
Ideally, I want this setup in a somewhat complicated manner. Long story short, our environment has three completely seperate AD domains. I’m going to need to reach into all of them. Thus, ideally i can run this in IIS under an MSA account. That account is granted access to our secret vault server, Thycotic.
I use a custom powershell function to grab service account credentials from the secret vault, which can then be used to reach into the three domains (IE, one service account per domain). That part is another story. Ideally, I’d like to have it store these on a scheduled sync in the local vault, reaching out to Thycotic every so often to sync them down if they update.
What’s the difference running this as a service? It HAS to be run on HTTPS ports. I assume I can do that running as a service instead?
Ok. Good to know.
IIS complicates the hosting deployment so as a debugging step it might be nice to run it as a service and as a regular user (just launch the Universal.Server.exe) to see if any of those configurations work. That will help rule out it totally being broken in the environment for some reason and we can start working into IIS hosting.
When running in IIS, IIS starts the w3wp.exe process as the app pool user which then starts the Universal.Server.exe process and some weird stuff happens in terms of process privileges. PSU should be able to run in IIS but it typically takes some messing around with accounts and privileges.
When running as a service, the service control manager starts Universal.Server.exe directly so there isn’t a the strange privilege scenario we run into in IIS. You’ll still need to follow the guide on setting up service accounts but there are less moving parts. https://docs.ironmansoftware.com/config/running-as-a-service-account
You can setup the Kestrel web server in PSU to use HTTPS: https://docs.ironmansoftware.com/config/hosting#configuring-https
The error that you are seeing is that it’s attempting to start the external PowerShell process and it’s failing to communicate with it.
Yeah, it’s working when running locally with the .exe.
I’ve gone through the user right’s assignment settings. All items specified in the doc are granted to my MSA account.
What might I be missing here? I granted my MSA account local admin on this system, in addition to all of the user right’s assignment items.