PSU 5.0.6 gRPC Errors

PowerShell Universal
1 
Product: PowerShell Universal
Version: 5.0.6

Hi all,

I’ll start with some environment info - we are running PSU in a nested IIS10 configuration on a Windows server. The application pool and application were set up with the applicable setup guides for v5. We use a nested folder structure of {...}\inetpub\<version>\ acting as the version root folder, with bin and data folders underneath. Anonymous authentication is enabled at the global level within IIS, as well as for the site version we are using.

I’m having some issues when I’m running various scripts from within PSU, of any level of complexity. I have yet to get any call that references a PSU cmdlet, such as Invoke-PSUScript or Get-PSUFolder. Every time I try to run these commands, with various parameters included or excluded, I am met with the following gRPC error:

Status(StatusCode="Internal", Detail="Bad gRPC response. HTTP status code: 400")

Take the following, for example. I have an event hub, EH_MDM, with a single connected computer. The agent logs on the connected computer are showing the connection successful, and the connection shows up within the event hub connections themselves. Therefore I am led to believe the connection is good.

Now, when I attempt to run the following command from within a script:
$Connections = Get-PSUEventHubConnection
I get the above gRPC error. I have tried with various combinations of passing app tokens, a computer name, and the -TrustCertificate flag (even though we have adjusted this behavior with the environment variable $env:PSU_TRUST_CERTIFICATE = $true). None of these options offer any different error codes or more information.

As I stated prior, this also happens when attempting to access any PSU resource from within a PSU script. This is causing us to not be able to invoke scripts from within our apps, or otherwise structure our application modularly. I have yet to get one of these commands to work since 5.0.1, and have tested on 5.0.1, 5.0.4, 5.0.5, and now 5.0.6. For contextual reasons while looking through the forums, I’ve noticed people mentioning their Invoke-PSUScript behavior is as is expected (in examples such as this), so I am assuming that it is a configuration mistake I have made.

Tl;dr: I’m looking for any help I can find to get our intersite scripts and commands to stop giving this gRPC error. Is there some IIS configuration I may be missing? As I stated prior the setup was done right along with the relevant guides. I’m not even sure where to begin looking. Any help is appreciated!

:wavy_dash:ZG

2

this issue persists after an update to 5.0.7, at which point i created a new non-nested IIS site off a separate application pool with fresh binaries.

3

i am able to use these cmdlets from within my terminal on my local computer. i tested with Connect-PSUServer -ComputerName $Server -AppToken $AppToken successfully, however as soon as i move that command into the system, through a terminal or through a script, i am met with these errors. i am able to get a different gRPC error since switching off a nested configuration, however:

Failed to connect to server with gRPC. Attempting gRPC-Web.Status(StatusCode="Internal", Detail="Error starting gRPC call. HttpRequestException: The HTTP/2 server reset the stream. HTTP/2 error code 'HTTP_1_1_REQUIRED' (0xd).

4

And now the issue has expanded - since moving off the nested setup, my agents will no longer connect to the server. They are getting the same gRPC stream reset message as the internal commands receive now.

5

Do you use a proxy for outbound connectivity at all?

6

@insomniacc
We do use an outbound proxy, but so far in our development everything we are connecting to the server with is on the same /16 network.

With this one, the agent is actually on the same /24 network as the server we are trying to connect on. To my knowledge there is no reason it would leave via the proxy just to route itself back, but I may be wrong. The proxy is also non-negotiable (it comes from higher up than we are able to control). Thanks for bringing that variable up; I hadn’t thought of that before!

7

The reason I mention it, and what you have may entirely be a different issue, but I had all manor of problems with blocked gRPC calls while using squid proxy for my outbound connections.
I was also confused because they’re internal/local connections but apparently my squid proxy was blocking them, in the end I had to set environment variables for http_proxy, https_proxy and no_proxy for the bypasses ‘127.0.0.1,localhost’ (all lower case - upper had issues). Worth a stab in the dark maybe?

8

Absolutely - thank you so much for that info! I’ll play with it and see what happens!

9

In light of that and the expansion of this issue into additional facets since opening the post, I’m going to put in a support ticket. I’ll respond back here with any resolution steps or enlightening information to help future users just in case.

10

@parzog - did you ever get an update on this one? Just curious as I’d like to migrate from v4 to v5 at some point, I tried it on the initial launch but there was too many problems so reverted back to v4 until it was in a more stable state.

11

Have you tried the most recent GA release (5.0.15)? It’s been stable and I haven’t had any show-stopping issues on it so far. 5.0.14 and lower, however, were different stories, and especially the initial 5.0.x releases - those were unusable and I had to revert to 4.x as well for a while until some of those big bugs got fixed. The new Integrated mode that came with 5.0.15 should solve the gRPC issues since it lets PSU behave like 4.x did and not require any authentication internally.

12

Our server wasn’t running Server 2022 IIS which was causing issues with HTTP2 and gRPC. The workaround was disabling HTTP2 at the time, but since then we have upgraded and everything is running smoothly.

@Jesse.Peden thanks for the recommendation - we’ve been in a bit of a holding pattern since 5.0 of staying on a version with bugs that are at least workaroundable, but it’s good to know it should be okay to move to 5.0.15. I just have a bad habit of waiting for my specific issues to be addressed before upgrading…

1 Like
13

I’m with you. I do the same thing. 5.0.15 fixed a critical bug I reported in 5.0.14 (even though 5.0.14 fixed another few bugs I ran into in 5.0.13 and below), so I rolled back to 5.0.13 which was mostly stable until 5.0.15 came out. 5.0.15, so far, has not shown me any errors or problems. I think it should be safe for you and @insomniacc to give a whirl. Your calls, though, of course.

1 Like
14

Appreciate the updates and I’ll take your recommendation - probably in December at some point. I started on initial releases for v5 and decided to roll back with some fundamental issues at the time but it sounds like that’s mostly sorted now!

I’m using PSU basically as an IGA solution at the moment for our IAM recertifications so it’s in full swing until a couple of weeks time! We have over 600+ users coming in to review data (upwards of 40k entitlements being reviewed) so I’m putting the solution through its paces but it’s keeping up and working really well!

2 Likes
15

Nice. We use it as a middleware for some systems that otherwise can’t talk together, and to keep some info updated between Azure and our documentation repository, dashboards, etc. We don’t have a ton running in it but some of those items peg PSU at 100% CPU for multiple hours each night, so we push it pretty hard.

1 Like
16

It’s really nice to hear about other use cases!! We don’t push it to its absolute limit, but we are building a suite of web-based applications to replace our former desktop applications for a lot of our IT day-to-day drivel, focusing on it from an RPA solution perspective; one of our apps for example leverages an event hub with multiple connections, two API endpoints, three scripts, and the app itself. It really is a world’s-your-oyster kind of application!

2 Likes
17

The first thing we used it for was to tie one of our clients’ Juniper Mist setups to their Palo Alto firewalls so that the wireless clients could be tracked via UserID and then allow for dynamic policy mapping. The API systems don’t have a way to talk directly so we use PSU to make some calls after receiving some webhook triggers from Mist, to pull down the client data and then send it to the Palo Alto APIs for ingestion.

1 Like