Cómo configurar Windows para trabajar con PowerShell Scripts más fácilmente

Windows y PowerShell tienen funciones de seguridad integradas y configuraciones predeterminadas destinadas a evitar que los usuarios finales ejecuten accidentalmente scripts en el curso de sus actividades diarias. Sin embargo, si sus actividades diarias consisten en escribir y ejecutar sus propios scripts de PowerShell, esto puede ser más una molestia que un beneficio. Aquí, le mostraremos cómo solucionar estas características sin comprometer completamente la seguridad.

Cómo y por qué Windows y PowerShell impiden la ejecución de scripts.

PowerShell es efectivamente el shell de comandos y el lenguaje de scripts destinado a reemplazar CMD y los scripts por lotes en los sistemas Windows. Como tal, un script de PowerShell puede configurarse para hacer cualquier cosa que pueda hacer manualmente desde la línea de comandos. Eso equivale a hacer prácticamente cualquier cambio posible en su sistema, hasta las restricciones establecidas en su cuenta de usuario. Por lo tanto, si solo pudiera hacer doble clic en un script de PowerShell y ejecutarlo con privilegios de administrador completos, una simple frase como esta realmente podría arruinar su día:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Quitar elemento -Force -Recurse -ErrorAction SilentlyContinue

NO ejecute el comando anterior!

Eso simplemente pasa por el sistema de archivos y elimina todo lo que pueda. Es interesante que esto no haga que el sistema deje de funcionar tan rápido como podría pensar, incluso cuando se ejecuta desde una sesión elevada. Pero si alguien te llama después de ejecutar este script, porque de repente no pueden encontrar sus archivos o ejecutar algunos programas, "apagarlo y volverlo a encender" probablemente los llevará a la Reparación de inicio de Windows donde se les dirá que hay nada que se pueda hacer para solucionar el problema. Lo que podría ser peor es que, en lugar de obtener un script que simplemente destruye su sistema de archivos, su amigo podría ser engañado para que ejecute uno que descargue e instale un registrador de teclas o un servicio de acceso remoto. Luego, en lugar de hacerle preguntas sobre Reparación de inicio, pueden terminar preguntándole a la policía algunas preguntas sobre el fraude bancario.!

A estas alturas, debería ser obvio por qué se necesitan ciertas cosas para proteger a los usuarios finales de ellos mismos, por así decirlo. Pero los usuarios avanzados, los administradores de sistemas y otros geeks son generalmente (aunque hay excepciones) un poco más desconfiados de estas amenazas, sabiendo cómo detectarlas y evitarlas fácilmente, y solo quieren continuar con su trabajo. Para hacer esto, tendrán que deshabilitar o solucionar algunos bloqueos de carreteras:

PowerShell no permite la ejecución de scripts externos de forma predeterminada.
La configuración de ExecutionPolicy en PowerShell evita la ejecución de scripts externos de forma predeterminada en todas las versiones de Windows. En algunas versiones de Windows, el valor predeterminado no permite la ejecución de secuencias de comandos en absoluto. Le mostramos cómo cambiar esta configuración en Cómo permitir la ejecución de scripts de PowerShell en Windows 7, pero también lo cubriremos en algunos niveles.
PowerShell no está asociado a la extensión de archivo .PS1 por defecto.
Lo mencionamos inicialmente en nuestra serie de PowerShell Geek School. Windows establece la acción predeterminada para que los archivos .PS1 los abran en el Bloc de notas, en lugar de enviarlos al intérprete de comandos de PowerShell. Esto es para evitar directamente la ejecución accidental de scripts maliciosos cuando simplemente se hace doble clic.
Algunos scripts de PowerShell no funcionarán sin los permisos de administrador.
Incluso si se ejecuta con una cuenta de nivel de administrador, debe pasar por el Control de cuentas de usuario (UAC) para realizar ciertas acciones. Para las herramientas de línea de comandos, esto puede ser un poco engorroso, por decir lo menos. No queremos deshabilitar UAC, pero sigue siendo bueno cuando podemos hacerlo un poco más fácil de manejar.

Estos mismos problemas se mencionan en Cómo usar un archivo por lotes para hacer que los scripts de PowerShell sean más fáciles de ejecutar, donde le explicamos cómo escribir un archivo por lotes para solucionarlos temporalmente. Ahora, le mostraremos cómo configurar su sistema con una solución más a largo plazo. Tenga en cuenta que, por lo general, no debe realizar estos cambios en los sistemas que usted no utiliza exclusivamente; de lo contrario, está poniendo a otros usuarios en mayor riesgo de tener los mismos problemas que estas funciones pretenden evitar..

