Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

We had an administrator delete the 3

Status
Not open for further replies.

fitzdr

Technical User
Aug 2, 2002
39
US
We had an administrator delete the RDP-Tcp (listener) while using the Terminal Services Configuration tool. When viewing from Terminal Services Manager there is no RDP-Tcp (listener)

Once I found this I went ahead and created a new Connection using the defaults. Failed.
Uninstalled and reinstalled TS. Failed
Port scan of server. port 3389 not open.
Checked KB article 186645, Trouble shooting RDP client. no luck.
The port has not been renamed and the registry entries appear to be all correct.
Permissions for TS and user are correct
Settings on connection properties are correct.

Not sure where to go from here. MS Premier site has no addtional information. I suspect some type of security but not sure.
 
This may be way off base but I've seen in 3 different instances where IPSEC got enabled after configuration changes were made to terminal server. I don't have a 2000 box in front of me right now to tell you exactly where it is but if you check the help file, I'm sure you can find it.
If it is enabled, disable it and try again...




~ The day I think I know it all, i'm changing careers ~
 
I have tried all of the above. Not sure about IPSEC, its running on all of our servers but there are no profiles so it shouldn't be performing a function.

I have summarized everything so far below.

Review of issue,

Port 3389 not open on server. Two servers suffering the problem.

Checked port 3389 with a port scanner, port not open. Checked port 3389 using NETSTAT from server, port not listening.

The port is not being blocked, there is no configuration for blocking the port on the server, there are no firewalls or network filtering occuring.

We can connect to the server using shares, the computer managment console and the default web site.

The Terminal Services Manager shows the RDP-Tcp (listener) as down on one server and does not exist on the other server. The one without the listener does not have the normal option to add one.

I have reinstalled T.S., the NIC, and TCPIP, with no change.

There are never any errors in the server logs because the workstation can never connect. Attempted to use TS client from server, there were no entries in any of the logs.

From the workstation we get the following error which is very generic.
The client could not connect to the remote computer.
Remote connections might not be enabled or the computer might be too busy to accept new connections.

Have reviewed and followed information in the following articles: Q270588, Q258021, Q186645. There were a few others that I reviewed but none applied.

Put simply, there are no errors, Port 3389 is not open on the server and cannot be opened. Help.

I did find one site that said the only way to fix this is a fresh install, thats not an option.
 
Try posting this on thethin.net... I do a bit of terminal services work, but my only suggestion is to reinstall. You could also try a MS support call.

Matt
 
I have resolved the issue on my own by comparing the registry entries for TS line for line. The following is what I did.

The registry entry for Terminal Services that defines the location of the video 0 device was missing. Once this line was added and the server restarted Terminal Services was again available.

The following is the registry entries that are affected. The entry for \\device\\video0 was the one missing.

---------------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\VIDEO\rdpdd]
"VgaCompatible"="\\Device\\Video0"
"\\Device\\Video0"=\\REGISTRY\\Machine\\System\\CurrentControlSet\\Services\\RDPDD\\Device0


 
To add to this resolution:

I too had the same problem resulting from our DB admin trying to break out of a terminal session. I'm still not exactly sure what he did. Unfortunately the specific entries mentioned [\device\\video0] were already present.

However by comparing the registry at this location from several of our functioning Terminal Servers I did find 2 other keys that did not match. By modifying these keys I was able to get TS back up and running on the sick server.

1st Key - I added this
------------------------
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\Winstations\RDP-TCP

This entry was missing completely from the server that would not accept remote sessions. There are over 60 entries under this key but I did manage to retype them manually.


2nd key - I deleted this
---------------------------
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\Lantable

This key existed on the sick server but not on any of our other functioning TS. The only way I can describe the entry under this key is that it has a MS Outlook Express "identity" look about it as a name. I'm wondering if this is residual and should have gotten automatically removed if a graceful terminal session termination had occurred.

By adding the 1st key manually and deleting the second after a reboot the server is functioning again.

Thanks to David for his help in identifying the registry location to modify.

Albert
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top