Identify Windows 2012 Server core

Question

I want to detect if a 2012 server is has been setup as a Core install using WMI. An earlier question, would seem to indicate that I can get the OperatingSystemSKU from Win32_OperatingSystem. My Windows 2012 Core systems are reporting a OperatingSystemSKU of 7. The article from the other question would seem to indicate is a PRODUCT_STANDARD_SERVER, and if had a core install I should expect to see a value of 0x0000000D instead for PRODUCT_STANDARD_SERVER_CORE.

What am I missing here. I eventually want to create a policy and use item level targeting to only apply that policy to Windows 2012 Server Core installs.

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

Solution 1

In PowerShell:

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

returns 1 on a full server and 2 on a server core install.

Edit:

While my answer above is correct, there are two problems with it:

1. When using this command on a workstation, it returns nothing, so you have to add an extra check for this.

2. It is slow, when I tried it, it took between 600 and 3500 milliseconds.

So the more pragmatic approach is to just check for the existence of a certain file:

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

This returns $false for a Server Core installations and $true for all others and it takes one millisecond to execute.

Solution 2

Funny, that MSDN article you linked contained the answer:

PRODUCT_*_SERVER_CORE values are not returned in Windows Server 2012.

This is because Server 2012 can be freely converted between "Server Core" and "full" installation simply by adding or removing the appropriate features.

You will want to check for the presence or absence of those features (e.g. Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience).

Solution 3

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'"

Solution 4

I would use Win32_ServerFeature, it is a much smaller class and only contains the roles installed on the server. Queries using Win32_Server feature should return much quicker.

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

Solution 5

Some clarification on the answers for local and remote scenarios as performance was discussed. The questioner asked WMI, and his example used PowerShell to invoke WMI. Using WMI directly from unmanaged code is also quicker.

Please note that the approaches apply effectively to Server 2012 and Server 2012 R2, and may not apply to future releases.

Some trade offs depending on your scenario... For most cases, Win32_ServerFeature is preferred as a general solution, or the local file check in a pinch.

• Local file check: quick and dirty. Very few moving parts.
• MSFT_ServerManagerDeploymentTasks: the underlying WMI provider used by Win32_ServerFeature and Get-WindowsFeature. It uses a local registry cache and normally returns very quickly unless there's been a configuration change since the last query. In the event of the cache miss, it's about the same as Win32_OptionalFeature. This is a very good interface if you're querying lots and lots of machines on a fast network and need lots of details about relationships of components and their status - but for normal use it's a pain. Use Win32_ServerFeature instead.
• Win32_ServerFeature: Generally the best all around choice for local or remote queries, but not as fast as the local file check. Returns only installed features, and puts little traffic on the network.
• Get-WindowsFeature: Very simple to use, assuming you're already using PowerShell as part of your calling path. When calling against a remote target, this puts upwards of 400K across the network which is overkill when you just want to know if a specific feature is installed.
• Win32_OptionalFeature / Get-WindowsOptionalFeature: this queries DISM on the target every time which can be pretty heavy.

That covers online local and remote scenarios. Some of the above also will target an offline image.

View more solutions

Comments

[john]

As a slight deflection to your question... How would one define server core? I read that server core is just the same with one or two less features installed (the GUI). Could you not query for that instead?

[TomTom]

Great answer - I particularly like the workaround you offer with all explanations ;) Perfect.