Cómo configurar Windows para Trabajo con secuencias de comandos PowerShell Más Fácil

Encabezamiento
Windows y PowerShell han incorporado características de seguridad y configuraciones predeterminadas destinadas a impedir a los usuarios finales de lanzar accidentalmente guiones en el curso de sus actividades diarias. Sin embargo, si sus actividades diarias implican rutinariamente escribir y ejecutar sus propios scripts de PowerShell, esto puede ser más una molestia que un beneficio. Aquí, le mostraremos cómo trabajar alrededor de estas características sin comprometer por completo en la seguridad.

¿Cómo y por qué Windows PowerShell y prevenir la ejecución del script.

PowerShell es efectivamente el lenguaje shell de comandos y secuencias de comandos que se pretende sustituir CMD y guiones de lotes en los sistemas Windows. Como tal, un script de PowerShell o menos se puede configurar para hacer cualquier cosa que podría hacer manualmente desde la línea de comandos. Eso equivale a hacer prácticamente cualquier posible cambio en el sistema, hasta las restricciones en su lugar en su cuenta de usuario. Por lo tanto, si se pudiera hacer doble clic en un script de PowerShell y ejecutarlo con privilegios de administrador completos, un sencillo de una sola línea como esto realmente podría arruinar su día:
Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
NO haga funcionar el comando anterior!
Eso simplemente pasa por el sistema de archivos y borra todo lo que pueda. Curiosamente, esto no puede hacer que el sistema que no funciona tan rápido como se podría pensar - incluso cuando se ejecuta desde una sesión elevada. Pero si alguien le llama después de ejecutar este script, porque de repente no pueden encontrar sus archivos o ejecutar algunos programas ", apagarlo y encenderlo" probablemente sólo les dejes caer en la reparación de inicio de Windows en el que van a ser dicho que hay nada de lo que se puede hacer para solucionar el problema. ¿Qué podría ser peor es, en vez de conseguir un guión que acaba destroza su sistema de archivos, su amigo podría ser engañado para ejecutar uno que descarga e instala un keylogger o servicio de acceso remoto. Entonces, en vez de hacerle preguntas sobre Reparación de inicio, que puede terminar pidiendo la policía algunas preguntas sobre fraude bancario!
A estas alturas debería ser obvio por qué se necesitan ciertas cosas para proteger a los usuarios finales de sí mismos, por así decirlo. Pero los usuarios de energía, administradores de sistemas y otros frikis son generalmente (aunque hay excepciones) un poco más de cuidado con estas amenazas, sabiendo cómo detectar y fácilmente evitarlos, y sólo quiero seguir adelante con conseguir su trabajo hecho. Para ello, tendrán que o bien deshabilitar o trabajan en torno a unas pocas cuadras de la carretera:
  • PowerShell no permite la ejecución de scripts externo por defecto.La puesta en PowerShell ExecutionPolicy impide la ejecución de scripts externos por defecto en todas las versiones de Windows. En algunas versiones de Windows, por defecto no permite la ejecución de scripts en absoluto. Te mostramos cómo cambiar esta configuración en Cómo permitir la ejecución de scripts de PowerShell en Windows 7 , pero vamos a cubrir en unos niveles aquí también.
  • PowerShell no está asociado a la extensión de archivo .ps1 por defecto.Lo comentamos inicialmente en nuestro PowerShell Geek escuela serie. Windows establece la acción predeterminada para los archivos .ps1 abrirlos en el Bloc de notas, en lugar de enviarlos a la intérprete de comandos de PowerShell. Esto es para evitar directamente la ejecución accidental de scripts maliciosos cuando están simplemente hacer doble clic.
  • Algunos scripts de PowerShell no funcionarán sin permisos de administrador.Incluso se ejecuta con una cuenta de nivel de administrador, usted todavía tiene que pasar por el Control de cuentas de usuario (UAC) para llevar a cabo ciertas acciones. Para las herramientas de línea de comandos, esto puede ser un poco incómodo para decir lo menos. No queremos desactivar UAC , pero sigue siendo agradable cuando podemos hacer un poco más fácil de tratar.
