script run right elevate and powershell administrator

right - run as powershell



PowerShell: Ejecutando un comando como administrador (24)

Auto guión PowerShell

Windows 8.1 / PowerShell 4.0 +

Una línea :)

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit } # Your script here

¿Sabes cómo si eres el usuario administrativo de un sistema y puedes hacer clic con el botón derecho del mouse, por ejemplo, un script por lotes y ejecutarlo como Administrador sin ingresar la contraseña del administrador?

Me pregunto cómo hacer esto con un script de PowerShell. No quiero tener que ingresar mi contraseña; Solo quiero imitar el método de Ejecutar como administrador con un clic derecho.

Todo lo que leo hasta ahora requiere que proporcione la contraseña de administrador.


Añadiendo mis 2 centavos. Mi versión simple basada en la sesión de red que funciona todo el tiempo hasta ahora en Windows 7 / Windows 10. ¿Por qué complicarlo más?

if (!(net session)) {$path = "& ''" + $myinvocation.mycommand.definition + "''" ; Start-Process powershell -Verb runAs -ArgumentList $path ; exit}

simplemente agréguelo a la parte superior del script y se ejecutará como administrador.


Algunas de las respuestas aquí están cerca, pero un poco más de trabajo del necesario.

Cree un acceso directo a su script y configúrelo para "Ejecutar como administrador":

  • Crear el acceso directo.
  • Haga clic derecho en el acceso directo y abra Properties...
  • Editar Target de <script-path> a powershell <script-path>
  • Haga clic en Avanzado ... y habilite Run as administrator

Aquí hay una adición a la sugerencia de Shay Levi (solo agregue estas líneas al comienzo de un script):

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { $arguments = "& ''" + $myinvocation.mycommand.definition + "''" Start-Process powershell -Verb runAs -ArgumentList $arguments Break }

Esto hace que el script actual se pase a un nuevo proceso de powershell en modo Administrador (si el Usuario actual tiene acceso al modo Administrador y el script no se inicia como Administrador).


Benjamin Armstrong publicó un excelente artículo sobre los guiones de PowerShell que se elevan a sí mismos . Hay algunos problemas menores con su código; a continuación se muestra una versión modificada basada en las correcciones sugeridas en el comentario.

Básicamente, obtiene la identidad asociada con el proceso actual, verifica si es un administrador y, si no lo es, crea un nuevo proceso de PowerShell con privilegios de administrador y finaliza el proceso anterior.

# Get the ID and security principal of the current user account $myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent(); $myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID); # Get the security principal for the administrator role $adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator; # Check to see if we are currently running as an administrator if ($myWindowsPrincipal.IsInRole($adminRole)) { # We are running as an administrator, so change the title and background colour to indicate this $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"; $Host.UI.RawUI.BackgroundColor = "DarkBlue"; Clear-Host; } else { # We are not running as an administrator, so relaunch as administrator # Create a new process object that starts PowerShell $newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell"; # Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it''s path $newProcess.Arguments = "& ''" + $script:MyInvocation.MyCommand.Path + "''" # Indicate that the process should be elevated $newProcess.Verb = "runas"; # Start the new process [System.Diagnostics.Process]::Start($newProcess); # Exit from the current, unelevated, process Exit; } # Run your code that needs to be elevated here... Write-Host -NoNewLine "Press any key to continue..."; $null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown");


Debe volver a ejecutar la secuencia de comandos con privilegios administrativos y verificar si la secuencia de comandos se inició en ese modo. A continuación, he escrito un script que tiene dos funciones: DoElevatedOperations y DoStandardOperations . Debe colocar su código que requiere derechos de administrador en la primera y las operaciones estándar en la segunda. La variable IsRunAsAdmin se utiliza para identificar el modo de administración.

Mi código es un extracto simplificado del script de Microsoft que se genera automáticamente al crear un paquete de aplicaciones para las aplicaciones de la Tienda Windows.

param( [switch]$IsRunAsAdmin = $false ) # Get our script path $ScriptPath = (Get-Variable MyInvocation).Value.MyCommand.Path # # Launches an elevated process running the current script to perform tasks # that require administrative privileges. This function waits until the # elevated process terminates. # function LaunchElevated { # Set up command line arguments to the elevated process $RelaunchArgs = ''-ExecutionPolicy Unrestricted -file "'' + $ScriptPath + ''" -IsRunAsAdmin'' # Launch the process and wait for it to finish try { $AdminProcess = Start-Process "$PsHome/PowerShell.exe" -Verb RunAs -ArgumentList $RelaunchArgs -PassThru } catch { $Error[0] # Dump details about the last error exit 1 } # Wait until the elevated process terminates while (!($AdminProcess.HasExited)) { Start-Sleep -Seconds 2 } } function DoElevatedOperations { Write-Host "Do elevated operations" } function DoStandardOperations { Write-Host "Do standard operations" LaunchElevated } # # Main script entry point # if ($IsRunAsAdmin) { DoElevatedOperations } else { DoStandardOperations }


