Networks

Ask something
Question Locked

Remote Desktop connection problems

0 helpful
34 replies

by jfuller05

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I've been using the remote desktop connection for me and a user outside our network to login to our server(a) for certain things. This week, the user calls and says she's not able to remotely connect to the server(a). I tried to remote in (I'm in the network) and I couldn't connect either. However, I was able to remote in to our other server(b).
I can see and access files on the (a), but I cannot connect to it to use remote desktop. Everything is fine with TS licensing, I couldn't find any problems there. Also, even if there were TS problems, shouldn't I still be able to use remote desktop (I believe at least one user can) without TS? I think so, so that makes this problem even stranger to me.
Anyway, the user was able to get her work done another way, but I still want to fix this problem. I believe it would be a hardware issue.
Any suggestions?
The user logins via VPN through our SonicWall, but I don't think that is an issue, since I can't even establish a connection within the network. Port 3389 is open for remote desktop. So it's not a firewall issue.

Server A: Windows Server 2008 standard.
Server B: Windows Server 2008 R2
Client Machines: Windows XP Pro SP3

34 replies

by markgreenhall

I had a similar issue with terminal services sessions not being closed properly (sessions remained open and eventually the server would not allow any more).

I would physically go to the server, log on, open Terminal Services Manager under Administration Tools and disconnect / log off and active profiles. Afterwards try and connect from your machine again.

If successful then it will have been due to existing open sessions from previous connections.

To avoid in the future then go into Terminal Services Configuration and right-click the "RDP-Tcp" connection. Under the "Sessions" tab tick to override the disconnected and idle sessions and set the time to say 3 hours (or maybe something like 8 hours). This will clear out and sessions that have been left open after a user has logged off and allow you to reconnect.

Regards
Mark

by jfuller05

but it didn't work. I tried logging off in TS manager, then going to my computer, and using remote desktop; it didn't work.
I then tried disconnecting, it didn't work either.

I forgot to mention that I restarted the server, in hopes that would solve it; it didn't work though.

Thanks again though. I'll remember to set the RDP-TCP settings whenever I can remote in to the server.

by cg it

rebooting should have closed any open sessions.

So when you log on locally to the server, then view open sessions, are they any? if not, check the remote desktop settings.

you might want to, just out of curiosity sake, set RDP to deny and remove the users, click ok, then go back and set it to allow, and then add the users. Window Servers are sometimes funky with registry values, remembering a certain configuration even after you change it until you reboot the server even if it doesn't prompt you to reboot.

by pshiflet-24

Did anything change on the server recently? Was it made a DC, updated, or even just rebooted or have a GPO modification? Can you verify that the Windows Firewall didn't either re-enable itself or have GPO changes impact it? Also, can you verify that the Terminal Services service is running (and maybe restart it, just to be sure) and that Remote Desktop is still enabled under System Properties - Remote and the users in question are listed in the appropriate groups to access TS? Lastly, does the event viewer show anything useful regarding TS such as denied connections or firewall blocking? Let me know. Thanks.

by jfuller05

No recent changes.
It's been and still a DC.
No updates. Most recent updates were from early June. None that would affect this b/c I've been able to remote in from within the network and the outside user was able to after the updates.
Windows Firewall didn't re-enable and no GPO changes.
TS was running, restarted, and running now.
Remote Desktop is still enabled.
Users are in the appropriate groups.

No firewall blocking in event viewer. There were some events regarding the TS licenses though, but I reactivated them and now the licenses are good to go in TS license manager. So it's not issuing temp licenses anymore.There were also events for Time sourcing. The time was out of sync, I re synced it though.

Still, can't remote in though.

I appreciate the suggestions.

by seanferd

Is there a router or switch between the workstation and the TS? I'd try rebooting that, if there is one.

If it keeps logs, maybe check those first.

by oldbaritone

You said "Remote Desktop Enabled" - but is it Started?

Especially since you can't connect internally, check to see that the service is up and running.

by cg it

there should be something in the event viewer probably the security events but I'd also check the application events.

so did this start happening after a "patch Tuesday" ?

by jfuller05

but I've been following the warnings and errors; nothing major.

There was a time-service issue, I fixed that. There were DNS issues, fixed those. TS was issuing out temp. licenses, but I reactivated the licenses, so now everything appears to be fine in TS now.
However, I could be wrong.
I want to fix this, but a wipe-reinstall is tempting at the moment. :)

