Identifier le noyau de Windows 2012 Server

Je souhaite détecter si un serveur 2012 a été configuré en tant qu'installation principale à l'aide de WMI. Une question antérieure semble indiquer que je peux obtenir le OperatingSystemSKU à partir de Win32_OperatingSystem . Mes systèmes Windows 2012 Core signalent un OperatingSystemSKU de 7. L' article de l'autre question semble indiquer qu'il s'agit d'un PRODUCT_STANDARD_SERVER, et s'il y avait une installation de base, je devrais m'attendre à voir une valeur de 0x0000000D à la place pour PRODUCT_STANDARD_SERVER_CORE.

Qu'est-ce que j'oublie ici. Je souhaite finalement créer une stratégie et utiliser le ciblage au niveau de l'élément pour n'appliquer cette stratégie qu'aux installations de 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

Dans PowerShell:

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

renvoie 1 sur un serveur complet et 2 sur une installation principale du serveur.

Éditer:

Bien que ma réponse ci-dessus soit correcte, elle présente deux problèmes:

1. Lorsque vous utilisez cette commande sur un poste de travail, elle ne renvoie rien, vous devez donc ajouter une vérification supplémentaire pour cela.

2. C'est lent, quand je l'ai essayé, ça a pris entre 600 et 3500 millisecondes.

L'approche la plus pragmatique consiste donc simplement à vérifier l'existence d'un certain fichier:

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

Cela revient $falsepour une installation Server Core et $truepour toutes les autres et il faut une milliseconde pour s'exécuter.

Drôle, cet article MSDN que vous avez lié contenait la réponse:

Les valeurs PRODUCT _ * _ SERVER_CORE ne sont pas renvoyées dans Windows Server 2012.

En effet, Server 2012 peut être librement converti entre une installation "Server Core" et une installation "complète" simplement en ajoutant ou en supprimant les fonctionnalités appropriées.

Vous voudrez vérifier la présence ou l'absence de ces fonctionnalités (par exemple Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Comme l'interface graphique n'est qu'une fonctionnalité, vous pouvez interroger la liste des fonctionnalités installées

Le simple fait de tester cela dans PowerShell sur un serveur ici a bien fonctionné:

Vider une liste de fonctionnalités pour saisir le nom

Get-WmiObject Win32_OptionalFeature > features.txt

La recherche dans le texte de features.txt m'indique que la fonctionnalité est nommée 'Server-Gui-Mgmt' (d'autres fonctionnalités peuvent également être installées comme Michael le note dans sa réponse, afin que vous puissiez également les tester), et nous pouvons rechercher pour voir si c'est présent

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

Je soupçonne qu'étant donné qu'ils sont essentiellement les mêmes en 2012 avec seulement quelques fonctionnalités optionnelles pour les différencier, vous pouvez interroger les fonctionnalités à la place.

cet article est une référence pour la classe Win32_OptionalFeature, qui vous permettra d'interroger les fonctionnalités. Les fonctionnalités facultatives sont définies comme Server-Gui-Mgmt-Infra, Server-Gui-Shell et Desktop-Experience, comme indiqué dans cet article .

Vous pouvez rechercher les 3 d'entre eux et utiliser la logique booléenne ET et NON pour sélectionner les serveurs sur lesquels aucune de ces fonctionnalités n'est installée.

J'utiliserais Win32_ServerFeature, c'est une classe beaucoup plus petite et ne contient que les rôles installés sur le serveur. Les requêtes utilisant la fonction Win32_Server devraient retourner beaucoup plus rapidement.

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

Quelques éclaircissements sur les réponses pour les scénarios locaux et distants lorsque les performances ont été discutées. L'interrogateur a demandé à WMI, et son exemple a utilisé PowerShell pour appeler WMI. L'utilisation de WMI directement à partir de code non managé est également plus rapide.

Veuillez noter que les approches s'appliquent efficacement à Server 2012 et Server 2012 R2 et peuvent ne pas s'appliquer aux versions futures.

Quelques compromis en fonction de votre scénario ... Pour la plupart des cas, Win32_ServerFeature est préféré comme solution générale, ou la vérification du fichier local à la rigueur.

• Vérification du fichier local: rapide et sale. Très peu de pièces mobiles.
• MSFT_ServerManagerDeploymentTasks: le fournisseur WMI sous-jacent utilisé par Win32_ServerFeature et Get-WindowsFeature. Il utilise un cache de registre local et renvoie normalement très rapidement, sauf s'il y a eu un changement de configuration depuis la dernière requête. En cas de défaillance du cache, c'est à peu près la même chose que Win32_OptionalFeature. C'est une très bonne interface si vous interrogez beaucoup de machines sur un réseau rapide et que vous avez besoin de beaucoup de détails sur les relations des composants et leur état - mais pour une utilisation normale, c'est pénible. Utilisez plutôt Win32_ServerFeature.
• Win32_ServerFeature: généralement le meilleur choix complet pour les requêtes locales ou distantes, mais pas aussi rapide que la vérification de fichier local. Renvoie uniquement les fonctionnalités installées et met peu de trafic sur le réseau.
• Get-WindowsFeature: Très simple à utiliser, en supposant que vous utilisez déjà PowerShell dans le cadre de votre chemin d'appel. Lorsque vous appelez contre une cible distante, cela met plus de 400 Ko sur le réseau, ce qui est exagéré lorsque vous voulez simplement savoir si une fonctionnalité spécifique est installée.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: cela interroge DISM sur la cible à chaque fois, ce qui peut être assez lourd.

Cela couvre les scénarios locaux et distants en ligne. Certains des éléments ci-dessus cibleront également une image hors ligne.

Je pensais simplement que je mettrais un filtre WMI pour cette solution, vous pouvez donc appliquer des GPO aux systèmes Core 2012+:

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

Pour tester cela sur la ligne de commande:

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

Je suis tombé sur ce fil en essayant de trouver un moyen de créer des filtres WMI pour les serveurs Core 2012, et pour une raison quelconque, je n'ai pas pensé que WMI vérifie Win32_OptionalFeature (ou bien qu'un tel chemin existe). J'espère que ceci aide quelqu'un d'autre.

Sur Windows Server 2012 R2, j'utilise ce qui suit, les performances sont bonnes tout en étant assez explicites.

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