Cambiando la asociación de archivos .PS1.

La primera, y quizás la más importante, es la asociación predeterminada para los archivos .PS1. Asociar estos archivos a otro que no sea PowerShell.exe tiene sentido para evitar la ejecución accidental de scripts no deseados. Pero, considerando que PowerShell viene con un entorno de secuencias de comandos integrado (ISE) que está diseñado específicamente para editar scripts de PowerShell, ¿por qué querríamos abrir los archivos .PS1 en el Bloc de notas de forma predeterminada? Incluso si no está listo para cambiar completamente a habilitar la funcionalidad de doble clic para ejecutar, probablemente querrá modificar estas configuraciones.

Puede cambiar la asociación de archivos .PS1 a cualquier programa que desee con el panel de control de Programas predeterminados, pero al ingresar directamente en el Registro le dará un poco más de control sobre cómo se abrirán los archivos. Esto también le permite configurar o cambiar opciones adicionales que están disponibles en el menú contextual para archivos .PS1. No olvide hacer una copia de seguridad del registro antes de hacer esto!

La configuración del registro que controla cómo se abren los scripts de PowerShell se almacena en la siguiente ubicación:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Para explorar estos ajustes antes de cambiarlos, eche un vistazo a esa clave y sus subclaves con Regedit. La clave de Shell solo debe tener un valor, "(Predeterminado)", que se establece en "Abrir". Este es un puntero a la acción predeterminada para hacer doble clic en el archivo, que veremos en las subclaves.

Expanda la clave de Shell y verá tres subclaves. Cada uno de estos representa una acción que puede realizar que es específica de los scripts de PowerShell.

Puede expandir cada clave para explorar los valores internos, pero básicamente equivalen a los siguientes valores predeterminados:

0 - Ejecutar con PowerShell. "Ejecutar con PowerShell" es en realidad el nombre de una opción que ya se encuentra en el menú contextual de los scripts de PowerShell. El texto simplemente se extrae de otra ubicación en lugar de usar el nombre de la clave como los demás. Y todavía no es la acción predeterminada de doble clic.
Editar - Abrir en PowerShell ISE. Esto tiene mucho más sentido que el Bloc de notas, pero todavía tiene que hacer clic derecho en el archivo .PS1 para hacerlo de manera predeterminada.
Abrir - Abrir en el Bloc de notas. Tenga en cuenta que este nombre de clave también es la cadena almacenada en el valor "(Predeterminado)" de la clave de Shell. Esto significa que hacer doble clic en el archivo lo "Abrirá" y que la acción normalmente está configurada para usar el Bloc de notas.

Si desea continuar con las cadenas de comando pre-compuestas ya disponibles, simplemente puede cambiar el valor "(Predeterminado)" en la clave de Shell para que coincida con el nombre de la clave que coincida con lo que desea hacer un doble clic. Esto se puede hacer fácilmente desde Regedit, o puede usar las lecciones aprendidas de nuestro tutorial sobre cómo explorar el registro con PowerShell (más un pequeño ajuste de PSDrive) para comenzar a crear un script reutilizable que pueda configurar sus sistemas por usted. Los siguientes comandos deben ejecutarse desde una sesión elevada de PowerShell, similar a ejecutar CMD como Administrador.

Primero, querrá configurar un PSDrive para HKEY_CLASSES_ROOT ya que esto no está configurado de forma predeterminada. El comando para esto es:

Registro de HKCR de New-PSDrive HKEY_CLASSES_ROOT

Ahora puede navegar y editar claves de registro y valores en HKEY_CLASSES_ROOT como lo haría en los PSDrives HKCU y HKLM normales.

Para configurar el doble clic para iniciar los scripts de PowerShell directamente:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(predeterminado)' 0

Para configurar el doble clic para abrir los scripts de PowerShell en el ISE de PowerShell:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(predeterminado) "Editar'

Para restaurar el valor predeterminado (establece hacer doble clic para abrir los scripts de PowerShell en el Bloc de notas):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(predeterminado) "Abrir'