by jfuller05

for me, the Admin, but no one else.

I set the RDP just as you said to, but I still can't remote in from my desktop.

Thanks for the suggestion though.
This is definitely a mystery to me!

by jfuller05

I know it has to be a setting that I'm missing in that server.

I'm able to remote in to our other server.

by jfuller05

and the service is started.

Also, I ran telnet to try and connect to the server that way. Here's the message:

connecting to 192.168.10.5...Could not open connection to the host, on port 23: Connect failed.

edit: ports 3389 and 3489 didn't work either.

by cg it

Is your remote desktop session for administrative work to the server? The RDP session is seen as a terminal services connection, but you don't need licensing for it. The server allows 2 concurrent connection without any terminal services client access licenses.

so what's really going on here.

by jfuller05

I use it for admin work to the server. Users outside the network use TS to login to the server and use it for software purposes.

That is why I'm confused, I should be able to login regardless, yet I can't! :0

by cg it

can you ping the server?

If your on the same subnet, and as a test you turned off the firewall, and you can ping the server, you should be able to RDP in provided your account is listed in the allowed accounts in the Systems settings for RDP [or are members of the Remote Desktop Users security group].

by cg it

on the server side of things. You've said you've checked everything everybody suggested which pretty much eliminates all the obvious problems of why you can't RDP in.

so all our suggestions end up being that 20 questions game.

The "not so obvious" problems could take up another 50 questions...

Personally, if the server itself will allow RDP sessions, and you can ping the server, there's no firewall settings restricting communications and no security policies restricting RDP sessions, you quess as to what the problem is, is probably as good or better than anyone else's guess.

by jfuller05

We're on the same subnet, turned off firewall, and I'm a member of the RDU group; still, I can't remote in.

Do you think I should just restore from a shadow copy?

Or do you think this issue can be solved?

by pshiflet-24

I believe you stated that this is a DC, as well. Can you (locally logged in from a DC) open up the Domain Controller Security Policy from Administrative Tools. In there go to Local Policies -User Rights Assignment and look for the settings for Allow Logon to Terminal Server, Allow Logon Locally, Deny Logon through Terminal Services, and Deny Logon Locally. Is there anything there that could cause your issue?

by pshiflet-24

Can you check out http://support.microsoft.com/kb/326945 and verify that the registry setting on that server is correct for the incoming port on the server (that it hasn't been, for whatever reason, modified)? Presumably if you have external users accessing numerous internal servers with the same WAN IP, there must be some port forwarding happening somewhere.

by jfuller05

I also found the entries to be correct in the registry.

I really appreciate the help.

by pshiflet-24

Is it possible the port is already in use by something else? Try running netstat -o to see all open ports and see if something is locking 3389. I have seen DNS lock a large range of ports. Check out http://support.microsoft.com/kb/956189 for info on checking the reserved ports and adding exceptions, if need be.

by jfuller05

there has to be a underlying problem (obviously).

Thanks for all the help and time you put in.

I'll probably just recover from a backup if I can't figure it out soon.

Thanks again.

by jfuller05

I appreciate it very much. This server has given me more work since I started here than any computer has ever given me.

I think it's time for wipe-reinstall.

Again, thank you all so much.
:-bd

by cg it

caulk this one up to the "Windows never ceases to Wonder" list.

by jfuller05

I can remote in to the server using GoToMyPC...

I thought I would post my updates to this crazy problem in case anyone else ever encounters this monster we can share ideas.

I guess since the outside user can access the server with GTMYPC, I can lower the priority of this problem. The server room is not that far away from my office, so it's not like I really need it.
I've been putting duties of this server on to our new one because the server just isn't acting like it used to.
Plus, I like WS2k8 R2 a little bit better. :)

by jfuller05

That's the only problem with GTMYPC when in comparison to RDC.

If RealVNC is faster, I might consider switching software.

by oldbaritone

but I've always had good luck with VNC.

Also, you can run VNC behind SSH for high-quality encryption and good security.

This discussion is closed to new replies.