Zidentyfikuj rdzeń systemu Windows 2012 Server

Chcę wykryć, czy serwer 2012 został skonfigurowany jako instalacja podstawowa przy użyciu WMI. Wcześniejsze pytanie wydaje się wskazywać, że mogę uzyskać OperatingSystemSKU z Win32_OperatingSystem . Moje systemy Windows 2012 Core zgłaszają wartość OperatingSystemSKU wynoszącą 7. Artykuł z drugiego pytania wydaje się wskazywać na PRODUCT_STANDARD_SERVER, a jeśli miałbym instalację podstawową, powinienem spodziewać się wartości 0x0000000D zamiast PRODUCT_STANDARD_SERVER_CORE.

Czego tu brakuje. W końcu chcę utworzyć zasadę i użyć kierowania na poziomie elementu, aby zastosować tę zasadę tylko do instalacji systemu 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

W PowerShell:

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

zwraca 1 na pełnym serwerze i 2 na podstawowej instalacji serwera.

Edytować:

Chociaż moja powyższa odpowiedź jest poprawna, istnieją z nią dwa problemy:

1. Gdy używasz tego polecenia na stacji roboczej, nic nie zwraca, więc musisz dodać do tego dodatkową kontrolę.

2. Jest powolny, kiedy go wypróbowałem, zajęło to od 600 do 3500 milisekund.

Bardziej pragmatycznym podejściem jest po prostu sprawdzenie istnienia określonego pliku:

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

Zwraca to $falsedla instalacji Server Core i $truedla wszystkich innych, a wykonanie zajmuje jedną milisekundę .

Zabawne, że ten artykuł MSDN, który podłączyłeś, zawierał odpowiedź:

Wartości PRODUCT _ * _ SERVER_CORE nie są zwracane w systemie Windows Server 2012.

Jest tak, ponieważ Server 2012 można swobodnie konwertować między „Server Core” a „pełną” instalacją, po prostu dodając lub usuwając odpowiednie funkcje.

Będziesz chciał sprawdzić obecność lub brak tych funkcji (np. Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Ponieważ GUI to tylko funkcja, możesz przeszukać listę zainstalowanych funkcji

Właśnie testowanie tego w PowerShell na serwerze działało wystarczająco dobrze:

Zrzuć listę funkcji, aby zdobyć nazwę

Get-WmiObject Win32_OptionalFeature > features.txt

Przeszukanie tekstu features.txt mówi mi, że funkcja nazywa się „Server-Gui-Mgmt” (inne funkcje mogą być również instalowane, jak zauważa Michael w swojej odpowiedzi, więc możesz je przetestować), a my możemy wyszukać jeśli to jest obecne

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

Podejrzewam, że ponieważ są one zasadniczo takie same w 2012 r. I mają tylko kilka opcjonalnych funkcji, aby je rozdzielić, możesz zamiast tego zapytać o funkcje.

ten artykuł jest odniesieniem do klasy Win32_OptionalFeature, która pozwoli ci zapytać o funkcje. Funkcje opcjonalne są zdefiniowane jako Server-Gui-Mgmt-Infra, Server-Gui-Shell i Desktop-Experience, jak opisano w tym artykule .

Możesz zapytać o 3 z nich i użyć logiki logicznej AND i NOT, aby wybrać serwery, na których nie zainstalowano żadnej z tych funkcji.

Chciałbym użyć Win32_ServerFeature, jest to znacznie mniejsza klasa i zawiera tylko role zainstalowane na serwerze. Zapytania korzystające z funkcji Win32_Server powinny zwracać się znacznie szybciej.

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

Omówiono pewne wyjaśnienia dotyczące odpowiedzi dla scenariuszy lokalnych i zdalnych w związku z wydajnością. Pytający zapytał WMI, a jego przykład użył PowerShell do wywołania WMI. Korzystanie z WMI bezpośrednio z niezarządzanego kodu jest również szybsze.

Należy pamiętać, że podejścia te dotyczą skutecznie Server 2012 i Server 2012 R2 i mogą nie mieć zastosowania w przyszłych wersjach.

Niektóre kompromisy w zależności od scenariusza ... W większości przypadków Win32_ServerFeature jest preferowane jako rozwiązanie ogólne lub kontrola pliku lokalnego w mgnieniu oka.

• Lokalne sprawdzanie plików: szybkie i brudne. Bardzo mało ruchomych części.
• MSFT_ServerManagerDeploymentTasks: bazowy dostawca WMI używany przez Win32_ServerFeature i Get-WindowsFeature. Używa lokalnej pamięci podręcznej rejestru i zwykle zwraca bardzo szybko, chyba że nastąpiła zmiana konfiguracji od ostatniego zapytania. W przypadku braku pamięci podręcznej jest mniej więcej taki sam jak Win32_OptionalFeature. Jest to bardzo dobry interfejs, jeśli odpytujesz wiele maszyn w szybkiej sieci i potrzebujesz wielu szczegółowych informacji na temat relacji między komponentami i ich statusu - ale przy normalnym użytkowaniu jest to uciążliwe. Zamiast tego użyj Win32_ServerFeature.
• Win32_ServerFeature: Ogólnie najlepszy wybór dla lokalnych lub zdalnych zapytań, ale nie tak szybki jak sprawdzanie plików lokalnych. Zwraca tylko zainstalowane funkcje i powoduje niewielki ruch w sieci.
• Get-WindowsFeature: bardzo prosty w użyciu, zakładając, że używasz PowerShell jako części ścieżki wywoływania. W przypadku połączenia ze zdalnym celem powoduje to zwiększenie o ponad 400 KB w sieci, co jest przesadą, gdy chcesz tylko wiedzieć, czy konkretna funkcja jest zainstalowana.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: to zapytanie DISM na celu za każdym razem, co może być dość ciężkie.

Dotyczy to lokalnych i zdalnych scenariuszy online. Niektóre z powyższych będą również kierowane na obraz offline.

Pomyślałem, że włączę filtr WMI dla tego rozwiązania, abyś mógł zastosować obiekty GPO do systemów Core 2012+:

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

Aby przetestować to w wierszu polecenia:

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

Natknąłem się na ten wątek, próbując znaleźć sposób na utworzenie filtrów WMI dla serwerów Core 2012, iz jakiegoś powodu nie przyszło mi do głowy, aby WMI sprawdził Win32_OptionalFeature (a nawet, że taka ścieżka istnieje). Mam nadzieję, że to pomaga komuś innemu.

W systemie Windows Server 2012 R2 używam następującego, wydajność jest dobra, a jednocześnie całkiem wyraźna.

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