Remote Desktop connection without "user interaction"

Hi all,

I need to have remote access to a computer running a measuring device
in the lab (basically to check whether the machine is running fine,
and to interfer if I need to).

Can I use a remote desktop connection for this?

- I need to see the current screen with the current software running,
i.e. not "switch users" and get an empty desktop

- I need to be able to connect to the remote computer without user
interaction (because there is nobody in the lab at night)...

I considered using VNC for that, but it seems to me that a remote
desktop connection would be more efficient in terms of CPU and network
load.

Thanks for your help

nospam wrote:
> I need to have remote access to a computer running a measuring
> device in the lab (basically to check whether the machine is
> running fine, and to interfer if I need to).
>
> Can I use a remote desktop connection for this?
>
> - I need to see the current screen with the current software
> running, i.e. not "switch users" and get an empty desktop
>
> - I need to be able to connect to the remote computer without user
> interaction (because there is nobody in the lab at night)...
>
> I considered using VNC for that, but it seems to me that a remote
> desktop connection would be more efficient in terms of CPU and
> network load.
>
> Thanks for your help

*shrug* As for the performance - depends really. You are sending
everything you normally see/do back-and-forth over the network no matter
what. Is the machine that lacking in processor/memory/network speed or does
the measuring device use that much in terms of resources (if so - this could
cause issues no matter what you choose.)

If you want to use the machine like you were in front of it and you don't
mind others seeing the screen while you are remotely using it: TeamViewer or
VNC are fine options.

Assuming Windows XP is the machine in question (given where you posted)....
And assuming you have Windows XP Professional (or some superset of that
version) running on the machine you want to remotely use...

If you don't mind the screen locking at the remote location (just because it
is locked doesn't mean things stop running) then remote desktop (using
Microsoft Terminal Services Client - mstsc - where you are to connect via an
RDP session) should work fine. It means someone at the remote location will
have to unlock the screen when they walk up to it - and that will cut you
off if you are connected remotely at that time.

The trick to doing this with Remote Desktop - you log in as the same user
that was logged in anyway. That's it. Nothing else. And you could,
truthfully, push the session back to the actual console (unlocking it at the
remote location) if you used the right command.

That means that user *has to have a password*. That means that user *has to
be a member of the remote desktop users group* (all local administrators are
by default.) That means that machine has to have Remote Desktop enabled.
That means that machine has to have the software firewall setup in such a
way to allow the remote desktop session. That means that any
routers/firewalls between your remote location and the machine itself must
be configured to allow the traffic and forward it if need be. (All in all -
Teamviewer Portable+TeamViewer Host is just easier. heh)

If you were logged into the remote machine locally (with the screen
unlocked) before you remoted into it and you logged in remotely as the same
user as was logged in locally - you can *push* the session back to the
console instead of just disconnecting...

Start button --> RUN --> tscon 0 /dest:console --> OK
(on the REMOTE machine - not the one you are using physically)

Given your user has the rights to do this and you WERE logged in as that
user before LOCALLY with the screen unlocked before you remoted in... That
should push the session view back to the local console on the machine.

Notice everything I highlighted by repeating. ;-)

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html

> *shrug* As for the performance - depends really. You are sending
> everything you normally see/do back-and-forth over the network no matter
> what.

This is not correct. VNC consumes considerably more bandwidth than does
RDP.

But there's another option, LogMeIn.com has the ability to reduce the color
level. Making a connection to a machine running in full color can be
agonizingly slow in VNC and somewhat tolerable in RDP. But logmein
provides the option to connect in black and white (leaving the desktop on
the machine in color, sending only B&W down the wire). This makes for a
much faster usage experience. I know, I do it regularly to a distant
machine with a 1920x1080x32 desktop using a rather slow connection. Works
quite well. Neither RDP nor VNC worked over the slow link (I can't recall
the uplink speed).

So if you're OK using a third-party service then try using logmein.com

-Bill Kearney

