Определить ядро 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
8 ответов
В PowerShell:
Get-WMIObject Win32_OptionalFeature | where Name -eq 'Server-Gui-Shell' | Select InstallState
возвращает 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'"
Я бы использовал Win32_ServerFeature, это гораздо меньший класс и содержит только роли, установленные на сервере. Запросы, использующие функцию Win32_Server, должны возвращаться намного быстрее.
Get-WmiObject -Query "Select * FROM Win32_ServerFeature WHERE Name = 'Server Graphical Shell'"
Я подозреваю, что, поскольку в 2012 году они, по сути, одинаковы с несколькими дополнительными функциями для их выделения, вы можете вместо этого запросить их.
эта статья является справочной для класса Win32_OptionalFeature, который позволит вам запрашивать функции. Дополнительные функции определены как Server-Gui-Mgmt-Infra, Server-Gui-Shell и Desktop-Experience, как описано в этой статье.
Вы можете запросить 3 из них и использовать логические операторы AND и NOT для выбора серверов, на которых не установлена ни одна из этих функций.
Обсуждались некоторые разъяснения относительно ответов для локальных и удаленных сценариев по мере выполнения. Спрашивающий спросил 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