Cannot see application opened on remote machine
Andrew
I'm using the following code to try and open an instance
of notepad on a remote machine:
Const WINDOW_STYLE = 5
strComputer = "hostname"
Set objWMIService = GetObject("winmgmts:"
& "{impersonationLevel=impersonate}!\\" & strComputer
& "\root\cimv2")
Set objStartup = objWMIService.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = WINDOW_STYLE
Set objProcess = GetObject("winmgmts:" & "\\" &
strComputer & "\root\cimv2:Win32_Process")
errReturn = objProcess.Create ("notepad.exe", null,
objConfig, intProcessID)
This appears to run fine but I cannot see notepad open on
the remote machine. However I can see notepad.exe running
in the processes view of task manager on the remote
machine.
Both machines are running Windows 2000.
Is there something fundamentally wrong with what I am
trying to do?
Any help greatly appreciated.
Andrew
Ivan Brugiolo [MSFT]
desktop.
That is fortunately disallowed since W2K-SP3.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Andrew" <andy...@hotmail.com> wrote in message
news:0d8401c37797$ea7b6bf0$a101...@phx.gbl...
Andrew
launch applications on remote machines that interact with
the desktop using WMI?
Thanks,
Andrew
>.
>
Ivan Brugiolo [MSFT]
Desktop"
and then schedule a Job on the remote machine (with at.exe, for example).
Beware of all the consequences of doing that.
There is basically no good reason to start an interactive application on a
remote desktop,
and there are too many good reason NOT to do that.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Andrew" <andy...@hotmail.com> wrote in message
news:07d601c37854$c83f6650$a401...@phx.gbl...
Andrew
Thanks again for your reply.
OK,I see why what I am trying to do is considered bad form.
What I was originally trying to do was take the original
Microsoft provided script for installing the Blaster worm
patch on machines on a domain, and modify it so that the
remote machines were not re-started after the patch was
applied. Instead I wanted to display a message informing
the remote user that the patch had been installed and that
they should restart their machine ASAP.
>.
>
Torgeir Bakken (MVP)
> OK,I see why what I am trying to do is considered bad form.
>
> What I was originally trying to do was take the original
> Microsoft provided script for installing the Blaster worm
> patch on machines on a domain, and modify it so that the
> remote machines were not re-started after the patch was
> applied. Instead I wanted to display a message informing
> the remote user that the patch had been installed and that
> they should restart their machine ASAP.
Hi
I would have used the "net send" command to send a message to the remote
computer/user:
Set oShell = CreateObject("WScript.Shell")
sNode = "136.164.48.162" ' IP address or computer name
' Chr(20) vill create a new line in the messenger service dialog box
sMsg = "An important security update is now installed on your computer." _
& Chr(20) & Chr(20) _
& "Please reboot the computer now to let it take effect!"
oShell.Run "net.exe send " & sNode & " """ & sMsg & """", 0, False
--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide: http://www.microsoft.com/technet/scriptcenter
Mark D. MacLachlan
I have to respectfully disagree with you. There is plenty
of good reason to do this. When supporting remote
computers this is an essential tool.
A perfect example would be a corporate environment that
has locked users out of the run command or command prompt
via Group Policy. A systems administrator who has
attached to an XP machine for remote assistance often
needs to run tools in the user environment that the user
does not have rights to. Being able to remotely start a
command prompt is essential for support.
I've read in msdn code samples that Microsoft even touts
this as an advantage of WMI. Now it would seem we are
locked out of that.
I've got a post for this same question (and there seems to
be quite a lot of us looking for this functionality). So
let's rephrase our question. Is there a way to turn off
the 'bug fix' that prevents this?
>.
>
Ivan Brugiolo [MSFT]
in the low-priviledged user desktop, and the user uses the process running
a high priviledged abbout to change the logon scripts to do something
interesting.
Opening a high-priviledged application on a low priviledged desktop is
giving
away the privilege to everybody.
You can always log-on via Terminal Server on that machine
(or use remote assistance, where the user can see your mouse movements).
Then open a command prompt via RunAs, and run your command.
Then close the priviledged command prompt and return the machine to the
user.
Short of rewriting the functionality in cimwin32.dll,
there is no way to restore the bogous behavior.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mark D. MacLachlan" <mmacl...@itsynergy.com> wrote in message
news:012501c3a240$e88df550$a601...@phx.gbl...
Torgeir Bakken (MVP)
> Ivan,
>
> I have to respectfully disagree with you. There is plenty
> of good reason to do this. When supporting remote
> computers this is an essential tool.
>
> A perfect example would be a corporate environment that
> has locked users out of the run command or command prompt
> via Group Policy. A systems administrator who has
> attached to an XP machine for remote assistance often
> needs to run tools in the user environment that the user
> does not have rights to. Being able to remotely start a
> command prompt is essential for support.
Hi
As I have understood it, this functionality was removed because of the security
issues it raised.
From a previous thread that discussed this issue, with examples on how both the
local and the remote user can be the "bad" guy/girl:
From: Ivan Brugiolo [MS] (ivan...@online.microsoft.com)
Subject: Re: Win32_Process, create process
Newsgroups: microsoft.public.win32.programmer.wmi
Date: 2002-06-23 11:36:07 PST
<quote>
Just imagine the security implications of opening a program remotely on
somebody
else interactive windowstation.
If you spawn explorer.exe for User1 in the interactive windowstation of User2,
you can induce User2 to think it's its own copy of explorer.exe, and you can
track it's activities, install message hooks, get its password by faking the UI
of the prompt-for-credentials.
</quote>
From: Ivan Brugiolo [MS] (ivan...@online.microsoft.com)
Subject: Re: Win32_Process, create process
Newsgroups: microsoft.public.win32.programmer.wmi
Date: 2002-06-24 07:21:43 PST
<quote>
You open Notepad.exe to leave a message to the user, and the user uses the
open/save-as dialogs to delete/replace all the logon scripts on the DC, since
he
has a process running as a domain admin.
If by any chance this process is, let's say, Word.exe, I can run VBScript code
as a Domain Admin, maybe using it to grant myself an admin account.
</quote>
dan tudor
I've read some of your replies regarding the fact that we cannot
execute a process on a remote computer, with that process's windows
being displayed.
I have one question: besides setting the process priority and
environment variables is there any use for Win32_ProcessStartup?
Thanks,
Dan Tudor
"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<OKkJxNko...@TK2MSFTNGP12.phx.gbl>...
Ivan Brugiolo [MSFT]
All the other properties should work
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"dan tudor" <dan....@sympatico.ca> wrote in message
news:ca4d262a.03110...@posting.google.com...