Add requires statement for UAC elevation - by TobiasW

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 455938 Comments
Status Closed Workarounds
Type Suggestion Repros 4
Opened 5/21/2009 10:24:03 PM
Duplicates 639008 Access Restriction Public


I’d like to see some sort of requires-statement for scripts that mark script as “admin privs required” so when the script is launched w/o admin privs, you would get a UAC elevation prompt and run it in an elevated console. 

Only then would scripts be equal citizens compared to compiled software.

Today, there are scripts containing commands that need elevation to run correctly. There is no way to mark those scripts as "requiring admin rights". The concept found in compiled apps should be extended to powershell scripts to make them useful for admins in all scenarios. A "marked as elevation" script should elevate itself automatically just like tools like diskpart do.
Sign in to post a comment.
Posted by Microsoft on 5/1/2014 at 7:49 PM
In PowerShell 4.0, we added #requires support for running as admin. For scripts that require elevation to run, add this to the top of the script:

#requires -RunAsAdministrator
Posted by Bernd Eckenfels on 6/5/2012 at 7:05 PM
I am not so much care about the declarative approach, it would be enough to have some commandlets to check and request elevation, or to pass it around (as a -Credential which is actually supported by Providers?)

BTW: Why does Get-WMIObject have a -EnableAllPrivilegs when it does not do what one would expect...
Posted by Richard.Siddaway on 12/6/2011 at 10:59 AM
I would much prefer to make a conscious decison myself as to whether I am runing an elevated prompt.
Posted by Joel 'Jaykul' Bennett on 12/3/2011 at 9:02 PM
You *can* resend the parameters to the elevated shell.
Posted by antize on 10/21/2011 at 9:26 PM
Please add direct support for UAC elevation! Currently the only way to do this is below. It doesn't work if the script being elevated requires parameters (because they can't be resent to the elevated shell)!

$currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())

if (-not $currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) {
# Re-launch with full privileges...
Start-Process powershell.exe -Verb RunAs -ArgumentList ('-noprofile -noexit -file "{0}"' -f ($myinvocation.MyCommand.Definition))
Posted by ewwallace on 8/8/2011 at 7:51 AM
This would be an excellent addition.
Posted by Oisín Grehan on 4/11/2011 at 7:15 AM
As discussed, there's reasonable support behind implementing this like:

#requires -role "administrators"

This string would map to the current principal's roles, a la Principal.IsInRole(...)