I was asked to take a look at a family members' friends' Win2k3 server - Remote Desktop was no longer working, and they were trying to figure out why. This server is running Win2k3 SP2.

I determined that the License services were having some issues (Event ID 19, see http://support.microsoft.com/kb/2021885 for details) - this was fixed by installing a hotfix (http://support.microsoft.com/kb/983385) and reactivating licenses, so the error no longer appears. However, RDP connections from the Internet still fail.

The network hardware that is connected is a DSL modem to a SonicWALL TZ170 appliance, and that is connected to a 24 port switch which supplies wired access to one PC and 10 or 11 thin clients (Neoware).

Just to go over what was looked at:
1. Port 3389 is listening on the server (netstat -a -o shows ms-wbt-server is listening on 3389)
2. Portqry (from a remote Win7 system) shows that 3389 TCP is Listening, but 3389 UDP is listening or filtered (UDP only determines audio, doesn't it?)
3. I am able to telnet to the system from a remote Win7 system, to both the hostname/IP on port 3389 and connect fine.
4. RDP works locally (ie. plug in a laptop to the local LAN, mstsc connects just fine to the server with the laptop having an internal 192.168.0.x address)
5. A portscan using nmap on a remote system shows that 3389 is open.
6. I did not notice an antivirus on the Win2k3 system (not sure if it's running on the SonicWALL appliance, although I can't check that as they forgot the admin password, and I'd really like to avoid doing a factory reset on it). The local Windows firewall on the Win2k3 server is not enabled.

Connections to the server remotely gets this message:

This computer can't connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote 
computer or your network administrator.

The Win2k3 server is well backlevel on fixes/patches from Windows Update, though - but why that would cause a problem when this was working before the license issue is beyond me..as the system had never had a full backup (just backups of the user data), I made an image of the drives before running the hotfix (just in case).

Any suggestions? I've done everything I can think of thats related to licensing, ports, etc. As it works locally but not over the Internet, the only thing I could think of was the Sonicwall was doing something (although the port forward seems to work fine to the internal IP of the win2k3 server, since it can see the service as its listening)..

Just at the end of my rope (and patience).

Thank you.


I'm not longer at the remote site at the moment, so I cannot check w/Wireshark - however, checking w/Wireshark remotely shows that the server does respond (SYN/ACK is done) but the connection just doesn't seem to come up.

As you can tell, I'm not that well versed in Win2k3; I'm mostly a UNIX guy. /grin

Port 443 is open on the SonicWALL as well, so I'm wondering if a TS Gateway is being used.

Modifying the RDP settings to use an RD Gateway (RD/TS, whatever!) does get me a certificate error from the Sonicwall - exporting that certificate and importing it into the Root Certs works, but trying to reconnect says the name (ie. CN) does not match - which makes sense, as the FQDN I'm connecting to doesn't match the cert name (the certificate that I received from the Sonicwall shows the internal IP of the Sonicwall, but not a full name).

Right! More confused now. /grin

3 Answers 3


Discovered the issue:

Although the 'netstat -a' does show terminal services listening, it shows it by name rather than port (ie. it shows ms-wbt-server, not port 3389). I went back after using Wireshark/etc. to verify information coming across to the server was making across the network (which it was - I'd rate up the two suggestions above, but I don't have the rep for it yet!).

Turns out someone had set the RDP on the server to run on a non-standard port.

The registry key which contains this is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

I changed that back to 3389 (decimal) and saved it, and rebooted the server.

Terminal Services worked after that.

Note that my previous consideration for port 443/TS Gateway was not applicable, as TS Gateways/443 is only used for Windows Server 2008 (as per MS Technet).


You may want to use NetMon or Wireshark on the Windows 2003 server to validate that the remote system connection is actually making it to the server on 3389.


"I am able to telnet to the system from a remote Win7 system, to both the hostname/IP on port 3389 and connect fine"

Compare the telnet connection banners between "over the Internet" and "locally within the network" to see if they match.

  • If not, then start working your way out towards the Internet from that network.
  • If they do match, then it may be a system configuration/interoperability issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .