Remote Desktop connection without "user interaction"

[Guest]

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

 

[Shenan Stanley]

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]

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. ;-)

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.