Определите ядро Windows 2012 Server
Если копия будет записана в файловую систему, в противоположность записанному к памяти, то будут соответствующие записи журнала событий. Однако Вы не можете ожидать, что единственная четкая запись скажет Вам, что произошло. например, удаление является на самом деле тремя отдельными операциями насколько вход идет. Я не уверен, каким количеством отличных операций копия будет всего лишь, я ожидал бы не менее чем шесть. Если какая-либо из операций не была зарегистрирована затем, операция копии была, вероятно, не успешна. Я предлагаю, чтобы Вы спросили относительно Переполнения стека, поскольку аспект кодирования этого немного выходит за рамки этого сайта.
В 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 для все остальные, и для их выполнения требуется одна миллисекунда .
As the GUI is just a feature, you can query the list of installed features
Just testing this in powershell on a server here worked well enough:
Dump a list of features to grab the name
Get-WmiObject Win32_OptionalFeature > features.txt
Searching the text of features.txt tells me that the feature is named 'Server-Gui-Mgmt' (other features may be installed too as Michael notes in his answer, so you can test for those too), and we can search to see if that's present
Get-WmiObject -query "select * from Win32_OptionalFeature where name = 'Server-Gui'"
Я подозреваю, что, поскольку в 2012 году они практически не изменились с несколькими дополнительными функциями, чтобы выделить их, вы можете вместо этого запросить эти функции.
эта статья является справочной. для класса Win32_OptionalFeature, который позволит вам запрашивать функции. Дополнительные функции определены как Server-Gui-Mgmt-Infra, Server-Gui-Shell и Desktop-Experience, как описано в этой статье .
Вы можете запросить 3 из них и использовать логическое значение Логика И и НЕ для выбора серверов, на которых не установлена ни одна из этих функций.
Забавно, эта статья MSDN, на которую вы ссылались, содержала ответ:
Значения PRODUCT _ * _ SERVER_CORE не возвращаются в Windows Server 2012.
Это связано с тем, что Server 2012 можно свободно преобразовать между «Server Core» и «полной» установкой, просто добавив или удалив соответствующие функции.
Вам может потребоваться проверьте наличие или отсутствие этих функций (например, Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).
Я просто подумал, что подключусь к этому решению с помощью фильтра 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 (или действительно, что такой путь существует). Надеюсь, это поможет кому-то другому.
Я бы использовал 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 на цели каждый раз, что может быть довольно тяжелым.
Это касается локальных и удаленных сетевых сценариев. Некоторые из вышеперечисленных также предназначены для автономных изображений.
В Windows Server 2012 R2 я использую следующее, производительность хороша и в то же время достаточно очевидна.
$gui = (Get-WindowsFeature -Name 'Server-Gui-Shell').Installed