At lost with WMI... Will worship anyone that can help in anyway :) Sharon

  • Thread starter Thread starter ricolee99
  • Start date Start date
R

ricolee99

Hi everyone,

I'm trying to invoke my .exe application from a remote server. Here is
the code:

ManagementClass processClass = new ManagementClass ("\\\\"

+"RemoteServerName"
+
"\\root\\CIMV2:Win32_Process");

//returns back an object that contains a list of input parameters for
the method
ManagementBaseObject inParams = processClass.GetMethodParameters

("Create");

//set the parameters
inParams ["CommandLine"] = "C:\\SomeFolder\\Startup.exe" + " \""
+
"C:\\SomeFolder\\someconfig.xml" + "\"";

InvokeMethodOptions options = new InvokeMethodOptions();
options.Timeout = new TimeSpan(0,0,0,30);

ManagementBaseObject outParams = processClass.InvokeMethod ("Create",
inParams,

options);


string return_code = outParams ["ReturnValue"].ToString();


When I run this, it runs under a valid domain account called:
someDomain/someAccount, I get a return code from the outParams
(return_code) of "8". Looking on msdn:
http://msdn.microsoft.com/library/d.../wmi/create_method_in_class_win32_process.asp


it tells me the value is "Unknown Failure".

I've tried many things, looking at permissions and finally the above
code to invoke my application successfully. I got it working by
granting someDomain/someAccount full administrator priviliges on the
remote machine and it worked like a charm.

The problem is my co. is not allowing me to grant this account admin
privileges on that machine. This doesn't make sense as it shouldn't
need admin access, as long as it has read/execute permissions on the
exe folder, winnt folder, and documents and settings folder on the
remote machine.

Can someone please tell me what the problem is? Why do I need
administrative access for that account on the remote server for it to
work?

Any suggestions would be much, much appreciated!

Thanks in advance

Sharon
 
Invoking WMI underlying methods normally does require Administrative access.
After all, you wouldn't want some rogue network user arbitrarily rebooting
your PC on you, would you?
Cheers,
Peter
 
Thanks for the response Peter, really appreciated!

