Come configurare Windows per lavorare con gli script di PowerShell in modo più semplice

Windows e PowerShell dispongono di funzionalità di sicurezza integrate e configurazioni predefinite per impedire agli utenti finali di avviare accidentalmente script durante le loro attività quotidiane. Tuttavia, se le tue attività quotidiane implicano normalmente la scrittura e l'esecuzione dei tuoi script PowerShell, questo può essere più fastidioso che vantaggioso. Qui ti mostreremo come aggirare queste funzionalità senza compromettere completamente la sicurezza.

Come e perché Windows e PowerShell impediscono l'esecuzione dello script.

PowerShell è in effetti la shell dei comandi e il linguaggio di scripting destinato a sostituire CMD e script batch su sistemi Windows. In quanto tale, uno script PowerShell può essere configurato per fare qualsiasi cosa tu possa fare manualmente dalla riga di comando. Ciò equivale a rendere praticamente possibile qualsiasi modifica sul tuo sistema, fino alle restrizioni sul tuo account utente. Quindi, se si potesse semplicemente fare doppio clic su uno script di PowerShell ed eseguirlo con i privilegi di amministratore completi, una semplice fodera come questa potrebbe davvero rovinare la giornata:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

NON eseguire il comando precedente!

Questo passa semplicemente attraverso il file system e cancella tutto ciò che può. È interessante notare che questo potrebbe non rendere il sistema inutilizzabile il più rapidamente possibile, anche quando viene eseguito da una sessione elevata. Ma se qualcuno ti chiama dopo aver eseguito questo script, perché improvvisamente non riescono a trovare i loro file o eseguire alcuni programmi, "spegnerlo e riaccenderlo" probabilmente li condurrà semplicemente a Ripristino all'avvio di Windows dove gli verrà detto che c'è nulla che possa essere fatto per risolvere il problema. Ciò che potrebbe essere peggio è, invece di ottenere uno script che semplicemente distrugge il loro file system, il tuo amico potrebbe essere indotto a eseguire uno che scarica e installa un keylogger o un servizio di accesso remoto. Quindi, invece di farti delle domande su Startup Repair, potrebbero finire per chiedere alla polizia alcune domande sulla frode bancaria!

Ormai dovrebbe essere ovvio il motivo per cui alcune cose sono necessarie per proteggere gli utenti finali da se stessi, per così dire. Ma gli utenti esperti, gli amministratori di sistema e altri fanatici sono generalmente (anche se ci sono eccezioni) un po 'più diffidenti nei confronti di queste minacce, sapendo come individuarle e evitarle facilmente, e vogliono solo continuare a portare a termine il loro lavoro. Per fare ciò, dovranno disabilitare o aggirare alcuni blocchi stradali:

PowerShell non consente l'esecuzione di script esterni per impostazione predefinita.
L'impostazione ExecutionPolicy in PowerShell impedisce l'esecuzione di script esterni per impostazione predefinita in tutte le versioni di Windows. In alcune versioni di Windows, l'impostazione predefinita non consente affatto l'esecuzione di script. Ti abbiamo mostrato come modificare questa impostazione in Come consentire l'esecuzione di script PowerShell su Windows 7, ma lo copriremo anche su alcuni livelli.
PowerShell non è associato all'estensione del file .PS1 per impostazione predefinita.
L'abbiamo portato inizialmente nella nostra serie PowerShell Geek School. Windows imposta l'azione predefinita per i file .PS1 per aprirli in Blocco note, anziché inviarli all'interprete dei comandi di PowerShell. Questo per impedire direttamente l'esecuzione accidentale di script dannosi quando vengono semplicemente fatti doppio clic.
Alcuni script PowerShell non funzioneranno senza le autorizzazioni di amministratore.
Anche con un account di livello Amministratore, è comunque necessario passare attraverso il Controllo dell'account utente (UAC) per eseguire determinate azioni. Per gli strumenti da riga di comando, questo può essere un po 'macchinoso per non dire altro. Non vogliamo disabilitare UAC, ma è ancora bello quando possiamo renderlo un po 'più facile da gestire.

Questi stessi problemi sono riportati in Come utilizzare un file batch per rendere gli script di PowerShell più facili da eseguire, in cui ti guidiamo attraverso la scrittura di un file batch per aggirarli temporaneamente. Ora, vi mostreremo come impostare il vostro sistema con una soluzione a più lungo termine. Ricorda che in genere non dovresti apportare queste modifiche a sistemi che non sono utilizzati esclusivamente da te, altrimenti, stai mettendo gli altri utenti a più alto rischio di incorrere negli stessi problemi che queste funzionalità hanno lo scopo di prevenire.

