Cmd Prompt with "Run As Administrator"

[IJRobson]

I want to run a command from a DOS Prompt in Windows 7 from within WinBatch:
           

Code (winbatch) Select Expand

RunHidewait( Environment("COMSPEC"), '/c %Commands% >"%CommandRes%"')

This works fine for normal commands but some like NETSH reports "The requested operation requires elevation (Run as administrator)."

How do you launch a DOS Prompt  with Run as administrator from WinBatch?

Thanks

[Deana]

Try ShellExecute with "RunAs" verb to launch your application as an Administrator

Code (winbatch) Select Expand

; You must be logged into a admin account for this wot work
ShellExecute(Environment("COMSPEC"), '/k Echo Test', '', @NORMAL, 'RunAs')
Exit

[IJRobson]

Thanks I will try this out.

[IJRobson]

That worked but each time you run the command Windows pops up a dialog box that you have to enter "Yes" to allow the CMD Prompt to run / modify Windows Settings.

Is there any way to suppress this dialog box?

Obviously I can change the Notification Level in Windows 7 but I only really want to do this when I am running the DOS Prompt in Administration Mode from WinBatch.

Thanks

[Deana]

That worked but each time you run the command Windows pops up a dialog box that you have to enter "Yes" to allow the CMD Prompt to run / modify Windows Settings.

Is there any way to suppress this dialog box?

Obviously I can change the Notification Level in Windows 7 but I only really want to do this when I am running the DOS Prompt in Administration Mode from WinBatch.

Thanks

Are you logged into an admin account? If so make sure you runt he script using the manifest setting HighestAvailble or RequireAdmin.

[IJRobson]

Yes, the account is an Admin Account but I had not changed the manifest setting.

I have now changed this to HighestAvailable and will test this new version on Monday.

Thanks

[IJRobson]

I have update my application (App2) to "HighestAvailable" setting so I can launch the CMD Prompt as Administrator without being asked if it is OK by Windows each time.

What I did not mention in my original Post is App2 gets launched by another WinBatch Application (App1).

Now when I Run App1 with the new version of App2 I get an error from this launching Application:

Code (winbatch) Select Expand

WinExec Error:  The requested operation requires elevation. APP1 does not have sufficient elevation to run APP2 Use ShellExecute

If I change APP1 to use ShellExecute should I use the 'RunAs' switch when I call APP2?

Would it be better to also compile APP1 with HighestAvailable setting and if I do that do I need to change anything else when calling APP2?

Thanks

[Deana]

You will need to make sure each application is properly manifested.Setting the level attribute for requestedExecutionLevel to "asInvoker" will make the application run with the token that started it, "highestAvailable" will present a UAC prompt for administrators and run with the usual reduced privileges for standard users, and "requireAdministrator" will require elevation. In both highestAvailable and requireAdministrator modes, failure to provide confirmation results in the program not being launched.

Also, an executable that is marked as "requireAdministrator" in its manifest CANNOT be started from a non-elevated process using Run(). This will trigger the error: The requested operation requires elevation.
As the error states... ShellExecute() must be used instead of Run.

Reference:
http://en.wikipedia.org/wiki/User_Account_Control#Requesting_elevation

[IJRobson]

Am I missing something we have already decided that I can't use AsInvoker I must use either "highestAvailable" or "requireAdministrator" but they both produce a UAC Prompt, so I can't use them?

So what do I have to set the manifest settings for APP1 and APP2 to allow APP2 to have a CMD Prompt "Run As Adminstrator" without a UAC Prompt appearing each time?

APP1 is run from Startup and thus I can't have a UAC Prompt appear here either!

[Deana]

You mentioned the logged in user is an Admin account, is this still correct? If so you should be able to launch an elevated process using ShellExecute if both the script and the process to launch is manifested with requestedElevationLevel "HighestAvailable" and receive no UAC prompt. 

Please read  the 'Manifest' topic in the WIL help file, to help understand how each manifest setting effects the process.

Okay...trying to run an administrative process at "Startup" introduces its own complications. User Account Control (UAC) RESTRICTS apps launched during the Windows startup process or logon process. You can only run processes manifested AsInvoker from startup. Therefore you will not be able to directly launch an elevated process at Start Up. Please see the following MSDN article that explains your options: http://msdn.microsoft.com/en-us/library/bb325654.aspx

[IJRobson]

The current setup is APP1 is running from Startup folder as "AsInvoker".  It was launching APP2 "HighestAvailable" using the Run command but that does not work so I will change this to ShellExecute instead.

The Logon User Account is an Administrator but App1 does not need to be an Administrator so as long as App1 can launch App2 using ShellExecute then I should be fine staying as "AsInvoker".  But the documentation implies both applications need to be "HighestAvailable" for stop the UAC Prompt but you can't run "HighestAvailable" from Startup Folder.

Setting up a Scheduled Task is one workaround described, what if I setup APP1 as a Windows Service instead?  I know this produces problems with User Interfaces and Desktop Access but can a Service be started as "HighestAvailable"?

What I want to do is option B in the MSDN trouble Shooting flowchart which is to have APP1 running from Startup and calling App2 with "HighestAvailable" but I may have to setup APP3 and have APP1 from StartUp launching App2 which in turn launches App3 with "HighestAvailable"?.

I have access to a Windows 7 machine tomorrow so I will try out some variations.

Thanks

[IJRobson]

I am getting nowhere with this.

There appears to be no way to go from "AsInvoker" to "HighestAvailable" without the UAC Prompt appearing?

