Can't UNC or RDP into a Windows 2008 R2 Server

Got an odd one here that I've never encountered before...

We have a terminal services server (Win2008 R2) that our users log into when they are off-site.

This server has mapped drives to many other locations on the network, but there is one particular server that it cannot map a drive to, UNC to, or even RDP to.

Pretty much every other machine on the network can UNC and RDP to the server in question, and the TS server can UNC and RDP to just about every other server on the network as well. It's like there's a specific relationship between these two servers that prevents UNC/RDP access and I can't seem to figure out why. Any thoughts?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Is the server that cannot be connected to via UNC or RDP a member of the domain?  If not, make it so it is.  

Can you RDP or UNC via the IP address instead of by name?  If not, you should also make sure that is listed in DNS with the correct IP address and that RDP is enabled.  For RDP trouble shooting check out the following:
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
Ensure you can ping the IP and the name.  Ensure the computer is part of the domain and see if you can logon locally on the server.  When you try to RDP do you get any errors or is it that the server name cannot be resolved.
BladeValant546Author Commented:
Yes, the computer I'm trying to RDP is a member of the domain (in fact, it's a domain controller)
Yes, I can ping it.
No, I can't RDP/UNC to it by IP either.
Yes, I can log on locally to the server and
Yes, Remote settings are enabled (not to mention that every other computer on the domain can RDP to this server, just not this TS server for some reason).

Any other ideas? I went through pretty much the same process you guys have listed out here, so you can probably see now why I was at a loss! :)

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

BladeValant546Author Commented:
Haven't heard back from anyone on this - I'm at a loss, anyone else out there with an idea as to why this is happening?

I can give whatever information you guys might need to know to help solve this one.

One possibility is a time sync issue.  If the TS/RDS and the DC have a time difference of greater than 5 minutes, then the kerberos negotiations will fail, and it will be in accessible.

BladeValant546Author Commented:
I was hoping that that was the case, since I hadn't thought of it, but unfortunately no, we aren't that lucky today... :/

Time is identical on both servers.

Rodney BarnhardtServer AdministratorCommented:
We have seen some issues where after a reboot, RDP and UNC did not work. Reboot the server again, and all is well. Also, I did not see it mentioned above, but did you check the firewall to make sure it isn't on? We had one server where it got turned on some how and it caused several problems.
I'd also agree with the firewall question...there could be a rule on the server you are trying to get to to block this access...

As a test can you do this

telnet <remote server trying to access ip> 3389

So if remote server is that's

telnet 3389

Do you get 'connection refused'? Or blank screen with blinking cursor?

Then based on result do the same from a WORKING server - what result does it return?

If you get a 'connection refused' on the first test that usually means a firewall is blocking you...especially if you get blank screens from the other tests...
Sorry for the delayed response back.  Check to make sure that this 2008 server has the four services for Terminal Services started.

1) Terminal Services
2) Terminal Services Configuration
3) Terminal Services Gateway
4) Terminal Services UserMode Port Redirector (if you are doing redirection)

smckeown777's check for telnet did work as a test on the server that I got the 4 terminal services services.  I did not know that telnet was a tool to check for this thanks smckeown777!
BladeValant546Author Commented:
Alright - figured the problem out.

I'm going to give partial credit to the guy who suggested the firewall because, though it wasn't the problem, it sparked the thoughts that led me down the right path.

What had happened was:

Between our two sites, HQ and we'll call the other JB, we have a point-to-point fiber connection that is able to communicate because of our Cisco routers at both sites. We also have a private VPN that is connected through our site firewalls. With this site (and only this site) do we have both the private VPN and the P2P.

For all other sites, it's perfectly OK for all traffic to go through the firewall because, ultimately, it is then filtered through the private VPN. For this site, however, traffic can possibly go through either pipe. In this case, traffic was going through the VPN from HQ to JB, but on the way back it was trying to Acknowledge the handshake through the P2P, thus creating a routing triangle.

This was caused by the default gateway on the TS Server having its default gateway changed to the firewall instead of the router in an experiment that we did about a month ago which we thought we had undone all the changes from. The handshake request and acknowledge, at that point, could never communicate over the same line from either direction.

So, to resolve, all I had to do was change the default gateway on the TS Server, and now both the TS Server and the server at the JB site can happily communicate again.

Thanks for all your effort guys, I don't expect any of you to have been able to know this intricate detail of our network in order to have solved this one, but I'm very glad that a couple of you said the magic words that rang the right bell in my head to get me looking in the right place! :)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
BladeValant546Author Commented:
There was no possible way that someone unfamiliar with the intimate details and recent history of our network could've been able to guess that the issue was a triangular route based on the way our connection between sites is configured. However, I am thankful that someone jogged my memory by saying the right words to get this one resolved.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.