nospam wrote:
> I need to have remote access to a computer running a measuring
> device in the lab (basically to check whether the machine is
> running fine, and to interfer if I need to).
>
> Can I use a remote desktop connection for this?
>
> - I need to see the current screen with the current software
> running, i.e. not "switch users" and get an empty desktop
>
> - I need to be able to connect to the remote computer without user
> interaction (because there is nobody in the lab at night)...
>
> I considered using VNC for that, but it seems to me that a remote
> desktop connection would be more efficient in terms of CPU and
> network load.
>
> Thanks for your help

Shenan Stanley wrote:
> *shrug* As for the performance - depends really. You are sending
> everything you normally see/do back-and-forth over the network no
> matter what. Is the machine that lacking in
> processor/memory/network speed or does the measuring device use
> that much in terms of resources (if so - this could cause issues no
> matter what you choose.)
> If you want to use the machine like you were in front of it and you
> don't mind others seeing the screen while you are remotely using
> it: TeamViewer or VNC are fine options.
>
> Assuming Windows XP is the machine in question (given where you
> posted).... And assuming you have Windows XP Professional (or some
> superset of that version) running on the machine you want to
> remotely use...
> If you don't mind the screen locking at the remote location (just
> because it is locked doesn't mean things stop running) then remote
> desktop (using Microsoft Terminal Services Client - mstsc - where
> you are to connect via an RDP session) should work fine. It means
> someone at the remote location will have to unlock the screen when
> they walk up to it - and that will cut you off if you are connected
> remotely at that time.
> The trick to doing this with Remote Desktop - you log in as the
> same user that was logged in anyway. That's it. Nothing else. And you
> could, truthfully, push the session back to the actual
> console (unlocking it at the remote location) if you used the right
> command.
> That means that user *has to have a password*. That means that
> user *has to be a member of the remote desktop users group* (all
> local administrators are by default.) That means that machine has
> to have Remote Desktop enabled. That means that machine has to have
> the software firewall setup in such a way to allow the remote
> desktop session. That means that any routers/firewalls between
> your remote location and the machine itself must be configured to
> allow the traffic and forward it if need be. (All in all -
> Teamviewer Portable+TeamViewer Host is just easier. heh)
> If you were logged into the remote machine locally (with the screen
> unlocked) before you remoted into it and you logged in remotely as
> the same user as was logged in locally - you can *push* the session
> back to the console instead of just disconnecting...
>
> Start button --> RUN --> tscon 0 /dest:console --> OK
> (on the REMOTE machine - not the one you are using physically)
>
> Given your user has the rights to do this and you WERE logged in as
> that user before LOCALLY with the screen unlocked before you
> remoted in... That should push the session view back to the local
> console on the machine.
> Notice everything I highlighted by repeating. ;-)

Bill Kearney wrote:
> This is not correct. VNC consumes considerably more bandwidth than
> does RDP.
>
> But there's another option, LogMeIn.com has the ability to reduce
> the color level. Making a connection to a machine running in full
> color can be agonizingly slow in VNC and somewhat tolerable in RDP.
> But logmein provides the option to connect in black and white
> (leaving the desktop on the machine in color, sending only B&W down
> the wire). This makes for a much faster usage experience. I know,
> I do it regularly to a distant machine with a 1920x1080x32 desktop
> using a rather slow connection. Works quite well. Neither RDP nor
> VNC worked over the slow link (I can't recall the uplink speed).
>
> So if you're OK using a third-party service then try using
> logmein.com

Depends on the flavor of VNC and the settings, extras, machine power at both
ends, etc. Just like everything else - depends, really.

"Performance" does not just mean "network bandwidth" - but how things are
compressed before they are sent, how they are decompressed (if at all) and
the performance of the machines at both ends during those processes. The
network may or may not be the bottleneck in the 'sending everything you
normally see/do back-and-forth over the network'. ;-)

Teamviewer (best I have seen)
LogMeIn
GoToMyPC
VNC (RealVNC, TightVNC, UltraVNC, etc...)
Etc...

All give you pretty much the same options, the devil is in the details of
what you want to do. If the OP ever returns (doubtful at this point) -
perhaps they can enlighten us as to what their research and testing showed
them and they ended up choosing.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html