Sorry, I failed to mention the following: On my development and
acceptance servers, I didn't need to grant that account administrative
access, and everything works fine (the account is not even given a
guest access, it just has read and execute access on those folders and
files. But in production, I've tried to give the account just rights
on those folders and files, similar to development and acceptance, but
the invoking mechanism does not work. I found out that granting that
account admin access, everything works fine in production....


Can you provide any hints or suggestions Peter?

Thanks so much

Sharon
Invoking WMI underlying methods normally does require Administrative access.
After all, you wouldn't want some rogue network user arbitrarily rebooting
your PC on you, would you?
Cheers,
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com




[email protected] said:
Hi everyone,

I'm trying to invoke my .exe application from a remote server. Here is
the code:

ManagementClass processClass = new ManagementClass ("\\\\"

+"RemoteServerName"
+
"\\root\\CIMV2:Win32_Process");

//returns back an object that contains a list of input parameters for
the method
ManagementBaseObject inParams = processClass.GetMethodParameters

("Create");

//set the parameters
inParams ["CommandLine"] = "C:\\SomeFolder\\Startup.exe" + " \""
+
"C:\\SomeFolder\\someconfig.xml" + "\"";

InvokeMethodOptions options = new InvokeMethodOptions();
options.Timeout = new TimeSpan(0,0,0,30);

ManagementBaseObject outParams = processClass.InvokeMethod ("Create",
inParams,

options);


string return_code = outParams ["ReturnValue"].ToString();


When I run this, it runs under a valid domain account called:
someDomain/someAccount, I get a return code from the outParams
(return_code) of "8". Looking on msdn:
http://msdn.microsoft.com/library/d.../wmi/create_method_in_class_win32_process.asp


it tells me the value is "Unknown Failure".

I've tried many things, looking at permissions and finally the above
code to invoke my application successfully. I got it working by
granting someDomain/someAccount full administrator priviliges on the
remote machine and it worked like a charm.

The problem is my co. is not allowing me to grant this account admin
privileges on that machine. This doesn't make sense as it shouldn't
need admin access, as long as it has read/execute permissions on the
exe folder, winnt folder, and documents and settings folder on the
remote machine.

Can someone please tell me what the problem is? Why do I need
administrative access for that account on the remote server for it to
work?

Any suggestions would be much, much appreciated!

Thanks in advance

Sharon
Click to expand...
Click to expand...
 
sorry, also, I heard that for invoking WMI methods, the only access
that you need to grant to the account is
read and execute access on the appropriate file/s and folder/s on the
remote machine. Or was I misinformed?

Thanks!

Sharon
 
Hi everyone,

I'm trying to invoke my .exe application from a remote server. Here is
the code:

ManagementClass processClass = new ManagementClass ("\\\\"

+"RemoteServerName"
+
"\\root\\CIMV2:Win32_Process");

//returns back an object that contains a list of input parameters for
the method
ManagementBaseObject inParams = processClass.GetMethodParameters

("Create");

//set the parameters
inParams ["CommandLine"] = "C:\\SomeFolder\\Startup.exe" + " \""
+
"C:\\SomeFolder\\someconfig.xml" + "\"";

InvokeMethodOptions options = new InvokeMethodOptions();
options.Timeout = new TimeSpan(0,0,0,30);

ManagementBaseObject outParams = processClass.InvokeMethod ("Create",
inParams,

options);


string return_code = outParams ["ReturnValue"].ToString();


When I run this, it runs under a valid domain account called:
someDomain/someAccount, I get a return code from the outParams
(return_code) of "8". Looking on msdn:
http://msdn.microsoft.com/library/d.../wmi/create_method_in_class_win32_process.asp


it tells me the value is "Unknown Failure".

I've tried many things, looking at permissions and finally the above
code to invoke my application successfully. I got it working by
granting someDomain/someAccount full administrator priviliges on the
remote machine and it worked like a charm.

The problem is my co. is not allowing me to grant this account admin
privileges on that machine. This doesn't make sense as it shouldn't
need admin access, as long as it has read/execute permissions on the
exe folder, winnt folder, and documents and settings folder on the
remote machine.

Can someone please tell me what the problem is? Why do I need
administrative access for that account on the remote server for it to
work?

Any suggestions would be much, much appreciated!

Thanks in advance

Sharon
Click to expand...


Add the non admin user to the WMI ACL for the namespace on the remote server
you want to connect with.
To do this you need to start wmimgmt.msc from the command line.
Right click WMI Control - select properties - security tab - open root and
select cimv2
click security and add the user account to the list of users, enable remote
connect and execute method permissions.
Click Apply when done.
Now this user should be able to connect and execute methods from a remote
server, note that the impersonated user will need filesystem privileges
execute and read to run the applications started remotely.
Also note that it's not possible to launch interactive processes through WMI
and that the remote processes don't have access to the users profile (the
Users Hive is not loaded through this remote invocation).

Willy.
 
Thanks for the response Willy,

Unfortunately, that particular user account is already added to the
CIMV2 with every single permissions (including remote and execute).
The application is a .net console application. This is just a really
weird problem for me... I think I've setted up the production box to be
the same as development and acceptance and yet there seems to be
something on the production box that doesn't like it when we try to
invoke the .exe.

Sharon
Hi everyone,

I'm trying to invoke my .exe application from a remote server. Here is
the code:

ManagementClass processClass = new ManagementClass ("\\\\"

+"RemoteServerName"
+
"\\root\\CIMV2:Win32_Process");

//returns back an object that contains a list of input parameters for
the method
ManagementBaseObject inParams = processClass.GetMethodParameters

("Create");

