raider25
Registered: 08/13/09
Posts: 4
|
|
|
| #1 |
Everything was working fine until we moved the PC's in the Tech support area to a new subnet. We can ping by name and by IP address. It attempts to connect and even authenticates if you try it from a user without local admin rights, but then comes up with the error:
Failed to start a remote control session with machine XXX
Error #10060. The attempt to connect timed out without establishing a connection.
One PC was not moved to the new subnet and it works fine. Any ideas?
|
| |
pbergeot
Moderator
Registered: 09/06/08
Posts: 227
|
|
|
| #2 |
Are you trying to connect to the machine using its name or new IP address?
If you are using the name, try to connect via the IP address and let me know if you get the same error message.
__________________
Pascal @ PJ Technologies, Inc.
http://www.goverlan.com |
| |
raider25
Registered: 08/13/09
Posts: 4
|
|
|
| #3 |
Thank you for your reply. We have tried both ways, IP and Name from Multiple PC's that worked previously. The eventvwr indicates that a remote control session was started. It connects, and it even authenticates if you try it from a PC that does not have someone logged in with the correct authority, it even looks like it installs the client, but after it the progress bar gets about half way, it times out. |
| |
pbergeot
Moderator
Registered: 09/06/08
Posts: 227
|
|
|
| #4 |
Ok, a couple of thinks to try:
First, let's do the test from a user account which has local administrative privileges on that client machine. It make it simpler.
Open the Credential Manager (View > Settings > Alternate Credentials > Credential Manager) and remove any entry for that client machine.
Open the Favorites Section (if hidden: View > Show Favorites) and insert the client machine (name or IP) into it.
Right click on the computer item in the favorites and:
1/ Select Goverlan Agents > Remove Agents - Tell me if this succeeds
2/ Select Goverlan Agents > Install Agents - Tell me if this succeeds
3/ Select View Sessions Log - Tell me if this succeeds
If it all succeeds, try to connect again. If it fails to connect, it might be that communications on port 21157 and 21158 are blocked?
Let me know.
__________________
Pascal @ PJ Technologies, Inc.
http://www.goverlan.com |
| |
raider25
Registered: 08/13/09
Posts: 4
|
|
|
| #5 |
1. Remove agents worked
2. Install agents worked
3. View Sessions Log opened a window that showed who connected and when. Same error with no connection. Do you still think it is ports 21157 and 21158 blocked? Are there any other test we can perform? Thank you again for your time.
|
| |
pbergeot
Moderator
Registered: 09/06/08
Posts: 227
|
|
|
| #6 |
Well, the Goverlan Services uses port 21159 to transfer general information (such as the Session Log). Then it uses ports 21157 and 21158 for remote control sessions.
Let's do a test, can you download and install Goverlan Remote Control v7 on one of the bad machine and try using this version? Since G7 only uses a single port (21159) for all purposes, we can see if indeed it is the issue.
PS: Goverlan v7 will install side by side with Goverlan v6.
__________________
Pascal @ PJ Technologies, Inc.
http://www.goverlan.com |
| |
raider25
Registered: 08/13/09
Posts: 4
|
|
|
| #7 |
To make a long story short, your advice helped narrow things down. I was able to contact the original person that put a GPO in place to limit IP addresses that could use Goverlan to connect remotely to PC's. He pointed me to correct policy. The ill-fated attempt basically only limited it to users with a 10.x.x.x address and when we went to the subnet starting with 172.x.x.x it did not work. I was finally able to convince the people responsible for administering AD that further investigation was warranted. v7 worked fine and I think helped point in the right direction as well. Suffice it to say that when we took the target and source out of a GPO-controlled area it worked and when we put it back in, it did not. Had to beat them over the head with that, but I finally got through. Thanks again for your time. |
| |
