Hi there, I have a command running in Universal Dashboard that is resulting in errors. I’ve been through lots of troubleshooting already, and the only way I can get it to work is with elevated powershell.
Is there any way to make the powershell instances spawned by Universal Dashboard run elevated?
Thanks @BoSen29, do you think there’s any way to have all PS processes spawned by UD run the same way? It’s going to be fairly hard to spin up a start-process given the number of parameters involved.
AFAIK there is no solution for this.
Why does the script require elavated access? How are you hosting your Universal?
I’d take a look at Process Monitor, and see what fails when your run the script as non-elavated and manually fix the required permissions.
Could you elaborate what said script does?
If none of these works for you, try the “Start-Process”, should simply be to wrap your scriptblock as a string and add it as a -argumentlist to start-process.
Thanks @BoSen29, I’m hosting on IIS. The specific use case is that I’m trying to call RDS related cmdlets, like Get-RDServer. Whenever I call this, it results in an error stating that the RDS farm cannot be found, indicating an authentication or authorisation error. Even logged in as the same user IIS is running as (with permission to call this command), it only ever works when you call it from an elevated PS window. The commands have been translated directly from the previous version of UD (before it was PS Universal with the new web UI).
From what i remember, all the RDS related CMDlets depends on PS Remoting, the auth error also comes if the application Pool identity doesn’t have “Load User Profile” enabled, can you validate this?
Can you via the Admin terminal to “Enter-pssession” to anther host, to validate?
Hi @BoSen29, thanks for your continued assistance and apologies for the delay.
I’ve attempted Load User Profile = True with no success, however have found that when I Enter-PSHostProcess for the PID the dashboard is running as, the commands work as expected.
It’s really strange as the previous version of UD (prior to the Universal app) still works fully in an application pool with identical configuration.
@BoSen29 - I’ve done a lot more investigation and found that even though the cmdlets were throwing errors that seem prohibitive, they still outputted the right values. I’d made an error further down that resulted in the data not being displayed.
I got caught on this error thinking it was the reason for displaying no data, which under normal circumstances I think it should be.