Назад | Перейти на главную страницу

Определить ядро ​​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).

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

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

Выгрузите список функций, чтобы захватить имя

Get-WmiObject Win32_OptionalFeature > features.txt

Поиск по тексту features.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, как указано в Эта статья.

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

Я бы использовал 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, чтобы вы могли применять GPO к системам 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