Estos mismos temas son criados en Cómo utilizar un archivo por lotes para hacer scripts de PowerShell más fácil de ejecutar , donde le caminamos por escribir un archivo por lotes para obtener temporalmente a su alrededor. Ahora, vamos a mostrar cómo configurar su sistema con una solución más a largo plazo. Tenga en cuenta que no se debe generalmente hacer estos cambios en los sistemas que no son utilizados exclusivamente por usted - de lo contrario, usted está poniendo a otros usuarios en mayor riesgo de encontrarse con los mismos problemas de estas características están destinadas a prevenir.

Cambio de la asociación de archivos .ps1.

La primera, y quizás más importante, la molestia de desplazarse es la asociación predeterminada para los archivos .ps1. La asociación de estos archivos para que no sea PowerShell.exe nada tiene sentido para la prevención de la ejecución accidental de secuencias de comandos no deseados. Pero, teniendo en cuenta que PowerShell viene con un Entorno de scripting integrado (ISE), que está diseñado específicamente para la edición de scripts de PowerShell, ¿por qué íbamos a querer abrir .ps1 archivos en el Bloc de notas por defecto?Incluso si usted no está listo para cambiar totalmente de permitir doble clic-to-run funcionalidad, es probable que desee para modificar estos ajustes.
Usted puede cambiar la asociación de archivos .ps1 a cualquier programa que desee con elProgramas predeterminados del panel de control, pero la excavación directamente en el Registro le dará un poco más de control sobre exactamente cómo se abrirán los archivos. Esto también le permite establecer o cambiar las opciones adicionales que están disponibles en el menú contextual de los archivos .ps1. No se olvide de hacer una copia de seguridad del registroantes de hacer esto!
Los ajustes del registro que controlan cómo los scripts de PowerShell se abren se almacenan en la siguiente ubicación:
HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell
Para explorar estas opciones antes de ir sobre el cambio de ellos, echar un vistazo a esa clave y sus subclaves con Regedit . La clave Shell sólo debe tener un valor "(Default)", que se establece en "Abrir". Este es un puntero a la acción predeterminada para hacer doble clic en el archivo, que veremos en los sub-llaves.
Expanda la clave Shell, y verás tres sub-llaves. Cada uno de ellos representa una acción que puede realizar, que es específico de scripts de PowerShell.
Shell-Key
Pueden ampliar cada tecla para explorar los valores dentro, pero que básicamente equivale a los siguientes valores por defecto:
  • 0 - Ejecutar con PowerShell. "Ejecutar con PowerShell" es en realidad el nombre de una opción que ya están en el menú contextual de scripts de PowerShell. El texto es sólo tiró desde otro lugar en vez de usar el nombre de clave como los demás. Y todavía no es el doble clic acción predeterminada.
  • Edición - Abrir en PowerShell ISE. Esto hace mucho más sentido que el Bloc de notas, pero usted todavía tiene que hacer clic en el archivo .ps1 hacerlo de forma predeterminada.
  • Abrir - Abrir en el Bloc de notas. Tenga en cuenta que este nombre clave es también la cadena almacenada en el "(predeterminado)" valor de la clave Shell. Esto significa hacer doble clic en el archivo será "Abrir", y que la acción se establece normalmente utilizar el Bloc de notas.
