4

I am looking for away to run batch files in elevated mode (runas administrator) so that it doesn't trip the UAC to prompt for user interaction. We have some registry edits, among other things, that we do in our login scripts which trigger the UAC to prompt for each registry that is run.

I realize that this sort of defeats the purpose of the UAC, but it would be nice if there was some way of running batch files on machines that have UAC enabled.

These batch files need to be able to run without any user interaction (they are mainly login scripts, and some administrative scripts). We are not using an Active Directory domain, so hopefully there is a solution for none AD domains.

The solutions that I have found so far are as follows:

  1. Disable the UAC altogether - We normally do this, but we might be running into some situations where we cannot disable it.

  2. Create a shortcut to the batch file we wish to run in elevated mode. Go to the properties of the shortcut > Shortcut tab > Advaned > Check off "Run as Administrator"

    • This solution seems to work, however the initial running of the shortcut causes the UAC prompt to come up. All the commands run within the batch file do not cause the UAC prompt. Close to the solution, but it would be nice not to get any prompts.

3. Running the batch file with the 'runas' command.

  • I have tried this, however it still doesn't see to achieve the elevation to prevent the UAC from prompting.
  • Also, using the echo 'password' | runas ..... method to provide the password doesn't seem to work right, so I am always having to type in the password.

The other thing that I was thinking, but I haven't really researched yet is, do powershell scripts run/work better in an environment where the UAC is enabled? Does Windows 'trust' certified powershell scripts and allow them to run unimpeded without triggering the UAC?

From what I have read, these is no way around the UAC other then disabling it. But I just wanted to see if anyone might be able to shed some additional light on this topic.

Thank you,

Cheers

bourne
  • 259
  • 1
  • 5
  • 13

3 Answers3

6

There is no official way to by-pass the UAC prompt for your application. There are a few ways to run a program as administrator if you have the account password (same as the runas approach).

you can use the following Power-Shell script to start your program as administrator without asking the password:

You'll need to save the user password somewhere as a secure string:

$pass = Read-Host -AsSecureString
ConvertFrom-SecureString $pass | out-file pass.txt

Then you can run the file as administrator with the stored password this way:

$pass = import-SecureString (get-content pass.txt)
$startinfo = new-object System.Diagnostics.ProcessStartInfo
$startinfo.UserName = "administrator"
$startinfo.Password = $pass
$startinfo.FileName = "your batch script file name"
$startinfo.UseShellExecute = $true
[System.Diagnostics.Process]::Start($startinfo)
fardjad
  • 20,031
  • 6
  • 53
  • 68
  • Thank you for your response. This is an interesting approach that I will have to play with a bit as well. – bourne May 30 '11 at 13:55
  • @bourne does the above approach work for you? to avoid the UAC prompt? – Princa Jun 15 '16 at 14:59
  • @Princa... As I recall, it didn't. At this time we were "misusing" batch scripts of you will. We later purchased a piece of software to handle much of our software deployment. After that, we purchased a piece of software that does automatic elevation called Viewfinity. I've recently looked into this sort of thing again and found that you can play with scheduled tasks to do elevation. I believe autoit can also be used to wrap an admin password around a specific process. – bourne Jun 15 '16 at 15:23
  • What about unofficial ways? – DeerSpotter Nov 20 '17 at 20:57
4

Registry manipulation for which the current user has access will not itself trigger a UAC prompt.

However using an application with a manifest that requires elevation if running as un-elevated administrator will prompt.

Are you trying to use regedit.exe to perform batch operation? If so replace with reg.exe (using cmd.exe) or, better, PowerShell's inbuilt registry support.

Eg.

get-itemproperties 'HKLM:\SOFTWARE\Classes\Folder'

will not require elevation (as that key is readable by everyone), but setting a property on that key will require an elevated PSH session.

An alternative approach, if you are performing operations that require administrative access (need modify access to some object with ACL that limits modification to administrators). Or, something a non-administrator could never do UAC or not, without enter an administrator's account's credentials.

Consider using Task Scheduler: a trigger of on user logon but configured under a specific elevated administrator account.

Summary: really need to know at least one of the things you are doing that triggers UAC in detail.

Richard
  • 106,783
  • 21
  • 203
  • 265
  • @bourne: Another route to consider would be Group Policy. (Summary: I can't imaging what keys requiring elevation one would need to update at *every* logon.) – Richard May 30 '11 at 13:47
  • Sorry for the lack of additional information, I never thought to include the operations we are attempting to do. In most cases, we are manipulating registry keys, doing actual edits on certain keys. Also, we do some copying of additional .exe into C:\Windows\ and C:\Windows\System32. I believe that it is these two processes that trigger the UAC to trip. I should also mention that users have administrative access on their PC's. The task scheduler is an interesting idea. I will have to do some testing with this. – bourne May 30 '11 at 13:51
  • @Richard: You are right, the keys don't need to be set at each login. Truthfully we haven't built the logic into our scripting yet to confirm whether or not the keys are set correctly. They are simple set at each login regardless. Currently we are doing very very little with Group Policy as we are restricted to using local group policies (we are not an AD domain). I could look into pushing a local group policy which contains the registry edits though. – bourne May 30 '11 at 13:54
  • @Richard I just tried your suggestion of running the scripts via the task scheduler and it seemed to work amazingly well! UAC on, scripts ran but didn't trigger the UAC. I will have to see if this will meet our needs. – bourne May 30 '11 at 14:36
  • its still chicken-n-egg though, since adding the scheduled task requires entering credentials for administrator level. – djangofan May 30 '11 at 18:35
  • @djangofan: True, but that is only done when the task is created (or modified). Whereas a logon script needs credentials on every logon. – Richard May 31 '11 at 06:49
  • I found this out the hard way! Creating the scheduled task GUI is easy and works great. Importing it though command-line fails because of the UAC it looks like http://social.technet.microsoft.com/Forums/en/winserverManagement/thread/454b0e9e-1ef1-4026-a8e3-91766f049f91 – bourne May 31 '11 at 12:57
  • It looks like after discussing it with the team, we are going to go ahead and choose to disable the UAC on all machines regardless. Will have to tighten up security, but it looks like this is the best solution for our current setup. Thank you to everyone that responded!! – bourne May 31 '11 at 12:59
  • I apologize if I wasted anyone's time! – bourne May 31 '11 at 13:06
  • It is a bad idea to disable UAC just so logon scripts work. This is strong evidence of a flawed design and is exactly the thing that UAC is designed to identify. I recommend fixing the design. This is like disabling the "check engine" light in your car because you're tired of looking at it. (It's there to tell you there's a problem!) – Bill_Stewart May 13 '14 at 21:34
1

Setting up a scheduled task that will run elevated needs one consent once when you set it up, and never again. Since you mention these are login scripts, a scheduled task that runs on login should meet your need perfectly.

Kate Gregory
  • 18,808
  • 8
  • 56
  • 85