To core or not to core… Should it be a question?

If you are using Windows Server 2012 or higher, why not go core? I understand that server core has started badly with windows server 2008 R2. The idea itself was great, but it was too much of a hassle for most IT administrators. The problem already started by installing the operating system where you had the choice of an installation with UI, or one without. If you chose the latter, then you had to do configure everything in PowerShell or by the commandline. Actually, most needed to be done through the commandline as PowerShell support wasn’t that big yet before Windows Server 2012.

But probably the worst was the fact that you weren’t able to do everything remotely, and the server manager that existed in 2008 R2 wasn’t really something you could call a success. As a result, many have experimented with it, not many have actually implemented it. The main issue? Not the configuration, but when something went wrong, and you needed to troubleshoot (and under pressure) it was very difficult to get the job done in a timely manner (what was that command again to do that? How can I view those specific logs when I have no remote access to my machine?…)

Fast forward to 2012 and 2012 R2. Not only did server manager improve a lot (and got overhauled completely) but now you are also able to switch between UI, MinShell and Core. Wait, what? MinShell? Before I start talking about switching, you need to understand that there are four options in Windows Server 2012 and R2. Let’s have a look at them:

  • Core: Is literally the baseline of your server installation. It comes with a command prompt, and the possibility to start a PowerShell session.
  • MinShell (aka Minimal Shell): Has the baseline also, but comes with a limited amount of management tools such as server manager but not everything is available. You still have benefits over the UI version (see later) but less than the Core version. On the other hand, you can locally use some tools when necessary…
  • Server Graphical Shell (aka the GUI version): The full blown server version with all the management tools and UI’s as you are used to.
  • Desktop Experience: The UI version and the full desktop experience, like you would be running windows 8 (server 2012) or windows 8.1 (server 2012 R2). This is only used in RDP desktop configurations or VDI implementations. I don’t really see another good reason for installing a desktop experience on servers running other workloads.


If you want to convince someone to run server core or minshell, you need to have some good reasons why you would want to loose the entire UI (or partly in case of MinShell) functionality. The reasons are very simple, and very convincing…

  • Resource consumption: Since it is stripped down from all unnecessary components, the system will have more resources available for running the actual workload instead of wasting those to something that is not necessary. With core you will have more resource savings than with MinShell, but even then you save on resources compared to the UI. The footprint is also smaller with less OS files on the disk.
  • Security: Because a lot of components are away, the attack surface becomes smaller. In fact, we all know patching very well because of the many vulnerabilities in (for example) Internet Explorer. With no IE on the box, you have less attack surface and the risk of 0-day and other security holes are greatly reduced.
  • Reduced management: Less patching to start with, but also less components means less troubles and therefore less troubleshooting.

But management is still harder!

Yes, I know, the moment you loose the UI, the management becomes harder. But you can do almost anything remotely with the new RSAT tools and Server Manager, so that is not an issue anymore. On top of that, because it will force you NOT to RDP to the box anymore, you will save resources again. Double win Smile. But I do realize it isn’t that easy to start with. In fact, the first couple of days I worked with Server Manager, it annoyed me having to learn a complete new way of working, but after that, I honestly can’t say I want to go back to the previous way of working. Again…

But as stated in the beginning… What if there is a problem, and you can’t use your remote tools anymore. Then it is up to you and your commands. Let’s answer that question a bit further.


Does every workload run on core? No, unfortunately not. But that doesn’t mean that you shouldn’t use it for other workloads. Almost every core infrastructure service of Microsoft is supported, and the latest SQL server is supported also. For more information, you can go to

But the workload that interests us is Hyper-V of course. (Although I don’t see a good reason to run Hyper-V in core mode and then the workloads on it in full UI mode… But that’s another discussion

But management is still harder!

Yes, indeed, and as promised, I will write a bit more about that. To start with, I always make sure that I have my list of commands and PowerShell cmdlets with me. In my case I use OneNote that is shared over all of my devices, but it can be on a piece of paper, word, whatever you prefer. In case of an emergency, I can always use that ‘cheat-sheet’ to do my work. Let’s be honest here, I am a Bear, and every command that I don’t use on a daily basis I forget. And that is exactly why I have that cheat sheet Smile

And that is what I will start to share with you all in the upcoming posts… All of the things I need to successfully manage core, specifically Hyper-V core, and even much more. The next post we will start with the fact that you can switch from GUI to Core (or MinShell inbetween) and vice versa very easily, although it will require a reboot. Another great thing that came with 2012 and later and wasn’t in 2008 R2


To run core or not should not be a real question anymore. The only question you should ask is whether you can run the workload in core mode or not. If it is possible, then you should. Is management a bit harder? Certainly, but with the right tools and the right set of commands and cmdlets available, you should have no issues with that. And that is what we are going to provide…

Till then


Hyper-V Bear


Hyper-V Reporting Script!

My first blog post and it is not even something specific from myself… But sometimes you just have to write about something you discovered on the web, and that is just fantastic… I am a big fan of PowerShell (OK, I am a huge fan of Hyper-V first, but I like to do as much as possible with PowerShell so automatically I am a fan of PowerShell also Winking smile) and one of the Hyper-V MVP’s has written a PowerShell script that is absolutely brilliant.

The MVP, Serhat AKINCI ( or has built a PowerShell script of over 2600+ lines that contains PowerShell, HTML, CSS and WMI. It produces a very nice HTML webpage with lots of information about your hyper-v environment.

The script requires an AD membership and runs on a cluster or standalone hosts for Windows Server 2012 (R2) and Hyper-V server 2012 (R2). It does have a few more requirements such as PowerShell 3.0 or 4.0 but some modules but mostly these will be already installed, unless you will be running the script remotely from a workstation.

It supports parameters also. The script, called Get-HyperVReport.ps1, accepts the following parameters:

  • -Cluster <nameofcluster>. This will give you the information about your cluster.
  • -Cluster <nameofcluster> –HighlightsOnly. This will give you only highlighted events and alerts
  • -VMHost <nameofhost>. This will give you the report for the host, and if you want a report for multiple hosts you can user <nameofhost>, <nameofhost2>, <nameofhost3>
  • -Cluster <nameofhost> -SendMail $true -SMTPServer -SMTPPort 587 –MailFrom <email-adress> –MailFromPassword <password> -SMTPServerTLSorSSL $true -MailTo, This will send the report through an SMTP server (pwd protected in this case) to different recepients.

But of course, the most interesting thing is to find out what kind of data this report generates (and it is A LOT). For this report, I used a standalone host to see what it delivers


First you get the information about the host. data such as State, Uptime, the domain, the # of VM, # of CPU, Used, Free and Total RAM are displayed as well (see the little asterisks) some additional info.


The second table gives you more information about your disks such as State, Usage, Owner, Bus Type and many more. Again valuable information that can be used in your CMDB if necessary. Normally this doesn’t change a lot, but for example the last column will tell you the percentage free. If you run this script regularly (or maybe schedule it or so…) you can follow what is happening with your storage.


The last table will give you your VMs and their information such as generation, clusteredresource or not, state, uptime, vCPU, vRAM (including Min/Mx and Assigned) and so on…

A much larger report with more different states can be viewed on the website of the author himself: and if you are interested (and you should Winking smile) then you can get all the information and download from here:

If you are running a Hyper-V environment, and you don’t have a monitoring tool in place, this certainly will be of use. Even if it is run on an irregular base. Of course it is not a replacement for a monitoring solution, but I am convinced it will come in handy for a specific reason Winking smile

Enjoy the script, and do sent feedback to the author (and maybe even enhancement requests? Smile)


Hyper-V Bear