Windows 10 Networking a domain computer via Remote Desktop on Server 2008 R2

[Thomskitten]

I'm replacing a workstation on our domain, but it will be used in a satellite location where we utilize Remote Desktop to access our server. I have upgraded the new workstation to Windows 10 Professional and have joined it to the domain. I have set it up (user name/computer name, etc) to mirror the workstation it will be replacing and I have enabled remote desktop on the new workstation as well, however when I try to make the connection to the server via Remote Desktop I get this error:

"Remote Desktop can't connect to the remote computer for on of these reasons:

1) Remote access to the server is not enabled

2) The remote computer is turned off

3) The remote computer is not available on the network"



The server is on and running and I have other workstations from other satellite locations utilizing Remote Desktop that are able to join and currently accessing it. So, I'm not sure what I'm missing, can anyone please advise?



Thank you in advance.

 

[Neemobeer]

• Are you using Windows firewall and if so which profile?
• Can you ping the server from the workstation?

 

[Thomskitten]

• Are you using Windows firewall and if so which profile?
• Can you ping the server from the workstation?

At the risk of sounding stupid, how do I tell which Windows firewall profile?
I can ping the server, as well as the domain controller and the pc is on the domain

 

[Neemobeer]

Control Panel > Windows Firewall, whichever profile says Connected is in use (Domain, Private, Public)

 

[Thomskitten]

Control Panel > Windows Firewall, whichever profile says Connected is in use (Domain, Private, Public)

On the pc that I'm trying to connect (new workstation) its Domain

 

[Neemobeer]

In the same screen go under "Allow an app or feature through the firewall" and make sure "Remote Desktop Connections" is checked for Domain

 

[Thomskitten]

In the same screen go under "Allow an app or feature through the firewall" and make sure "Remote Desktop Connections" is checked for Domain

I did do that already. I'm wondering if there is some setting (like allowing a new IP address) that I'm missing on the server (Server 2008 R2) in the Remote Desktop settings. I'm very new to Windows 10 so it takes me a few minutes to figure out where I'm going, but the new Windows 10 PC is replacing an XP machine on the network. I was hoping to just be able to "swap" the old unit with this new one. One thing that I've noticed is different and cannot figure out how to change (and I'm not sure it makes a difference, I'm still learning) is that when I look at the existing RD connection properties, under the details tab, for the property "Type" the value is Remote Desktop Connection but on the new PC for the same property the value is Shortcut.

 

[Neemobeer]

Connections are typically user specific, so as long as the user is allowed on the server for RDP you should be able to connect. It may be worth running wireshark on the workstation and capture the RDP attempt. If you do you can PM me the pcap file so it's not public.

 

[ussnorway]

I don't remember 08 well but 10 may need a tick in anonymous logon allowed before it will play nice

 

[BIGBEARJEDI]

I experience lots of frustration with RD in 2008 server at my home network before it died last year. Most of it was none of my workstations had Windows Pro on any and couldn't connect. I since have Pro on several machines via W10. But no server to login to. That's neither here nor there, just rambling.

Back to topic; I had lots of RD problems going back to 2000 server days. I found an easy way to fix it. You'll have to go get that new W10 machine at the remote site (fly or drive there and bring it back to your location where the domain server lives). Or have someone there ship it to you. Plug it in to your main network, a different subnet port on your main network would be ideal. Attempt to remote into the W10 desktop and get it working like that. If it works; the network settings are ok on the internal network, and so you can look for exclusions or firewall blocks in your main server location as the probable cause of it failing to work at your remote location (either router/firewall equipment at the main location or at the remote location). Once you do admin logins to both main core routers and go through all the settings you can probably isolate and fix the problem. Ship the W10 machine back out to the remote site and have someone turn it on and plug it into the network. Retest; if it lets you remote in, you've fixed it! Easy, right?

If the W10 machine fails to let you remote in across a different subnet in your server location, physically move the W10 machine to a port on the core router which should be the same subnet as your 2008 server is plugged into. If you are out of ports on that core router, hang an Ethernet switch on an available port or even a hub, and plug the W10 machine in to that. Retest. Can you remote into the W10 machine with it plugged into the core router where the server Ethernet connection also lives? If you cannot remote in with the W10 machine on the same subnet, it's likely to be a problem with that machine. You may have to do a manual rebuild using W10 Clean Install and reinstall all your programs and data manually. You can also use a different W10 machine and plug that in to the core router. If that 2nd PC works, but the original one doesn't, yet another reason to rebuild it.

