Batch scripting, Powershell, and not triggering the UAC in Windows_问答_开发者

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 ar开发者_如何转开发e 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:

Disable the UAC altogether - We normally do this, but we might be running into some situations where we cannot disable it.
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

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)

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.

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.