Modifica dell'associazione file .PS1.

Il primo, e forse il più importante, fastidio da risolvere è l'associazione di default per i file .PS1. Associare questi file a qualcosa di diverso da PowerShell.exe ha senso per prevenire l'esecuzione accidentale di script indesiderati. Ma, visto che PowerShell viene fornito con un ISE (Integrated Scripting Environment) appositamente progettato per la modifica degli script di PowerShell, perché dovremmo voler aprire i file .PS1 in Blocco note per impostazione predefinita? Anche se non sei pronto per passare completamente all'attivazione della funzionalità di doppio clic per eseguire, probabilmente vorrai modificare queste impostazioni.

È possibile modificare l'associazione di file .PS1 con qualsiasi programma desiderato con il pannello di controllo Programmi predefiniti, ma scavando direttamente nel Registro di sistema si otterrà un maggiore controllo sul modo esatto in cui i file verranno aperti. Ciò consente anche di impostare o modificare le opzioni aggiuntive disponibili nel menu di scelta rapida per i file .PS1. Non dimenticare di fare un backup del registro prima di farlo!

Le impostazioni del registro che controllano il modo in cui vengono aperti gli script di PowerShell sono archiviati nel seguente percorso:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Per esplorare queste impostazioni prima di cambiarle, dai un'occhiata a quella chiave e alle sue sottochiavi con Regedit. La chiave Shell dovrebbe avere solo un valore, "(Predefinito)", che è impostato su "Apri". Questo è un puntatore all'azione predefinita per fare doppio clic sul file, che vedremo nelle sottochiavi.

Espandi la chiave Shell e vedrai tre sottochiavi. Ognuna di queste rappresenta un'azione che è possibile eseguire e che è specifica per gli script di PowerShell.

È possibile espandere ciascuna chiave per esplorare i valori all'interno, ma sostanzialmente equivalgono alle seguenti impostazioni predefinite:

0 - Esegui con PowerShell. "Esegui con PowerShell" è in realtà il nome di un'opzione già presente nel menu di scelta rapida per gli script di PowerShell. Il testo viene semplicemente estratto da un'altra posizione anziché utilizzare il nome della chiave come gli altri. E non è ancora l'azione di doppio clic predefinita.
Modifica - Apri in PowerShell ISE. Questo ha molto più senso del Blocco note, ma è comunque necessario fare clic con il pulsante destro del mouse sul file .PS1 per farlo in modo predefinito.
Apri - Apri nel blocco note. Si noti che questo nome chiave è anche la stringa memorizzata nel valore "(Predefinito)" della chiave Shell. Ciò significa che fare doppio clic sul file lo "aprirà" e che l'azione è normalmente impostata per utilizzare Blocco note.

Se si desidera mantenere le stringhe di comando predefinite già disponibili, è sufficiente modificare il valore "(Predefinito)" nella chiave Shell in modo che corrisponda al nome della chiave che corrisponde a ciò che si desidera fare con un doppio clic. Questo può essere fatto facilmente da Regedit, oppure puoi usare le lezioni apprese dal nostro tutorial sull'esplorazione del registro con PowerShell (più un piccolo tweed PSDrive) per iniziare a creare uno script riutilizzabile che possa configurare i tuoi sistemi per te. I seguenti comandi devono essere eseguiti da una sessione PowerShell elevata, simile alla CMD in esecuzione come amministratore.

Per prima cosa, devi configurare un PSDrive per HKEY_CLASSES_ROOT poiché questo non è impostato per impostazione predefinita. Il comando per questo è:

Registro HKCR New-PSDrive HKEY_CLASSES_ROOT

Ora puoi navigare e modificare chiavi e valori di registro in HKEY_CLASSES_ROOT proprio come faresti nel normale HKDU e HKLM PSDrives.

Per configurare il doppio clic per avviare direttamente gli script di PowerShell:

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

Per configurare il doppio clic per aprire gli script di PowerShell in PowerShell ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(predefinito) "Modifica"

Per ripristinare il valore predefinito (imposta il doppio clic per aprire gli script di PowerShell nel Blocco note):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Predefinito) "Apri"