//set the parameters
inParams ["CommandLine"] = "C:\\SomeFolder\\Startup.exe" + " \""
+
"C:\\SomeFolder\\someconfig.xml" + "\"";

InvokeMethodOptions options = new InvokeMethodOptions();
options.Timeout = new TimeSpan(0,0,0,30);

ManagementBaseObject outParams = processClass.InvokeMethod ("Create",
inParams,

options);


string return_code = outParams ["ReturnValue"].ToString();


When I run this, it runs under a valid domain account called:
someDomain/someAccount, I get a return code from the outParams
(return_code) of "8". Looking on msdn:
http://msdn.microsoft.com/library/d.../wmi/create_method_in_class_win32_process.asp


it tells me the value is "Unknown Failure".

I've tried many things, looking at permissions and finally the above
code to invoke my application successfully. I got it working by
granting someDomain/someAccount full administrator priviliges on the
remote machine and it worked like a charm.

The problem is my co. is not allowing me to grant this account admin
privileges on that machine. This doesn't make sense as it shouldn't
need admin access, as long as it has read/execute permissions on the
exe folder, winnt folder, and documents and settings folder on the
remote machine.

Can someone please tell me what the problem is? Why do I need
administrative access for that account on the remote server for it to
work?

Any suggestions would be much, much appreciated!

Thanks in advance

Sharon
Click to expand...


Add the non admin user to the WMI ACL for the namespace on the remote server
you want to connect with.
To do this you need to start wmimgmt.msc from the command line.
Right click WMI Control - select properties - security tab - open root and
select cimv2
click security and add the user account to the list of users, enable remote
connect and execute method permissions.
Click Apply when done.
Now this user should be able to connect and execute methods from a remote
server, note that the impersonated user will need filesystem privileges
execute and read to run the applications started remotely.
Also note that it's not possible to launch interactive processes through WMI
and that the remote processes don't have access to the users profile (the
Users Hive is not loaded through this remote invocation).

Willy.
Click to expand...
 
Thanks for the response Willy,

Unfortunately, that particular user account is already added to the
CIMV2 with every single permissions (including remote and execute).
The application is a .net console application. This is just a really
weird problem for me... I think I've setted up the production box to be
the same as development and acceptance and yet there seems to be
something on the production box that doesn't like it when we try to
invoke the .exe.

Sharon
Click to expand...


You mean that in that case it returns error 8?
That's real weird, because the error is retuned by the WMI service not by
your remoted application, WMI returns the error because for some weird
reason it cannot start the application.
Could you please post a complete repro case?

Willy.
 
Hi Willy,

Not sure what you mean by repro case... but here's what's going on:

Some background information: We're using IBM's websphere message
queue. The jist of IBM's websphere message queue is that it provides
functionality to enable applications to place character messages on a
'queue' and the queue is setup so that whenever a message is placed on
it, it triggers our .exe to read those messages.

We have IBM's service running in the background on a server called
'Zeus'. IBM's service is scanning the queue periodically for any
messages. When a message is placed on the queue, IBM's service
triggers their .exe which calls one of our applications called
Trigger.exe. Trigger.exe also sits on Zeus.

Trigger.exe basically determines which queue the message came from.
Once the queue is determined, Trigger.exe will invoke the appropriate
application. We're using WMI for invoking, the main code logic is in
my previous thread. Trigger.exe runs under a domain account, let's
call it: someDomain/someUser

We're the first application to use the Trigger.exe. Our application is
called DoIt.exe. DoIt.exe is just a console application that utilizes
com components within it's logic to process the messages on the queue.
DoIt.exe sits on another server on the same domain, the server is
called 'Hercules'.

