Running System Exec vi as Administrator in Win7

[BobbyCee]

Has anyone been able to run the 'System Exec.vi' as Administrator using Win7?

I have a service that I need to start and stop and can do so with the following cmd line: cs start mxchange OR cs stop mxchange

The catch is, in Win7 I need to be running CMD as Adminstrator

Any suggestions?

[BobbyCee]

Looks like I found the solution to my problem.

After changing the User Account Control settings to 'Never Notify' and rebooting, I was able to run System_Exec.vi with my Start / Stop service commands successfully.

[crelf]

Looks like I found the solution to my problem.

Hey Bob - would you mind adding that info to the LabVIEWiki ?

[BobbyCee]

OK, Wiki sounds like a good idea.

I am also experimenting with a .NET assembly to perform the same task as the System_Exec.vi. I think I may be able to write .NET code that will allow Win7 application control to maintain higher User Level Security and still Start and Stop my desired local service.

[Rolf Kalbermatter]

OK, Wiki sounds like a good idea.

I am also experimenting with a .NET assembly to perform the same task as the System_Exec.vi. I think I may be able to write .NET code that will allow Win7 application control to maintain higher User Level Security and still Start and Stop my desired local service.

I believe that in order to start and stop a service you need to have administration privileges in Windows 2000 higher. Windows Vista and higher might even require specifically elevated privileges that an administrator account doesn't automatically grant to an executable, but requires an additional explicit User Authentification as administrator.

It would be strange that CMD.EXE itself is requiring elevated privileges but it is the service manager start and stop command you try to execute in CMD.EXE that is barking on the to low privileges you have as normal user. .Net can't circumvent the privilege level control for the service control manager but it might have extra support to allow temporary privilege elevation for the current executable for execution of service control manager commands which would require at least the according admin login credentials somehow (and if they care about security it won't be a programmatic login but an interactive login).

[BobbyCee]

I believe that in order to start and stop a service you need to have administration privileges in Windows 2000 higher. Windows Vista and higher might even require specifically elevated privileges that an administrator account doesn't automatically grant to an executable, but requires an additional explicit User Authentification as administrator.

It would be strange that CMD.EXE itself is requiring elevated privileges but it is the service manager start and stop command you try to execute in CMD.EXE that is barking on the to low privileges you have as normal user. .Net can't circumvent the privilege level control for the service control manager but it might have extra support to allow temporary privilege elevation for the current executable for execution of service control manager commands which would require at least the according admin login credentials somehow (and if they care about security it won't be a programmatic login but an interactive login).

You are correct, higher administrative privileges are needed to control services. I have found that the .NET architecture is more flexible than simply using System_Exec.vi with string commands and therefore I will be pursuing the .NET method to handle querying, starting, and stopping my local services. However, I will have to talk with the system owner regarding the removing the User Access Control level that prevents interaction at the service level. I am fortunate to have a number of in-house resources to offer expert advice on .NET coding and will share my findings with the LAVA community.

[Shaun Hayward]

OK... I got intrigued by this whilst waiting for an installer test to finish running and came up with a little something that works:

Hope this helps,

Shaun

[BobbyCee]

OK... I got intrigued by this whilst waiting for an installer test to finish running and came up with a little something that works:

Hope this helps,

Shaun

Thanks for the code snipet, Shaun. I did try out your method and had a User Account Control popup appear. I did some futher MSDN reading and it looks like via impersonation I may be able to run my administrator account elevated so as to not need to acknowledge the UAC popup. This system will be used without a monitor and will not have user interaction. I need to keep standard permissions on the box because the system will be on a network and I want to limit people running scripts that could affect system operation.

I will post this code as soon as I get it tested successfully. Thanks again for showing me another way to access Process Start Info processes!

[Rob Calhoun]

Thanks for the code snipet, Shaun. I did try out your method and had a User Account Control popup appear. I did some futher MSDN reading and it looks like via impersonation I may be able to run my administrator account elevated so as to not need to acknowledge the UAC popup. This system will be used without a monitor and will not have user interaction. I need to keep standard permissions on the box because the system will be on a network and I want to limit people running scripts that could affect system operation.

I will post this code as soon as I get it tested successfully. Thanks again for showing me another way to access Process Start Info processes!

The UAC in Vista and later is designed to prevent even administrator accounts from doing "dangerous" things without user confirmation. Running as Administrator alone is not sufficient to avoid the prompt as Microsoft has tried very hard to ensure that the prompts cannot be worked around. (This is so that virus authors can't go that route.)

The "right" way to handle this is to ship a manifest that tells Windows that an application needs elevation. It will ask for it on launch. If there is no manifest, Windows tries to figure out which applications require elevation (for example, an installer named "setup.exe") and request elevation from the user on launch. It is very frequently wrong and this results in cascade of errors later on.

I agree with you that disabling UAC entirely on a machine is the wrong approach. I'm no fan of UAC, but it is the world Microsoft wants us to live in. None of them really get rid of the UAC prompt, they just get the user's permission at some more convenient point in the launch process. (I realize not all of these apply to your situation:)

1. Number one recommendation: avoid tasks that Microsoft considers "dangerous". Sometimes elevation is unavoidable but other times it is the result of using deprecated Windows programming techniques like writing a config file to the %ProgramFiles% directory. In these cases I recommend capitulation to the Borg; if Microsoft wants you to write to %AllUserProfile% instead of %ProgramFiles%, just give in and change it. I recommend testing the application in a regular (non-Administrative) user to see where the problems are.
   
2. If you just want to do a simple SysExec call and you don't mind getting the prompt (i.e. it needs to work, but it doesn't need to work unattended), you can use John Robbins' elevate.exe to run the command (sc start or whatever) with elevation. We use elevate.exe in our installer batch file; the user clicks through one UAC prompt which elevates the batch file that runs multiple installers. (Johannes Passing wrote a version of elevate.exe in regular C; I haven't tried it.)
   
3. Run your application as a service. Microsoft believes that applications that run unattended should be services. A service running in a privileged account (i.e. LocalSystem) can perform tasks that require elevation without any dialog boxes. The thought here is that since UAC elevation is required to install the service no further prompts are needed. This is how our production application runs. We use FireDaemon to do this and it is quite easy to convert your LV app to a service this way. (There is also the free "srvany.exe" application from Microsoft floating around.) There are other advantages to running as a service, such as automatic restarts when the application quits or crashes. There is, unfortunately, a winkle running an app as a service under Windows 7: starting with Vista, Microsoft no longer allows services to have user interfaces. (This is another security "feature".) Thus to go this route you will have split the functional part of your application from your UI. It's quite doable (especially if you use the VI Server) but if your application has a lot of UI this might be an untenable amount of work. I suppose you could go the other way and have a lightweight helper service that performs just a few tasks that require elevation under the command of your main app. That would be pretty easy.
   
4. Have your application request elevation on startup. This is the method Microsoft wants you to take. (Well, not really: they want you to have buttons all over the place with little shield logos that only request elevation on the specific tasks that really require elevation.) You can request elevation by embedding a manifest in the application. This is supported by the LV Application Builder, although documentation is extremely sparse. See this PowerPoint presentation on how to construct the manifest.
   
5. While you are at it, digitally signing the application will avoid another bunch of UAC warnings on installation and launch. You can use self-signed certificate or a "real" certificate backed up by Verisign etc. "Real" certificates cost money but provide traceability. Signing your code shows that your application hasn't been modified since your released it.
   

While we are talking Windows 7, keep in mind that the Program Files directory is now called Program Files (x86) when 32-bit LV is running on a 64-bit versions of windows. So make sure to clean out those hard-coded paths!

-Rob