Everybody knows that security is a big deal, especially when your servers are internet-connected.  When an administrator wants to protect a machine from possible remote attacks, a common quick-reflex defense is to block incoming traffic on ports 80 and 443, so that no messages can be sent to the machine via the internet.  However, if you also block management commands, it will be hard to diagnose and fix any possible damage that was done to the server, or to patch the security hole that prompted the shutdown in the first place!  Because of scenarios like this, the smart approach is to direct management traffic and web traffic to different ports.

 

In lieu of this, the default ports used for WS-Management and PowerShell remoting have been changed to 5985 an 5986 for connections over HTTP and HTTPS, respectively.

 

This means that, unless otherwise specified, all WS-Management listeners that are created will accept traffic on these ports, and all connections created will go through these ports, including listeners created using the commands winrm quickconfig or Enable-PSRemoting.

 

 

Though we recommend using these new ports for the sake of security, we also understand that there are some situations where moving to these new ports is either tricky or impossible.  If changing to these new ports will wreak havoc on your existing deployments, don’t worry – there are mechanisms in place to make it easy to maintain your current configuration.  If you want to accept traffic on ports 80 and 443, you need to use the new compatibility listeners.

 

The compatibility listeners are not directly addressable like your other listeners, meaning they can’t be retrieved using a WS-management get operation and their settings can’t be modified.  When you enumerate your active listeners, these special listeners are tagged with the string [Source=”Compatibility”] to distinguish them from the rest.  For example, the second listener below is a compatibility listener:

 

C:\Windows\system32>winrm e winrm/config/listener

 

Listener

    Address = *

    Transport = HTTP

    Port = 5985

    Hostname

    Enabled = true

    URLPrefix = wsman

    CertificateThumbprint

    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12

 

Listener [Source="Compatibility"]

    Address = *

    Transport = HTTP

    Port = 80

    Hostname

    Enabled = true

    URLPrefix = wsman

    CertificateThumbprint

    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12

 

If you want to create a listener to field traffic on ports 80 or 443 for HTTP or HTTPS traffic, respectively, you can do it two different ways.  You can directly modify WinRM configuration:

 

winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

winrm set winrm/config/service @{EnableCompatibilityHttpsListener="true"}

 

Or, you can use the new Group Policy settings under Windows Components > Windows Remote Management (WinRM) > WinRM Service:

 

“Turn On Compatibility HTTP Listener”

“Turn On Compatibility HTTPS Listener”

 

 

If you’d rather use PowerShell to manage your listeners, you can enumerate all active listeners with the following command:

 

Get-WSManInstance –ResourceURI winrm/config/listener –Enumerate

 

To create a compatibility listener on ports 80 or 443 for HTTP or HTTPS traffic, respectively, use the following commands:

 

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener -Value true

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value true

 

 

What will happen when you upgrade your current machines?  If you have existing listeners that are on non-default ports, meaning either an HTTP listener on something other than port 80 or an HTTPS listener on something other than port 443, nothing will change – those listeners will still exist with the same configuration.  However, any listeners that exist on the default ports will be moved to the new default ports (5985 for HTTP and 5986 for HTTPS), and a compatibility listener will take the place of the old listener.

 

So, for example, if your machine had one listener accepting HTTPS traffic on port 443, after upgrade your machine would have one listener accepting HTTPS traffic on port 5986 and one compatibility listener accepting HTTPS traffic on port 443.

 

 

For all you PowerShell users, the New-PSSession cmdlet has been modified to take these changes into account.  New-PsSession now takes on two different parameter sets, which are differentiated based on the existence (or absence) of two parameters:  ComputerName and ConnectionURI.

 

When the ComputerName parameter is given, then we will honor the default client port setting in the WinRM configuration (unless you change them, they will be 5985/5986 for HTTP/HTTPS).  When the ConnectionURI parameter is given, then the string will be interpreted in the same way as Internet Explorer does it (using ports 80/443 for HTTP/HTTPS).  In both cases, if a port number is explicitly given, then we will use that port – the difference is in the defaults.

 

So, the following PowerShell command will connect to my desktop machine on port 5985 (unless you go in and change the WinRM configuration settings for the default client ports):

 

                New-PSSession –ComputerName NathanDesktop

 

This command will connect to my desktop machine over HTTPS on port 5986 (unless you go in and change the WinRM configuration settings for the default client ports):

 

                New-PSSession –ComputerName NathanDesktop –UseSSL

 

This command will connect to my desktop machine on port 4444 (assuming there is a listener set up to handle the request):

 

                New-PSSession –ComputerName NathanDesktop –Port 4444

 

This command will connect to Exchange over port 80:

 

                New-PSSession –ConnectionURI http://Exchange.labs.com/Exchange

 

This command will connect to Exchange over HTTPS on port 443:

 

                New-PSSession –ConnectionURI https://Exchange.labs.com/Exchange

 

Finally, this command will connect to Exchange over port 4444:

 

                New-PSSession –ConnectionURI http://Exchange.labs.com/Exchange:4444

 

 

The following cmdlets for WS-Management operations have also undergone the same changes as described above:

 

Connect-WSMan

Get-WSManInstance

Invoke-WSManAction

New-WSManInstance

Remove-WSManInstance

Set-WSManInstance

 

 

The WinRM command-line tool has been updated in the same way.  If the user passes a computer name to the WinRM command line using the –remote:<Computername> switch, then we will pick the default client HTTP port from the WinRM config (by default, 5985).  If the user passes a computer name to the WinRM command line using the –remote:<Computername> switch and includes the –UseSSL flag, then we will pick the default client HTTPS port from the WinRM config (by default, 5986).

 

If the user passes a computer name to the WinRM command line using the –remote:<Computername> switch and specifies a particular port, then we will use the specified port.

 

If the user passes the connection URI string to the WinRM command line, such as –remote:http://Mycomputer/wsman, we will interpret the URI in the same way as Internet Explorer does it (using ports 80/443 as default for HTTP/HTTPS).

 

If the text below looks familiar, it’s probably because almost all of the text was copied and pasted from the PowerShell examples above – consistency is always a good thing!

 

The following command will connect to my desktop machine on port 5985 (unless you go in and change the WinRM configuration settings for the default client ports):

 

                winrm identify –remote:NathanDesktop

 

This command will connect to my desktop machine over HTTPS on port 5986 (unless you go in and change the WinRM configuration settings for the default client ports):

 

                winrm identify –remote:NathanDesktop –usessl

 

This command will connect to my desktop machine on port 4444 (assuming there is a listener set up to handle the request):

 

                winrm id –remote:NathanDesktop:4444

 

This command will connect to Exchange over port 80:

 

                winrm id –remote:http://Exchange.labs.com/Exchange

 

This command will connect to Exchange over HTTPS on port 443:

 

                winrm id –remote:https://Exchange.labs.com/Exchange

 

Finally, this command will connect to Exchange over port 4444:

 

                winrm id –remote:http://Exchange.labs.com/Exchange:4444

 

 

Nathan Burkhart

Program Manager  |  WS-Management