Forcing a URL to open on a remote desktop
Ted Davis
happens or can be made to happen if the remote browser is open but
minimized. This is of interest to system administrators.
psexec \\host -d -i cmd /s start "" url
launches the url on the remote machine, assuming it is run from a
machine logged in as a user with the necessary rights on the remote
machine. If the browser is open, the url replaces the open one; if
the browser is closed, a new instance is launched, owned by the user
issuing the command, but the user on the remote machine can interact
with it in either case.
My boss expects to loose some sleep tonight thinking about the
implications of that.
PsExec, is from the PsTools tool kit from SystemInternals. It's
built-in help seems to indicate that you can't use the -d switch in
interactive mode, but you can: " -d Don't wait for process to
terminate (non-interactive)."
T.E.D. (tda...@gearbox.maem.umr.edu - e-mail must contain "T.E.D." or my .sig in the body)
Reinhardt Kern
>I haven't worked out all the aspects of this, especially not what
>happens or can be made to happen if the remote browser is open but
>minimized. This is of interest to system administrators.
>
> psexec \\host -d -i cmd /s start "" url
>
>launches the url on the remote machine, assuming it is run from a
>machine logged in as a user with the necessary rights on the remote
>machine. If the browser is open, the url replaces the open one; if
>the browser is closed, a new instance is launched, owned by the user
>issuing the command, but the user on the remote machine can interact
>with it in either case.
>
>My boss expects to loose some sleep tonight thinking about the
>implications of that.
What is the problem? The remote starting of any processes was
possible from the very beginning of Windows NT. NT is a multiuser
OS. BTW: Linux and Xwindows have both the same ability.
PsExec just uses existing system calls. There is no secret in it.
If you have a lot of time for research: Try to remote control an
existing application with "sendkeys()" via a psexec started
vbscript.
And you already mentioned the solution: You need the appropriate
rights to use psexec, i.e. local administrator or domain
administrator.
Reinhardt
Ted Davis
Ballenger) wrote:
>If you have an application on the remote machine that will run
>programs, then all types of things are possible. Running IE from
>a batch file is interesting for some simple tinkering. I can have
>some event on this computer run a batch file with a URL in it,
>which opens IE (default brouser) and connects to the webserver on
>the remote machine, and in turn the webserver on the remote
>computer runs another batch file there in the cgi folder, which
>has that computer do what ever I need. If running IE from a batch
>file, only one instance of IE is started, which is nice to keep
>the clutter down.
My initial application is to provide interactive messages on certain
machines about the updates that are about to be forced: the page will
have a message saying that the programs will be run in about one hour,
'do it now' button, and a form to fill out if the timing is
inconvenient or the updates are not wanted. The 'no' form will
require information about the physical location of the machine and who
is responsible for it ... then we will remove its network access until
they agree to accept the security updates.
T.E.D. (tda...@gearbox.maem.umr.edu)
SPAM filter: Messages to this address *must* contain "T.E.D."
somewhere in the body or they will be automatically rejected.
Ted Davis
Yes indeed, it's one of those things that is completely obvious ...
once somebody actually does it.
It is also true that NT is a multiuser OS, though Microsoft has
consistently denied this, as have the authors who write about it - XP
was the first version actually advertised as having some multiuser
capability. However, this multiuser capability is severely limited,
even in XP, and getting anything at all sophisticated actually to work
is something of an accomplishment - getting it to work in all the NT
OSs is a triumph.
This is not the first time I have published a technique that has had
little or not prior exposure and had people say it is too obvious to
mention .. then start using it and writing about it themselves (for
years, you hardly ever saw a recursive batch file that didn't use }{
as the recursion marker - I introduced that many years ago; before
then you didn't see recursive batch files, though there were probably
some in dark corners of the batch world).
Al Dunbar
"Ted Davis" <tda...@gearbox.maem.umr.edu> wrote in message
news:94iukvcao5i1ihskb...@4ax.com...
> On Fri, 29 Aug 2003 11:56:08 +0200, Reinhardt Kern
> <Reinhar...@gmx.de> wrote:
>
> >Ted Davis <tda...@gearbox.maem.umr.edu> wrote:
<snip>
> This is not the first time I have published a technique that has had
> little or not prior exposure and had people say it is too obvious to
> mention .. then start using it and writing about it themselves (for
> years, you hardly ever saw a recursive batch file that didn't use }{
> as the recursion marker - I introduced that many years ago; before
> then you didn't see recursive batch files, though there were probably
> some in dark corners of the batch world).
Smart of you to come up with a hidden quazi-trademark string like that. I
wonder if you thought about it at the time: "hey, if this idea is copied by
others, their code will wind up carrying my little mark around so when I see
it I will realize the effect I have had"! ;-)
Pardon the mild sarcasm, Ted. It is not aimed at you so much as at those
(myself included) whose own skills benefit by the work of others, but who,
when asked, will not remember where they got each little nugget in their
toolbox. I guess that is the nature of batch scripting.
/Al
Ted Davis
Ballenger) wrote:
>On Fri, 29 Aug 2003 07:34:53 -0500, Ted Davis
>Sounds like most of what you want to do is using HTTP and cgi
>setups for the forms and such. Probably the big decision point is
>the type of server that is to be running in the back ground on
>the client machines listnening for an incomming instruction to
>start IE and load a web page with the forms. I just tinker using
>simple web server applications in conjunction with some webcams..
>I've never really tinkered with PsExec as a server application.
>The other option is to have IE on the client connect to the
>update site when the client computer boots up to either load the
>update page or a "have a nice day" page. All of tis is probably
>clunky compared to the way most networks are administered.
Forget IE - it is a mistake to assume that all users prefer it, some
may have it disabled. Using a pure URL, provided that whatever it
points to is in standard, not MS, HTML, and that it is simple enough
for IE to render (it knows it IE specific stuff but only some of
standard HTML), then the browser doean't matter. That is the concept
behind HTML - browser independence.
There is no need for anything to run on the remote machne excep the
browser, which is launched if needed. Otherwise, the system is
stateless and all the smarts are on the server that the the form on
the page accesses. I will be using one on the administrator machine,
locked down to out VLAN only.
PsExec is not a server, in fact it is a client - the remote machine
acts ac the server for processing remote commands.
There is an updating service for XP that can be automated, but none
for NT or W2K - my scheme is to push the patches rather than pull
them.
Ted Davis
Ballenger) wrote:
>I don't understand how you are connecting to the remote computer
>from what you have described here. I don't think most brousers
>can listen for incomming request from other computers. Something
>on the remote machine has to act as a server that is listening
>for incomming calls, and have the capability to execute
>programs/scripts.
I'm executing a command on the remote computer using PsExec as the RPC
client - the command is four layers deep: PsExec remotely launches
(and returns immediately) a command processor to launch START to
launch the URL, which by association, launches the browser. The
command processor, START, and the browser continue to run until they
terminate normally without regard to PsExec which has spun that whole
chain off in a string of virtual machines.
>
>>PsExec is not a server, in fact it is a client - the remote machine
>>acts ac the server for processing remote commands.
>>
>>There is an updating service for XP that can be automated, but none
>>for NT or W2K - my scheme is to push the patches rather than pull
>>them.
>
>I'm not familiar with PsExec or windows admin tools. I'm pretty
>much limited to what is already available and what I can type
>into notepad.
Limited? I'd say crippled. I have a large toolbox, but the primary
tools are gawk, Apache, PsTools (most of them), and a few odds and
ends of ported GNU tools such as less (imagine MORE on steroids),
along with a few from the various NT series Resource Kits such as
REG.EXE, TLIST, and KILL (though I use PsList and PsKill more
frequently). Some tasks involve interaction between scripts on an NT
or XP machine and another in a Linux box - there are *a lot* of neat
tools that come with the Linux/GNU distros.