If you cannot get any W10 machines to work on your network domain while plugged into the core router where the 2008 server lives; you probably have a topological problem with your network and you'll need to create a network diagram to fix it; if you don't already have one. A sketch is a good idea; but you should really have a program like Visio at your disposal to create that diagram and keep it updated with any and all future changes to your network. You'd be surprised at how many of my customers could have solved their own problems if they just did this. It's only taught in universities and trade tech schools however, so the average Tech is often unaware of it's power to solve problems.

Hope that provides some further insight.
<<<BIGBEARJEDI>>>

 

[Neemobeer]

Well it's either going to be a firewall rule somewhere, potentially in between the remote network segment and where the server resides blocking port 3389 (RDP) or it's an ACL on the server itself.

 

[BIGBEARJEDI]

My money is on the firewall rule (probably inbound or outbound traffic filtering). I'm guessing it's on the router or firewall box at the remote location. I've seen this so many times, and the customer never believes me...LOL.

BBJ

 

[Neemobeer]

Yup, a wireshark capture would really help narrow down the issue.

 

[Thomskitten]

My bad, I should have mentioned that I have not actually taken the new Win10 machine to the remote location yet. It is currently at the location where the server resides, I was trying to get it set up here first. It is currently plugged into a switch in an office next to my office where the server resides so that it has internet and is on the network however I have not mapped the network drive for the server to it because these machines connect differently. All of the machines in this location are linked to the server via network cables/hubs and switches and the network drive for the server is mapped onto each machine...the machines at the remote locations use RD to access our server. On the server is where our actual POS software resides.

As for wireshark, I am unfamiliar with it. I googled it and read about it yesterday. I installed it but for the life of me could not figure out how to use it :/

 

[Neemobeer]

All you need to do, is run it on the workstation, select the NIC you use to connect it should start showing captured packets, then attempt to RDP to the server, once it fails click the stop button and save the capture as a pcap or pcapng

 

[BIGBEARJEDI]

Well, if it's not working off the switch in your office which I assume is on a different subnet (is it?), why don't you try picking that PC up and walking it over to the server room, and plugging into the core router as I suggested?? Retest for RD capability there. If it works, your network or your server has the problem and you need to go fix it.

If the RD fails when you've got the W10 PC plugged directly into the core router (must be same subnet as domain server), then it's the firewall settings or ACL as neemo suggests or possible a bad install on that PC. You'll need to take another W10 client machine that does work with RD and hook that to the core router; repeat the test. If that 2nd PC works; it's probably something scrambled in the original W10 machine, and you need to rebuild it with a W10 clean install. If the 2nd PC does NOT work, it's network related (Firewall, router, or ACL settings). Since you haven't provided us with a network diagram we have to guess how many boxes are hung between the core router and the TDC of your network; appliances such as E-mail exchange servers, and Radius servers, DHPC or Proxy Servers, etc. You'll have to disconnect all of those at some point during a holiday, evening, or weekend and do a scheduled maintenance in order to get to the bottom of your network problem.

Perhaps getting the pcap log file to neemo will help. If no PCs work on the same core router with RD, you might be looking at bringing in a network engineer and hooking a LANalyzer up to your network to resolve it. Your a long way from that; but you should know the cost of those runs like $300-$500 an hour, so in order to justify a person like that to come and help you fix it, you had better do all the things we've suggested and document everything you're doing. I've sat in a lot of those meetings to get approval to do that, as well as being one of the engineers performing that repair.

BBJ

 

[Thomskitten]

Thanks all. I'm on it (in my "spare time"). I've had to walk away from this for a bit to get my "actual" job done. I've spent a great deal of time on this issue, so once i get myself caught up in my own office I'll get right back to working on these suggestions. I thank you for your time and I'll respond again once I've had the opportunity to follow through with them. [emoji4]

Sent from my SM-N920P using Windows Forums mobile app