Questo è solo il fondamento della modifica dell'azione di doppio clic predefinita. Andremo più in dettaglio sulla personalizzazione di come vengono gestiti gli script di PowerShell quando vengono aperti in PowerShell da Explorer nella prossima sezione. Tenere presente che l'ambito impedisce a PSDrives di persistere tra le sessioni. Quindi, probabilmente vorrai includere la riga New-PSDrive all'inizio di qualsiasi script di configurazione che hai creato per questo scopo, o aggiungerlo al tuo profilo PowerShell. Altrimenti, dovrai eseguire quel bit manualmente prima di provare a fare le modifiche in questo modo.

Modifica dell'impostazione ExecutionPolicy di PowerShell.

ExecutionPolicy di PowerShell è un altro livello di protezione contro l'esecuzione di script dannosi. Ci sono più opzioni per questo, e un paio di modi diversi che può essere impostato. Dal più al meno sicuro, le opzioni disponibili sono:

Limitato: non è consentito l'esecuzione di script. (Impostazione predefinita per la maggior parte dei sistemi). Ciò impedirà anche l'esecuzione dello script del profilo.
AllSigned: tutti gli script devono essere firmati digitalmente da un editore attendibile per essere eseguiti senza chiedere conferma all'utente. Gli script firmati da editori definiti in modo esplicito come non attendibili o script non firmati digitalmente non verranno eseguiti. PowerShell chiederà all'utente di confermare se uno script è firmato da un editore non ancora definito attendibile o non affidabile. Se non hai firmato digitalmente lo script del tuo profilo e hai fiducia in quella firma, non sarà possibile eseguirlo. Fai attenzione a quali editori ti fidi, dato che puoi ancora eseguire script dannosi se ti fidi di quello sbagliato.
RemoteSigned: per gli script scaricati da Internet, questo è effettivamente lo stesso di "AllSigned". Tuttavia, gli script creati localmente o importati da fonti diverse da Internet possono essere eseguiti senza alcuna richiesta di conferma. Qui, dovrai anche prestare attenzione a quali firme digitali ti fidi, ma anche a prestare maggiore attenzione agli script non firmati che scegli di eseguire. Questo è il livello di sicurezza più alto in base al quale è possibile avere uno script di profilo funzionante senza doverlo firmare digitalmente.
Senza restrizioni: tutti gli script possono essere eseguiti, ma per gli script da Internet è richiesta una richiesta di conferma. Da questo momento in poi, spetta esclusivamente a te evitare di eseguire script non affidabili.
Bypass: tutto funziona senza avviso. Stai attento con questo.
Non definito: nessuna politica è definita nell'ambito corrente. Viene utilizzato per consentire il fall-back alle politiche definite in ambiti inferiori (maggiori dettagli di seguito) o ai valori predefiniti del sistema operativo.

Come suggerito dalla descrizione di Non definito, le politiche precedenti possono essere impostate in uno o più di diversi ambiti. È possibile utilizzare Get-ExecutionPolicy, con il parametro -List, per vedere tutti gli ambiti e la loro configurazione corrente.

Gli ambiti sono elencati in ordine di precedenza, con l'ambito definito più in alto che ignora tutti gli altri. Se non vengono definite politiche, il sistema torna alle impostazioni predefinite (nella maggior parte dei casi, è limitato).

MachinePolicy rappresenta un criterio di gruppo in vigore a livello di computer. Questo è generalmente applicato solo in un dominio, ma può essere fatto anche localmente.
UserPolicy rappresenta un criterio di gruppo in vigore per l'utente. Questo è in genere utilizzato solo negli ambienti aziendali.
Il processo è un ambito specifico per questa istanza di PowerShell. Le modifiche al criterio in questo ambito non influiranno su altri processi PowerShell in esecuzione e saranno inefficaci dopo il termine di questa sessione. Questo può essere configurato dal parametro -ExecutionPolicy quando viene avviato PowerShell, oppure può essere impostato con la corretta sintassi Set-ExecutionPolicy dall'interno della sessione.
CurrentUser è un ambito configurato nel registro locale e si applica all'account utente utilizzato per avviare PowerShell. Questo ambito può essere modificato con Set-ExecutionPolicy.
LocalMachine è un ambito configurato nel registro locale e applicabile a tutti gli utenti del sistema. Questo è l'ambito predefinito che viene modificato se Set-ExecutionPolicy viene eseguito senza il parametro -Scope. Poiché si applica a tutti gli utenti del sistema, può essere modificato solo da una sessione elevata.