El código publicado por Jonathan y Shay Levy no funcionó para mí.

Por favor encuentre el código de trabajo a continuación:

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { #"No Administrative rights, it will display a popup window asking user for Admin rights" $arguments = "& ''" + $myinvocation.mycommand.definition + "''" Start-Process "$psHome/powershell.exe" -Verb runAs -ArgumentList $arguments break } #"After user clicked Yes on the popup, your file will be reopened with Admin rights" #"Put your code here"


El problema con las @pgk y @Andrew Odri es cuando tiene parámetros de script, especialmente cuando son obligatorios. Puedes resolver este problema usando el siguiente enfoque:

  1. El usuario hace clic con el botón derecho en el archivo .ps1 y selecciona "Ejecutar con PowerShell": pregúntele por los parámetros a través de los cuadros de entrada (esta es una opción mucho mejor que usar el atributo del parámetro HelpMessage );
  2. El usuario ejecuta el script a través de la consola: le permite pasar los parámetros deseados y deja que la consola lo obligue a informar los obligatorios.

Aquí está cómo sería el código si el script tuviera los parámetros obligatorios ComputerName y Port :

[CmdletBinding(DefaultParametersetName=''RunWithPowerShellContextMenu'')] param ( [parameter(ParameterSetName=''CallFromCommandLine'')] [switch] $CallFromCommandLine, [parameter(Mandatory=$false, ParameterSetName=''RunWithPowerShellContextMenu'')] [parameter(Mandatory=$true, ParameterSetName=''CallFromCommandLine'')] [string] $ComputerName, [parameter(Mandatory=$false, ParameterSetName=''RunWithPowerShellContextMenu'')] [parameter(Mandatory=$true, ParameterSetName=''CallFromCommandLine'')] [UInt16] $Port ) function Assert-AdministrativePrivileges([bool] $CalledFromRunWithPowerShellMenu) { $isAdministrator = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) if ($isAdministrator) { if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine) { # Must call itself asking for obligatory parameters & "$PSCommandPath" @script:PSBoundParameters -CallFromCommandLine Exit } } else { if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine) { $serializedParams = [Management.Automation.PSSerializer]::Serialize($script:PSBoundParameters) $scriptStr = @" `$serializedParams = ''$($serializedParams -replace "''", "''''")'' `$params = [Management.Automation.PSSerializer]::Deserialize(`$serializedParams) & "$PSCommandPath" @params -CallFromCommandLine "@ $scriptBytes = [System.Text.Encoding]::Unicode.GetBytes($scriptStr) $encodedCommand = [Convert]::ToBase64String($scriptBytes) # If this script is called from another one, the execution flow must wait for this script to finish. Start-Process -FilePath ''powershell'' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -EncodedCommand $encodedCommand" -Verb ''RunAs'' -Wait } else { # When you use the "Run with PowerShell" feature, the Windows PowerShell console window appears only briefly. # The NoExit option makes the window stay visible, so the user can see the script result. Start-Process -FilePath ''powershell'' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -NoExit -File ""$PSCommandPath""" -Verb ''RunAs'' } Exit } } function Get-UserParameters() { [string] $script:ComputerName = [Microsoft.VisualBasic.Interaction]::InputBox(''Enter a computer name:'', ''Testing Network Connection'') if ($script:ComputerName -eq '''') { throw ''The computer name is required.'' } [string] $inputPort = [Microsoft.VisualBasic.Interaction]::InputBox(''Enter a TCP port:'', ''Testing Network Connection'') if ($inputPort -ne '''') { if (-not [UInt16]::TryParse($inputPort, [ref]$script:Port)) { throw "The value ''$inputPort'' is invalid for a port number." } } else { throw ''The TCP port is required.'' } } # $MyInvocation.Line is empty in the second script execution, when a new powershell session # is started for this script via Start-Process with the -File option. $calledFromRunWithPowerShellMenu = $MyInvocation.Line -eq '''' -or $MyInvocation.Line.StartsWith(''if((Get-ExecutionPolicy'') Assert-AdministrativePrivileges $calledFromRunWithPowerShellMenu # Necessary for InputBox [System.Reflection.Assembly]::Load(''Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'') | Out-Null if ($calledFromRunWithPowerShellMenu) { Get-UserParameters } # ... script code Test-NetConnection -ComputerName $ComputerName -Port $Port


En la parte superior de la respuesta de Shay Levy, siga la configuración a continuación (solo una vez)

  1. Iniciar un PowerShell con derechos de administrador.
  2. Siga la pregunta de Desbordamiento de pila PowerShell dice "la ejecución de scripts está deshabilitada en este sistema" .
  3. Coloque su archivo .ps1 en cualquiera de las carpetas PATH , por ejemplo. Carpeta Windows / System32

Después de la configuración:

  1. Presione Win + R
  2. Invoque el powershell Start-Process powershell -Verb runAs <ps1_file>

Ahora puede ejecutar todo en una sola línea de comando. Lo anterior funciona en Windows 8 Basic de 64 bits.


Esta es una aclaración ...

La credencial powershell RUNAS / SAVECRED "no es segura", la probó y agrega la identidad y la contraseña de administrador a la caché de credenciales y se puede usar en otros lugares ¡OOPS! Si ha hecho esto, le sugiero que verifique y elimine la entrada.

Revise su programa o código porque la política de Microsoft es que no puede tener un código de usuario y administrador mixto en el mismo blob de código sin el UAC (el punto de entrada) para ejecutar el programa como administrador. Esto sería sudo (lo mismo) en Linux.

El UAC tiene 3 tipos, no ver, un aviso o un punto de entrada generado en el manifiesto del programa. No eleva el programa, por lo que si no hay un UAC y necesita administración, fallará. El UAC, aunque como requisito de administrador es bueno, evita la ejecución de código sin autenticación y evita que el escenario de códigos mixtos se ejecute a nivel de usuario.


Este comportamiento es por diseño. Hay varias capas de seguridad, ya que Microsoft realmente no quería que los archivos .ps1 fueran el último virus de correo electrónico. Algunas personas consideran que esto es contrario a la noción misma de automatización de tareas, lo cual es justo. El modelo de seguridad de Vista + es "des-automatizar" las cosas, lo que hace que el usuario las apruebe.

Sin embargo, sospecho que si inicia el propio powershell como elevado, debería poder ejecutar archivos por lotes sin volver a solicitar la contraseña hasta que cierre el powershell.


Estoy usando la solución de abajo. Maneja stdout / stderr a través de la función de transcripción y pasa el código de salida correctamente al proceso principal. Es necesario ajustar la ruta de transcripción / nombre de archivo.

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { echo "* Respawning PowerShell child process with elevated privileges" $pinfo = New-Object System.Diagnostics.ProcessStartInfo $pinfo.FileName = "powershell" $pinfo.Arguments = "& ''" + $myinvocation.mycommand.definition + "''" $pinfo.Verb = "RunAs" $pinfo.RedirectStandardError = $false $pinfo.RedirectStandardOutput = $false $pinfo.UseShellExecute = $true $p = New-Object System.Diagnostics.Process $p.StartInfo = $pinfo $p.Start() | Out-Null $p.WaitForExit() echo "* Child process finished" type "C:/jenkins/transcript.txt" Remove-Item "C:/jenkins/transcript.txt" Exit $p.ExitCode } Else { echo "Child process starting with admin privileges" Start-Transcript -Path "C:/jenkins/transcript.txt" } # Rest of your script goes here, it will be executed with elevated privileges


He encontrado una manera de hacer esto ...

Crea un archivo por lotes para abrir tu script:

@echo off START "" "C:/Scripts/ScriptName.ps1"

Luego cree un acceso directo, en su escritorio diga (haga clic derecho en Nuevo -> Acceso directo ).

Luego pegue esto en la ubicación:

C:/Windows/System32/runas.exe /savecred /user:*DOMAIN*/*ADMIN USERNAME* C:/Scripts/BatchFileName.bat

Al abrir por primera vez, deberá ingresar su contraseña una vez. Esto lo guardará en el administrador de credenciales de Windows.

Después de esto, debería poder ejecutarse como administrador sin tener que ingresar un nombre de usuario o contraseña de administrador.


La forma más confiable que he encontrado es envolverla en un archivo .bat autoelevante:

@echo off NET SESSION 1>NUL 2>NUL IF %ERRORLEVEL% EQU 0 GOTO ADMINTASKS CD %~dp0 MSHTA "javascript: var shell = new ActiveXObject(''shell.application''); shell.ShellExecute(''%~nx0'', '''', '''', ''runas'', 0); close();" EXIT :ADMINTASKS powershell -file "c:/users/joecoder/scripts/admin_tasks.ps1" EXIT

El .bat comprueba si ya eres administrador y reinicia el script como administrador si es necesario. También evita que se abran ventanas "cmd" extrañas con el 4to parámetro de ShellExecute() configurado a 0 .


No he visto mi propia forma de hacerlo antes, así que prueba esto. Es mucho más fácil de seguir y tiene una huella mucho más pequeña:

if([bool]([Security.Principal.WindowsIdentity]::GetCurrent()).Groups -notcontains "S-1-5-32-544") { Start Powershell -ArgumentList "& ''$MyInvocation.MyCommand.Path''" -Verb runas }

Muy simple, si se llamó a la sesión actual de Powershell con privilegios de administrador, el SID conocido del Grupo de administradores se mostrará en los Grupos cuando tome la identidad actual. Incluso si la cuenta es miembro de ese grupo, el SID no se mostrará a menos que el proceso se haya invocado con credenciales elevadas.

Casi todas estas respuestas son una variación del método inmensamente popular de Microsoft de Ben Armstrong de cómo lograrlo sin realmente comprender qué es lo que realmente está haciendo y cómo emular la misma rutina.


Otra solución más sencilla es que también puede hacer clic con el botón derecho en "C: / Windows / System32 / cmd.exe" y elegir "Ejecutar como administrador", luego puede ejecutar cualquier aplicación como administrador sin proporcionar ninguna contraseña.


Para adjuntar la salida del comando a un nombre de archivo de texto que incluye la fecha actual, puede hacer algo como esto:

$winupdfile = ''Windows-Update-'' + $(get-date -f MM-dd-yyyy) + ''.txt'' if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE/$winupdfile -Append`"" -Verb RunAs; exit } else { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE/$winupdfile -Append`""; exit }


Puede agregar fácilmente algunas entradas de registro para obtener un menú contextual "Ejecutar como administrador" para archivos .ps1 :

New-Item -Path "Registry::HKEY_CLASSES_ROOT/Microsoft.PowershellScript.1/Shell/runas/command" ` -Force -Name '''' -Value ''"c:/windows/system32/windowspowershell/v1.0/powershell.exe" -noexit "%1"''

(actualizado a un script más simple de @Shay)

Básicamente, en HKCR:/Microsoft.PowershellScript.1/Shell/runas/command configura el valor predeterminado para invocar el script usando Powershell.


Puede crear un archivo por lotes ( *.bat ) que ejecute su secuencia de comandos powershell con privilegios administrativos cuando haga doble clic. De esta manera, no necesita cambiar nada en su script de powershell . Para hacer esto, cree un archivo por lotes con el mismo nombre y ubicación de su script de powershell y luego coloque el siguiente contenido en él:

@echo off set scriptFileName=%~n0 set scriptFolderPath=%~dp0 set powershellScriptFileName=%scriptFileName%.ps1 powershell -Command "Start-Process powershell /"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `/"cd /`/"%scriptFolderPath%/`/"; & /`/"./%powershellScriptFileName%/`/"`/"/" -Verb RunAs"

¡Eso es!

Aquí está la explicación:

Suponiendo que su script de powershell se encuentra en la ruta C:/Temp/ScriptTest.ps1 , su archivo por lotes debe tener la ruta C:/Temp/ScriptTest.bat . Cuando alguien ejecuta este archivo por lotes, ocurrirán los siguientes pasos:

  1. El cmd ejecutará el comando.

    powershell -Command "Start-Process powershell /"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `/"cd /`/"C:/Temp/`/"; & /`/"./ScriptTest.ps1/`/"`/"/" -Verb RunAs"

  2. Se abrirá una nueva sesión de powershell y se ejecutará el siguiente comando:

    Start-Process powershell "-ExecutionPolicy Bypass -NoProfile -NoExit -Command `"cd /`"C:/Temp/`"; & /`"./ScriptTest.ps1/`"`"" -Verb RunAs

  3. Otra nueva sesión de powershell con privilegios administrativos se abrirá en la carpeta system32 y se le pasarán los siguientes argumentos:

    -ExecutionPolicy Bypass -NoProfile -NoExit -Command "cd /"C:/Temp/"; & /"./ScriptTest.ps1/""

  4. El siguiente comando se ejecutará con privilegios administrativos:

    cd "C:/Temp"; & "./ScriptTest.ps1"

    Una vez que la ruta del script y los argumentos del nombre están entre comillas dobles, pueden contener espacio o caracteres de comillas simples ( '' ).

  5. La carpeta actual cambiará de system32 a C:/Temp y se ejecutará el script ScriptTest.ps1 . Una vez que se -NoExit pasado el parámetro -NoExit , la ventana no se cerrará, incluso si la secuencia de comandos de powershell produce alguna excepción.


Resulta que fue demasiado fácil. Todo lo que tienes que hacer es ejecutar un cmd como administrador. Luego escribe explorer.exe y pulsa enter. Eso abre el Windows Explorer . Ahora haga clic derecho en el script de PowerShell que desea ejecutar, elija "ejecutar con PowerShell", que se iniciará en PowerShell en modo administrador.

Puede pedirle que habilite la política para ejecutarse, escriba Y y presione Intro. Ahora el script se ejecutará en PowerShell como administrador. En caso de que se ejecute todo en rojo, eso significa que su política aún no se ha hecho efectiva. Entonces inténtalo de nuevo y debería funcionar bien.


Si la consola actual no está elevada y la operación que intenta realizar requiere privilegios elevados, entonces puede iniciar powershell con la opción "Ejecutar como administrador"

PS> Start-Process powershell -Verb runAs


También puede forzar que la aplicación se abra como administrador. Si tienes una cuenta de administrador, por supuesto.

Localice el archivo, haga clic con el botón derecho en> propiedades> Acceso directo> Avanzado y marque Ejecutar como administrador

Luego haga clic en Aceptar.


Utilizando

#Requires -RunAsAdministrator

Aún no se ha declarado. Parece estar ahí solo desde PowerShell 4.0.

http://technet.microsoft.com/en-us/library/hh847765.aspx

Cuando este parámetro de modificador se agrega a su declaración de requisitos, especifica que la sesión de Windows PowerShell en la que está ejecutando el script debe iniciarse con derechos de usuario elevados (Ejecutar como administrador).

Para mí, esto parece ser una buena manera de hacerlo, pero aún no estoy seguro de la experiencia de campo. Los tiempos de ejecución de PowerShell 3.0 probablemente ignoren esto, o peor aún, dan un error.

Cuando el script se ejecuta como un administrador no, se da el siguiente error:

El script ''.ps1'' no se puede ejecutar porque contiene una declaración "#requires" para ejecutarse como Administrador. La sesión actual de Windows PowerShell no se está ejecutando como administrador. Inicie Windows PowerShell con la opción Ejecutar como administrador y luego intente ejecutar el script nuevamente.

+ CategoryInfo : PermissionDenied: (.ps1:String) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : ScriptRequiresElevation


C:/Users/"username"/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Windows PowerShell es donde reside el acceso directo de PowerShell. También sigue yendo a una ubicación diferente para invocar el ''exe'' real ( %SystemRoot%/system32/WindowsPowerShell/v1.0/powershell.exe ).

Dado que PowerShell es manejado por perfil de usuario cuando se trata de permisos; Si su nombre de usuario / perfil tiene los permisos para hacer algo, entonces bajo ese perfil, en PowerShell, por lo general, también podría hacerlo. Dicho esto, tendría sentido que alterara el acceso directo ubicado debajo de su perfil de usuario, por ejemplo, C:/Users/"username"/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Windows PowerShell .

Haga clic derecho y haga clic en Propiedades. Haga clic en el botón "Avanzado" debajo de la pestaña "Acceso directo" ubicado justo debajo del campo de texto "Comentarios" junto a la derecha de los otros dos botones, "Abrir ubicación de archivo" y "Cambiar icono", respectivamente.

Marque la casilla de verificación que dice "Ejecutar como administrador". Haga clic en Aceptar , luego en Aplicar y en Aceptar . Una vez más, haga clic derecho en el icono etiquetado ''Windows PowerShell'' ubicado en C:/Users/"username"/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Windows PowerShell y seleccione "Fijar al menú Inicio / Barra de tareas".

Ahora, cada vez que haga clic en ese icono, invocará el UAC para su escalado. Después de seleccionar ''SÍ'', notará que la consola PowerShell está abierta y se etiquetará como "Administrador" en la parte superior de la pantalla.

Para ir un paso más allá ... puede hacer clic con el botón derecho en el mismo acceso directo del ícono en la ubicación de su perfil de Windows PowerShell y asignar un atajo de teclado que haga exactamente lo mismo que si hiciera clic en el ícono recientemente agregado. Entonces, donde dice "Tecla de acceso directo", coloque una combinación de teclas / botones del teclado como: Ctrl + Alt + P P (para PowerShell) . Haga clic en Aplicar y Aceptar .

Ahora todo lo que tiene que hacer es presionar la combinación de botones que asignó y verá que se invoca el UAC, y después de seleccionar ''SÍ'' verá que aparece una consola PowerShell y se muestra "Administrador" en la barra de título.