sm4kxd
asked on
Cannot connect to 2003 DC via RDP over VPN
I have a 2003 SBS machine as my primary domain controller in location 1. There is a VPN connecting it (SonicWall to SonicWall) to a 2003 Standard machine location 2.
- 2003 Standard was able to join the domain over the VPN link (and was able to dcpromo no problem).
- I can ping each server from the other.
- I can connect to SMB shares (\\<server name>) from each side and connect to printers hosted by each server.
- I can issue a 'shutdown /m \\<server name> /r from location 1 and the server at location 2 does reboot.
From all the above signs, I am deducing that the VPN link and DNS is working properly. However, I cannot remote desktop into the 2003 Standard server, even though I know I manually enabled it. It is a fresh 2003 server install, and actually does not have any other software installed on it (I was running short on time, and had to catch the flight back home). Since Location 1 and Location 2 are several states away, I need this RDP connection to work.
Is there a way I can verify that RDP is enabled (I know I can't enable it via GPO)? Is it possible that something else is getting in the way of the RDP link?
- 2003 Standard was able to join the domain over the VPN link (and was able to dcpromo no problem).
- I can ping each server from the other.
- I can connect to SMB shares (\\<server name>) from each side and connect to printers hosted by each server.
- I can issue a 'shutdown /m \\<server name> /r from location 1 and the server at location 2 does reboot.
From all the above signs, I am deducing that the VPN link and DNS is working properly. However, I cannot remote desktop into the 2003 Standard server, even though I know I manually enabled it. It is a fresh 2003 server install, and actually does not have any other software installed on it (I was running short on time, and had to catch the flight back home). Since Location 1 and Location 2 are several states away, I need this RDP connection to work.
Is there a way I can verify that RDP is enabled (I know I can't enable it via GPO)? Is it possible that something else is getting in the way of the RDP link?
To clarify, say you're running XP on your system. You would right click on "my computer" > manage > right click on "Computer Management (local)" and select "Connect to another computer". Specify the server in question. If for some reason you get "access denied", try mapping a drive to the server first. This way you pass your credentials to the server and should have no problem opening the session.
Once you're connected with computer management console, expand services and check for "Terminal Services" as outlined earlier.
...and if for some reason it was not enabled, here's how to do it remotely:
http://www.petri.co.il/remotely_enable_remote_desktop_on_windows_server_2003.htm
Once you're connected with computer management console, expand services and check for "Terminal Services" as outlined earlier.
...and if for some reason it was not enabled, here's how to do it remotely:
http://www.petri.co.il/remotely_enable_remote_desktop_on_windows_server_2003.htm
OK first thing is to check and see if any errors are getting produced in event viewer.
I had an issue earlier today where RDP wouldnt work on a new machine.
This was the answer
http://support.microsoft.com/kb/323497
It was on an SBS machine also.
Check there first. If this isnt the answer you will need to make sure you in fact did enable remote desktop
Here is how you can enable via policy and or a script
https://www.experts-exchange.com/questions/21936881/Group-Policy-to-Enable-Remote-Desktop-on-workstations.html
I had an issue earlier today where RDP wouldnt work on a new machine.
This was the answer
http://support.microsoft.com/kb/323497
It was on an SBS machine also.
Check there first. If this isnt the answer you will need to make sure you in fact did enable remote desktop
Here is how you can enable via policy and or a script
https://www.experts-exchange.com/questions/21936881/Group-Policy-to-Enable-Remote-Desktop-on-workstations.html
ASKER
I am able to connect to it via compmgmt.msc and Terminal Services is running, but was set to Manual. I went ahead and set to to automatic.
The VPN should not be configured to filter any traffic, but I will have the team who set it up take a closer look at it to verify.
Also, just for clarification, the server that I cannot connect to is a 2003 Standard server. The 2003 SBS machine is behaving just fine.
The VPN should not be configured to filter any traffic, but I will have the team who set it up take a closer look at it to verify.
Also, just for clarification, the server that I cannot connect to is a 2003 Standard server. The 2003 SBS machine is behaving just fine.
Hey Ryan, based on some of the info provided I have some doubts about applicability of the kb you quoted.
SM4kxd - if you can connect to one of the servers, chances are your VPN appliance is not filtering ports on per IP basis. This means that you should be able to connect to other server as long as RDP (term services) is running. Once you change to "automatic" you'll need to reboot the box for changes to take effect. I don't believe you can start Term Services if they weren't loaded at start up. (could be rusty on that). There's no difference in RDP functionality between these OSes.
SM4kxd - if you can connect to one of the servers, chances are your VPN appliance is not filtering ports on per IP basis. This means that you should be able to connect to other server as long as RDP (term services) is running. Once you change to "automatic" you'll need to reboot the box for changes to take effect. I don't believe you can start Term Services if they weren't loaded at start up. (could be rusty on that). There's no difference in RDP functionality between these OSes.
ASKER
I think I am having some deeper DNS issues, or something.
As far as I can tell, nothing has changed on the network, except now I am suddenly unable to connect with compmgmt.msc, and am not able to send it the shutdown command, even though I can still ping it, and the VPN still is connected.
I have somehow taken a step backwards, but I don't think I actually did anything to make a change like this.
As far as I can tell, nothing has changed on the network, except now I am suddenly unable to connect with compmgmt.msc, and am not able to send it the shutdown command, even though I can still ping it, and the VPN still is connected.
I have somehow taken a step backwards, but I don't think I actually did anything to make a change like this.
ASKER
Alright, well for some reason it is magically working again this morning, so I will ignore the 'disappearing' issue for now.
I verified that 'Terminal Services' was set to Automatic and rebooted the server. Now that it is back up, it still gives me the "This computer can't connect to the remote computer - Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator."
Looking through the event log I can't find any errors or flags indicating that something is wrong with terminal services. I can see entries from when the server rebooted on my command, but I can't see anything about failed connections or even failed authentication.
Since this was a fresh 2003 server install, is it possible that I forgot to enable something that is required for Terminal Services to work properly?
I verified that 'Terminal Services' was set to Automatic and rebooted the server. Now that it is back up, it still gives me the "This computer can't connect to the remote computer - Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator."
Looking through the event log I can't find any errors or flags indicating that something is wrong with terminal services. I can see entries from when the server rebooted on my command, but I can't see anything about failed connections or even failed authentication.
Since this was a fresh 2003 server install, is it possible that I forgot to enable something that is required for Terminal Services to work properly?
Some suggestions/things to check:
1. Are you a member of local admin group or "remode desktop users"?
2. Is your password non-blank? Sometimes freshly built system will deny you remote logon ability if your password is blank (part of local security policy setting).
3. Check your security policy settings - e.g. Logon Interactively (locally) or Deny local logon.
4. To exclude DNS, try connecting by IP - see if that works.
5. From the command line try "telnet servername 3389" (without quotes) this should connect you to server's RDP port - if you get a flashing cursor, that means that service is started and server is listening on port 3389, and it also means that your VPN is not blocking you
6. Check your event logs on the server - see if there are any "Failure" messages, could be a security issue such as wrong password.
7. I'm pretty sure this won't work either but worth a shot - try running "mstsc /console" - this will connect you to server's console RDP session but if you can't get in through regular RDP, chances are this won't work either.
Though I do suspect that you may have an issue due to your VPN. Here's a little trick you can try:
You said you can RDP in your SBS server... Try connecting to your SBS server and then launch RDP session from SBS server to your new server. If you can connect, then it's your VPN. If not, I'd double-check to ensure you can ping new server and/or map drives to it. Could possibly be a network issue.
Let us know what you find out.
1. Are you a member of local admin group or "remode desktop users"?
2. Is your password non-blank? Sometimes freshly built system will deny you remote logon ability if your password is blank (part of local security policy setting).
3. Check your security policy settings - e.g. Logon Interactively (locally) or Deny local logon.
4. To exclude DNS, try connecting by IP - see if that works.
5. From the command line try "telnet servername 3389" (without quotes) this should connect you to server's RDP port - if you get a flashing cursor, that means that service is started and server is listening on port 3389, and it also means that your VPN is not blocking you
6. Check your event logs on the server - see if there are any "Failure" messages, could be a security issue such as wrong password.
7. I'm pretty sure this won't work either but worth a shot - try running "mstsc /console" - this will connect you to server's console RDP session but if you can't get in through regular RDP, chances are this won't work either.
Though I do suspect that you may have an issue due to your VPN. Here's a little trick you can try:
You said you can RDP in your SBS server... Try connecting to your SBS server and then launch RDP session from SBS server to your new server. If you can connect, then it's your VPN. If not, I'd double-check to ensure you can ping new server and/or map drives to it. Could possibly be a network issue.
Let us know what you find out.
ASKER
(I've separated the answers below that might be interesting)
1. I am using the Domain Administrator account, and I think that since this server has been dcpromo'd all local users/groups have been removed.
2. Password is non-blank.
3. Local logon is not denied, and logon interactively is permitted for this account.
4. IP address nets me the same error message.
5. Telnet fails: "Could not open connection to host, on port 3389: Connect failed"
6. I see nothing in the event logs that seems to be related to any authentication failures.
7. 'mstsc -console' gives me the same response as standard 'mstsc'.
I am unable to RDP or connect to shares from SBS to 2k3, but SBS CAN ping the server by both name and ip address.
My workstation can, however, connect to admin shares on the 2k3 machine. It cannot RDP.
1. I am using the Domain Administrator account, and I think that since this server has been dcpromo'd all local users/groups have been removed.
2. Password is non-blank.
3. Local logon is not denied, and logon interactively is permitted for this account.
4. IP address nets me the same error message.
5. Telnet fails: "Could not open connection to host, on port 3389: Connect failed"
6. I see nothing in the event logs that seems to be related to any authentication failures.
7. 'mstsc -console' gives me the same response as standard 'mstsc'.
I am unable to RDP or connect to shares from SBS to 2k3, but SBS CAN ping the server by both name and ip address.
My workstation can, however, connect to admin shares on the 2k3 machine. It cannot RDP.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
BTW, try running that reghack I linked to earler to enable RDP (or confirm that it is enabled).
Can you confirm that Remote Procedure Call (RPC) service is running on the system that's having a problem? Also, try connecting to \\servername\c$ or \\servername\admin$
ASKER
Okay, I took some drastic measures and walked a user through installing GoToMyPC on the server just so I had the ability to log in and see just wtf is going on.
GoToMyPC gets me right in, of course. From that machine I can see that I do have 'Remote Access' enabled on the machine. The only firewall on the machine is the standard Windows Firewall, which as it turns out was the culprit. Adding an exception to the firewall for RDP connections let me right in.
I feel pretty silly with all the other hoops I jumped through.
Thanks CynepMeH for all your suggestions and sticking with it.
GoToMyPC gets me right in, of course. From that machine I can see that I do have 'Remote Access' enabled on the machine. The only firewall on the machine is the standard Windows Firewall, which as it turns out was the culprit. Adding an exception to the firewall for RDP connections let me right in.
I feel pretty silly with all the other hoops I jumped through.
Thanks CynepMeH for all your suggestions and sticking with it.
Don't kick yourself too hard - happens to the best of us. We all have our days and that's why you have sites like this... so that all that useless knowledge we all accumulated through user (or *cough* our own *cough*) screw-ups could be shared with others =)
Post some add'l info to my comments if nothing helped.