Poiché questo articolo riguarda principalmente la sicurezza per facilitare l'usabilità, siamo solo preoccupati per i tre ambiti inferiori. Le impostazioni di MachinePolicy e UserPolicy sono davvero utili solo se si desidera applicare una politica restrittiva che non sia semplicemente ignorata. Mantenendo le nostre modifiche al livello di processo o al di sotto, possiamo facilmente utilizzare qualsiasi impostazione di politica che riteniamo appropriata per una data situazione in qualsiasi momento.

Per mantenere un certo equilibrio tra sicurezza e usabilità, la politica mostrata nello screenshot è probabilmente la migliore. L'impostazione del criterio LocalMachine su Restricted generalmente impedisce l'esecuzione di script da parte di chiunque tranne te. Naturalmente, questo può essere aggirato dagli utenti che sanno cosa stanno facendo senza troppi sforzi. Ma dovrebbe impedire agli utenti non esperti di tecnologia di attivare accidentalmente qualcosa di catastrofico in PowerShell. Avere il CurrentUser (cioè tu) impostato come Senza restrizioni consente di eseguire manualmente gli script dalla riga di comando come preferisci, ma mantiene un avvertimento di cautela per gli script scaricati da Internet. L'impostazione RemoteSigned a livello di processo dovrebbe essere eseguita in un collegamento a PowerShell.exe o (come faremo di seguito) nei valori del Registro di sistema che controllano il comportamento degli script di PowerShell. Ciò consentirà una facile funzionalità double-click-to-run per tutti gli script scritti, mettendo al contempo una barriera più forte contro l'esecuzione involontaria di script (potenzialmente dannosi) da fonti esterne. Vogliamo farlo qui poiché è molto più semplice accidentalmente fare doppio clic su uno script di quanto non lo sia normalmente per chiamarlo manualmente da una sessione interattiva.

Per impostare i criteri CurrentUser e LocalMachine come nella schermata sopra, eseguire i seguenti comandi da una sessione PowerShell con privilegi elevati:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Per applicare il criterio RemoteSigned sugli script eseguiti da Explorer, dovremo modificare un valore all'interno di una delle chiavi del Registro di sistema che stavamo guardando in precedenza. Ciò è particolarmente importante perché, a seconda della versione di PowerShell o di Windows, la configurazione predefinita potrebbe ignorare tutte le impostazioni di ExecutionPolicy ad eccezione di AllSigned. Per vedere qual è la configurazione corrente per il tuo computer, puoi eseguire questo comando (assicurandoti che HKCR PSDrive sia mappato per primo):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Select-Object '(Default)'

La tua configurazione di default sarà probabilmente una delle seguenti due stringhe, o qualcosa di abbastanza simile:

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

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

