27Aug
WMI e il suo nuovo fratello CIM possono entrambi essere utilizzati per gestire le macchine Windows nel proprio ambiente. Ma conosci la differenza tra loro? Unisciti a noi mentre diamo un'occhiata.
Leggere gli articoli precedenti della serie:
- Imparare come automatizzare Windows con PowerShell
- Imparare ad utilizzare i cmdlet in PowerShell
- Imparare come utilizzare gli oggetti in PowerShell
- Imparare la formattazione, il filtraggio e il confronto in PowerShell
- Imparare a utilizzare i servizi remoti inPowerShell
E rimanete sintonizzati per il resto della serie per tutta la settimana.
Introduzione
WMI è l'acronimo di Strumentazione gestione Windows. La parola "Strumentazione" si riferisce al fatto che WMI ti consente di ottenere informazioni sullo stato interno del tuo computer, proprio come gli strumenti del cruscotto nella tua auto possono recuperare e visualizzare informazioni sullo stato dei componenti interni della tua auto.
WMI è costituito da un repository che contiene classi che rappresentano componenti che possono essere gestiti all'interno della macchina. Con questo intendiamo solo perché WMI ha una classe Win32_Battery, non significa che la tua macchina contenga una batteria. Queste classi possono quindi essere interrogate per informazioni localmente o anche attraverso una rete utilizzando un linguaggio di query molto simile a SQL chiamato WQL.Tuttavia, WMI è stato conosciuto per essere molto inaffidabile, principalmente per il fatto che è basato su RPC( Remote Procedure Calls), che fanno cose pazze con le porte su cui scelgono di comunicare.
A partire da Windows 8 e Server 2012, WMI è in fase di eliminazione a favore del Common Information Model o CIM in breve. L'unica differenza tra WMI e CIM sono i protocolli di trasporto che utilizzano. Mentre WMI esegue query utilizzando Remote Procedure Calls, CIM utilizza HTTP, che sembra fare una grande differenza. Sul backend stanno ancora parlando allo stesso repository di informazioni.
Utilizzo di WMI
Il modo più rapido e semplice di esplorare le informazioni disponibili tramite WMI è di prelevare una copia di qualsiasi WMI Object Browser gratuito. Ci piace questo. Una volta scaricato, attivalo e avrai un'interfaccia grafica per sfogliare le classi WMI.
Se vuoi scoprire qualcosa sulla configurazione del disco di un computer, premi la combinazione di tasti Ctrl + F per aprire una casella di ricerca, quindi digita "logicaldisk" e premi invio.
Immediatamente questo ti porterà alla classe Win32_LogicalDisk.
Nella metà inferiore dell'applicazione, puoi vedere che abbiamo due istanze della classe.
Una volta che abbiamo la classe che stiamo cercando, interrogarla da PowerShell è semplice.
Get-WmiObject -Query "SELECT * FROM Win32_LogicalDisk"
Non ho visto questa sintassi per un po 'con le persone in questi giorni preferendo utilizzare la nuova sintassi parametrizzata.
Get-WmiObject -Class Win32_LogicalDisk
Se si desidera ottenere le informazioni da un altro computer sulla rete, è sufficiente utilizzare il parametro ComputerName.
Get-WmiObject -Class Win32_LogicalDisk -ComputerName Viper -Credential viper \ administrator
Utilizzo di CIM
Tenendo presente che CIM è disponibile solo su Windows 8 e Server 2012, andare avanti è sicuramente la strada da percorrere.
Get-CimInstance -ClassName Win32_LogicalDisk
Esiste anche il completamento della tabulazione per il parametro -ClassName quando si utilizza Get-CimInstance, che mostra che in futuro è qui che gli sforzi di Microsoft saranno concentrati.
In effetti, WMI è stato sviluppato da un team completamente separato all'interno di Microsoft, ma è stato successivamente rilevato dai responsabili di PowerShell. Erano quelli che hanno notato che sarebbe stato molto difficile ripulire il disordine che WMI aveva lasciato dietro di sé.Nel tentativo di rimediare alla situazione, stanno cercando di rendere WMI e CIM più disponibili scrivendo cmdlet wrapper che usano WMI e CIM sotto il cofano. L'unico modo per verificare se un cmdlet è un wrapper è osservare la documentazione. Ad esempio, il cmdlet Get-Hotfix è un wrapper per la classe Win32_QuickFixEngineering, come mostrato nella documentazione.
Ciò significa che è possibile ottenere gli hotfix su macchine remote utilizzando il cmdlet Get-HotFix anziché una query WMI.
Get-HotFix -ComputerName localhost
Quindi eccoci qui. Ricorda che se esiste un cmdlet dedicato, lo si vorrà sempre utilizzare, seguito da CIM se non esiste un cmdlet. Infine, se tutto il resto fallisce, o si hanno macchine più vecchie nel proprio ambiente, si vorrà usare WMI.Questo è tutto ciò che ho per questa volta. Ci vediamo domani per più divertimento con PowerShell.