Installed with MSI as a service, running under system context.
Bit of a headscratcher here, fresh install, I’ve got mostly everything working.
However it seems that if I create a test script, and run it on a non integrated environemnt, it doesnt want to run.
It just hangs and eventually times out, with the following error:
‘Error executing job: PowerShell did not respond in a timely fashion. PowerShell Universal is currently waiting 30 seconds for PowerShell to start running the script.
You can increase the timeout by setting the ‘Job Handshake Timeout’ setting in the Settings \ General \ Automation page.
If you are still experiencing issues, you may need to consider increasing the resources available on your system or take advantage of the Random Delay parameter for schedules to stagger jobs.’
I installed PS 7.4.1 (tried wither other versions too).
I can see it’s detected as ‘Powershell 7’ (current ps version) but also ‘7.4.1’ in the environments list.
Also I can see the process ID in PSU for the job, and can see that pwsh.exe is runinng in task man - after a short while the process disappears although the job in PSU continues.
I’ve checked the logs and cannot find anything related or any errors generally.
I’ve tried setting execution policy to unrestricted in the system context (via psexec)
I’ve also deleted my environments.ps1, deleted my sqllite databases in the C:\ProgramData\UniversalAutomation\ folder, reinstalled PS core and reinstalled PSU, but still no joy. All the while, running these scripts or apps in the integrated environment works fine. Any ideas?
Hey thanks for this, thats likely the issue. My setup is super restrictive so my VM is configured via a proxy with limited outbound access. @adam - what are your thoughts on this one? is this something that can be added to the support for the setting ‘Proxy URL’ under settings\general\platform (if it isnt already part of that) - or alternativly is there a way to bypass this need all together so scripts can be run locally without that outbound access?
I’ve just put in a request for outbound access to that ip but things here can be slow at times, i’ll update once I’ve got connectivity, until then i’ll just use the integrated env.
Hmmm… just checked with my networking team, seems that *.digicert.com is already whitelisted and I’ve confirmed I can get to it. - although the issue is still present in PSU.
If it navigate directly to the address http://192.229.221.95/ though it shows access denied.
Do we think it’s being referenced by IP directly rather than hostname?
Frustratingly, I’m only allowed to use fqdn as we dont use ip’s in whitelisting rules.
This is a bit of a blocker for me at the moment.
It’s also an issue with SQL interaction too (since I need to run scripts as another user and can’t do that in the integrated enviornment)
I get ‘Welcome to nginx!’ when browsing to http://192.229.221.95/. We use a fortigate firewall which can distinguish CRL traffic from other traffic so we allow all CRL traffic.
Note that case sensitivity of these variable names is important, I had mixed results with upper case and weird behaviour that left me scratching my head for a while.
Lower case everything works as expected.