Eso es solo lo básico de cambiar la acción predeterminada de doble clic. Vamos a entrar en más detalles sobre cómo personalizar cómo se manejan los scripts de PowerShell cuando se abren en PowerShell desde Explorer en la siguiente sección. Tenga en cuenta que el alcance impide que los PSDrives persistan entre las sesiones. Por lo tanto, es probable que desee incluir la línea New-PSDrive al comienzo de cualquier secuencia de comandos de configuración que cree para este propósito, o agregarla a su perfil de PowerShell. De lo contrario, deberá ejecutar ese bit manualmente antes de intentar realizar cambios de esta manera..

Cambiar la configuración de PowerShell ExecutionPolicy.

La política de ejecución de PowerShell es otra capa de protección contra la ejecución de scripts maliciosos. Existen múltiples opciones para esto, y se pueden configurar un par de maneras diferentes. De mayor a menor seguridad, las opciones disponibles son:

Restringido: no se permiten secuencias de comandos para ejecutarse. (Configuración predeterminada para la mayoría de los sistemas). Esto incluso evitará que su script de perfil se ejecute.
AllSigned: todos los scripts deben estar firmados digitalmente por un editor de confianza para que se ejecuten sin preguntar al usuario. Los scripts firmados por editores definidos explícitamente como no confiables, o los scripts sin firma digital, no se ejecutarán. PowerShell solicitará al usuario que confirme si un script está firmado por un editor aún no definido como confiable o no confiable. Si no ha firmado digitalmente su secuencia de comandos de perfil, y ha establecido confianza en esa firma, no podrá ejecutarse. Tenga cuidado en qué publicadores confía, ya que aún puede terminar ejecutando scripts maliciosos si confía en el incorrecto.
RemoteSigned: para los scripts descargados de Internet, en realidad es lo mismo que "AllSigned". Sin embargo, los scripts creados localmente o importados de fuentes distintas de Internet pueden ejecutarse sin ningún aviso de confirmación. Aquí, también deberá tener cuidado con las firmas digitales en las que confía, pero incluso con más cuidado con los scripts no firmados que elija para ejecutar. Este es el nivel de seguridad más alto en el que puede tener un script de perfil en funcionamiento sin tener que firmarlo digitalmente.
Sin restricciones: todos los scripts pueden ejecutarse, pero se requerirá un mensaje de confirmación para los scripts de Internet. A partir de este momento, depende completamente de usted evitar la ejecución de scripts no confiables..
Bypass - Todo se ejecuta sin una advertencia. Ten cuidado con éste.
No definido: no se define ninguna política en el ámbito actual. Esto se usa para permitir el repliegue de políticas definidas en ámbitos inferiores (más detalles a continuación) o para los valores predeterminados del sistema operativo.

Como lo sugiere la descripción de Undefined, las políticas anteriores se pueden establecer en uno o más de varios ámbitos. Puede usar Get-ExecutionPolicy, con el parámetro -List, para ver todos los ámbitos y su configuración actual.

Los ámbitos se enumeran en orden de prioridad, con el ámbito definido más arriba que los demás. Si no se definen políticas, el sistema vuelve a su configuración predeterminada (en la mayoría de los casos, esto está restringido).

MachinePolicy representa una directiva de grupo en vigor en el nivel de equipo. Esto generalmente se aplica solo en un dominio, pero también puede hacerse localmente.
UserPolicy representa una Política de grupo en efecto sobre el usuario. Esto también se suele utilizar en entornos empresariales..
El proceso es un ámbito específico para esta instancia de PowerShell. Los cambios a la política en este ámbito no afectarán a otros procesos en ejecución de PowerShell y serán ineficaces después de que termine esta sesión. Esto se puede configurar mediante el parámetro -ExecutionPolicy cuando se inicia PowerShell, o se puede configurar con la sintaxis Set-ExecutionPolicy adecuada desde dentro de la sesión.
CurrentUser es un ámbito que se configura en el registro local y se aplica a la cuenta de usuario utilizada para iniciar PowerShell. Este alcance se puede modificar con Set-ExecutionPolicy.
LocalMachine es un ámbito configurado en el registro local y que se aplica a todos los usuarios del sistema. Este es el alcance predeterminado que se cambia si Set-ExecutionPolicy se ejecuta sin el parámetro -Scope. Como se aplica a todos los usuarios del sistema, solo se puede cambiar desde una sesión elevada.

