- WMI e i cmdlet CIM di PowerShell consentono di interrogare e modificare in modo efficiente le informazioni di gestione locali e remote.
- Le sessioni Cim con WSMan o DCOM facilitano l'accesso sicuro e compatibile ad apparecchiature di rete moderne e meno recenti.
- L'utilizzo di funzioni avanzate, moduli, processi e DSC trasforma PowerShell in un linguaggio completo per l'automazione dell'infrastruttura.
- PowerShell integra la gestione locale, remota, di Azure e di Microsoft 365 in un unico ambiente, riducendo le attività manuali ripetitive.
Se lavori nell'amministrazione di sistemi Windows, prima o poi ti imbatterai in PowerShell, WMI e automazione avanzata . Non si tratta solo di saper eseguire alcuni comandi: quando gestisci decine o centinaia di server, hai bisogno di un approccio serio, strutturato e sicuro per raccogliere informazioni, applicare modifiche e ripetere attività senza impazzire... o combinare guai.
Nelle righe seguenti, esploreremo, con calma ma in modo approfondito, come sfruttare WMI, CIM e la comunicazione remota tramite PowerShell per automatizzare qualsiasi operazione, dalle semplici query agli scenari infrastrutturali più complessi. Vedremo anche come tutto ciò si integri con i moduli, le attività in background, Azure, Microsoft 365 e alcune funzionalità avanzate che fanno davvero la differenza nel lavoro quotidiano di un amministratore di sistema.
Miglioramenti di PowerShell e panoramica dell'automazione avanzata
Windows PowerShell si è evoluto notevolmente dalle sue prime versioni, e gran parte di questa evoluzione è avvenuta con Windows Server 2012, dove la comunicazione remota è stata migliorata, i cmdlet disponibili sono stati ampliati e funzionalità come il debug, i processi in background e gli endpoint con restrizioni sono state semplificate per migliorare la sicurezza.
Uno dei principi fondamentali di questo ambiente è la possibilità per gli amministratori di creare comportamenti simili ai cmdlet senza dover ricorrere a una programmazione complessa , sfruttando funzionalità avanzate, moduli riutilizzabili e un sistema di aiuto completo. Ciò significa che, anziché affidarsi a strumenti grafici eterogenei, è possibile creare un insieme coerente di script e moduli che automatizzano i processi di gestione di server, reti, Active Directory, Azure o Microsoft 365.
Nel campo dell'automazione avanzata, spiccano funzionalità come i job per l'esecuzione asincrona di attività, i workflow, l'amministrazione basata sulla configurazione con PowerShell DSC e opzioni di sicurezza come JEA (Just Enough Administration) o PowerShell Web Access, che consentono un controllo dettagliato su ciò che ogni persona può fare e da dove.
Questo intero ecosistema si integra particolarmente bene con WMI e CIM, poiché le informazioni di gestione esposte dal sistema operativo (hardware, servizi, processi , configurazione di rete, software installato, ecc.) diventano un insieme di oggetti che è possibile interrogare, filtrare e modificare utilizzando comandi PowerShell progettati per l'automazione di massa.
WMI e CIM: concetti chiave e differenze pratiche
Windows Management Instrumentation, meglio conosciuto come WMI, è una tecnologia indipendente da PowerShell presente in Windows da anni. Espone un archivio di informazioni di gestione relative al sistema operativo, all'hardware e a numerose applicazioni. Sebbene non dipenda da PowerShell, quest'ultimo lo sfrutta ampiamente per automatizzare le attività.
Il naturale successore di WMI nell'ecosistema PowerShell sono i cmdlet CIM (Common Information Model) , introdotti con PowerShell 3.0. Questi cmdlet sono raggruppati nel modulo CimCmdlets e includono comandi come Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance e Remove-CimInstance, tra gli altri.
Nelle versioni precedenti di Windows PowerShell, come Windows 10 PowerShell 5.1 o Windows 11 PowerShell, è ancora possibile trovare i cmdlet WMI classici (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Tuttavia, questi cmdlet sono deprecati e non sono più inclusi in PowerShell 6 e versioni successive, quindi sono utili solo per la manutenzione di script legacy o per la revisione di codice obsoleto.
Quando si parla di "interrogare WMI con i cmdlet CIM", non si tratta di una contraddizione: i cmdlet CIM accedono comunque alle informazioni WMI , ma lo fanno utilizzando protocolli più moderni come WSMan e un'API più coerente. In termini pratici, per i nuovi sviluppi, è consigliabile concentrarsi su CIM e prendere in considerazione i cmdlet WMI solo quando è necessario migrare o comprendere script legacy.
Storicamente, molti amministratori utilizzavano VBScript con il linguaggio di query WQL per interrogare WMI, ad esempio, connettendosi allo spazio dei nomi root\CIMV2 e interrogando classi come Win32_BIOS. La stessa query WQL può essere riutilizzata oggi con Get-CimInstance passando il parametro -Query, il che semplifica notevolmente la transizione da VBScript a PowerShell senza dover riscrivere la logica da zero.
Utilizzo pratico di Get-CimInstance e query efficienti
Per le attività quotidiane, il modo più naturale per interrogare WMI con PowerShell è utilizzare Get-CimInstance con il parametro -ClassName , anziché scrivere query WQL complete. Ad esempio, per ottenere informazioni sul BIOS, è possibile utilizzare Get-CimInstance -ClassName Win32_BIOS e si riceverà un oggetto con proprietà come Manufacturer, Name, SerialNumber o SMBIOSBIOSVersion.
Poiché in PowerShell tutto è un oggetto, è molto facile filtrare e selezionare solo ciò che serve . Se si è interessati solo al numero di serie, è possibile reindirizzare l'output a `Select-Object -Property SerialNumber` oppure utilizzare `Select-Object -ExpandProperty SerialNumber` per ottenere una semplice stringa anziché un oggetto con una proprietà. Un'altra opzione comune è utilizzare la sintassi con il punto (`Get-CimInstance ...`).SerialNumber` per accedere direttamente al valore.
È importante notare che, per impostazione predefinita, le query WMI restituiscono più proprietà di quelle effettivamente utilizzate . Su una macchina locale, questo di solito non crea problemi, ma quando si iniziano a interrogare molte macchine remote, ciò si traduce in tempi di elaborazione aggiuntivi e traffico di rete non necessario. È qui che entra in gioco il parametro `-Property` di `Get-CimInstance`, che consente di limitare le proprietà recuperate dall'origine.
Specificando, ad esempio, -Property SerialNumber, si riduce la quantità di dati trasferiti, rendendo la query più veloce ed efficiente, soprattutto su larga scala . Questa mentalità del "chiedere solo ciò di cui si ha bisogno" è fondamentale quando si progettano script di inventario o di audit che vengono eseguiti su decine o centinaia di macchine.
In sintesi, Get-CimInstance offre un ottimo equilibrio tra semplicità (un solo comando da riga di comando) e flessibilità , sia che si lavori con classi concrete, query WQL legacy o proprietà specifiche che si desidera ottimizzare per il recupero dei dati.
Consulenze a distanza con CIM, sessioni e protocolli WSMan/DCOM
Quando ci si allontana dal proprio computer locale per accedere a macchine remote, entrano in gioco diversi fattori: permessi, protocollo di comunicazione e prestazioni . Sebbene molti considerino PowerShell "pericoloso", la verità è che non concede alcun privilegio aggiuntivo: si hanno esattamente gli stessi permessi dell'interfaccia grafica o di qualsiasi altro strumento, né più né meno.
Se si tenta di eseguire `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` senza privilegi sufficienti su quella macchina, verrà visualizzato un errore "Accesso negato" . Questo non è dovuto a un errore di PowerShell, ma semplicemente al fatto che l'utente con cui si esegue la sessione non dispone dei diritti per accedere a tali informazioni in WMI. È possibile aprire una console come amministratore di dominio, ovviamente, ma ciò significa che qualsiasi comando verrà eseguito con tali privilegi, il che rappresenta un rischio inutile in molti ambienti.
Si raccomanda di applicare il principio del minimo privilegio ed elevare i privilegi solo quando necessario . Nei cmdlet che supportano il parametro -Credential, è possibile specificare credenziali alternative solo per il comando in questione. Get-CimInstance, tuttavia, non accetta direttamente -Credential, ed è qui che CimSessions si rivela una soluzione elegante.
Una CimSession è una connessione persistente a un computer remoto che è possibile creare con New-CimSession, passando il nome del computer e le credenziali (ad esempio, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Questa sessione viene memorizzata in una variabile, ad esempio $CimSession, e quindi riutilizzata con Get-CimInstance utilizzando il parametro -CimSession anziché -ComputerName, consentendo di consolidare più query in un'unica connessione.
Oltre al requisito delle credenziali, Get-CimInstance utilizza per impostazione predefinita il protocollo WSMan (basato su WinRM) . Ciò significa che il computer remoto deve avere la versione dello stack WSMan 3.0 o superiore, in genere presente in PowerShell 3.0 e versioni successive. È possibile verificare la versione dello stack WSMan su un computer con `Test-WSMan -ComputerName RemoteComputer` e accertarsi che il valore "Stack" sia 3.0 o superiore per poter utilizzare questo metodo di connessione.
Sessioni CIM con DCOM e compatibilità con le versioni precedenti
I cmdlet WMI meno recenti basati su Get-WmiObject si affidano al protocollo DCOM, ancora supportato dalle versioni precedenti di Windows . Il problema è che, sui sistemi più moderni, i firewall spesso bloccano DCOM per impostazione predefinita, obbligando ad aprire porte specifiche per poterlo utilizzare, il che può violare le policy di sicurezza dell'organizzazione.
I cmdlet CIM offrono una potente soluzione intermedia: è possibile creare opzioni di sessione con `New-CimSessionOption -Protocol Dcom` , salvarle in una variabile (ad esempio, `$DCOM`) e quindi combinarle con `New-CimSession` per generare una sessione CIM che utilizza DCOM anziché WSMan. Ciò consente di connettersi a server molto vecchi, anche a quelli precedenti a Windows Server 2000, dove PowerShell non è nemmeno installato.
Di solito è comodo memorizzare le credenziali dell'amministratore di dominio o le credenziali di un account con privilegi elevati in una variabile (ad esempio, $Cred = Get-Credential ) per evitare di doverle digitare ogni volta. Quindi, con un comando come New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, è possibile avviare una sessione CimSession tramite DCOM verso un server meno recente che non supporta WSMan ma dispone di WMI.
Dal punto di vista dello sceneggiatore, il vantaggio principale è che l'output di `Get-CimInstance` non cambia a seconda del protocollo : si ottengono gli stessi oggetti e proprietà sia che si utilizzi WSMan che DCOM. Questo semplifica notevolmente la logica, perché è possibile incapsulare il rilevamento del protocollo appropriato in una funzione e lasciare che il resto del codice interagisca sempre in modo trasparente con CimSessions.
Infatti, è piuttosto comune creare funzioni personalizzate che testano WSMan con Test-WSMan e, se non è disponibile, passano automaticamente a DCOM utilizzando New-CimSessionOption. Questo permette di standardizzare la creazione di CimSession in ambienti misti con server sia moderni che legacy, senza dover replicare la logica di connessione in tutti gli script.
Gestione, indicizzazione e pulizia delle CimSessions
Quando si inizia a utilizzare le CimSession in modo estensivo, è importante tenerne traccia per evitare di accumulare connessioni non necessarie. Con Get-CimSession è possibile elencare tutte le sessioni aperte , vedere a quale macchina puntano e verificare quale protocollo utilizzano (WSMAN o DCOM), il che è molto utile per diagnosticare problemi di connettività o di autenticazione.
È inoltre possibile recuperare le sessioni esistenti in una variabile, ad esempio $CimSession = Get-CimSession , e utilizzarle in un singolo comando Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS per interrogare più computer contemporaneamente, combinando sessioni WSMan e DCOM nella stessa operazione.
Una volta terminata l'analisi delle informazioni, è consigliabile chiudere le sessioni per evitare di lasciare risorse aperte inutilmente. Il cmdlet Get-CimSession | Remove-CimSession rimuove contemporaneamente tutte le sessioni Cim attive dal profilo corrente. In alternativa, è possibile passare sessioni specifiche al cmdlet Remove-CimSession per chiuderne solo alcune.
Lavorare in questo modo consente di avere cicli di connessione e disconnessione controllati , il che è altamente raccomandato quando si utilizzano script all'interno di attività pianificate, runbook di automazione o pipeline di integrazione continua che possono lasciare sessioni in sospeso se non si pianifica esplicitamente la loro chiusura.
PowerShell come linguaggio di automazione completo
Oltre a WMI e CIM, PowerShell è diventato un linguaggio di automazione generico che va ben oltre i tipici script di gestione di Windows. Esistono libri e interi corsi dedicati alle sue funzionalità avanzate, che coprono ogni aspetto, dall'installazione su Linux e Windows allo sviluppo di moduli distribuibili tramite NuGet, fino ad ambienti di sviluppo moderni come Visual Studio Code.
Un punto di partenza comune è comprendere a fondo le funzionalità avanzate di PowerShell , che consentono di definire parametri, eseguire convalide, generare output strutturati e accedere alla guida integrata quasi al livello di un cmdlet nativo. Da lì, l'organizzazione del codice in moduli facilita il lavoro collaborativo all'interno dei team operativi, poiché è possibile versionare e pubblicare questi moduli in repository NuGet interni o pubblici.
Lavorare con oggetti e classi personalizzati è fondamentale , in quanto apre le porte a modelli di dati molto più ricchi rispetto ai tipici script lineari. Ciò consente di incapsulare la logica di business, riutilizzare le strutture e progettare API interne per il proprio team di gestione, il tutto grazie al motore PowerShell.
Nell'ambito dell'automazione avanzata, i processi in background e i flussi di lavoro svolgono un ruolo cruciale , consentendo la gestione di attività asincrone, l'esecuzione di operazioni di lunga durata senza bloccare la console e l'orchestrazione di sequenze complesse su più macchine. Queste funzionalità si adattano perfettamente a scenari di query in blocco verso WMI/CIM e di amministrazione remota, dove spesso è necessario attendere che i sistemi implementino le modifiche o restituiscano i dati.
Un altro componente chiave è PowerShell DSC (Desired State Configuration), che consente di definire la configurazione desiderata di un'infrastruttura (ruoli, funzionalità, servizi, file, impostazioni di sicurezza, ecc.) e di applicare tali stati ripetutamente. In combinazione con le informazioni ottenute tramite WMI/CIM, è possibile rilevare le anomalie, correggerle in modo proattivo e mantenere ambienti coerenti con un minore intervento manuale.
Gestione locale, remota e cloud con PowerShell
A livello locale, PowerShell fornisce cmdlet per la gestione dei servizi di dominio di Active Directory , la configurazione delle reti e l'amministrazione dei server. In Windows 10 e versioni successive, l'integrazione è ancora più profonda, consentendo di automatizzare qualsiasi operazione, dalla creazione di siti Web alla gestione degli oggetti di Active Directory e alla configurazione delle schede di rete.
Un componente meno conosciuto ma molto utile è PSProviders e PSDrives , che consentono di trattare diverse posizioni di archiviazione (file system, registro di sistema, Active Directory, ecc.) come se fossero unità navigabili. Grazie a ciò, è possibile, ad esempio, creare gruppi di Active Directory, chiavi di registro o strutture di cartelle su computer remoti utilizzando la stessa sintassi che si userebbe per navigare sul disco rigido.
Per quanto riguarda l'amministrazione remota, PowerShell integra un potente set di funzionalità per connettersi a uno o più computer ed eseguire comandi per conto dell'utente . È possibile utilizzare sessioni PSSession persistenti, tecniche di accesso remoto avanzate, scenari uno-a-molti (per gestire più server contemporaneamente) o scenari uno-a-uno per il debug di casi specifici. Il tutto, ovviamente, nel rispetto dell'architettura e del modello di sicurezza dell'accesso remoto.
Anche il cloud gioca oggi un ruolo fondamentale. Con Azure PowerShell e Azure Cloud Shell, è possibile gestire macchine virtuali, storage e sottoscrizioni direttamente dalla riga di comando. Installare i moduli di Azure PowerShell e familiarizzare con essi è quasi obbligatorio se si gestiscono ambienti ibridi o interamente ospitati su Azure.
D'altro canto, PowerShell si è affermato anche come strumento di riferimento per la gestione di Microsoft 365 (Exchange Online, SharePoint Online, Teams, utenti e licenze). Dalla creazione e gestione degli account all'amministrazione delle risorse di Exchange Online, inclusi gruppi, siti SharePoint e Microsoft Teams, tutto può essere orchestrato tramite script che riducono drasticamente il lavoro manuale sul portale web.
Scripting, pipeline e migliori pratiche di lavoro
Per sfruttare al meglio l'automazione avanzata con WMI e CIM, è fondamentale padroneggiare il modello pipeline di PowerShell . A differenza di altre shell, qui non si passa testo semplice, bensì oggetti completi, il che consente di selezionare, ordinare, misurare, filtrare, enumerare e trasformare le informazioni con grande precisione.
Imparare a lavorare con le pipeline implica utilizzare correttamente i cmdlet di selezione e filtro , comprendere come enumerare oggetti complessi e imparare a passare dati tra comandi e script senza perdere informazioni. Questo viene rafforzato dall'uso organizzato di variabili, array e tabelle hash, che fungono da strutture dati temporanee su cui costruire logiche più avanzate.
Il passo successivo è la creazione degli script: raggruppare i comandi in script riutilizzabili con controllo del flusso (if, for, foreach), importare dati da file CSV o altri formati, gestire l'input dell'utente, la gestione degli errori e la registrazione degli eventi. Tutto ciò consente di passare da comandi isolati a strumenti integrati più robusti.
La risoluzione dei problemi e la gestione degli errori sono particolarmente importanti negli ambienti di automazione su larga scala con WMI/CIM, poiché un'interruzione di rete, un'autorizzazione configurata in modo errato o una classe mancante possono interrompere un processo se non gestite correttamente. Con blocchi try/catch, azioni di errore configurabili e registrazione dettagliata, è possibile prevedere e reagire in modo più efficace a queste situazioni.
Infine, tutto ciò che riguarda funzioni e moduli completa il cerchio : si firmano gli script per garantirne l'integrità, si impacchettano le funzioni in moduli, si distribuiscono questi moduli in repository interni o pubblici e si crea un ecosistema di strumenti condivisi all'interno dell'organizzazione. In questo modo, qualsiasi nuovo sviluppo su WMI, CIM o accesso remoto viene integrato in una suite coerente e di facile manutenzione.
Combinando tutti gli elementi sopra menzionati (WMI/CIM, sessioni remote, scripting, processi asincroni, DSC, Azure e Microsoft 365), si ottiene un ambiente in cui l'automazione avanzata con PowerShell diventa il fulcro dell'amministrazione. Grazie a una solida base di best practice, un utilizzo intelligente di CimSessions (sia con WSMan che con DCOM) e una progettazione modulare degli script, è possibile gestire infrastrutture eterogenee in modo coerente, sicuro e molto più efficiente rispetto al solo utilizzo di procedure guidate grafiche o strumenti isolati.
