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

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? — john, Aug 06 '13 at 19:30
If you can provide an answer on how to detect that feature is installed via WMI, then I would upvote it, and test it out. Any answer that can be used to identify Server core with WMI would be helpful in my opinion. — Zoredache, Aug 06 '13 at 19:33
Try using WMI on the remote machines. `Get-WMIObject Win32_OptionalFeature | Select Name, InstallState` and filter on whether the server has the server GUI bits installed or not. — Ryan Ries, Aug 06 '13 at 19:33

Peter Hahndorf · Accepted Answer · 2013-09-29T08:04:05.220

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:

When using this command on a workstation, it returns nothing, so you have to add an extra check for this.
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.

Great answer - I particularly like the workaround you offer with all explanations ;) Perfect. — TomTom, May 28 '14 at 12:09

score 6 · Answer 2 · answered Aug 06 '13 at 19:33

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).

score 5 · Answer 3 · answered Aug 06 '13 at 19:47

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

enter image description here

Icolan · Answer 4 · 2015-11-02T15:25:01.520

3

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

edited Nov 02 '15 at 15:25

answered Nov 02 '15 at 15:16

Icolan

31
3

score 2 · Answer 5 · answered Aug 06 '13 at 19:43

I suspect that since they are essentially the same in 2012 with just a few optional features to set them apart, you could query the features instead.

this article is a reference for the Win32_OptionalFeature class, which will allow you to query the features. The optional features are defined as Server-Gui-Mgmt-Infra, Server-Gui-Shell and Desktop-Experience, as outlined in this article.

You can query for the 3 of them and use Boolean AND and NOT logic to select servers which have none of these features installed.

Matthew Wetmore · Answer 6 · 2017-06-05T15:35:19.843

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.

score 1 · Answer 7 · answered Nov 25 '14 at 14:39

I just thought I'd chime in with a WMI Filter for this solution, so you can apply GPOs to Core 2012+ systems:

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

To test this on the command line:

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

I stumbled on this thread when trying to find a way to create WMI Filters for Core 2012 servers, and for some reason it didn't occur to me to have WMI check Win32_OptionalFeature (or indeed, that such a path exists). Hope this helps someone else.

score 0 · Answer 8 · answered Jun 08 '16 at 21:15

0

On Windows Server 2012 R2, I'm using the following, performance is good while still being quite explicit.

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

answered Jun 08 '16 at 21:15

Jules Clements

201
2
8

Identify Windows 2012 Server core

8 Answers8

Linked