PowerShell: Running the Get-Command command in a remote session reported the following error
-
just the obvious contact MS or maybe was "Netsh" done? to take control
-
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Import-PSSession -Session $Session
What if you try...
Import-PSSession -Session $Session -AllowClobber? -
@Osvaldo said in PowerShell: Running the Get-Command command in a remote session reported the following error:
just the obvious contact MS or maybe was "Netsh" done? to take control
MS does not provide support, that's not how MS works. Netsh doesn't apply in this case.
-
@dafyre said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Import-PSSession -Session $Session
What if you try...
Import-PSSession -Session $Session -AllowClobber?No luck. Identical error.
-
Seems like some kind of permissions or elevation error with how you are running or calling the script.
Any more details to add?
-
@Obsolesce said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Seems like some kind of permissions or elevation error with how you are running or calling the script.
Any more details to add?
What details would you like? Nothing has changed in elevation in a year. And it should not need elevation. It should run as a user. And when run locally, it does. It's the same user local or remote.
-
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@Obsolesce said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Seems like some kind of permissions or elevation error with how you are running or calling the script.
Any more details to add?
What details would you like? Nothing has changed in elevation in a year. And it should not need elevation. It should run as a user. And when run locally, it does. It's the same user local or remote.
Is that user ID a local Admin?
-
@Obsolesce said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@Obsolesce said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Seems like some kind of permissions or elevation error with how you are running or calling the script.
Any more details to add?
What details would you like? Nothing has changed in elevation in a year. And it should not need elevation. It should run as a user. And when run locally, it does. It's the same user local or remote.
Is that user ID a local Admin?
It is, yes.
-
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Using a script that has worked for a long time. It has been being used for a year, no issues. The one day, it just stopped. The script will still run fine when executed locally, but when called over SSH it gives this error:
Running the Get-Command command in a remote session reported the following error: Win32 internal error "Access is denied" 0x5 occurred while reading the console output buffer. Contact Microsoft Customer Support Services..A quick search on the error doesn't result in anything. We are functional, but not nearly as functional as we were before whatever update was done that breaks PowerShell yet again.
When was the last time Windows updates were installed? If this broke right after the install, it might be time to start uninstalling one by one to see what broke.
-
When local, can you run "Enable-PSRemoting -Force" to make sure something didn't inadvertently turn off remote PS execution.
Try this also, when you are local:
"Get-PSSessionConfiguration | Format-Table -Property Name, Permission -Auto"
See what it says about your permissions.
and lastly, is WinRM running? or need to be restarted?
-
@JasGot said in PowerShell: Running the Get-Command command in a remote session reported the following error:
When local, can you run "Enable-PSRemoting -Force" to make sure something didn't inadvertently turn off remote PS execution.
Seemed like we were getting somewhere. Clearly a connection had set itself to Public when it should have been Private. But after fixing that, still doesn't work.
-
@JasGot said in PowerShell: Running the Get-Command command in a remote session reported the following error:
Try this also, when you are local:
"Get-PSSessionConfiguration | Format-Table -Property Name, Permission -Auto"
See what it says about your permissions.Seems good...
-
@JasGot said in PowerShell: Running the Get-Command command in a remote session reported the following error:
and lastly, is WinRM running? or need to be restarted?
Was running. But restarted just in case, but no change.
-
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@JasGot said in PowerShell: Running the Get-Command command in a remote session reported the following error:
and lastly, is WinRM running? or need to be restarted?
Was running. But restarted just in case, but no change.
Is it just one PC it's not working on? Does it work on others?
-
@Obsolesce said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@scottalanmiller said in PowerShell: Running the Get-Command command in a remote session reported the following error:
@JasGot said in PowerShell: Running the Get-Command command in a remote session reported the following error:
and lastly, is WinRM running? or need to be restarted?
Was running. But restarted just in case, but no change.
Is it just one PC it's not working on? Does it work on others?
Only one to run it on. I'll have to find another machine to test against. It exists only for that machine.
-
@scottalanmiller I realise this is an old topic, but I've been fighting something similar all day. As it turns out, the implementation of PTY (and also TTY) has changed in recent versions of OpenSSH for windows. When the SSH session is built from within a script, the new OpenSSH implementation detects that the session is not setup from an interactive terminal, and therefore does not assign a PTY to the session, which results in the unability of the Get-Command command to send its output to STDOUT, hence the access denied error. Solution is (at least in the situation I am in) to use the -t (or even -tt) flag with the ssh command to set up the session