Dado que este artículo trata principalmente sobre cómo evitar la seguridad para facilitar la usabilidad, solo nos preocupan los tres ámbitos inferiores. La configuración de MachinePolicy y UserPolicy son realmente útiles solo si desea aplicar una política restrictiva que no se omite. Al mantener nuestros cambios en el nivel del Proceso o por debajo, podemos usar fácilmente cualquier configuración de política que consideremos adecuada para una situación determinada en cualquier momento.

Para mantener un cierto equilibrio entre la seguridad y la facilidad de uso, la política que se muestra en la captura de pantalla es probablemente la mejor. La configuración de la política de LocalMachine en Restricted generalmente evita la ejecución de scripts por cualquier persona que no sea usted. Por supuesto, esto puede ser evitado por usuarios que saben lo que están haciendo sin mucho esfuerzo. Pero debería evitar que cualquier usuario no experto en tecnología dispare accidentalmente algo catastrófico en PowerShell. Tener el CurrentUser (es decir, usted) configurado como Sin restricciones le permite ejecutar scripts manualmente desde la línea de comandos como desee, pero conserva un recordatorio de precaución para los scripts descargados de Internet. La configuración de RemoteSigned en el nivel de Proceso debería realizarse en un acceso directo a PowerShell.exe o (como lo haremos a continuación) en los valores del Registro que controlan el comportamiento de los scripts de PowerShell. Esto permitirá la funcionalidad fácil de hacer doble clic para ejecutar cualquier script que escriba, al tiempo que crea 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 hacer doble clic accidentalmente en un script de lo que generalmente es llamarlo manualmente desde una sesión interactiva.

Para configurar las políticas de CurrentUser y LocalMachine como se muestra en la captura de pantalla anterior, ejecute los siguientes comandos desde una sesión elevada de PowerShell:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Para aplicar la política de RemoteSigned en los scripts ejecutados desde Explorer, tendremos que cambiar un valor dentro de una de las claves de registro que vimos anteriormente. Esto es particularmente importante porque, dependiendo de su versión de PowerShell o Windows, la configuración predeterminada puede ser omitir todas las configuraciones de ExecutionPolicy excepto AllSigned. Para ver cuál es la configuración actual para su computadora, puede ejecutar este comando (asegurándose de que el PSDrive de HKCR esté mapeado primero):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Seleccionar objeto '(predeterminado)'

Su configuración predeterminada probablemente sea una de las siguientes dos cadenas, o algo bastante similar:

(Visto en Windows 7 SP1 x64, con PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-file" "% 1"

(Visto en Windows 8.1 x64, con PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "if ((Get-ExecutionPolicy) -ne 'AllSigned') Set-ExecutionPolicy -Scope Process Bypass; & '% 1 ''

La primera no está tan mal, ya que todo lo que hace es ejecutar el script bajo la configuración de ExecutionPolicy existente. Se podría mejorar, aplicando restricciones más estrictas para una acción más propensa a los accidentes, pero esto no fue pensado originalmente para activarse con un doble clic de todos modos, y la política predeterminada generalmente está restringida después de todo. La segunda opción, sin embargo, es un desvío completo de cualquier política de ejecución que pueda tener, incluso restringida. Dado que la omisión se aplicará en el ámbito del Proceso, solo afecta a las sesiones que se inician cuando los scripts se ejecutan desde Explorer. Sin embargo, esto significa que podría terminar lanzando scripts que de otro modo podría esperar (y desearía) que su política prohíba.

Para configurar ExecutionPolicy a nivel de proceso para los scripts lanzados desde Explorer, de acuerdo con la captura de pantalla anterior, deberá modificar el mismo valor de registro que acabamos de consultar. Puedes hacerlo manualmente en Regedit, cambiándolo a esto:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

También puede cambiar la configuración desde PowerShell si lo prefiere. Recuerde hacer esto desde una sesión elevada, con el PSDrive de HKCR mapeado.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(predeterminado) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -ExecutionPolicy "" RemoteSigned "" -file "" % 1 "'

Ejecutar scripts de PowerShell como administrador.

Así como es una mala idea deshabilitar el UAC por completo, también es una mala práctica de seguridad ejecutar scripts o programas con privilegios elevados a menos que realmente los necesite para realizar operaciones que requieran acceso de administrador. Por lo tanto, no se recomienda crear el mensaje de UAC en la acción predeterminada para los scripts de PowerShell. Sin embargo, podemos agregar una nueva opción de menú de contexto para permitirnos ejecutar fácilmente scripts en sesiones elevadas cuando sea necesario. Esto es similar al método utilizado para agregar "Abrir con Bloc de notas" al menú contextual de todos los archivos, pero aquí solo vamos a dirigirnos a los scripts de PowerShell. También vamos a continuar con algunas técnicas utilizadas en el artículo anterior, en el que utilizamos un archivo por lotes en lugar de trucos de registro para iniciar nuestro script de PowerShell..

Para hacer esto en Regedit, regrese a la clave de Shell, en:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Allí, crea una nueva subclave. Llámelo "Ejecutar con PowerShell (Admin)". Debajo de eso, crea otra subclave llamada "Comando". Luego, establezca el valor "(Predeterminado)" bajo Comando a esto:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' -Verb RunAs  "

Hacer lo mismo en PowerShell en realidad necesitará tres líneas esta vez. Una para cada nueva clave y otra para establecer el valor "(Predeterminado)" para Comando. No olvides 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 with PowerShell (Admin) \ Command "(predeterminado)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & & Inicio-Proceso PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Además, preste especial atención a las diferencias entre la cadena que se está colocando a través de PowerShell y el valor real que está ingresando en el Registro. Particularmente, tenemos que envolver todo el asunto en comillas simples y duplicar las comillas simples internas para evitar errores en el análisis de comandos..

Ahora debería tener una nueva entrada en el menú contextual para los scripts de PowerShell, llamada "Ejecutar con PowerShell (Admin)".

La nueva opción generará dos instancias consecutivas de PowerShell. El primero es solo un iniciador para el segundo, que usa el Proceso de Inicio con el parámetro "-Verb RunAs" para solicitar la elevación para la nueva sesión. Desde allí, su script debería poder ejecutarse con privilegios de administrador después de hacer clic en el indicador de UAC.

Últimos retoques.

Hay solo un par de ajustes más para esto que pueden ayudar a hacer la vida un poco más fácil aún. Por un lado, ¿qué hay de deshacerse por completo de la función de Bloc de notas? Simplemente copie el valor "(Predeterminado)" de la tecla Comando debajo de Editar (abajo), en la misma ubicación debajo de Abrir.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

O bien, puede usar este bit de PowerShell (con Admin y HKCR, por supuesto):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(predeterminado) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe ""% 1 "'

Otra molestia menor es el hábito de la consola de desaparecer una vez que se completa un script. Cuando eso sucede, no tenemos ninguna oportunidad de revisar la salida del script en busca de errores u otra información útil. Esto puede solucionarse poniendo una pausa al final de cada uno de sus scripts, por supuesto. Alternativamente, podemos modificar los valores "(Predeterminado)" para que nuestras teclas de comando incluyan el parámetro "-NoExit". A continuación se muestran los valores modificados..

(Sin acceso de administrador)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

(Con acceso de administrador)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Verb RunAs "

Y, por supuesto, también le daremos aquellos en los comandos de PowerShell. Último recordatorio: Elevación y HKCR!

(No administrador)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(predeterminado) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned "" -file ""% 1 "'

(Administración)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run with PowerShell (Admin) \ Command "(predeterminado)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Tomándolo para dar una vuelta.

Para probar esto, usaremos una secuencia de comandos que puede mostrarnos la configuración de ExecutionPolicy en su lugar y si la secuencia de comandos se inició con los permisos del Administrador. La secuencia de comandos se llamará “MyScript.ps1” y se almacenará en “D: \ Script Lab” en nuestro sistema de muestra. El código está abajo, para referencia.

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Write-Output 'Running as Administrator!' else Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Usando la acción "Ejecutar con PowerShell":

Utilizando la acción "Ejecutar con PowerShell (Admin)", después de hacer clic a través de UAC:

Para demostrar la ExecutionPolicy en acción en el ámbito del Proceso, podemos hacer que Windows crea que el archivo proviene de Internet con este código de PowerShell:

Add-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Value "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier '

Afortunadamente, teníamos -NoExit habilitado. De lo contrario, ese error hubiera pasado, y no lo sabríamos.!

El Zone.Identifier se puede eliminar con esto:

Clear-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

Referencias útiles:

Ejecutando scripts de PowerShell desde un archivo por lotes - Blog de programación de Daniel Schroeder
Comprobando los permisos de administrador en PowerShell - ¡Hola, Scripting Guy! Blog