Starting with core… Or full UI?

This is a question I get a lot, should I start with windows server core? Or should I install it with a UI, configure it, and then go to core. As always in Tech world… It depends. If you can deploy machines with the right settings (domain join, network settings, firewall settings, rdp settings, storage config…), in other words, the baseline image that matches your environment, then why should you bother using the UI in the first place. After the initial deployment, you connect with your remote server manager and tools (that’s a topic for later on…) and you are good to go and can continue doing what you need to do.

Unfortunately, not everyone has that possibility and today there are still a lot of companies that need to deploy manually, or have a very basic baseline and still need to configure additional settings depending on what role the server will take. In that case, unless you like to configure everything through commands and PowerShell, I advice to start in UI mode.

As I said in my previous post there is the possibility to switch to another mode. Since server core is kind of the underlying server stack and the MinShell and full UI are more or less roles on top of that, you can remove (or add) those roles very easily.

So let’s go back to our example. We have deployed windows server with the UI using your preferred deployment method, you have added the Hyper-V role on top of it (although this can be done remotely also…) and configured the storage connections, network connections and everything else you need to do. Now the only thing left to do is patching and your server is ready for use…

OK, I don’t agree on the patching part… As we said in the previous post there will be less patches when you are running in Core mode, so why go through the trouble of patching an entire server while you can do it when it is in core mode so you need to do less patching and loose less time. I’ll come back to that. First, I want to go to core with my full-blown server.

There are two ways to remove these roles… (There are actually three, you can also use DISM but I’ll skip this one…). You have the UI way, and the PowerShell way. Note that you only can use the UI way when you are actually using a UI, so it is certainly better to learn how to do it in PowerShell.

The UI way

For the UI way, it is very simple. Go to Remove Roles and Features (from Server Manager for example), select your server, go over the Server Roles and when you  are at the Features page of the wizard, you will find User Interfaces and Infrastructure

image

Deselect Graphical Management Tools and Infrastructure and Server Graphical Shell. Note that it is perfectly possible that you will get a warning that certain other features and roles need to be de-installed also. If you installed the Hyper-V role and the tools, the tools need to be removed. If you have PowerShell ISE running, it will need to be removed… And there are  other features, tools and roles that can’t run on a core server. In that case, review the box very well and make sure you are not removing a component that is actually needed on that server. In that case, this server is not meant to be core Smile

Finish the wizard, know that it will reboot afterwards and then you are in core mode.

The PowerShell way

For the PowerShell way, it is actually also very simple.

Import-module servermanager
Uninstall-windowsfeature -name Server-GUI-Mgmt-Infra,Server-GUI-Shell
RESTART-Computer

Note that you probably won’t need to use the Import-Module CmdLet because you probably will run this directly on the server. And the last command is necessary to restart the computer, but I am sure you know other ways to do this Winking smile

But let me give some more background. To know what kind of roles and features are installed, you can simply type in a PowerShell window the  command Get-WindowsFeature

image

As you can see in the screenshot above, you get all the roles and features listed with upfront some sort of checkbox. When there is an X between the  brackets [X] it means the role / feature is installed. So when I scroll down I will find this:

image

In this screenshot you see that Server Graphical Shell and Graphical Management Tools and Infrastructure is installed.

To make it a bit more easier, we can search more granular and use

Get-WindowsFeature -name *GUI*

image

And now for the updates

After the restart, we have our core server running… Now on to the patching part as I promised. I am sure that many of you will have a favorite method of patching, but in case you want to do it manually…

I could say PowerShell again, but unfortunately, for some dark reason MSFT did not put this functionality in PowerShell (yet?). Now you can download this module https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc and use PowerShell anyway, but when you are a bit like me, you don’t like additional stuff being installed on a server so I like to use other methods.

But in the end, it is still very simple. Open a RDP connection to server core, and type in sconfig in the command prompt

image

Press number 6

image

Choose A for all updates or R for recommended updates and let the script do its magic.

image

Now you can choose which updates  you want to install… Choose A for all updates, N for no updates or select a specific one by using S

image

Finally you will be able to reboot after the installation.

Enjoy

Cheers

Hyper-V Bear

Advertisements

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.

Benefits?

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.

Workloads?

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 http://technet.microsoft.com/en-us/library/hh831786.aspx

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

Conclusion

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

Cheers

Hyper-V Bear