Product: PowerShell Universal
Version: 2.3.0
Hi @adam , are there any known issues with creating a PSSession in version 2.3.0? Since upgrading from 2.2.1 to 2.3.0 , I have been receiving an error specifically when trying to create a new PSSession within my dashboard. It was working as expected prior to upgrading.
Not that I’m aware of. Can you let me know what the error is?
I’m attempting to run the following:
$Session01 = New-PSSession -ComputerName “Server1”
The .Net exception is:
System.Management.Automation.Remoting.PSRemotingTransportException
The way my dashboard code is set up, it still creates and displays the dashboard, but because I cannot create a session on the targeted server, I can’t pull the data and therefore my UDTable is empty.
The one thing that might be affecting this is the environment that dashboard is running in. Can you check to see the environment is set correctly?
Check here:
The Environment is set to default. The strange part is, I have receiving an “Access denied” error when running the dashboard but I can open a powershell window with the same credentials and enter a pssession on the same computer.
Try setting the environment to PS 7 or PS 5.1 (which ever you are trying to use). Or set the default environment in Settings \ General to PS 7 or PS 5.1.
No luck when setting the environment to PS 7 or PS 5.1. I tried setting it to each (one at a time) in the dashboard settings as well as the general settings. It’s still failing specifically when it tries to create the PSSession on the targeted server.
How are you hosting PSU? Did you install via MSI?
I am running PSU as a Windows service. Everything was working fine prior to updating PSU from 2.2.1 to 2.3.0 (this was to resolve the issue of not being able to access the dashboard using the hostname, which it did resolve). After upgrading to 2.3.0 by running “PowerShellUniversal.2.3.0.msi” this Session issue started.
Did you set service account for your service previously or were you running with the default local system account?
I’m still using my personal domain credentials right now (same as before). Down the road I’d plan on creating a service account used only for my dashboards.
Just so I’m understanding correctly. You have the service set to run as your local account and not the Local System Account?
As I went to verify this, I found the culprit.
So when I was on 2.2.1, the Windows service was set to run with the settings log on as “this account” as in the picture below. After updating to 2.3.0, that must have been flipped back to “Local System Account” and that was why I could not successfully create a session.
That leads me to ask, how can I get the PSSession to be created with the user’s credentials instead of the account running the dashboard? Currently, when the user accesses the dashboard, they are prompted to enter their username and password. I’m successfully pulling $User data. How can I pass their password into the New-PSSession command?
@mtndrew11, we use Dashboards and APIs in our environment to connect to many different O365 services. We often have to connect with different service accounts. We use an on-prem database to store all our credentials (encrypted of course). Then in the script we pull back those credentials from the database. We have a rather mature environment so that may be out of scope for you.
You could simply create a $cred variable in your $profile which loads whenever PowerShell loads and then reference it in the script whenever you want to call New-PSSession. You have have to setup the account on the server.
$profile
# Define clear text string for username and password
[string]$userName = 'MyUserName'
[string]$userPassword = 'MySuperSecurePassword'
# Convert to SecureString
[securestring]$secStringPassword = ConvertTo-SecureString $userPassword -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($userName, $secStringPassword)
Script:
New-PSSession -Credential $cred
If you’re doing this for multiple accounts which have elevated permissions I would recommend storing the password and username values in a secure way. Azure KeyVault is a good solution if you have access to the internet from your server
Thanks @zalcorshark. My goal is to use the user’s credentials and not necessarily service accounts. The following is the workflow I’m walking through:
I’ve tried referencing $Credential in the authentication.ps1 file but that is not storing their username/password as I was expecting.
My recommendation is to use a service account for this. If the data you are accessing is user specific lock down the dashboard and use the $identity variable to alter how your data returns to the end user
Adam pointed me in the right direction for storing the credentials as secret variables: