Визначте ядро ​​Windows Server Server

Я хочу виявити, чи був встановлений сервер 2012 року в якості основної установки за допомогою WMI. Попереднє запитання, здавалося б, вказує на те, що я можу отримати OperatingSystemSKU від Win32_OperatingSystem . Мої основні системи Windows 2012 звітують про операційну системуSKU 7 Стаття з іншого питання, здавалося б, вказує на PRODUCT_STANDARD_SERVER, і якби ядро ​​встановило, я повинен очікувати, що замість PRODUCT_STANDARD_SERVER_CORE я побачу значення 0x0000000D.

Що мені тут не вистачає. Я врешті-решт хочу створити політику та використовувати націлювання на рівень елементів, щоб застосувати її лише до встановлень 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для встановлення серверного ядра та $trueдля всіх інших . На виконання цього потрібна одна мілісекунда .

Смішно, що стаття MSDN, яку ви пов’язали, містила відповідь:

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

Це тому, що Server 2012 можна вільно конвертувати між "Server Core" і "повною" установкою, просто додаючи або видаливши відповідні функції.

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

Оскільки GUI - це лише функція, ви можете запитувати список встановлених функцій

Просто тестування цього в powerhell на сервері тут працювало досить добре:

Вивантажте список функцій, щоб захопити ім'я

Get-WmiObject Win32_OptionalFeature > features.txt

Пошук у тексті Features.txt повідомляє мені, що функція має ім’я "Server-Gui-Mgmt" (інші функції можуть бути встановлені також, як відзначає Майкл у своїй відповіді, тож ви також можете перевірити їх), і ми можемо шукати, щоб побачити якщо це є

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

Я підозрюю, що оскільки вони по суті однакові у 2012 році, маючи лише кілька додаткових функцій для їх роз'єднання, ви можете запитувати їх натомість.

Ця стаття є посиланням на клас Win32_OptionsFeature, який дозволить вам запитувати функції. Додаткові функції визначаються як Server-Gui-Mgmt-Infra, Server-Gui-Shell та Desktop-Experience, як зазначено в цій статті .

Ви можете здійснити запит на 3 з них і використовувати логіку Boolean 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_OptionsFeature. Це дуже хороший інтерфейс, якщо ви запитуєте багато та багато машин у швидкій мережі та потребуєте безлічі деталей про зв’язки компонентів та їх стан - але для нормального використання це біль. Замість цього використовуйте Win32_ServerFeature.
• Win32_ServerFeature: як правило, найкраще все навколо вибору для локальних або віддалених запитів, але не так швидко, як перевірка локальних файлів. Повертає лише встановлені функції та надає мало трафіку в мережі.
• Get-WindowsFeature: Дуже простий у використанні, припускаючи, що ви вже використовуєте PowerShell як частину вашого шляху виклику. Коли ви телефонуєте проти віддаленої цілі, це збільшує 400 КК по всій мережі, що є надмірним, коли ви просто хочете дізнатися, чи встановлена ​​певна функція.
• Win32_OptionsFeature / Get-WindowsOfaultFeature: цей запит 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_OptionsFeature (і справді, такий шлях існує). Сподіваюся, що це допомагає комусь іншому.

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

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