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.