Si quiere seguir con las cadenas de comandos pre-construido ya disponible, sólo puede cambiar el "(predeterminado)" valor en la clave Shell para que coincida con el nombre de la clave que coincide con lo que quieres es un doble clic hacer. Esto se puede hacer fácilmente desde el interior de Regedit, o usted podría utilizar las lecciones aprendidas de nuestro tutorial sobreexplorar el registro con PowerShell (más un pequeño tweak PSDrive) para comenzar a construir una secuencia de comandos reutilizables que pueden configurar sus sistemas para usted. Los siguientes comandos deben ejecutarse desde una sesión de PowerShell elevada, similar aejecutar CMD como Administrador .
En primer lugar, usted querrá configurar un PSDrive para HKEY_CLASSES_ROOT ya que esto no está configurado de forma predeterminada. El comando para esto es:
Nueva PSDrive HKCR Registro HKEY_CLASSES_ROOT
Ahora usted puede navegar y claves y valores en HKEY_CLASSES_ROOT edición del registro al igual que lo haría en los PSDrives regulares HKCU y HKLM.
Para configurar un doble clic para lanzar directamente scripts de PowerShell:
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(por defecto)' 0
Para configurar un doble clic para abrir scripts de PowerShell en el PowerShell ISE:
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(por defecto)' 'Editar'
Para restaurar el valor por defecto (conjuntos de doble clic para abrir scripts de PowerShell en el Bloc de notas):
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(por defecto)' 'Open'
Eso es sólo lo básico de cambio de la de doble clic acción predeterminada. Vamos a entrar en más detalles sobre cómo personalizar la forma en scripts de PowerShell se manejan cuando están abiertas en PowerShell desde el Explorador en la siguiente sección. Tenga en cuenta quealcance impide PSDrives de persistir a través de sesiones . Así, es probable que desee incluir la línea Nueva PSDrive al inicio de cualquier script de configuración se genera para este fin, o añadirlo a tu perfil PowerShell . De lo contrario, tendrá que ejecutar ese pedacito manualmente antes de tratar de hacer cambios de esta manera.

Cambio del ajuste de PowerShell ExecutionPolicy.

ExecutionPolicy de PowerShell es otra capa de protección contra la ejecución de scripts maliciosos. Existen múltiples opciones para este y un par de maneras diferentes que se pueden establecer. De más a menos segura, las opciones disponibles son:
  • Restringido - No está permitido correr. (Ajuste por defecto para la mayoría de los sistemas). Esto incluso prevenir su script perfil se ejecute.
  • AllSigned - Todos los scripts deben estar firmados digitalmente por un editor de confianza para funcionar sin preguntar al usuario. Scripts firmados por editores definen explícitamente como no confiable, o scripts no firmados digitalmente en absoluto, no se ejecutará. PowerShell solicitará al usuario que confirme si un guión está firmado por un editor aún no definidos como de confianza o no confiable. Si usted no ha firmado digitalmente el script de perfil, y estableció la confianza en que la firma, que no será capaz de ejecutar. Tenga cuidado de que los editores de confianza, ya que todavía puede llegar a ejecutar scripts maliciosos si confía en el equivocado.
  • RemoteSigned - Para los scripts descargados de Internet , esto es efectivamente lo mismo que "AllSigned". Sin embargo, los scripts creados localmente o importados de fuentes distintas de Internet se pueden ejecutar sin ningún mensaje de confirmación. Aquí, tendrás que tener cuidado también que las firmas digitales de su confianza, pero incluso ser más cuidadoso de los guiones no firmado que decide correr. Este es el nivel más alto de seguridad en las que se puede tener un guión perfil de trabajo sin tener que firmar digitalmente ella.
  • Sin restricción - Todos los scripts se les permite correr, pero un mensaje de confirmación se requerirá para las escrituras de la Internet. A partir de ahora, es totalmente de usted para evitar la ejecución de scripts de poca confianza.
  • Bypass - Todo funciona sin una advertencia. Tenga cuidado con éste.
  • Undefined - Ninguna política se define en el ámbito actual. Esto se utiliza para permitir repliegue a las políticas definidas en ámbitos inferiores (más detalles a continuación) oa los valores por defecto del sistema operativo.
