Identificare il core di Windows 2012 Server

Voglio rilevare se un server 2012 è stato impostato come installazione Core tramite WMI. Una domanda precedente, sembrerebbe indicare che posso ottenere OperatingSystemSKU da Win32_OperatingSystem . I miei sistemi Windows 2012 Core riportano un OperatingSystemSKU di 7. L' articolo dall'altra domanda sembrerebbe indicare è un PRODUCT_STANDARD_SERVER, e se avessi un'installazione core dovrei aspettarmi di vedere un valore di 0x0000000D invece di PRODUCT_STANDARD_SERVER_CORE.

Cosa mi sto perdendo qui. Alla fine voglio creare un criterio e utilizzare il targeting a livello di elemento per applicare tale criterio solo alle installazioni di Windows 2012 Server Core.

PS C:\Users\zoredache\Documents> gwmi -Query "select OPeratingSystemSKU,Version,ProductType from Win32_OperatingSystem"

__GENUS            : 2
__CLASS            : Win32_OperatingSystem
__SUPERCLASS       :
__DYNASTY          :
__RELPATH          : Win32_OperatingSystem=@
__PROPERTY_COUNT   : 3
__DERIVATION       : {}
__SERVER           :
__NAMESPACE        :
__PATH             :
OperatingSystemSKU : 7
ProductType        : 2
Version            : 6.2.9200

In PowerShell:

Get-WMIObject Win32_OptionalFeature | where Name -eq 'Server-Gui-Shell' | Select InstallState

restituisce 1 su un server completo e 2 su un'installazione core del server.

Modificare:

Mentre la mia risposta sopra è corretta, ci sono due problemi con esso:

1. Quando si utilizza questo comando su una workstation, non restituisce nulla, quindi è necessario aggiungere un ulteriore controllo per questo.

2. È lento, quando l'ho provato, ci sono voluti tra 600 e 3500 millisecondi.

Quindi l'approccio più pragmatico è semplicemente verificare l'esistenza di un determinato file:

(Test-Path "$env:windir\explorer.exe")

Questo ritorna $falseper installazioni Server Core e $trueper tutti gli altri e richiede un millisecondo per essere eseguito.

Divertente, quell'articolo MSDN che hai collegato conteneva la risposta:

I valori di PRODUCT _ * _ SERVER_CORE non vengono restituiti in Windows Server 2012.

Questo perché Server 2012 può essere convertito liberamente tra "Server Core" e l'installazione "completa" semplicemente aggiungendo o rimuovendo le funzionalità appropriate.

Ti consigliamo di verificare la presenza o l'assenza di tali funzionalità (ad esempio Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Poiché la GUI è solo una funzionalità, è possibile eseguire una query sull'elenco delle funzionalità installate

Il solo test di questo in PowerShell su un server qui ha funzionato abbastanza bene:

Scarica un elenco di funzionalità per afferrare il nome

Get-WmiObject Win32_OptionalFeature > features.txt

La ricerca nel testo di features.txt mi dice che la funzione è denominata 'Server-Gui-Mgmt' (altre funzioni possono essere installate anche come osserva Michael nella sua risposta, in modo da poterne verificare anche quelle), e possiamo cercare di vedere se è presente

Get-WmiObject -query "select * from Win32_OptionalFeature where name = 'Server-Gui'"

Ho il sospetto che dal momento che sono essenzialmente le stesse nel 2012 con solo alcune funzionalità opzionali per distinguerle, è possibile invece interrogare le funzionalità.

questo articolo è un riferimento per la classe Win32_OptionalFeature, che ti permetterà di interrogare le funzionalità. Le funzionalità opzionali sono definite come Server-Gui-Mgmt-Infra, Server-Gui-Shell e Desktop-Experience, come indicato in questo articolo .

È possibile eseguire una query per 3 di essi e utilizzare la logica booleana AND e NOT per selezionare i server su cui non è installata nessuna di queste funzionalità.

Vorrei usare Win32_ServerFeature, è una classe molto più piccola e contiene solo i ruoli installati sul server. Le query che utilizzano la funzione Win32_Server dovrebbero restituire molto più rapidamente.

Get-WmiObject -Query "Select * FROM Win32_ServerFeature WHERE Name = 'Server Graphical Shell'" 

Sono stati discussi alcuni chiarimenti sulle risposte per scenari locali e remoti durante la performance. L'interrogatore ha chiesto a WMI e il suo esempio ha usato PowerShell per invocare WMI. Anche l'uso di WMI direttamente da codice non gestito è più rapido.

Si noti che gli approcci si applicano efficacemente a Server 2012 e Server 2012 R2 e potrebbero non applicarsi alle versioni future.

Alcuni compromessi a seconda del tuo scenario ... Nella maggior parte dei casi, Win32_ServerFeature è preferita come soluzione generale o il controllo del file locale in un pizzico.

• Controllo file locale: veloce e sporco. Pochissime parti mobili.
• MSFT_ServerManagerDeploymentTasks: il provider WMI sottostante utilizzato da Win32_ServerFeature e Get-WindowsFeature. Utilizza una cache del registro locale e normalmente ritorna molto rapidamente a meno che non ci sia stata una modifica della configurazione dall'ultima query. In caso di mancanza della cache, è quasi uguale a Win32_OptionalFeature. Questa è un'ottima interfaccia se stai interrogando un sacco di macchine su una rete veloce e hai bisogno di molti dettagli sulle relazioni dei componenti e il loro stato - ma per un uso normale è una seccatura. Utilizzare invece Win32_ServerFeature.
• Win32_ServerFeature: generalmente la scelta migliore per le query locali o remote, ma non così veloce come il controllo dei file locali. Restituisce solo le funzionalità installate e inserisce poco traffico sulla rete.
• Get-WindowsFeature: molto semplice da usare, supponendo che tu stia già utilizzando PowerShell come parte del tuo percorso di chiamata. Quando si effettua una chiamata su un target remoto, questo mette oltre 400K attraverso la rete, il che è eccessivo quando si desidera solo sapere se è installata una funzione specifica.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: questo interroga DISM sul target ogni volta che può essere piuttosto pesante.

Che copre scenari online locali e remoti. Alcune delle precedenti saranno anche indirizzate a un'immagine offline.

Ho appena pensato di entrare in contatto con un filtro WMI per questa soluzione, quindi puoi applicare gli oggetti Criteri di gruppo ai sistemi Core 2012+:

SELECT * FROM Win32_OptionalFeature WHERE Caption = "Microsoft-Windows-Server-Gui-Shell-Package-DisplayName" AND InstallState = "2"

Per testarlo dalla riga di comando:

WMIC PATH Win32_OptionalFeature WHERE "Caption = 'Microsoft-Windows-Server-Gui-Shell-Package-DisplayName' AND InstallState = 2"

Mi sono imbattuto in questo thread durante il tentativo di trovare un modo per creare filtri WMI per server Core 2012 e per qualche motivo non mi è venuto in mente di avere WMI che controlla Win32_OptionalFeature (o, in effetti, che esiste un tale percorso). Spero che questo aiuti qualcun altro.

Su Windows Server 2012 R2, sto usando quanto segue, le prestazioni sono buone pur essendo abbastanza esplicite.

$gui = (Get-WindowsFeature -Name 'Server-Gui-Shell').Installed