Identificar el núcleo del servidor de Windows 2012

Quiero detectar si un servidor 2012 se ha configurado como una instalación Core usando WMI. Una pregunta anterior parecería indicar que puedo obtener el OperatingSystemSKU de Win32_OperatingSystem . Mis sistemas Windows 2012 Core informan un OperatingSystemSKU de 7. El artículo de la otra pregunta parecería indicar que es un PRODUCT_STANDARD_SERVER, y si tuviera una instalación central, esperaría ver un valor de 0x0000000D en lugar de PRODUCT_STANDARD_SERVER_CORE.

Que me estoy perdiendo aqui. Eventualmente quiero crear una política y usar la orientación a nivel de elemento para aplicar solo esa política a las instalaciones 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

En PowerShell:

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

devuelve 1 en un servidor completo y 2 en una instalación central del servidor.

Editar:

Si bien mi respuesta anterior es correcta, hay dos problemas con ella:

1. Al utilizar este comando en una estación de trabajo, no devuelve nada, por lo que debe agregar una comprobación adicional para esto.

2. Es lento, cuando lo probé, tomó entre 600 y 3500 milisegundos.

Entonces, el enfoque más pragmático es simplemente verificar la existencia de un archivo determinado:

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

Esto regresa $falsepara las instalaciones de Server Core y $truepara todas las demás y se tarda un milisegundo en ejecutarse.

Es curioso que el artículo de MSDN que vinculó contenía la respuesta:

Los valores de PRODUCT _ * _ SERVER_CORE no se devuelven en Windows Server 2012.

Esto se debe a que Server 2012 se puede convertir libremente entre la instalación "Server Core" y la instalación "completa" simplemente agregando o quitando las características apropiadas.

Deberá verificar la presencia o ausencia de esas características (por ejemplo, Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Como la GUI es solo una característica, puede consultar la lista de características instaladas

Simplemente probar esto en powershell en un servidor aquí funcionó bastante bien:

Volcar una lista de características para obtener el nombre

Get-WmiObject Win32_OptionalFeature > features.txt

Al buscar el texto de features.txt me dice que la función se llama 'Server-Gui-Mgmt' (también se pueden instalar otras funciones como Michael señala en su respuesta, para que pueda probarlas también), y podemos buscar para ver si eso está presente

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

Sospecho que, dado que son esencialmente iguales en 2012 con solo algunas características opcionales para diferenciarlas, puede consultar las características en su lugar.

Este artículo es una referencia para la clase Win32_OptionalFeature, que le permitirá consultar las características. Las características opcionales se definen como Server-Gui-Mgmt-Infra, Server-Gui-Shell y Desktop-Experience, como se describe en este artículo .

Puede consultar los 3 y utilizar la lógica booleana AND y NOT para seleccionar servidores que no tengan ninguna de estas características instaladas.

Usaría Win32_ServerFeature, es una clase mucho más pequeña y solo contiene los roles instalados en el servidor. Las consultas que utilizan la función Win32_Server deberían volver mucho más rápido.

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

Algunas aclaraciones sobre las respuestas para escenarios locales y remotos a medida que se discutía el rendimiento. El interrogador le preguntó a WMI, y su ejemplo usó PowerShell para invocar a WMI. Usar WMI directamente del código no administrado también es más rápido.

Tenga en cuenta que los enfoques se aplican de manera efectiva a Server 2012 y Server 2012 R2, y pueden no aplicarse a versiones futuras.

Algunas compensaciones dependen de su escenario ... En la mayoría de los casos, se prefiere Win32_ServerFeature como una solución general, o la comprobación local de archivos en caso de necesidad.

• Verificación de archivos locales: rápida y sucia. Muy pocas partes móviles.
• MSFT_ServerManagerDeploymentTasks: el proveedor WMI subyacente utilizado por Win32_ServerFeature y Get-WindowsFeature. Utiliza un caché de registro local y normalmente regresa muy rápidamente a menos que haya habido un cambio de configuración desde la última consulta. En el caso de la falta de caché, es casi lo mismo que Win32_OptionalFeature. Esta es una interfaz muy buena si está consultando muchas máquinas en una red rápida y necesita muchos detalles sobre las relaciones de los componentes y su estado, pero para el uso normal es una molestia. Utilice Win32_ServerFeature en su lugar.
• Win32_ServerFeature: generalmente es la mejor opción para consultas locales o remotas, pero no tan rápido como la verificación de archivos locales. Devuelve solo las características instaladas y pone poco tráfico en la red.
• Get-WindowsFeature: Muy fácil de usar, suponiendo que ya esté usando PowerShell como parte de su ruta de llamada. Cuando se llama contra un objetivo remoto, esto genera más de 400K en la red, lo cual es excesivo cuando solo desea saber si hay una característica específica instalada.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: esto consulta DISM en el objetivo cada vez, lo que puede ser bastante pesado.

Eso cubre escenarios locales y remotos en línea. Algunos de los anteriores también se orientarán a una imagen sin conexión.

Solo pensé en intervenir con un filtro WMI para esta solución, para que pueda aplicar GPO a los sistemas Core 2012+:

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

Para probar esto en la línea de comando:

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

Me topé con este hilo cuando trataba de encontrar una manera de crear filtros WMI para servidores Core 2012, y por alguna razón no se me ocurrió que WMI verificara Win32_OptionalFeature (o que esa ruta existe). Espero que esto ayude a alguien más.

En Windows Server 2012 R2, estoy usando lo siguiente, el rendimiento es bueno y sigue siendo bastante explícito.

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