Como se sugiere por la descripción de Indefinido, las políticas anteriores se pueden establecer en uno o más de varios ámbitos. Puede utilizar Get-ExecutionPolicy, con el parámetro -Lista, para ver todos los alcances y su configuración actual.
ExecutionPolicy-List
Los ámbitos se enumeran en orden de prioridad, con el alcance definido superior anulando todas las demás. Si no se definen las políticas, el sistema se cae de nuevo a su configuración predeterminada (en la mayoría de los casos, esto se Restringido).
  • MachinePolicy representa una directiva de grupo , en efecto, a nivel de equipos. Esto generalmente se aplica solamente en un dominio , pero se puede hacer a nivel local también.
  • UserPolicy representa una directiva de grupo en el efecto sobre el usuario. Esto es también típicamente utilizado en entornos empresariales.
  • El proceso es un ámbito específico para esta instancia de PowerShell. Los cambios en la política en este ámbito no se afectan otros procesos de PowerShell en ejecución, y serán ineficaces después de esta sesión se termina. Esto puede ser configurado por el parámetro -ExecutionPolicy cuando se inicia PowerShell, o puede configurarse con la sintaxis Set-ExecutionPolicy adecuada dentro de la sesión.
  • CurrentUser es un ámbito que está configurado en el registro local y se aplica a la cuenta de usuario utilizada para iniciar PowerShell. Este ámbito de aplicación puede ser modificado con Set-ExecutionPolicy.
  • LocalMachine es un ámbito configurado en el registro local y la aplicación a todos los usuarios en el sistema. Este es el ámbito predeterminado que se cambia si Set-ExecutionPolicy se ejecuta sin el parámetro -Ámbito. Como se aplica a todos los usuarios en el sistema, sólo se puede cambiar de una sesión elevada.
Dado que este artículo trata principalmente sobre cómo moverse de seguridad para facilitar la usabilidad, sólo estamos preocupados por los tres ámbitos inferiores. Los ajustes MachinePolicy y UserPolicy son realmente útiles sólo si desea aplicar una política restrictiva que no está tan simplemente omite. Al mantener nuestros cambios en el nivel de proceso o por debajo, podemos utilizar simplemente lo configuración de directiva que consideremos apropiado para una situación dada en cualquier momento.
Para mantener un cierto equilibrio entre la seguridad y la facilidad de uso, la política se muestra en la captura de pantalla es probablemente el mejor. Establecimiento de la política LocalMachine en Restringido general impide la ejecución de scripts por nadie más que usted.Por supuesto, esto puede ser vencida por los usuarios que saben lo que están haciendo sin mucho esfuerzo. Pero debe mantener ningún tipo de usuarios no-tech-comprensión activen accidentalmente algo catastrófico en PowerShell. Tener la CurrentUser (es decir: usted) establece como No restringido permite ejecutar manualmente los scripts desde la línea de comandos como más te guste, pero sí conserva un recordatorio de precaución para los scripts descargados de Internet. Tendría que ser hecho en un acceso directo a PowerShell.exe o (como lo haremos más adelante) en los valores del Registro que controlan el comportamiento de los scripts de PowerShell El ajuste RemoteSigned a nivel de proceso. Esto permitirá fácil doble clic-para-ejecutar la funcionalidad de las secuencias de comandos que usted escribe, mientras que la colocación de una barrera más fuerte contra la ejecución involuntaria de scripts (potencialmente maliciosos) de fuentes externas. Queremos hacer esto aquí, ya que es mucho más fácil accidentalmente haga doble clic en un guión de lo que generalmente es llamar manualmente desde una sesión interactiva.
Para establecer las políticas y CurrentUser LocalMachine como en la imagen de arriba, ejecute los siguientes comandos desde una sesión de PowerShell elevada:
Set-ExecutionPolicy Restringido
Set-ExecutionPolicy sin restricciones -Ámbito CurrentUser
Para hacer cumplir la política RemoteSigned en ejecutar scripts desde el Explorador, tendremos que cambiar un valor en el interior de una de las claves de registro que estaban mirando antes.Esto es particularmente importante, ya que, dependiendo de su versión de Windows PowerShell o, la configuración por defecto puede ser pasar por alto todos los ajustes excepto ExecutionPolicy AllSigned. Para ver cuál es la configuración actual está para su equipo, puede ejecutar este comando (asegurándose de que el HKCR PSDrive se asigna primero):
Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Select-Object "(predeterminado)"
Su configuración por defecto será probablemente una de las dos cadenas siguientes, o algo bastante similar:
(Visto en Windows 7 x64 SP1, con PowerShell 2.0)
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-file" "% 1"
(Visto en Windows 8.1 x 64, con PowerShell 4.0)
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "if ((Get-ExecutionPolicy) -ne 'AllSigned') {Set-ExecutionPolicy -Ámbito Bypass Proceso}; & '% 1 '"
El primero no es tan malo, ya que lo único que hace es ejecutar la secuencia de comandos en la configuración ExecutionPolicy existentes. Podría ser mejor, mediante la aplicación de restricciones más estrictas para una acción más propenso a los accidentes, pero esto no fue pensada originalmente para ser activado en un doble clic en de todos modos, y la política por defecto suele estar restringida después de todo. La segunda opción, sin embargo, es una derivación completa de lo ExecutionPolicy es muy probable que tenga en su lugar - incluso Restringido. Desde la carretera de circunvalación se aplicará en el ámbito del proceso, que sólo afecta a las sesiones que se inician cuando los scripts se ejecutan desde el Explorador. Sin embargo, esto significa que usted podría terminar lanzando scripts que de otro modo podrían esperar (y desear) su política de prohibir.
Para establecer el nivel ExecutionPolicy Proceso para scripts lanzados desde el Explorador, en línea con la imagen anterior, tendrá que modificar el mismo valor del registro sólo pregunté.Puede hacerlo de forma manual en Regedit, cambiándola a esto:
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"
Regedit-RemoteSigned
También puede cambiar la configuración desde dentro PowerShell si lo prefiere. Recuerda hacer esto de una sesión elevada, con el HKCR PSDrive asignada.
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(por defecto)' '"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1" '

