8

I'm trying to connect to a non-domain joined remote Win2008R2 server using PS from a Win8 host (same subnet, it's a local VM). Tried everything I could find, nothing works.

SERVER:

PS C:\Users\Administrator> winrm quickconfig
PS C:\Users\Administrator> enable-psremoting

CLIENT:

PS C:\scripts> $cred = get-credential -username "administrator" -message "Enter password"

PS C:\scripts> $sess = new-pssession -computername 10.10.106.2 -credential $cred -authentication default
new-pssession : [10.10.106.2] Connecting to remote server 10.10.106.2 failed with the following error message : The
WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the
TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts
list might not be authenticated. You can get more information about that by running the following command: winrm help
config. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:9
  + $sess = new-pssession -computername 10.10.106.2 -credential $cred -authenticatio ...
  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : ServerNotTrusted,PSSessionOpenFailed

PS C:\scripts> winrm set winrm/config/client '@{TrustedHosts="10.10.106.2"}'
WSManFault
Message = The client cannot connect to the destination specified in the request. Verify that the service on the dest
ination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running o
n the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the
destination to analyze and configure the WinRM service: "winrm quickconfig".
Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is run
ning and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destinat
ion, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination t
o analyze and configure the WinRM service: "winrm quickconfig".

PS C:\scripts> $sess = new-pssession -computername 10.10.106.2 -credential $cred -usessl
new-pssession : [10.10.106.2] Connecting to remote server 10.10.106.2 failed with the following error message : WinRM
cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over
the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By
default, the WinRM firewall exception for public profiles limits access to remote computers within the same local
subnet. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:9
  + $sess = new-pssession -computername 10.10.106.2 -credential $cred -usessl
  +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin   gTransportException
    + FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed

Oh and RDP works fine between those two hosts with the same credentials.

Even this works:

PS C:\scripts> Get-WinEvent -computername 10.10.106.2 -credential $cred
12

On client side

winrm quickconfig
winrm set winrm/config/client '@{TrustedHosts="Computer1,Computer2"}'

On server side

Enable-PSRemoting -Force
winrm quickconfig

for https

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="_";CertificateThumbprint="_"}

for http

winrm create winrm/config/Listener?Address=*+Transport=HTTP

Test with

Test-WsMan ComputerName
Test-WsMan ComputerName -UseSSL

Edit: Set TrustedHosts with PowerShell

Or with PowerShell (as Admin)

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "Computer1,Computer2"

And check (don't need Admin for that)

Get-Item WSMan:\localhost\Client\TrustedHosts
4

Your problem, as found in one of those error messages is:

If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting.

Basically, you need to either set WinRM to use HTTPS (rather than the default HTTP), or add the machine you're connecting from as a Trusted Host on the machine you're connecting to.

  • I can't use that command since there is no valid certificate on the server. As you see in my original question, I did try to add the machine to the trustedhosts on the client side. Do I need to do the same on the server side too? – Dendory Jan 7 '15 at 16:49
  • RDP into the remote server, and set the Trusted Hosts from your RDP session, if that's the way you want to go about this. I think it's easier and a lot better to just set WinRM/WinRS to use HTTPS instead of HTTP on all the computers I manage (for more reasons than just this particular issue), but I guess that's your call. – HopelessN00b Jan 7 '15 at 16:53
  • Yeah but PS HTTPS apparently requires a real certificate (not self-signed) along with a public DNS name. Why doesn't it use the same encryption as RDP? Don't need anything special for it. This is a local VM for development and such, no choice, can't get a public CA for it. – Dendory Jan 7 '15 at 17:00
  • winrm set winrm/config/client '@{TrustedHosts="10.10.106.1"}' worked on the server, but I still get the same error messages on my client, it still won't connect. – Dendory Jan 7 '15 at 17:02
  • 1
    @Dendory WinRM over HTTPS works fine with a certificate issued by an internal certificate authority, provided you have the machine setup properly to trust the issuing CA. It doesn't require the machine to have a valid external DNS name, just that you use its DNS name, and that the certificate does as well. If that's not an option, for whatever reason, you'll have to hope that someone else comes along who can help you get it working with just the Trusted Hosts entry (entries?) - I just don't do it that way, because it's too much of a pain in the ass, and didn't seem to work reliably for me. – HopelessN00b Jan 7 '15 at 17:07
0

I finally got mine to work... where xxx.xxx.xxx.xxx is the IP Address.

PS C:\Users\Administrator> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
PS C:\Users\Administrator> Enable-PSRemoting -Force
WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.
PS C:\Users\Administrator> winrm set winrm/config/client '@{TrustedHosts="xxx.xxx.xxx.xxx"}'
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = xxx.xxx.xxx.xxx

PS C:\Users\Administrator> Enter-PSSession  -ComputerName xxx.xxx.xxx.xxx -Credential "~\Administrator"
[xxx.xxx.xxx.xxx]: PS C:\Users\Administrator\Documents>
0

My issue was for an instance hosted in AWS.

  • I had to open 5985 on the instance security group
  • I had to modify the firewall rule to allow 5985 for all profiles and any remote address

    New-NetFirewallRule -Name PsRemotingHttp -Direction Inbound -Action Allow -Protocol tcp -LocalPort 5985 -DisplayName PsRemotingHttp

I worked this out when I ran test-wsman:

"By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet."

0

After months of this problem, for me it turned out I needed to add both the IP of the Remote Server and it's DNS Name to the trusted hosts. Just adding the IP was not sufficient!

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.