Batch script, Powershell, not starting UAC on Windows

Question

I am looking to run batch files in elevated mode (runas administrator) so that it does not disable UAC in order to request user interaction. We have some registry changes, among other things, what we do in our login scripts that run UAC to query each startup registry.

I understand that this view defeats the goal of UAC, but it would be nice if there was some way to run batch files on machines with UAC enabled.

These batch files should be able to run without any user interaction (mainly login scripts and some administrative scripts). We do not use an Active Directory domain, so I hope there is a solution for all AD domains.

The solutions I have found so far are as follows:

• Disable UAC altogether - we usually do this, but we may encounter some situations where we cannot disable it.

• Create a shortcut for the batch file that we want to run in elevated mode. Go to shortcut properties> Shortcut tab> Advaned> Run as Administrator

  • This solution works, however the initial launch of the shortcut prompts the UAC prompt. All commands running in a batch file do not invoke a UAC prompt. Close to a solution, but it would be nice to get any hints.

3. Run the batch file with the "runas" command.

• I tried this, however it still does not see to reach the mark in order to prevent the UAC request.
• Also using echo 'password' | runas ..... the password method does not seem to work correctly, so I always need to enter a password.

Another thing I was thinking about but not yet explored is, do powershell scripts really work / work better in an environment where UAC is enabled? Does Windows check "certified powershell scripts" and allow them to run smoothly without starting UAC? A.

From what I read, it has nothing to do with another UAC, and then disables it. But I just wanted to see if anyone could shed some extra light on this topic.

Thanks,

Greetings

Answer 1

Manipulating the registry for which the current user has access will not itself invoke the UAC prompt.

However, when using an application with a manifest requiring elevation, if it is running as an administrator with a failed request.

Are you trying to use regedit.exe to perform a batch operation? If so, replace reg.exe (using cmd.exe ) or, better, built-in PowerShell registry support.

Eg.

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

It will not require elevation (since this key is read by everyone), but an elevated PSH session will be required to set the property on this key.

---

An alternative approach if you perform operations that require administrative access (you need to modify access to some object with an ACL that restricts the modification to administrators). Or, something a non-administrator could never do UAC or not, without entering the credentials of an administrator account.

Consider using the task scheduler: a trigger for a user to log in, but configured under a specific administrator account.

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

Answer 2

There is no official way around the UAC prompt for your application. There are several ways to run the program as administrator , if you have an account password (the same as for runas mode).

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

You 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 password saved as follows:

 $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) 

Answer 3

Setting up a scheduled task that will be performed at a higher level requires one consent once when setting it up and never again. Since you mention that these are login scenarios, the scheduled task that you perform at login should best meet your needs.