Ejecutar scripts de PowerShell como administrador.

Así como es una mala idea para desactivar UAC completamente, también es mala práctica de seguridad para ejecutar scripts o programas con privilegios elevados a menos que realmente los necesita para llevar a cabo las operaciones que requieren acceso de administrador. Por lo tanto, no se recomienda la construcción de la UAC en la acción predeterminada para scripts de PowerShell. Sin embargo, podemos añadir una nueva opción del menú contextual que nos permite ejecutar fácilmente secuencias de comandos en sesiones elevados cuando necesitamos. Esto es similar al método utilizado para añadir "Abrir con el Bloc de notas" al menú contextual de todos los archivos - pero aquí sólo nos vamos a apuntar a scripts de PowerShell. También vamos a realizar sobre algunas técnicas utilizadas en el artículo anterior, en donde se utilizó un archivo por lotes en lugar de hacks del registro para lanzar nuestro script de PowerShell.
Para hacer esto en Regedit, volver a entrar en la clave Shell, en:
HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell
En allí, crear una nueva sub-clave. Llámelo "Ejecutar con PowerShell (Admin)". Debajo de eso, crear otro sub-clave llamada "Comando". A continuación, establezca el "(predeterminado)" valor bajo comando a esto:
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & {Start-Proceso PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' RunAs -Verb } "
Regedit-RunAsAdmin
Hacer lo mismo en PowerShell realmente necesitará tres líneas de este tiempo. Uno para cada nueva clave, y uno para ajustar el "(predeterminado)" valor de Comando. No te olvides de la elevación y el mapeo HKCR.
New-Item 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run con PowerShell (Admin)'
New-Item 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run con PowerShell (Admin) \ Command'
Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run con PowerShell (Admin) \ Command' '(por defecto)' '"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "- Comando "" "& {Start-Proceso PowerShell.exe -ArgumentList '' -ExecutionPolicy RemoteSigned -File \"% 1 \ "'' -Verb RunAs}" '
También, preste especial atención a las diferencias entre la cadena que se están poniendo en medio de PowerShell y el valor real que está pasando en el Registro. En particular, tenemos que envolver toda la cosa en comillas simples y de doble arriba en las comillas simples internos, a fin de evitar errores en la orden de análisis.
Ahora usted debería tener una nueva entrada de menú contextual para los scripts de PowerShell, llamado "Ejecutar con PowerShell (Admin)".
Botón derecho del ratón
La nueva opción se generan dos instancias PowerShell consecutivos. La primera es simplemente un lanzador para el segundo, que utiliza Start-Proceso con el parámetro "RunAs -Verb" para solicitar la elevación para el nuevo período de sesiones. A partir de ahí, el guión debe ser capaz de ejecutar con privilegios de administrador después de hacer clic a través de la UAC.