The MSDN Article implies it is possible using option B but there is not information on how it is done and from a search of the Internet developers just switch off UAC Reporting to get anything else to work?

Any ideas, has anyone ever got this to work?

[Deana]

The current setup is APP1 is running from Startup folder as "AsInvoker".  It was launching APP2 "HighestAvailable" using the Run command but that does not work so I will change this to ShellExecute instead.
The Logon User Account is an Administrator but App1 does not need to be an Administrator so as long as App1 can launch App2 using ShellExecute then I should be fine staying as "AsInvoker".  But the documentation implies both applications need to be "HighestAvailable" for stop the UAC Prompt but you can't run "HighestAvailable" from Startup Folder.

Sorry, You simply cannot launch an elevated app from the Startup Folder in Windows with UAC on.

Setting up a Scheduled Task is one workaround described, what if I setup APP1 as a Windows Service instead?  I know this produces problems with User Interfaces and Desktop Access but can a Service be started as "HighestAvailable"?

What I want to do is option B in the MSDN trouble Shooting flowchart which is to have APP1 running from Startup and calling App2 with "HighestAvailable" but I may have to setup APP3 and have APP1 from StartUp launching App2 which in turn launches App3 with "HighestAvailable"?.

I have access to a Windows 7 machine tomorrow so I will try out some variations.

Here is my understanding of the situation: Some applications must have both standard user and administrative privileges to function. These applications are often called "mixed-mode" applications since they include both standard user mode and administrator mode functionality. Here are some possible ways to deal with the situation:

Option 1 (unprompted)
Use the Task Scheduler to run your Elevated script as the Local System account in service mode rather than as interactive tasks in the user's session, then the scripts will have admin rights locally but won't have any identity on the network except for that of the computer on which the script is running. Here is a UAC-friendly method to have your WinBatch script Run As Administrator.  http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/UAC+Run~As~Admin~WinBatch~Script~With~UAC~On.txt

Option 2 (unprompted)
App1 (AsInvoker ) can be run at startup and can handle standard user operations, and App2 can be a Windows Service (no user interface)
If necessary, the service can communicate with the standard user application.

Option 3 (prompted)[/
App1 (AsInvoker ) can be run at startup and handle standard operations, then it can place itself in the task bar (IntControl 1007) waiting for a user to click, once the icon is clicked it could ShellExecute the elevated App2(HighestAvailable). However you will be prompted for elevation.

[IJRobson]

Thanks for clarification.

What I want to implement is exactly what the MSDN Option B is describing. 

A Mixed_mode application with a User interface in Standard User mode (App1) and then in Administrator Mode (App2) for the installation and Windows configuration stages.

Because the Standard User mode is likely to be run from the Startup Folder that causes the problem.

Both Option 1 and 2 will allow App2 to run but then there is no point in App1 launching App2, App 2 may as well be launched separately and then pass data between the App2 and App1 as required.  These require extra code to install and configure the Task or Service and makes updating an issue and Debugging harder so are really not an option.

Option 3 is really what Option B is describing but as my tests show and you reported I am Prompted for Elevation.  My system is working now using this method, and without using IntControl 1007, but I always get the Prompt when starting App2.

The MSDN Example does not mention anything about being prompted and you would expect an application of Mixed Mode to be able to switch between the two modes without being Prompted but it looks like it is not possible?

I will investigate a bit further to see if a can find another method of switching modes by Launching App2 but if that does not get me anywhere then I will scrap the whole idea.

Let me know if anyone has any other ideas and I will update the Post if I find anything else.

Thanks.

[Deana]

If you do not want a UAC prompt...Forget about launching app2(elevated) from app1(unelevated).

You will need two totally separate processes.

For the unelevated process:
(AsInvoker) process can launch at start up.

For the elevated process:
I recommend using the Task Scheduler to run your Elevated script as the Local System account. Here is a UAC-friendly method to have your WinBatch script Run As Administrator.  http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/UAC+Run~As~Admin~WinBatch~Script~With~UAC~On.txt

NOTE: Starting with Windows Vista, processes running under the System account cannot interact with the desktop. This is a pain for scripts, but it was a necessary security improvement to Windows.

If you ABSOLUTELY need the two scripts to communicate:
Your scripts will need to be designed to pass messages between the two programs, which can be challenging to do reliably and efficiently (i.e. not waste too many CPU cycles). Named Pipes is one possible method. For more on named pipes see: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+Tutorials+Named~Pipes.txt

[IJRobson]

The Problem is because the System is used to install Updates I wanted App1 to handle the User Interface and monitor for Updates.  When new ones are found, reported to the User and they Select install it runs App2 to Install these Updates.

Splitting the system in this way is the easiest method to support Updates to App1 and App2.

If you don't split the two then it is very difficult for the Application to update itself without Reboots or delayed Writes.

Also as App1 can be run by the User or from Startup, the User Interface the related Update Logic really needs to control when App2 is Launched and what App2 does when it is running.  As it is the Administrator related parts of App2 are small and only sometimes used depending on the Contents of the Update passed by App1 so removing them is easier.

This also ties in with the FTP Firewall Issue that I raised in another Post on the Forum.

To be honest I prefer Windows Services over Scheduled Tasks but in both cases updating these is more difficult then replacing an EXE as used by App1 / App2.

[IJRobson]

OK, I have scrapped this System, I can't do what I need so I have kept the Run As Administrator Code but I just post a Message just before I run it to tell the Operator to Accept the UAC Prompt.

Sadly you can't control Windows to auto-accept the Prompt so I have to rely on the Operator.

Not Ideal but it is the best solution possible with UAC ON.