Определить ядро ​​Windows 2012 Server

Я хочу определить, настроен ли сервер 2012 в качестве базовой установки с использованием WMI. Более ранний вопрос, похоже, указывает на то, что я могу получить OperatingSystemSKU из Win32_OperatingSystem . Мои системы Windows 2012 Core сообщают, что OperatingSystemSKU равен 7. В статье из другого вопроса, по-видимому, указывается, что это PRODUCT_STANDARD_SERVER, и если бы у меня была установка ядра, я бы ожидал увидеть значение 0x0000000D вместо PRODUCT_STANDARD_SERVER_CORE.

Что мне здесь не хватает. В конце концов я хочу создать политику и использовать таргетинг на уровне элементов, чтобы применять эту политику только к установкам 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

В PowerShell:

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

возвращает 1 для полного сервера и 2 для установки ядра сервера.

Редактировать:

Хотя мой ответ выше верен, с ним есть две проблемы:

1. При использовании этой команды на рабочей станции она ничего не возвращает, поэтому вам нужно добавить дополнительную проверку для этого.

2. Это медленно, когда я попробовал, это заняло от 600 до 3500 миллисекунд.

Поэтому более прагматичный подход - просто проверить наличие определенного файла:

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

Это возвращается $falseдля установок Server Core и $trueдля всех остальных, и выполнение занимает одну миллисекунду .

Забавно, что статья MSDN, на которую вы ссылались, содержала ответ:

Значения PRODUCT _ * _ SERVER_CORE не возвращаются в Windows Server 2012.

Это связано с тем, что Server 2012 можно свободно преобразовать между «Server Core» и «полной» установкой, просто добавив или удалив соответствующие функции.

Вы можете проверить наличие или отсутствие этих функций (например, Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Поскольку GUI - это просто функция, вы можете запросить список установленных функций.

Простое тестирование в PowerShell на сервере здесь работает достаточно хорошо:

Создать список функций, чтобы захватить имя

Get-WmiObject Win32_OptionalFeature > features.txt

Поиск по тексту файла functions.txt говорит мне, что эта функция называется «Server-Gui-Mgmt» (другие функции могут быть установлены, как замечает Майкл в своем ответе, так что вы можете проверить их тоже), и мы можем искать, чтобы увидеть если это присутствует

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

Я подозреваю, что, поскольку в 2012 году они, по сути, одинаковы с несколькими дополнительными функциями для их выделения, вы можете вместо этого запросить их.

эта статья является справочной для класса Win32_OptionalFeature, который позволит вам запрашивать функции. Дополнительные функции определены как Server-Gui-Mgmt-Infra, Server-Gui-Shell и Desktop-Experience, как описано в этой статье .

Вы можете запросить 3 из них и использовать логические операторы AND и NOT для выбора серверов, на которых не установлена ​​ни одна из этих функций.

Я бы использовал Win32_ServerFeature, это гораздо меньший класс и содержит только роли, установленные на сервере. Запросы, использующие функцию Win32_Server, должны возвращаться намного быстрее.

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

Обсуждались некоторые разъяснения относительно ответов для локальных и удаленных сценариев по мере выполнения. Спрашивающий спросил WMI, и его пример использовал PowerShell для вызова WMI. Использование WMI напрямую из неуправляемого кода также происходит быстрее.

Обратите внимание, что эти подходы эффективно применяются к Server 2012 и Server 2012 R2 и могут не применяться к будущим выпускам.

Некоторые компромиссы в зависимости от вашего сценария ... В большинстве случаев Win32_ServerFeature предпочтительнее в качестве общего решения или проверки локального файла в крайнем случае.

• Проверка локальных файлов: быстрая и грязная. Очень мало движущихся частей.
• MSFT_ServerManagerDeploymentTasks: основной поставщик WMI, используемый Win32_ServerFeature и Get-WindowsFeature. Он использует локальный кэш реестра и, как правило, очень быстро возвращается, если с момента последнего запроса не произошло изменение конфигурации. В случае отсутствия кэша он примерно такой же, как Win32_OptionalFeature. Это очень хороший интерфейс, если вы запрашиваете много и много машин в быстрой сети и вам нужно много подробностей о взаимосвязях компонентов и их состоянии - но для нормального использования это боль. Вместо этого используйте Win32_ServerFeature.
• Win32_ServerFeature: обычно лучший выбор для локальных или удаленных запросов, но не так быстро, как проверка локальных файлов. Возвращает только установленные функции и оставляет мало трафика в сети.
• Get-WindowsFeature: очень прост в использовании, если вы уже используете PowerShell как часть пути вызова. При вызове с удаленной цели это увеличивает 400К по сети, что является избыточным, когда вы просто хотите узнать, установлена ​​ли конкретная функция.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: это запрашивает DISM на цели каждый раз, что может быть довольно тяжелым.

Это охватывает онлайн локальные и удаленные сценарии. Некоторые из вышеупомянутых также будут нацелены на автономное изображение.

Я просто подумал, что мне нужно подключиться к WMI-фильтру для этого решения, чтобы вы могли применять объекты групповой политики к системам Core 2012+:

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

Чтобы проверить это в командной строке:

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

Я наткнулся на этот поток, пытаясь найти способ создания фильтров WMI для серверов Core 2012, и по какой-то причине мне не пришло в голову проверить WMI Win32_OptionalFeature (или, действительно, такой путь существует). Надеюсь, это поможет кому-то еще.

На Windows Server 2012 R2 я использую следующее: производительность хорошая, но все еще довольно явная.

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