Toques finales.

Sólo hay un par de retoques a esto que pueden ayudar a hacer la vida un poco más fácil todavía. Por un lado, la forma de deshacerse de la función de la libreta del todo? Simplemente copie el "(predeterminado)" valor de la tecla Comando en Editar (abajo), en el mismo lugar bajo en Abrir.
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"
O bien, puede utilizar este poco de PowerShell (con administración y HKCR por supuesto):
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(por defecto)' '"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"'
Una más pequeña molestia es el hábito de la consola de desaparecer una vez que un script se ha completado. Cuando eso sucede, no tenemos ninguna oportunidad de revisar la salida de la escritura de los errores u otra información útil. Esto puede ser atendido por poner una pausa al final de cada una de las secuencias de comandos, por supuesto. Alternativamente, podemos modificar las "(predeterminado)" valores de las llaves de comando para incluir el parámetro "-NoExit". A continuación se presentan los valores modificados.
(Sin acceso Admin)
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"
(Con acceso Admin)
"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & {Start-Proceso PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Verbos RunAs} "
Y, por supuesto, le daremos los de PowerShell comandos también. El último recordatorio: Elevación y HKCR!
(Non-Admin)
Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(por defecto)' '"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1" '
(Admin)
Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run con PowerShell (Admin) \ Command' '(por defecto)' '"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "- Comando "" "& {Start-Proceso PowerShell.exe -ArgumentList '' -NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "'' -Verb RunAs}" '

Si lo toma para una vuelta.

Para probar esto, vamos a utilizar un script que nos puede mostrar la configuración ExecutionPolicy en su lugar y si es o no el guión fue lanzado con permisos de administrador. El guión se llamará "MyScript.ps1" y se almacena en "D: \ Lab Guión" en nuestro sistema muestra.El código está abajo, para referencia.
if(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrador"))
{Write-Output 'Correr como administrador!'}
más
{Write-Output 'Running limitado!'}
Get-ExecutionPolicy -Lista
El uso de la acción "Ejecutar con PowerShell":
Limited-ExecutionPolicy
Utilizando el "Ejecutar con PowerShell (Admin)" acción, después de hacer clic a través de UAC:
Admin-ExecutionPolicy
Para demostrar la ExecutionPolicy en acción en el ámbito del proceso, podemos hacer que Windows cree el archivo provenía de Internet con este trozo de código PowerShell:
Add-contenido -Path 'D: \ script Lab \ MyScript.ps1' -Value "[ZoneTransfer]` nZoneId = 3 "'Zone.Identifier' -stream
RemoteSigned-Error
Afortunadamente, habíamos -NoExit habilitado. De lo contrario, ese error habría apenas parpadeó por, y no habría sabido!
El Zone.Identifier se puede quitar con esto:
Clear-Content -Path 'D: \ script Lab \ MyScript.ps1' 'Zone.Identifier' -stream

Referencias útiles:
  • Ejecución de scripts de PowerShell de un archivo por lotes - Programación Blog de ​​Daniel Schroeder
  • Comprobación de los permisos de administrador en PowerShell - Hey, chicos del scripting!Blog