Re: XP to Vista Remote Assistance.
- From: Charlie3110 <Charlie3110@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 14 Jul 2009 01:23:02 -0700
Let me know i am delighted with TeamViewer and have no need to experiment but
I am always imtersted in what others think of programs.
"Douglas Baumwall" wrote:
Microsoft has a free program called Microsoft SharedView.
I'd be interested to understand how it compares to TeamViewer.
Try Team Viewer it is so simple and foolproof MS should look long and hard
at it and then get TeamViewer on their staff to write them a remote
Assistance program for 7! Their idea of RA is so complicated with the right
ports and firewalls that it is way above what is needed. Teamviewer just gets
on with it.
"Douglas Baumwall" wrote:
Microsoft certainly missed the mark on this. Remote assistance needs to be
simple and foolproof but it's not. I've been able to quickly and easily
provide assistance from XP to Vista using crossloop.com, but only when Vista
is operating via an administrator account. It doesn't currently work when
Vista is operating via a user account. This unfortunately conflicts with the
goal of computing via a user account.
thanks Ian for that. The whole point of having and wanting to give remote
assistance to any one, is for the reason that they need it. How they are
expected to open ports etc. is unreasonable and unthinkable. I think MS needs
to get itself sorted for 7 and get back to basics. I am using Teamviewer now
and my elderly relatives find it easier than the old RA so even if 7
facilitates RA I think we have moved on. Thanks again for being interested
pity MS isn't?
"Ian ten Cate" wrote:
"Shenan Stanley" wrote:
The *you* refers to whom? This is a publically published peer-to-peer
worldwide newsgroup - you may want to be more specific in the future. You
*may be* referring to my advice - and I would still suggest it to you (it's
easier to set up if there are routers/firewalls involved and is secure.)
However - it is not necessary.
For XP to Vista - you have a couple of choices.
1) Have the Vista end turn off the NLA requirement for Remote Desktop.
(Allow connections from computers running any version of Remote Desktop)
(Assumes a given edition of Vista or above - however - that is an
assumption as you have not given it.)
2) Install and activate the NLA ability on Windows XP.
(You have installed Windows XP SP3 - so...)
I suggest #2.
That all also assumes you have the proper ports forwarded/redirected on
*each* end to allow for the traffic to be directed properly. (Routers with
multiple machines behind them and 3389 directed to the proper machines,
firewalls on both sides with Remote Desktop and Remote Assistance as allowed
Thus - why I recommend the ease of something like TeamViewer. UltraVNC
SingleClick is good too - if you understand how to setup your end.
How To Ask Questions The Smart Way
Just wanted to add for everyone's benefit who might be looking into the same
problem - I've been researching this (trying to help out a friend) and there
are actually two issues anyone might run into:
1) XP to Vista assistance software issues - covered by Shenan Stanley above
2) RA network issues - change in the nature of the Remote Assistance
listening port from XP to Vista.
Basically, RA on XP listened on the regular RDP port (3389) so that all the
recipient of help had to do was a one-time thing to allow 3389 through their
firewall and to the machine. Often 3rd-party software and hardware firewalls
(think Norton, your ISP's modem/router, etc.) had a rule to allow this port
for remote assistance which was either turned on by default or easy to turn
With Vista, Microsoft moved to using random ports for the recipient to
listen on for each request for assistance, and embedded it in the invitation.
Works fine if you have
a) a uPNP router which can dynamically open that port at the request of the
Vista machine or
b) a really knowledgeable recipient who can manually open the correct port
each time they ask for help and set up the port-forwarding rule so that
traffic hitting the external address gets sent to the appropriate internal
machine (though if they were that knowledgeable, they probably don't need
help); along with a fairly knowledgeable helper who can manually modify the
ticket to reflect the external address of the firewall (in the case of
hardware firewalls) rather than the internal (likely NATted) address of the
Vista machine. Guess how many times that will happen :)
c) a fairly knowledgeable recipient who can configure their firewall to put
it into "DMZ mode" (where traffic is actually allowed to hit the internal
machine without going through the firewall) and pull it out again after
assistance has been given, plus the fairly knowledgeable helper who can
manually modify the ticket as described in b)
As far as I know (I've been looking without success fpr a few hours) there's
no way to tell Vista to use a static port choice again.
That seems to be why a lot of people are moving away again from the
OS-provided solution (which now just doesn't apply in a lot of cases - in my
case I'm looking at a user who's getting their access from Bell Sympatico,
who've chosen a 2701HG-G router/gateway as have Qwest and a bunch of others,
which doesn't understand uPnP).
I have to side with those who feel that Microsoft's taken a useful thing for
home users, which might rarely have posed a security risk (the listening
service would only be there occasionally, for as long as the ticket was
valid, since Remote Desktop wasn't a feature of the Home editions) and made
it unworkable to address a concern on the part of enterprise users, who have
Remote Desktop services running all the time.
Probably they should have made a product differentiation and said that the
Home version of RA stayed on 3389 while the versions with Remote Desktop
running all the time got the random ports for safety.
If I find an answer I'll post it here too. Just thought I'd help people
avoid some of the frustration of trying to get everything working on 3389 and
being baffled when it didn't work.
Anybody know if anything's changing in 7? I haven't had the time to check