Identifique o núcleo do Windows 2012 Server

18

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

O que estou perdendo aqui. Eu, eventualmente, quero criar uma política e usar a segmentação no nível de item para aplicar apenas 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
    
por Zoredache 06.08.2013 / 21:25

8 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 este comando em uma estação de trabalho, ele não retorna nada, então você precisa adicionar uma verificação extra para isso.

  2. É lento, quando eu tentei, demorei 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 $false para instalações do Núcleo do Servidor e $true para todos os outros e leva um milissegundo para ser executado.

    
por 06.08.2013 / 21:41
6

Engraçado, o artigo do MSDN vinculado continha a resposta:

PRODUCT_*_SERVER_CORE values are not returned in 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ê desejará verificar a presença ou ausência desses recursos (por exemplo, Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

    
por 06.08.2013 / 21:33
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:

Faça o download de uma lista de recursos para pegar o nome

Get-WmiObject Win32_OptionalFeature > features.txt

A pesquisa no texto do features.txt informa que o recurso se chama 'Server-Gui-Mgmt' (outros recursos podem ser instalados também, como Michael observa em sua resposta, para que você possa testá-los também). pesquise para ver se isso está presente

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

    
por 06.08.2013 / 21:47
2

Eu suspeito que, como eles são essencialmente os mesmos em 2012, com apenas alguns recursos opcionais para separá-los, você poderia 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 em este artigo .

Você pode consultar os 3 deles e usar a lógica Booleana AND e NOT para selecionar servidores que não possuam nenhum desses recursos instalados.

    
por 06.08.2013 / 21:43
2

Eu usaria 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 rápido.

Get-WmiObject -Query "Select * FROM Win32_ServerFeature WHERE Name = 'Server Graphical Shell'" 
    
por 02.11.2015 / 16:16
2

Alguns esclarecimentos sobre as respostas para cenários locais e remotos como desempenho foram discutidos. O questionador perguntou ao WMI e seu exemplo usou o PowerShell para chamar o WMI. Usar o WMI diretamente de código não gerenciado também é mais rápido.

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

Alguns trade-offs dependem do seu cenário ... Na maioria dos casos, o Win32_ServerFeature é preferido como uma solução geral, ou o arquivo local é checado.

  • Verificação do arquivo local: rápida e suja. Muito poucas partes móveis.
  • MSFT_ServerManagerDeploymentTasks: o provedor WMI subjacente usado por Win32_ServerFeature e Get-WindowsFeature. Ele usa um cache de registro local e normalmente retorna muito rapidamente, a menos que haja uma alteração de configuração desde a última consulta. No caso de falha no cache, é quase o mesmo que Win32_OptionalFeature. Esta é uma interface muito boa se você está consultando muitas e muitas máquinas em uma rede rápida e precisa de muitos detalhes sobre relacionamentos de componentes e seu status - mas para o uso normal é uma dor. Use Win32_ServerFeature em seu lugar.
  • Win32_ServerFeature: Geralmente, a melhor opção para consultas locais ou remotas, mas não tão rápida quanto a verificação de arquivos locais. 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 de seu caminho de chamada. Ao chamar um alvo remoto, isso gera mais de 400K na rede, o que é um exagero quando você quer apenas saber se um recurso específico está instalado.
  • Win32_OptionalFeature / Get-WindowsOptionalFeature: isso consulta o DISM no destino toda vez que pode ser bem pesado.

Isso abrange cenários locais e remotos online. Algumas das opções acima também segmentarão uma imagem off-line.

    
por 14.09.2016 / 02:40
1

Acabei de pensar em usar um filtro WMI para essa solução, para que você possa aplicar os 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 thread ao tentar encontrar uma maneira de criar filtros WMI para servidores Core 2012 e, por algum motivo, não ocorreu a mim que o WMI verificasse Win32_OptionalFeature (ou, na verdade, que esse caminho existe). Espero que isso ajude alguém.

    
por 25.11.2014 / 15:39
0

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

$gui = (Get-WindowsFeature -Name 'Server-Gui-Shell').Installed
    
por 08.06.2016 / 23:15