Adam DriscollQuesta è probabilmente una delle domande più frequenti su PowerShell Universal. Perché il mio script non funziona allo stesso modo in PowerShell Universal e in un prompt PowerShell? Questo articolo offre contesto e passaggi per identificare i problemi che possono verificarsi quando gli script vengono eseguiti nella piattaforma.
Versioni di PowerShell
Deve conoscere le versioni in gioco quando esegue script in PowerShell Universal. È facile selezionare versioni diverse di PowerShell, quindi si assicuri di eseguire lo script nella versione prevista.
Le versioni di PowerShell sono elencate nella pagina Platform > Environments. Quando aggiorna PowerShell 7, PowerShell Universal usa automaticamente quella nel percorso predefinito. È anche possibile installare versioni di PowerShell 7 affiancate e configurare PowerShell Universal per usarne più di una.
Un problema comune riguarda i moduli che non funzionano in modo nativo in PowerShell 7. In quel caso interviene Windows PowerShell Compatibility. Sembrerà funzionare come previsto, ma in background partono nuovi processi Windows PowerShell. Ogni runspace che usa il modulo Windows PowerShell nell’ambiente PowerShell 7 avvia un nuovo processo. Questo può ridurre notevolmente le prestazioni.
Ambiente integrato
L’ambiente integrato è una versione dell’SDK PowerShell 7 incorporata in PowerShell Universal. Non cambia quando aggiorna PowerShell sulla macchina host. Cambia solo quando una nuova versione di PowerShell Universal aggiorna la versione dell’SDK PowerShell.
L’ambiente integrato è veloce perché non deve avviare processi esterni né comunicare su un canale RPC. Lo svantaggio è che è un singolo punto di errore per tutti gli script, le API e le dashboard, perché condividono lo stesso spazio di processo. Può anche incontrare conflitti di assembly quando carica molti moduli che usano assembly .NET comuni.
Questo accade spesso con la libreria Newtonsoft.Json. Gli script che usano moduli integrati o nessun modulo sono ottimi candidati per l’ambiente integrato.
Autorizzazioni e privilegi
Eseguire uno script come utente locale su una macchina può essere molto diverso dall’eseguirlo in PowerShell Universal quando è ospitato come servizio o in IIS. Deve sapere dove sono installati i moduli, perché PowerShell Universal potrebbe non scoprirli nello stesso punto.
Inoltre, se ospita come servizio e il modulo deve interagire con il desktop (come Selenium), dovrà configurare il servizio con particolare attenzione.
IIS limita ulteriormente l’utente del pool di applicazioni riducendo i privilegi dell’account in esecuzione. Questo significa che accedere a determinate directory o elevare a un altro account può causare problemi anche se l’utente è amministratore. Un esempio: New-WebServiceProxy non funziona in IIS perché il cmdlet tenta di scrivere file C# e compilarli dal disco e il pool di applicazioni non ha quel privilegio.
Può usare la funzionalità Terminal di PowerShell Universal per esaminare l’ambiente attualmente configurato e vedere le differenze.
Host personalizzati
PowerShell Universal ha due host personalizzati. Il primo viene usato quando gli script vengono eseguiti come job. Questo host offre funzioni come l’attesa di feedback e l’output su vari stream. Il secondo viene usato per tutte le altre operazioni in PowerShell Universal. Non implementa funzioni di host personalizzate oltre alla registrazione.
Se dimentica parametri o chiede un feedback all’utente, con qualcosa come Read-Host, in un host che non lo supporta, riceverà errori. La pratica consigliata è evitare questo tipo di interazione in PowerShell Universal.
Stato dei runspace di breve durata
PowerShell Universal usa pool di runspace per la maggior parte delle funzionalità del sistema. Crea runspace quando servono e li rilascia quando non servono più. Dopo ogni esecuzione di una funzione, come un’API o un endpoint di dashboard, lo stato del runspace viene reimpostato.
Questo può influire sugli script che usano funzioni di PowerShell come sessioni o remoting. Non potrà usare sessioni tra chiamate di endpoint a meno che non attivi la funzione persistent runspace.
Processo di lunga durata
PowerShell Universal è progettato per restare in esecuzione a lungo. Periodicamente puliamo le risorse e ricicliamo i runspace dopo un numero di utilizzi o un intervallo di tempo. Alcuni moduli PowerShell non sono ben progettati per questo tipo di ambiente di esecuzione. Si aspettano di girare in un processo PowerShell che invoca uno script e poi termina.
Per aggirare il problema, può eseguire gli script come job in processi esterni, così tutte le risorse vengono pulite al termine dello script. Alcuni moduli come PowerCLI e dbatools hanno classi .NET statiche che possono mantenere stato e consumare memoria anche quando i runspace vengono rilasciati e viene eseguito il garbage collection .NET.
IIS può riciclare il processo di PowerShell Universal a intervalli, quando vengono raggiunti determinati limiti di risorse o quando il server non è in uso.
Gestione dei segreti
L’implementazione di gestione dei segreti di PowerShell Universal si basa sui moduli Microsoft SecretManagement. L’installazione predefinita include il modulo principale insieme a diversi moduli vault.
Tutti i vault inclusi per impostazione predefinita implementano meccanismi di archiviazione specifici dell’utente. Se cambia l’account utente del servizio PowerShell Universal, non potrà più accedere ai segreti. Questo significa anche che, se crea segreti nell’ambiente locale con il proprio utente, è probabile che PowerShell Universal non possa accedere a quei segreti.
Conclusione
Questo articolo dovrebbe averle dato il contesto per identificare i problemi nell’esecuzione di script in PowerShell Universal.
Pronto a iniziare a creare? Scarichi PowerShell Universal.