Permissions
--------------------
-On 'Hercules' server, someDomain/someUser has read/execute permissions
on the c:\winnt folder, c:\document and settings folder, and the folder
where DoIt.exe resides.
-someDomain/someUser is not defined in any of the Local Groups security
on 'Hercules'. (so that means it's not a guest, nor a admin, etc.)
-The WMI permissions on the CIMV2 has someAccount/someUser granted with
all permissions, including remote access.


Okay, now for the weird part... initially the Trigger.exe was able
invoke DoIt.exe in production. Hooray! But we were experiencing some
problems with the DoIt.exe logic, so we decided to grant
someAccount/someUser as Administrator on that box to see if it fixed
the DoIt logic problem. After we finished adding and testing DoIt.exe,
we wanted everything to be back to status-quo, so we removed
someDomain/someUser from Administrators group. So theoretically, the
Trigger.exe should still be able to invoke DoIt.exe, right? Well,
after removing the account from Administrators group... the Trigger.exe
was not able to invoke DoIt.exe.

When we run this in production, it chokes, right on the line:

processClass.InvokeMethod ("Create", inParams, options); <-- please
refer to the code in previous thread

We have similar environments set up in development and acceptance, and
it's all good. I can't seem to replicate the problem with those
environments as to production. I've scanned the security in dev. and
acceptance and compared them with production, nothing looks out of the
ordinary.

I'm not allowed to touch the 'Zeus' as it's a production box. So what
I did, was take the main core logic from Trigger.exe... being the
invoking part (the code from the above thread) and ran it on my
developer machine to point to the DoIt.exe in production. When I ran
the application in debug mode, I made sure I ran it as
someDomain/someUser account. Putting the break points, it appears to
be returning an "8" from the InvokeMethod.

It's almost as if when we added the account to the Admin group and then
removed the account, it wiped out some security setting that allowed
Trigger.exe to invoke the DoIt.exe.

However, if I grant someDomain/someUser local admin access on
'Hercules', everything works fine. I wish everything was that simple,
by just granting someDomain/someUser admin access on 'Hercules', but I
work for a company that believes in red tape and we have a security
team that will crack down on me. They basically say that I need to
identify the root cause as dev and acceptance works fine without the
admin account and it's basically tough luck for me if it can't work in
production.

I'm really at lost as to what I can do... it's been 10 days and
counting, I sincerely appreciate your help for looking into this for
me.

Sharon
 
Hi Willy,

Not sure what you mean by repro case... but here's what's going on:

Some background information: We're using IBM's websphere message
queue. The jist of IBM's websphere message queue is that it provides
functionality to enable applications to place character messages on a
'queue' and the queue is setup so that whenever a message is placed on
it, it triggers our .exe to read those messages.

We have IBM's service running in the background on a server called
'Zeus'. IBM's service is scanning the queue periodically for any
messages. When a message is placed on the queue, IBM's service
triggers their .exe which calls one of our applications called
Trigger.exe. Trigger.exe also sits on Zeus.

Trigger.exe basically determines which queue the message came from.
Once the queue is determined, Trigger.exe will invoke the appropriate
application. We're using WMI for invoking, the main code logic is in
my previous thread. Trigger.exe runs under a domain account, let's
call it: someDomain/someUser

We're the first application to use the Trigger.exe. Our application is
called DoIt.exe. DoIt.exe is just a console application that utilizes
com components within it's logic to process the messages on the queue.
DoIt.exe sits on another server on the same domain, the server is
called 'Hercules'.

Permissions
--------------------
-On 'Hercules' server, someDomain/someUser has read/execute permissions
on the c:\winnt folder, c:\document and settings folder, and the folder
where DoIt.exe resides.
-someDomain/someUser is not defined in any of the Local Groups security
on 'Hercules'. (so that means it's not a guest, nor a admin, etc.)
-The WMI permissions on the CIMV2 has someAccount/someUser granted with
all permissions, including remote access.


Okay, now for the weird part... initially the Trigger.exe was able
invoke DoIt.exe in production. Hooray! But we were experiencing some
problems with the DoIt.exe logic, so we decided to grant
someAccount/someUser as Administrator on that box to see if it fixed
the DoIt logic problem. After we finished adding and testing DoIt.exe,
we wanted everything to be back to status-quo, so we removed
someDomain/someUser from Administrators group. So theoretically, the
Trigger.exe should still be able to invoke DoIt.exe, right? Well,
after removing the account from Administrators group... the Trigger.exe
was not able to invoke DoIt.exe.

When we run this in production, it chokes, right on the line:

processClass.InvokeMethod ("Create", inParams, options); <-- please
refer to the code in previous thread

We have similar environments set up in development and acceptance, and
it's all good. I can't seem to replicate the problem with those
environments as to production. I've scanned the security in dev. and
acceptance and compared them with production, nothing looks out of the
ordinary.

I'm not allowed to touch the 'Zeus' as it's a production box. So what
I did, was take the main core logic from Trigger.exe... being the
invoking part (the code from the above thread) and ran it on my
developer machine to point to the DoIt.exe in production. When I ran
the application in debug mode, I made sure I ran it as
someDomain/someUser account. Putting the break points, it appears to
be returning an "8" from the InvokeMethod.

It's almost as if when we added the account to the Admin group and then
removed the account, it wiped out some security setting that allowed
Trigger.exe to invoke the DoIt.exe.

However, if I grant someDomain/someUser local admin access on
'Hercules', everything works fine. I wish everything was that simple,
by just granting someDomain/someUser admin access on 'Hercules', but I
work for a company that believes in red tape and we have a security
team that will crack down on me. They basically say that I need to
identify the root cause as dev and acceptance works fine without the
admin account and it's basically tough luck for me if it can't work in
production.

I'm really at lost as to what I can do... it's been 10 days and
counting, I sincerely appreciate your help for looking into this for
me.

Sharon
Click to expand...


What I call a repro is a complete sample that illustrates the issue,
something like following sample:
Could you please try this one, and watch if notepad (or any other simple
program that doesn't require specific privileges) starts on the remote
server.
Check the "RunProcess" and change the arguments to suit your needs (for
instance use a non admin account as ConnectionUser).
Note that while a program runs remotely it's main window is not be visible,
so you'll have to check it's presence in taskman (and kill it when done).
If this doesn't work, I suggest you to turn on WMI logging on the Client and
the server and enable Logon auditing (failure and Success) on the server.
Try again with Logging turned on and inspect the logging files and the
eventlog (Security) when done.


using System;
using System.Management;
using System.IO;
class App {
private static void Main(string[] args)
{
// Run a program remotely under domain\useraccount, note however that
because the Logon type is network (3).
// (this logon is created by wmiprvse.exe) the started application won't
have network access privileges!
String processName = "notepad.exe";
RunProcess M = new RunProcess("domain\\useraccount", "hisPwd",
"RemoteServerName");
M.Run(processName);
}
}
sealed class RunProcess
{
private ManagementBaseObject inputArgs = null;
private ManagementBaseObject outParams = null;
private uint ret = 0;
private ConnectionOptions co;
private ManagementScope scope;

public RunProcess(string ConnectionUser, string ConnectionPassword, string
Machine )
{
co = new ConnectionOptions();
co.Username = ConnectionUser;
co.Password = ConnectionPassword;
co.Impersonation = ImpersonationLevel.Impersonate;

scope = new ManagementScope(@"\\" + Machine + @"\root\cimv2", co);
}
public RunProcess() : this("", "", ".")
{}
public void Run(string process)
{
ManagementClass si = new ManagementClass("Win32_ProcessStartup");
using(ManagementClass mc = new ManagementClass("Win32_Process"))
{
mc.Scope = scope;
inputArgs = mc.GetMethodParameters("Create");
inputArgs["CommandLine"] = process;
inputArgs["ProcessStartupInformation"] = si;
outParams = mc.InvokeMethod("Create", inputArgs, null);
ret = Convert.ToUInt32(outParams.Properties["ReturnValue"].Value);
if(ret != 0)
Console.WriteLine("Failed : {0}", ret);
}

}
}

Willy.
 
Hi Willy,

Thanks for the hints.

I've ran the .exe program that you have from above and I still get the
same error, returning an "8". I've turned on the WMI error logging and
no logs were created on both the client and remote machines.

I've configured auditing on the remote server and couldn't find
anything trying to access the application folder/file. I've also
audited the login/logoff on the remote machine and couldn't find the
someDomain/someAccount trying to log onto the server.



Sharon
 
Hi Willy,

Thanks for the hints.

I've ran the .exe program that you have from above and I still get the
same error, returning an "8". I've turned on the WMI error logging and
no logs were created on both the client and remote machines.

I've configured auditing on the remote server and couldn't find
anything trying to access the application folder/file. I've also
audited the login/logoff on the remote machine and couldn't find the
someDomain/someAccount trying to log onto the server.



Sharon
Click to expand...

Weird, authentication has been done when calling
GetMethodParameters("create"), so before calling :
InvokeMethod("Create....); and as this call doesn't throw a
System.UnauthorizedAccessException:
there should be logon audit messages in the security log. You can try this
by denying access to the remote server (set deny access to this server in
Local Security Policy on the remote server).

Could you try to run the exact same code from a local admin's logon session
(logon or runas with a local administrators credentials)?

Willy.
 
Hi again,

Sorry, I made a mistake, I was looking at the wrong security logs. The
remote server is a load balancing server, so I looked at the wrong node
;)

I invoked my app with local admin privileges to someDomain/someAccount
which works
and invoked my app with non-local admin privileges to
someDomain/someAccount which doesn't work.

I setted the auditing for logon/logoff and object access to the
application directory and files on the remote server. All logon/logoff
events are successful in both scenarios. In both scenarios, the event
viewer records the application account I'm trying to logo on as, in
this case it's: someDomain/someAccount. The event viewer also recorded
my own personal account: someDomain/myAccount (I'm guessing that even
though I'm using someDomain/someAccount to access the .exe, for some
reason the auditing records my own personal ID as trying to log on
too).

There are some major differences in the event logs between the local
admin scenario and the non-local admin:

Event Viewer for scenario that granted local admin to
someDomain/someAccount:

Logon to server with someDomain/someAccount
Logon to server with someDomain/someAccount
Logoff to server with someDomain/someAccount
Logon to server with someDomain/someAccount
Logoff to server with someDomain/someAccount
Logon to server with someDomain/myAccount
Logon to server with someDomain/someAccount
Logon to server with someDomain/myAccount
Logon to server with someDomain/someAccount
Object Access to .exe and the user is someDomain/someAccount

More object Access stuff...

Logoff to server with someDomain/someAccount Logoff
Logoff to server with someDomain/myAccount Logoff
Logoff to server with someDomain/myAccount Logoff
Logoff to server with someDomain/someAccount Logoff


Here is the Event Viewer for the scenario where someAccount/someDomain
has no access:


Logon to server with someDomain/someAccount Logon
Logon to server with someDomain/someAccount Logon
Logoff to server with someDomain/someAccount Logoff
Logon to server with someDomain/someAccount Logon
Logoff to server with someDomain/someAccount Logoff
Logon to server with someDomain/myAccount Logon
Logon to server with someDomain/someAccount Logon
Logon to server with someDomain/myAccount Logon
Logon to server with someDomain/someAccount Logon
Logoff to server with someDomain/someAccount Logoff
Logoff to server with someDomain/myAccount Logoff
Logoff to server with someDomain/myAccount Logoff
Logoff to server with someDomain/someAccount Logoff


As you can see for some reason the non-local admin scenario logged off
someDomain/someAccount and someDomain/myAccount. It didn't even tried
accessing the .exe as it just logged off for some reason. Whereas the
local admin had the logon still up, accessed the .exe and logged off.

This is really strange. There is no application error that came up in
the event viewer nor security access.

Sharon
 
Back
Top