I profili in Windows PowerShell permettono di creare alias, variabili e funzioni personalizzate valide in ogni sessione aperta; in pratica un modo per estendere le potenzialità di base di PS.
Per poter caricare un profilo (che viene letto all'avvio di ogni sessione di PS), è necessario che il criterio di esecuzione lo permetta, ovvero non può essere settato a Restricted (che è bene ricordare essere l'impostazione di default all'installazione di PS).
Esistono quattro diversi profili che vengono caricati sequenzialmente all'avvio di una sessione di PS, che vanno ad influenzare differentemente utenti e shell:
- %windir%\system32\WindowsPowerShell\v1.0\profile.ps1
Questo profilo si applica a tutti gli utenti e a tutte le shell
- %windir%\system32\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps1
Questo profilo si applica a tutti gli utenti, ma solo alla shell Microsoft.PowerShell.
- %UserProfile%\Documenti\WindowsPowerShell\profile.ps1
Questo profilo si applica solo all'utente corrente, ma riguarda tutte le shell.
- %UserProfile%\Documenti\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Questo profilo si applica solo all'utente corrente e alla shell Microsoft.PowerShell.

Per creare un nuovo profilo utente ad esempio lanciamo il comando:
new-item -path $profile -itemtype file -force

$profile è una variabile che contiene il path al file del profilo personale. Volendo creare un altro dei restanti profili sarà necessario specificare il path completo.
A questo punto possiamo andarci a scrivere quello che desideriamo essere il nostro profilo caricato in automatico; ad esempio io ho nel mio profilo una funzione per cambiare il prompt, visto che quello di default (PS directory>) scritto in bianco non mi piace molto, primo perchè occupa 3 caratteri inutili (PS ) e poi perchè se lancio script con lunghe elaborazioni non vedo dove finisce l'esecuzione di un comando e inizia la successiva. La sezione di script in questione è la seguente:

function prompt
{
    Write-Host ("[" + $(get-location) +"]") -nonewline -foregroundcolor Red
    return " "
}

E si ottiene un prompt come da figura. E' importante ricordarsi che la funzione prompt deve ritornare una stringa, in caso contrario verrà utilizzato il prompt di default "PS> ". E' utile anche considerare che questa funzione viene valutata spesso, quindi un buon consiglio da tenere a mente è quello di non esagerare con la complessità.

Gli script sono estremamente potenti, purtroppo però la storia ci insegna che possono anche essere utilizzati per danneggiare un sistema. In PS esistono una serie di funzionalità di protezione, tra cui i criteri di esecuzione che determinano se gli script possono essere eseguiti ed eventualmente se devono essere firmati. Vedremo più avanti che questi criteri determinano anche la possibilità di caricare file di configurazione per la PS (ad esempio i profili).
Il criterio può assumere 4 valori:
- Restricted: è quello impostato quando installiamo la PS, non consente l'esecuzione di script né il caricamento di file di configurazione;
- AllSigned: consente l'esecuzione di script, ma questi devono essere firmati digitalmente (con certificato rilasciato da una CA riconosciuta), sia che siano scaricati da internet, sia che siano creati sul computer locale;
- RemoteSigned: consente l'esecuzione di script, che devono essere firmati digitalmente (con certificato rilasciato da una CA riconosciuta) se sono stati scaricati da internet, o dalla posta elettronica, o da software di messaggistica; possono invece venire eseguiti tranquillamente quelli creati sul computer locale;
- Unrestricted: permette l'esecuzione di script non firmati.

Se creiamo un semplice file helloworld.ps1 contenente la sola riga
Write-Output "Hello World"
e poi cerchiamo di eseguirlo, avremo il seguente errore:

Verifichiamo quindi il criterio di protezione tramite il cmdlet Get-ExecutionPolicy e verifichiamo che sia effettivamente Restricted. Modifichiamolo quindi con il cmdlet Set-ExecutionPolicy RemoteSigned (questa l'impostazione che uso io attualmete). Proviamo ora a rilanciare lo script e verifichiamone il corretto funzionamento.
Non è molto intuitivo ricordarselo, ma per lanciare gli script bisogna indicare il path di esecuzione (nel nostro caso il ./ prima del nome dello script); un modo facile per non dimenticarselo è utilizzare l'autocomplete attivato sul tasto tab, che ci completa la stringa digitata a mano (caratteristica molto utile a chi, come me, ha una memoria di fango!).

Powershell è la nuova shell (e decisamente anche linguaggio di script) su cui microsoft punta per riuscire ad ottenere un unico strumento di gestione delle reti. Tutte le nuove versioni dei prodotti server di Microsoft saranno fortemente basate su questo strumento, prima conosciuto con il nome di "Monad".
Dicevamo che Powershell è una shell; il suo "inventore" dice di aver tratto ispirazione e di aver migliorato le funzionalità dalle 3 grandi shell: quella di AS400, quella dei sistemi CMS e quelle linux come bash. In realtà è molto di più! Possiede builtin una serie di Cmdlets che sono le unità atomiche di PS, che eseguono una determinata azione; può contenere Funzioni, intese come blocchi di azioni atomiche che si possono riutilizzare; può anche eseguire Script, blocchi di codice che eseguono operazioni complesse.
Un aspetto interessante di PS è che non è necessario studiarsi un manuale per iniziare ad usarla. E' perfettamente compatibile con gli strumenti che già utilizziamo: cmd, vbs, js, wsh... quindi si può scaricare installare e iniziare ad usare.
Una caratteristica fondamentale è che si tratta di un sistema object-pipelined, in pratica si effettuano pipe di oggetti e non solo di stringhe; questo ad esempio permette di ereditare dal framework .NET, su cui PS è basato, Reflection ovvero la possibilità di ottenere informazioni sulla struttura dell'oggetto.
Spero a breve di poter compilare molti post su questo prodotto che mi piace molto, anche se lo conosco ancora troppo poco.