Identifique o núcleo do Windows 2012 Server


18

Quero detectar se um servidor de 2012 está configurado como uma instalação Core usando o WMI. Uma pergunta anterior, parece indicar que posso obter o OperatingSystemSKU do Win32_OperatingSystem . Meus sistemas Windows 2012 Core estão relatando um OperatingSystemSKU de 7. O artigo da outra pergunta parece indicar um PRODUCT_STANDARD_SERVER e, se tiver uma instalação principal, espero ver um valor 0x0000000D em vez de PRODUCT_STANDARD_SERVER_CORE.

O que estou perdendo aqui. Eventualmente, quero criar uma política e usar a segmentação no nível do item para aplicar somente essa política às instalações do 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

Como um pequeno desvio para sua pergunta ... Como alguém definiria o núcleo do servidor? Eu li que o núcleo do servidor é o mesmo com menos um ou dois recursos instalados (a GUI). Você não poderia consultar isso?
— Joao

Se você puder fornecer uma resposta sobre como detectar esse recurso está instalado via WMI, eu o votaria e o testaria. Qualquer resposta que possa ser usada para identificar o núcleo do servidor com o WMI seria útil na minha opinião.
— Zoredache

Tente usar o WMI nas máquinas remotas. Get-WMIObject Win32_OptionalFeature | Select Name, InstallStatee filtre se o servidor tem os bits da GUI do servidor instalados ou não.
— Ryan Ries

Respostas:


24

No PowerShell:

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

retorna 1 em um servidor completo e 2 em uma instalação principal do servidor.

Editar:

Embora minha resposta acima esteja correta, há dois problemas:

  1. Ao usar esse comando em uma estação de trabalho, ele não retorna nada; portanto, você deve adicionar uma verificação extra para isso.

  2. É lento, quando tentei, demorou entre 600 e 3500 milissegundos.

Portanto, a abordagem mais pragmática é apenas verificar a existência de um determinado arquivo:

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

Isso retorna $falsepara instalações do Server Core e $truepara todas as outras e leva um milissegundo para ser executado.


Ótima resposta - eu particularmente gosto da solução alternativa que você oferece com todas as explicações;) Perfeito.
— TomTom

6

Engraçado, esse artigo do MSDN que você vinculou continha a resposta:

Os valores PRODUCT _ * _ SERVER_CORE não são retornados no Windows Server 2012.

Isso ocorre porque o Server 2012 pode ser convertido livremente entre a instalação "Server Core" e a instalação "completa" simplesmente adicionando ou removendo os recursos apropriados.

Você deseja verificar a presença ou ausência desses recursos (por exemplo, Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).


5

Como a GUI é apenas um recurso, você pode consultar a lista de recursos instalados

Apenas testar isso no PowerShell em um servidor aqui funcionou bem o suficiente:

Despejar uma lista de recursos para pegar o nome

Get-WmiObject Win32_OptionalFeature > features.txt

A pesquisa no texto de features.txt me diz que o recurso se chama 'Server-Gui-Mgmt' (outros recursos também podem ser instalados como Michael observa em sua resposta, para que você possa testá-los também), e podemos pesquisar para ver se estiver presente

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

insira a descrição da imagem aqui


2

Eu suspeito que, uma vez que eles são essencialmente os mesmos em 2012, com apenas alguns recursos opcionais para diferenciá-los, você pode consultar os recursos.

este artigo é uma referência para a classe Win32_OptionalFeature, que permitirá que você consulte os recursos. Os recursos opcionais são definidos como Server-Gui-Mgmt-Infra, Server-Gui-Shell e Desktop-Experience, conforme descrito neste artigo .

Você pode consultar os três deles e usar a lógica booleana AND e NOT para selecionar servidores que não possuem nenhum desses recursos instalados.


2

Eu usaria o Win32_ServerFeature, é uma classe muito menor e contém apenas as funções instaladas no servidor. Consultas usando o recurso Win32_Server devem retornar muito mais rapidamente.

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

2

Alguns esclarecimentos sobre as respostas para cenários locais e remotos à medida que o desempenho foi discutido. O interlocutor perguntou ao WMI e seu exemplo usou o PowerShell para invocar o WMI. Usar o WMI diretamente de código não gerenciado também é mais rápido.

Observe que as abordagens se aplicam efetivamente ao Server 2012 e Server 2012 R2 e podem não se aplicar a versões futuras.

Algumas desvantagens dependendo do seu cenário ... Na maioria dos casos, o Win32_ServerFeature é preferido como uma solução geral ou a verificação de arquivo local com uma pitada.

  • Verificação local de arquivos: rápida e suja. Muito poucas peças móveis.
  • MSFT_ServerManagerDeploymentTasks: o provedor WMI subjacente usado pelo Win32_ServerFeature e Get-WindowsFeature. Ele usa um cache de registro local e normalmente retorna muito rapidamente, a menos que haja uma alteração na configuração desde a última consulta. No caso de falta de cache, é quase o mesmo que Win32_OptionalFeature. Essa é uma interface muito boa se você estiver consultando muitas e muitas máquinas em uma rede rápida e precisar de muitos detalhes sobre as relações dos componentes e seu status - mas, para uso normal, é uma dor. Use Win32_ServerFeature em vez disso.
  • Win32_ServerFeature: Geralmente, a melhor opção para consultas locais ou remotas, mas não tão rápido quanto a verificação do arquivo local. Retorna apenas os recursos instalados e coloca pouco tráfego na rede.
  • Get-WindowsFeature: Muito simples de usar, supondo que você já esteja usando o PowerShell como parte do seu caminho de chamada. Ao chamar contra um destino remoto, isso gera mais de 400 K na rede, o que é um exagero quando você só quer saber se um recurso específico está instalado.
  • Win32_OptionalFeature / Get-WindowsOptionalFeature: consulta o DISM no destino toda vez que pode ser bastante pesado.

Isso abrange cenários locais e remotos on-line. Algumas das opções acima também terão como alvo uma imagem offline.


1

Eu apenas pensei em usar um filtro WMI para esta solução, para que você possa aplicar GPOs aos sistemas Core 2012+:

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

Para testar isso na linha de comando:

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

Eu tropecei nesse segmento ao tentar encontrar uma maneira de criar filtros WMI para servidores Core 2012 e, por algum motivo, não me ocorreu que o WMI verifique o Win32_OptionalFeature (ou, de fato, esse caminho existe). Espero que isso ajude outra pessoa.


0

No Windows Server 2012 R2, estou usando o seguinte, o desempenho é bom e ainda é bastante explícito.

$gui = (Get-WindowsFeature -Name 'Server-Gui-Shell').Installed
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.