Forum Discussion
Attempting Powershell Remoting but experiencing errors
Hi, all.
I'm attempting to use PowerShell Remoting and came across this article, which also addresses the double hop issue, but I don't even get to that part.
https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/
Powershell Remoting is enabled on both Server VMs and I tested the connection between the two. According to the command
"Test-NetConnection ServerName -Port 5985", the connection between the two Servers is good.
Also tried increasing the "MaxEnvelopeSizekb" to 8192
Following the instructions, I run this command: (removed the actual computer name and domain/usn) but receiving these errors:
Invoke-Command -ComputerName RemoteServerName -ScriptBlock { Register-PSSessionConfiguration -Name GP4WinScript -RunAsCredential domain\username-Force }
WARNING: When RunAs is enabled in a Windows PowerShell session configuration, the Windows security model cannot enforce a security boundary between different user sessions that are created by using this endpoint. Verify that the Windows
PowerShell runspace configuration is restricted to only the necessary set of cmdlets and capabilities.
WARNING: You are running in a remote session and have selected the Force option which means the WinRM service may restart.If the WinRM service restarts then this remote session will be terminated and you will need to create a new
session to continue
[RemoteServerName] Processing data from remote server RemoveServerName failed with the following error message: The I/O operation has been aborted because of either a thread exit or an application request. For more information, see the
about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (RemoveServerName:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : WinRMOperationAborted,PSSessionStateBroken
Pleas help! Thank you.
4 Replies
Hi MBee
The error you're encountering is behavior when using Register-PSSessionConfiguration with the -Force parameter in a remote session. The warning messages are telling you exactly what's happening - the WinRM service is restarting, which terminates your current remote session.
Would running the script on that remote host as a scheduled task be an option for you for instance?Hi MBee
From a security perspective, using CredSSP is less of an issue than the approach outlined in the 4sysops article.
In order of preference from most to least, I'd recommend:
- Kerberos constrained delegation;
- Enabling and using CredSSP;
- 4sysops article (which, frankly, I would never use).
With respect to the error, the clue for the final error in red is right there in the second warning in yellow/orange: Using the -Force parameter results in the remote WinRM service restarting, which in turn leads to the I/O operation being aborted. In other words, this is an expected outcome.
Getting back to CredSSP, it may pay to check that it hasn't been disabled by mechanics such as Group Policy, Intune, System Center Configuration Manager, etc. first, otherwise, you won't be able to use it.
Assuming it hasn't been disabled, then the following commandlet has all the examples you need to enable it on both sides, where the computer making the outbound call is the client and the remote server on which the command is being run is the server - it has nothing to do with the operating system being Windows Servervs. 10, 11, etc.
Cheers,
Lain
Hi, LainRobertson.
Thank you very much for the response!
I've been reluctant to use those methods and just tried a few articles like the aforementioned one that states "solve the double-hop" issue and followed blindly., but couldn't get the commands to work.
I will try
- Kerberos constrained delegation;
- Enabling and using CredSSP;
as suggested.
Thank you!
Hi MBee,
Between Kerberos constrained and CredSSP, you will find CredSSP easier to implement and maintain.
If your jump host (the server in the middle) is going to talk to a lot of constantly changing remote servers, you might want to just run with the CredSSP approach.
Kerberos constrained is more secure than CredSSP but you might find the ongoing administration overwhelming.
The only point I wanted to make in my original reply is that the 4sysops article is the least secure option of all three. So, even if you settle on CredSSP instead of Kerberos constrained delegation, at least it's a more secure option than what's in that article.
Cheers,
Lain
