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=@
__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 6, 2013 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 6, 2013 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 6, 2013 at 19:33

8 Answers 8


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.


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.

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

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


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


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

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.


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.


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.