locked
Cannot connect from W2016 Server RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I am actually trying to setup the RDS role on a W2016 Server. It fails with cannot connect to remote powershell. I have gone through all the enable-PSremoting, disabling all group policies, disabling firewalls etc. but it keeps coming back to this error. Now I tested the remote capability of the server, and the strange thing is that I can access the remote powershell from a W2012 server just fine! I do Enter-PSSession -ComputerName <<W2016Servername>> on the W2012 server and it opens the session. Another W2016 server cannot connect, and this W2016 server cannot connect to the W2012 server either, while other W2012 servers can.

    So the issue seems to be that the W2016 servers cannot start to build the connection to an external server, it is not the receiving end that is not working but the initiating side. Has anyone got any thoughts on this?

    Thanks In Advance,

    Kind Regards,

    Theo Baarslag

    Monday, January 28, 2019 11:01 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    SOLVED! By me! Well, with a little help from another thread in another Microsoft forum. In one of the posts on the exchange forum I found a way to check on the actual proxy settings. I had checked them from the control panel, and they were set to the correct script settings as other servers. But when I checked them with:

    netsh winhttp show proxy

    , I found that it had the correct ip-address range as bypass list, but the named part was wrong (wrong domain, no idea why it took a different domain in there. That domain is known here on the network, but it is on the other side of the firewall). Also, the proxy server it wsa trying to get to, was one that is only reachable on the other side of the firewall.

    Long story short, I changed the proxy settings to the correct ones with netsh winhttp set proxy <etc>

    And now the problem with remote access to my powershell is gone. The RDS roles have installed properly and it is working now.

    So if you have checked that psremoting is enabled, but still you cannot get a "remote" session from this same server to itself, then it is time to check the proxy settings with this netsh winhttp show proxy. Apparently it needs to find itself by its full FQDN, using the proxy settings there.

    • Marked as answer by C.T. Baarslag Thursday, February 7, 2019 1:27 PM
    Thursday, February 7, 2019 1:27 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    First of all not all WSMan iplementations are compatible to eachother. So please check the installed PowerShell Version.

    if you want to enale psremoting use the cmdlet enable-psremoting.

    if your two Servers are not a member of the same Active Directory you have to configure the trustedservers switch

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.2" -Force

    regards Thomas Paetzold visit my blog on: http://sus42.wordpress.com

    Monday, January 28, 2019 11:25 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Thomas,

    thanks for the reaction.

    The two W2016 installations that I tried it with, and that both fail to connect to each other and themselves with a PSSession, are of the same version, only a different Revision number for some reason:

    Major  Minor  Build  Revision
    -----  -----  -----  --------
    5      1      14393  2636

    Major  Minor  Build  Revision
    -----  -----  -----  --------
    5      1      14393  2125

    But my assumption is that it is not that critical to connect when only the Revision number is different.

    The W2012 machine that these W2016 servers can connect to of course has a different version:

    Major  Minor  Build  Revision
    -----  -----  -----  --------
    4      0      -1     -1

    All servers mentioned here are part of the exact same Active Directory domain.

    Thanks,

    KR,

    Theo Baarslag

    Monday, January 28, 2019 2:14 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    if all Servers are a member of the same active Directory use the cmdlet

    enable-psremoting

    in order to activate the Remoting feature.

    regards Thomas Paetzold visit my blog on: http://sus42.wordpress.com

    • Proposed as answer by Nedim Sadovic Monday, February 4, 2019 10:43 AM
    • Unproposed as answer by C.T. Baarslag Monday, February 4, 2019 11:44 AM
    Monday, February 4, 2019 10:11 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I wrote in my original post that I had tried that PSRemoting, so no that is not the answer.

    Thanks anyway for your reply.

    KR,

    Theo Baarslag

    Monday, February 4, 2019 11:45 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    SOLVED! By me! Well, with a little help from another thread in another Microsoft forum. In one of the posts on the exchange forum I found a way to check on the actual proxy settings. I had checked them from the control panel, and they were set to the correct script settings as other servers. But when I checked them with:

    netsh winhttp show proxy

    , I found that it had the correct ip-address range as bypass list, but the named part was wrong (wrong domain, no idea why it took a different domain in there. That domain is known here on the network, but it is on the other side of the firewall). Also, the proxy server it wsa trying to get to, was one that is only reachable on the other side of the firewall.

    Long story short, I changed the proxy settings to the correct ones with netsh winhttp set proxy <etc>

    And now the problem with remote access to my powershell is gone. The RDS roles have installed properly and it is working now.

    So if you have checked that psremoting is enabled, but still you cannot get a "remote" session from this same server to itself, then it is time to check the proxy settings with this netsh winhttp show proxy. Apparently it needs to find itself by its full FQDN, using the proxy settings there.

    • Marked as answer by C.T. Baarslag Thursday, February 7, 2019 1:27 PM
    Thursday, February 7, 2019 1:27 PM