(Visto su 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 Bypass processo; & '% 1 '"

Il primo non è male, poiché tutto ciò che fa è eseguire lo script con le impostazioni ExecutionPolicy esistenti. Potrebbe essere migliorato, imponendo restrizioni più stringenti per un'azione più incline agli incidenti, ma questo non era originariamente previsto per essere attivato con un doppio clic e il criterio predefinito di solito è Restrito dopo tutto. La seconda opzione, tuttavia, è un bypass completo di qualsiasi ExecutionPolicy che è probabile che sia in atto, anche limitato. Poiché il bypass verrà applicato nell'ambito del processo, influisce solo sulle sessioni avviate quando gli script vengono eseguiti da Explorer. Tuttavia, questo significa che potresti finire per lanciare script che altrimenti ti aspetteresti (e vorresti) che la tua politica proibisca.

Per impostare Process-level ExecutionPolicy per gli script avviati da Explorer, in linea con lo screenshot precedente, è necessario modificare lo stesso valore di registro appena interrogato. Puoi farlo manualmente in Regedit, cambiandolo in questo:

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

Se lo preferisci, puoi anche modificare le impostazioni da PowerShell. Ricordarsi di fare questo da una sessione elevata, con l'HKCR PSDrive mappato.

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

Esegui script PowerShell come amministratore.

Così come è una cattiva idea disabilitare completamente il controllo dell'account utente, è anche una cattiva pratica di sicurezza eseguire script o programmi con privilegi elevati, a meno che non siano effettivamente necessari per eseguire operazioni che richiedono l'accesso come amministratore. Pertanto, non è consigliabile creare il prompt UAC nell'azione predefinita per gli script di PowerShell. Tuttavia, possiamo aggiungere una nuova opzione del menu contestuale per permetterci di eseguire facilmente gli script in sessioni elevate quando è necessario. Questo è simile al metodo utilizzato per aggiungere "Apri con Blocco note" al menu di scelta rapida di tutti i file - ma qui andremo solo a scegliere gli script di PowerShell. Riporteremo anche alcune tecniche utilizzate nell'articolo precedente, in cui abbiamo utilizzato un file batch anziché gli hack del Registro di sistema per avviare il nostro script PowerShell.

Per fare ciò in Regedit, torna nella chiave Shell, a:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

In là, crea una nuova sottochiave. Chiamalo "Esegui con PowerShell (amministratore)". Al di sotto di questo, crea un'altra sottochiave chiamata "Comando". Quindi, imposta il valore "(predefinito)" sotto Comando a questo:

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

Fare lo stesso in PowerShell avrà effettivamente bisogno di tre linee questa volta. Uno per ogni nuova chiave e uno per impostare il valore "(Predefinito)" per Comando. Non dimenticare l'elevazione e la mappatura HKCR.

Nuovo elemento 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Esegui con PowerShell (Admin)' Nuovo elemento 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Esegui con PowerShell (amministratore) \ Comando' Set-ItemProperty ' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Esegui con PowerShell (Admin) \ Command "(Predefinito)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Inoltre, prestate molta attenzione alle differenze tra la stringa che viene inserita in PowerShell e il valore effettivo che entra nel Registro. In particolare, dobbiamo racchiudere il tutto nelle virgolette singole e raddoppiare le virgolette interne, per evitare errori nell'analisi dei comandi.

Ora dovresti avere una nuova voce del menu contestuale per gli script di PowerShell, chiamata "Esegui con PowerShell (Admin)".

La nuova opzione genererà due istanze PowerShell consecutive. Il primo è solo un launcher per il secondo, che utilizza Start-Process con il parametro "-Verb RunAs" per richiedere l'elevazione per la nuova sessione. Da lì, lo script dovrebbe essere in grado di essere eseguito con i privilegi di amministratore dopo aver fatto clic sul prompt UAC.

Ritocchi finali.

Ci sono solo un paio di modifiche a questo che possono aiutare a rendere la vita un po 'più facile ancora. Per uno, che ne pensi di eliminare completamente la funzione Blocco note? Basta copiare il valore "(Predefinito)" dal tasto Comando sotto Modifica (sotto), nella stessa posizione sotto Apri.

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

Oppure, puoi utilizzare questo bit di PowerShell (con Admin e HKCR, ovviamente):

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

Un altro fastidio minore è l'abitudine della console di scomparire una volta che una sceneggiatura è completa. Quando ciò accade, non abbiamo alcuna possibilità di rivedere l'output dello script per errori o altre informazioni utili. Questo può essere risolto mettendo una pausa alla fine di ciascuno dei tuoi script, ovviamente. In alternativa, possiamo modificare i valori "(Default)" per le nostre chiavi di comando per includere il parametro "-NoExit". Di seguito sono riportati i valori modificati.

(Senza accesso amministratore)

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

(Con accesso amministratore)

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

E naturalmente, ti daremo anche quelli con comandi PowerShell. Ultimo promemoria: Elevation & HKCR!

(Non-Admin)

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

(Admin)

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

Prenderlo per un giro.

Per verificarlo, utilizzeremo uno script che può mostrarci le impostazioni di ExecutionPolicy e se lo script è stato avviato con autorizzazioni di amministratore. Lo script sarà chiamato "MyScript.ps1" e verrà memorizzato in "D: \ Script Lab" sul nostro sistema di esempio. Il codice è sotto, per riferimento.

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

Utilizzando l'azione "Esegui con PowerShell":

Utilizzando l'azione "Esegui con PowerShell (Admin)", dopo aver fatto clic su UAC:

Per dimostrare che ExecutionPolicy è in azione nell'ambito del processo, possiamo fare in modo che Windows pensi che il file provenga da Internet con questo bit di codice PowerShell:

Aggiungi-Contenuto -Path 'D: \ Script Lab \ MyScript.ps1' -Valore "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier '

Fortunatamente, avevamo -Non uscire abilitato. Altrimenti, quell'errore sarebbe stato appena accennato, e non avremmo saputo!

Zone.Identifier può essere rimosso con questo:

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

Riferimenti utili:

Esecuzione di script PowerShell da un file batch: il Blog di programmazione di Daniel Schroeder
Verifica delle autorizzazioni di amministratore in PowerShell - Hey, Scripting Guy! blog