cearlockdavid

Just found this “You will need to be accessing PowerShell Universal locally in order to login with a Devolutions account. Docker hosting is not supported.”

I pulled down the latest ubuntu docker image after I read about the new developer edition. Well when you try to login using the devolutions account it redirects you to something like “http://127.0.0.1:60370/api/v1/signin/devolutions?returnUrl=” well obviously that is a problem. Even if I correct the url it doesn’t work. My docker compose does expose that port. Any ideas?

Well, I got it working completely by accident. I was rechecking everything and I saw that the no_proxy env had our local domain but not localhost and 127.0.0.1 so I added them and restarted the service. I was then able to login using SAML2. That didn’t make sense to me so I removed them and restarted the service again and it failed again. Again putting it back fixed it.

I have no idea why that would impact where traffic to https://login.microsoftonline.com/ gets routed to.

Thanks for the reply we do have the proxy set in the PSU admin menu and we also have those environment variables set. We have found that those things fix most of the proxy related issues as well but not in this case unfortunately.

Product: PowerShell Universal
Version: 5.6.8

I opened a support ticket because PSU is not using the defined proxy when attempting to connect to https://login.microsoftonline.com during the SAML2 authentication process. Since the traffic isn’t going through our proxy it is being blocked by our firewall and auth is failing.

The response I got after going in a few circles was “I will open an internal item with our development team so they can review this behavior and determine whether we can improve or document it in a future version. At this time I cannot promise any specific outcome or ETA.”

Saying I am not happy with that result would be an understatement. Having SAML2 working is a new requirement internally and bypassing the proxy is not an option.

Has anyone else run into this problem?

Product: PowerShell Universal
Version: 5.5.3

We recently upgraded one of our development servers from version 4.X.X to 5.5.3. Following the upgrade, the service fails to start and does not generate any logs only a generic “failed to start” message is displayed.

Notably, we successfully upgraded two other development servers without any issues. The only difference between the servers appears to be the Git branch specified in their respective appsettings.json files, which are otherwise identical.

We attempted to increase the service timeout, but this had no effect. The Windows Event Log does not contain any relevant or helpful information, and since the PSU logs are not being updated, we’re unsure what else to investigate.

We also performed a full uninstall (including sc delete), followed by a reboot and clean reinstall. Unfortunately, the issue persists.

Any suggestions?

Thank you, that is exactly what I needed!

Product: PowerShell Universal
Version: 5.5.3

In our environment, each developer has their own development server running a developer license, pointing to their own git branch, which flows up to the stage branch, which our QA PSU servers are connected to, and that flows up to our main branch, which our production PSU servers point to.

Well, the problem is job schedules. Let’s say another developer works on and adds an automation that runs on a schedule, and it makes its way into production when I pull down the latest changes into my dev branch, that job tries to run in my dev environment. Well, that isn’t desirable most of the time because my dev server doesn’t have the right environment variables, the required database running locally, or whatever.

It would be nice to enable or disable jobs and have that stored in the DB instead of a file that gets pushed into git.

That would also allow us to temporarily disable jobs in prod which isn’t allowed to write changes to git.

I would also be open to any other suggestions on how to handle this. There might be a better way to handle this that I am not aware of.

Adam helped me solve the problem today. The solution was to add the local host to the “no_proxy” environment variable. I added the actual hostname of the server, the URL used for the web interface, localhost, and 127.0.0.1 and restarted the service. Then everything worked as expected.

Internally Signed Certs

I added this yesterday. I was thinking it might have caused the current problem with being stuck on the loading screen.

“Api”: {

“SecurityModel”: “Permissive”,

“TrustCertificate”: true,

“URL”: “https://psudev.x.x”

}

All of our servers are Windows Server 2022. We use the MSI installer for all, and we do not run IIS.

Our production and QA servers are running 4.4.1. Both our prod and qa systems are behind load balancers.

Each developer has a developer server configured the same as Prod and QA.

Production points to the main git branch, qa points to a branch named stage and each developer has their own branch for dev.

The problem I have described is happening on my dev server, which I just upgraded from 4.4.1 to 5.5.3.

I hope that answers your questions.

I am having several issues.

The first issue was this KB0081 - unknown certificate lookup failure during git sync but the solution was to add “ExternalGitClient”: true, to the appsettings file and not the solution listed in the kb.

I was also having an issue when trying to invoke an endpoint. Error “The proxy tunnel request to proxy ‘http://restrictedproxy.xxx.xxxxx.com/’ failed with status code ‘502’.”

I opened a support ticket yesterday but haven’t heard back yet.

However, when I arrived this morning, the website wasn’t working, so I restarted the service. Now, I’m unable to get past the loading screen after logging in. I didn’t see anything useful in the log so I went trying to figure out how to enable more logging which got me to asking questions about the appsettings.json settings in this thread.

Product: PowerShell Universal
Version: 5.5.3

Is the documentation here ( App Settings | PowerShell Universal) up to date and complete?

Recommendations from the forum seem to contradict the documentation. I am working through several issues after the upgrade, and not knowing if the forums or the documentation are correct is complicating things.

Product: PowerShell Universal
Version: 4.4.1

I am trying to use PSU endpoints within Microsoft Copilot Studio, but Copilot doesn’t like the swagger file. It says, “Illegal state: Invalid OpenAPI specification.”

Is anyone else using Copilot Studio to access PSU endpoints?

Update

I tried creating a custom connector in PowerApps and got this.

Product: PowerShell Universal
Version: 4.4.1

We have two staging PSU servers behind a load balancer. They connect to an SQL DB and are set up for two-way sync with the staging branch in Git.

We have two production PSU servers behind a load balancer. They connect to an SQL DB and have a one-way sync set up to the main branch in git.

When the code is ready to move from staging to production, we merge it from the staging branch to the main branch.

We currently develop on the staging servers, but we want to start developing locally.

The idea is to do feature branches off the staging branch and use them locally. Then, merge those branches into the staging branch for testing before merging them into the main branch.

My question is, does that make sense? Is there a better way? How does everyone else handle this?