1

A vendor helped set up several servers on remote sites. Generally, this is done in conjunction with me. I realized after they were done this time, I could not connect via RDP. It’s not a credentials thing because We don’t even get to that point, it just won’t connect.

I can access the servers via browsing through explorer, regedit, powershell, etc, just not RDP. I changed the fDenyTSConnections value to 0, the remote desktop service is running. I was even working with the vendor the other day who was connected via teamviewer and he showed me that RDP was turned on (and my policy that allows specific users access had obviously applied as it showed the correct group with access). And yet I still can’t connect. Kind of a weird one here - All the affected servers are running Server 2022.

Any ideas?

6 Spice ups
2

My first thought is to go back to the vendor that helped you set this all up and let them know it’s not working as per the original scoping documents and they need to get back on and figure out why. That’s why you paid them to set it up, so that it just worked out of the box, without you having to do it all, right? Then, make sure you’re getting your moneys’ worth!

3

Oh I don’t have any issues doing that - the vendor works with us regularly, although technically, even though they are providing the server, it’s for a specific application, and as far as everything correctly on the domain, that’s usually more determined by me and our group policies. The vendor usually just gets logged into the server and installs the application and I do all the domain joining, etc.

Again, I don’t mind getting them involved, but this isn’t necessarily something I would say they screwed up and I’m sure they are fine looking at it with me, I’m just trying to find a “windows reason” this wouldn’t work.

1 Spice up
4

But if all the servers are running the same GPO’s, and only this latest batch are having issues, the common denominator is the recent work done.

5

It can be turn on and blocked because:

  1. the windows firewall doesn’t allow it
  2. the devices defender profile isn’t correct. e.g. public vs private or domain
  3. a firewall between the subnets isn’t allowing 3389
  4. You’re using DNS and the device isn’t fully registered - try it’s IP.
  5. 3rd party firewall or AV blocking it.
3 Spice ups
6

It can be turn on and blocked because:

  1. the windows firewall doesn’t allow it
  2. the devices defender profile isn’t correct. e.g. public vs private or domain
  3. a firewall between the subnets isn’t allowing 3389
  4. You’re using DNS and the device isn’t fully registered - try it’s IP.
  5. 3rd party firewall or AV blocking it.
  1. I have checked the firewall Domain profile using powershell - appears to be the same as everything else is that works.
  2. It is possible there could be something with defender - any way to check that remotely?
  3. See #1 - firewall appears to be off for the domain.
  4. I have tried via the ip - the IP is pingable, but can’t connect to RDP that way.
  5. I don’t believe there are any 3rd party firewalls or AV.

Thanks for suggestions - this is an odd one and haven’t run into it. It’s not super urgent at all - I will be working with the vendor on some other stuff next week and can check it then, was just trying to figure out if there was another way I could get to it.

1 Spice up
7

Is it possible that the RDP port was customized in the firewall for these servers? I know we use non-standard ports for RDP here, as well as non-standard ports for a lot of other things…it made getting up-to-speed a little tricky here because things work differently…just a thought.

8

I really don’t think so - I’ve worked with this vendor on many other similar projects and never ran into this before. I think the only difference is that this may be the first time he set up 2022 servers for the projects, but really don’t see any difference. I guess I’m just going to have to work with him next week to get in via Teamviewer and poke around. It DOES sound like issues I’ve seen before with DNS (it’s always DNS), so maybe he put something in wonky.

1 Spice up
9

That’s possible, as well…maybe a typo or number swap?

10

This really just sounds like RDP is being blocked. Try this in PowerShell and see if it gives you an error.

Test-NetConnection -ComputerName <name_of_computer> -Port 3389 -Verbose

Event viewer might also give you more info on why the connection is being denied. Likely something on the target server dropping the connection or something in-between like an ACL or firewall.

EDIT: You can try and pull up event viewer on the remote server as well and see something there. You can do this by opening up event viewer, right clicking on Event Viewer (Local) and selecting “Connect to another computer”

1 Spice up
11

For this note on firewall, I meant between the subnets, not the locally installed one.

If you cannot connect via IP either, then there is either a firewall in the way, a missing route if this hops subnets or the connection is not listening.

Open a remote PS session on this server and check for port 3389 on 0.0.0.0

netstat -a

Look for 0.0.0.0:3389 or IP:3389

If the server is multi-homed or using DNS that is NOT within your network this wont help.

Typically, yes, but not if the IP doesn’t work either - it’s more likely something blocking the port.

1 Spice up
12

I have been having trouble with RDP not responding for months now. The only thing that I can do is remote in with a different program and restart the machines. So far no one has been able to give me a decent answers to why this occurs

1 Spice up
13

Why not just look at the firewall GUI ? Sometimes the GUI can give more answers ?
Else just “enable” every setting for Domain or just off the firewall (for the testing period) ?

Then see if you have remote access (RDP) enabled ?

2 Spice ups
14

That actually helped me out this past week.

However, something else to check is RDP still set to the default 3389, or has it been modified?
There is (read as was) a Registry edit that would allow us to select the RDP port as needed, it allowed us ot use multiple concurrent remote VNC sessions to a company.

1 Spice up
15

Okay, so the answer to this problem was: DNS, because it’s always DNS.

So the subnets that these servers are on are new and were created by our Network admin. Last week I realized that and also noticed that while forward zones were created, reverse zones were not. So I made those on Friday. The servers were still not accessible, but I had another way to reach them, and after rebooting them, RDP works fine.

3 Spice ups
16

Thanks for reporting back! So glad to see your situation has improved!

17

Woo Hoo!!

The DNS is broken…The DNS is Fixed! Long Live the DNS!

wait, you said reverse DNS…

The SND is broken, The SND is fixed! Long Live the NDS!
:slight_smile:

1 Spice up
18

While I’m glad to hear it’s better, the reason makes no sense, you said it didn’t work by IP, which would generally rule out DNS.

1 Spice up
19

You know you are right, that doesn’t make sense. Perhaps there was more than one thing going on…

The thing is, I had been unable to access them to try anything, and when I did get access, I rebooted, so who knows what all that may have fixed.

1 Spice up
20

Did they add any routes to the machine, if there are no routes, traffic will make it to the device, but not be able to find its way back.

1 Spice up