Per diversi motivi, per lo più legati alla sicurezza, gli script di PowerShell non sono altrettanto facilmente trasferibili e utilizzabili come script batch. Tuttavia, possiamo raggruppare uno script batch con i nostri script PowerShell per ovviare a questi problemi. Qui, ti mostreremo alcune di quelle aree problematiche e come creare uno script batch per aggirarle.
A meno che il sistema di destinazione non sia stato preconfigurato per consentire l'esecuzione di script arbitrari, con i privilegi richiesti e utilizzando le giuste impostazioni, è probabile che si verifichino dei problemi quando si tenta di farlo.
Iniziamo affrontando il primo problema: le associazioni di file .PS1. Non è possibile fare doppio clic per eseguire i file .PS1, ma è possibile eseguire un file .BAT in questo modo. Quindi, scriveremo un file batch per chiamare lo script PowerShell dalla riga di comando per noi.
Quindi non dobbiamo riscrivere il file batch per ogni script, o ogni volta che spostiamo uno script, utilizzerà una variabile autoreferenziale per creare il percorso del file per lo script PowerShell. Per fare in modo che funzioni, il file batch dovrà essere collocato nella stessa cartella dello script PowerShell e avere lo stesso nome file. Quindi, se lo script PowerShell si chiama "MyScript.ps1", ti consigliamo di assegnare un nome al file batch "MyScript.bat" e assicurarti che si trovi nella stessa cartella. Quindi, inserisci queste righe nello script batch:
@ECHO OFF PowerShell.exe -Command "& '% ~ dpn0.ps1'" PAUSE
Se non fosse per le altre restrizioni di sicurezza in atto, sarebbe davvero essere tutto ciò che serve per eseguire uno script PowerShell da un file batch. In effetti, la prima e l'ultima riga sono principalmente solo una questione di preferenza - è la seconda linea che sta davvero facendo il lavoro. Ecco la descrizione:
@ECHO OFF disattiva il comando eco. Ciò mantiene solo gli altri comandi da mostrare sullo schermo quando viene eseguito il file batch. Questa linea è nascosta dall'uso del simbolo (@) davanti ad essa.
PowerShell.exe -Command "& '% ~ dpn0.ps1'" esegue effettivamente lo script PowerShell. PowerShell.exe può ovviamente essere chiamato da qualsiasi finestra CMD o file batch per avviare PowerShell su una console nuda come al solito. Puoi anche usarlo per eseguire comandi direttamente da un file batch, includendo il parametro -Command e gli argomenti appropriati. Il modo in cui questo viene utilizzato per indirizzare il nostro file .PS1 è con la variabile% ~ dpn0 speciale. Eseguito da un file batch,% ~ dpn0 valuta la lettera dell'unità, il percorso della cartella e il nome del file (senza estensione) del file batch. Poiché il file batch e lo script PowerShell si troveranno nella stessa cartella e avranno lo stesso nome,% ~ dpn0.ps1 verrà convertito nel percorso file completo dello script PowerShell.
PAUSE interrompe l'esecuzione del batch e attende l'input dell'utente. In genere è utile avere alla fine dei file batch, in modo da avere la possibilità di rivedere qualsiasi output di comando prima che la finestra scompaia. Mentre testiamo ogni fase, l'utilità di ciò diventerà più ovvia.
Quindi, il file batch di base è impostato. A scopo dimostrativo, questo file viene salvato come "D: Script Lab MyScript.bat" e c'è un "MyScript.ps1" nella stessa cartella. Vediamo cosa succede quando facciamo doppio clic su MyScript.bat.
Ovviamente lo script di PowerShell non è stato eseguito, ma c'è da aspettarselo, dopotutto abbiamo affrontato solo il primo dei nostri quattro problemi. Tuttavia, qui sono mostrati alcuni bit importanti:
Il profilo, in questo caso, è un semplice script a riga singola usato per questa dimostrazione per generare output ogni volta che il profilo è attivo. Puoi anche personalizzare il tuo profilo PowerShell per fare questo, se vuoi testare questi script tu stesso. Aggiungi semplicemente la seguente riga allo script del tuo profilo:
Scrivi-Output 'Profilo PowerShell personalizzato in effetto!'
La ExecutionPolicy sul sistema di test qui è impostata su RemoteSigned. Ciò consente l'esecuzione di script creati localmente (come lo script del profilo), mentre blocchi gli script da fonti esterne a meno che non siano firmati da un'autorità attendibile. A scopo dimostrativo, è stato utilizzato il seguente comando per contrassegnare MyScript.ps1 come proveniente da un'origine esterna:
Aggiungi contenuto -Path 'D: Script Lab MyScript.ps1' -Valore "[ZoneTransfer] 'nZoneId = 3 "-Stream" Zone.Identifier "
Imposta il flusso di dati alternativo di Zone.Identifier su MyScript.ps1 in modo che Windows pensi che il file provenga da Internet. Può essere facilmente invertito con il seguente comando:
Cancella-Contenuto -Path 'D: Script Lab MyScript.ps1' -Stream 'Zone.Identifier'
Come ottenere attorno all'impostazione ExecutionPolicy, da CMD o da uno script batch, è in realtà piuttosto semplice. Modifichiamo semplicemente la seconda riga dello script per aggiungere un altro parametro al comando PowerShell.exe.
PowerShell.exe -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"
Il parametro -ExecutionPolicy può essere utilizzato per modificare la ExecutionPolicy che viene utilizzata quando si genera una nuova sessione di PowerShell. Ciò non persisterà oltre quella sessione, quindi possiamo eseguire PowerShell in questo modo ogni volta che è necessario senza indebolire la postura di sicurezza generale del sistema. Ora che l'abbiamo risolto, diamo un altro risultato:
Ora che lo script è stato eseguito correttamente, possiamo vedere cosa fa realmente. Ci fa sapere che stiamo eseguendo la sceneggiatura come utente limitato. Lo script è infatti gestito da un account con autorizzazioni di amministratore, ma il controllo dell'account utente sta intralciando. Sebbene i dettagli su come lo script sta verificando l'accesso come amministratore non rientrano nell'ambito di questo articolo, ecco il codice che viene utilizzato per la dimostrazione:
if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) {Write-Output 'Running as Administrator!'} Else {Write-Output 'Running Limited!'} Pause
Noterai anche che ora ci sono due operazioni di "Pausa" nell'output dello script: uno dallo script PowerShell e uno dal file batch. Il motivo per questo sarà più evidente nel passaggio successivo.
Se il tuo script non esegue alcun comando che richiede elevazione, sei sicuro che non avrai per preoccuparti che i profili personalizzati di chiunque si intromettano, puoi saltare il resto di questo. Se stai eseguendo alcuni cmdlet a livello di amministratore, avrai bisogno di questo pezzo.
Sfortunatamente, non c'è modo di attivare UAC per l'elevazione da un file batch o da una sessione CMD. Tuttavia, PowerShell ci consente di farlo con Start-Process. Se utilizzato con "-Verb RunAs" nei suoi argomenti, Start-Process tenterà di avviare un'applicazione con le autorizzazioni di amministratore. Se la sessione di PowerShell non è già elevata, verrà attivato un prompt UAC. Per utilizzare questo dal file batch per l'avvio del nostro script, finiremo per generare due processi PowerShell: uno per avviare Start-Process e un altro, avviato da Start-Process, per eseguire lo script. La seconda riga del file batch deve essere modificata in questo modo:
PowerShell.exe -Command "& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "' - Verb RunAs} "
Quando viene eseguito il file batch, la prima riga di output che vedremo proviene dallo script del profilo PowerShell. Quindi, quando Start-Process tenta di avviare MyScript.ps1.
verrà avviato un prompt UAC. Dopo aver fatto clic sul prompt UAC, verrà generata una nuova istanza di PowerShell. Perché questa è una nuova istanza, ovviamente, vedremo di nuovo la notifica del profilo. Quindi, MyScript.ps1 viene eseguito e vediamo che siamo davvero in una sessione elevata.
E c'è anche il motivo per cui abbiamo due pause qui. Se non fosse per quello nello script di PowerShell, non vedremmo mai l'output dello script: la finestra di PowerShell si aprirà e scomparirà non appena viene eseguito lo script. E senza la pausa nel file batch, non saremmo in grado di vedere se ci sono stati errori durante l'avvio di PowerShell.
Liberiamoci da quello sgradevole avviso del profilo personalizzato ora, dobbiamo? Qui, non è nemmeno una seccatura, ma se il profilo PowerShell di un utente cambia le impostazioni, le variabili o le funzioni predefinite in modi che potresti non aver previsto con il tuo script, possono essere davvero fastidiosi. È molto più semplice eseguire il tuo script senza il profilo in modo da non doverti preoccupare di questo. Per fare ciò, abbiamo solo bisogno di cambiare la seconda riga del file batch ancora una volta:
PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "'-Verb RunAs}"
L'aggiunta del parametro -NoProfile a entrambe le istanze di PowerShell avviate dallo script significa che lo script del profilo dell'utente verrà completamente ignorato in entrambi i passaggi e il nostro script PowerShell funzionerà in un ambiente predefinito abbastanza prevedibile. Qui, puoi vedere che non c'è nessun avviso di profilo personalizzato in nessuna delle shell generate.
Se non hai bisogno dei diritti di amministratore nello script PowerShell e hai saltato il Passaggio 3, puoi fare a meno della seconda istanza di PowerShell e la seconda riga del file batch dovrebbe avere il seguente aspetto:
PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"
L'output sarà simile a questo:
( Ovviamente, per gli script non-Administrator, puoi fare a meno di una pausa di fine script nello script PowerShell anche da questo momento, poiché tutto viene catturato nella stessa finestra della console e verrà trattenuto dalla pausa alla fine del file batch.
A seconda che siano necessarie o meno le autorizzazioni di amministratore per lo script PowerShell (e in realtà non dovresti richiederli se non lo fai) il file batch finale dovrebbe apparire come uno dei due seguenti.
Senza accesso amministratore:
@ECHO OFF PowerShell.exe -NoProfile -ExecutionPoli cy Bypass -Command "& '% ~ dpn0.ps1'" PAUSE
Con accesso amministratore:
@ECHO OFF PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile - ExecutionPolicy Bypass -File "% ~ dpn0.ps1 " '-Verb RunAs} "PAUSE
Ricordarsi di mettere il file batch nella stessa cartella dello script PowerShell per il quale si desidera utilizzarlo e dargli lo stesso nome . Quindi, indipendentemente dal sistema in cui vengono portati i file, sarete in grado di eseguire il vostro script PowerShell senza dover perdere tempo con nessuna delle impostazioni di sicurezza del sistema. È possibile eseguire tali modifiche manualmente ogni volta, ma questo ti evita i problemi e non dovrai preoccuparti di ripristinare le modifiche in un secondo momento.
Riferimenti:
3 trucchi Gmail per ridurre lo spam e organizzare l'email
Anche se Gmail è ottimo per filtrare lo spam, continuo a ricevere un sacco di posta indesiderata da fonti di spam non tradizionali come le iscrizioni nei negozi di mattoni e malta o le registrazioni in un ufficio di medici. Questi di solito non sono spam nel senso tradizionale, ma se continui a ricevere le e-mail regolarmente, può essere abbastanza fastidioso.
Come modificare il browser Web predefinito e il client di posta elettronica su un Mac
La modifica dell'applicazione predefinita per la maggior parte dei file in OS X è semplice. OS X consente inoltre di scegliere il browser Web predefinito e il client di posta elettronica, ma queste opzioni sono nascoste in un luogo che non ci si potrebbe aspettare. Alcuni browser e client di posta elettronica potrebbero offrire automaticamente il valore predefinito al momento del lancio, ma se non lo fanno, o se vuoi cambiarlo in seguito, dovrai trovare le impostazioni di OS X per questi.