If you've ever installed Windows Server you'll have been presented with two options. There's the one that used to be called "Server Core" and there's one that's now called the "Desktop Experience". Most people go ahead and hit the second option, because who wants Windows without the actual windows, right? Well... you might want to give it some thought.
What is Windows Server Core, and why might you want to use it? Windows Server Core is Windows Server, without the graphical user interface. When you log on you get a command prompt and nothing else. For a lot of windows admins that could be a shock, but for a large proportion of the world servers... that's completely normal. Yes, Linux admins, you have every right to chuckle; because you were doing command-line only before it was cool.
Microsoft obviously agree there's merit to the approach, because they are now pushing Server Core as the default and recommended installation type for Windows Server. But why? Why would a Windows admin want to reverse decades of progress and go back to DOS? Well, firstly it's not DOS; and secondly, there are some real advantages.
The primary reason for Windows Server Core's existence is security. When it was first released, Microsoft calculated that in the previous five years, 70% of the security vulnerabilities that were discovered would not affect Windows Server Core. By stripping away all of the graphical components that aren't strictly necessary for the running of the server, you drastically reduce its attack surface.
Consider this example. There have been many, many security vulnerabilities discovered over the years in web browsers; a lot of which can be triggered just by visiting a compromised website. You load the webpage, your browser loads malicious code, and now your computer is compromised. If that happens on a server the results can be pretty dire, but you shouldn't really be browsing the internet on a server anyway - it's not there to do your online shopping or to check up on Facebook. Solution? Remove the web browser. You didn't actually need it in the first place, and now it can't be exploited.
Windows Server Core takes that same logic and extends it to every non-essential graphical component on the server. Now let's face it: on a server most graphical components are non-essential. At most, you use them to administer the server occasionally, but most of the time the server just sits there chugging away by itself without any display even attached to it. Which is kind of wasteful really. A graphical interface consumes resources. It eats memory, it uses CPU cycles, it takes up disk space. 99% the time you're not getting any benefit from it, but it's costing you money just by being there. If you can remove those graphical components you free up resources for more important tasks.
In theory that can lead to better performance, but these days you might see more benefit from being able to reduce the size of your server instead. With virtualization technology a smaller per-server footprint allows you to run more servers on fewer hosts - potentially saving you money on hardware. The cost saving is even more apparent in the cloud, where you're billed for resources used over time. If you can reduce the size your servers by going Core it can make a lot of sense. Otherwise, you're just paying for a bigger server in order to host a graphical interface, that most of time you're not even using.
A benefit that's often claimed with Windows Server Core is reduced maintenance; and when it first came out that was definitely true. That was back in the day when Windows updates were delivered as a whole pile of individual updates. Windows Server Core didn't have the graphical components so there was less to patch. That meant each month you got fewer updates, and on some months you didn't get any, and that was great. These days it doesn't really hold true so much, because these days Windows updates are delivered as one big cumulative update; and you have to install that one big update regardless of how many components you're actually using that got patched. That really negated a lot of the benefit of going Windows Server Core for reduced maintenance. The benefits these days are definitely around security, followed by cost, and then performance.
But hold on! This is Windows, not Linux. Wouldn't removing the graphical components cripple functionality? Well, in the early days, yeah. When Server Core first came out with Windows Server 2008. it didn't include the likes of .NET or PowerShell, which seriously limited what you could do with it. It's worth mentioning that in those early days Server Core wasn't the recommended installation option, as it is now. The inclusion of PowerShell in particular has made Server Core a lot more practical. If you haven't noticed, a lot of Microsoft's applications these days are preferring the use of PowerShell over their graphical tools. By that I mean the graphical tools can only configure a subset of options compared to PowerShell. If you spend enough time in Skype, Exchange, or System Center for example; then at some point you're going to have to break out the command line. In a world where the command line is more powerful than the graphical tools, Server Core makes a lot of sense. PowerShell has made Server Core a lot easier to administer directly, but this is Windows, and Windows has always been about the graphical tools. That hasn't changed. You just run them on your workstation instead of the server. The process is exactly the same, you just need to run management tools on a different machine.
As you can see, the sort of tasks you typically do in a graphical interface can still be done in a graphical interface. You just don't log on to the server to do it. In a lot of ways, Server Core enforces good practice. Now that's face it: logging on the server to click buttons was never really best practice in the first place; and it leads to people using the server like their own personal desktop.
Those of you who've worked with me will know how much I hate logging on a server and finding like three new web browsers installed. I don't care if you prefer Chrome and you prefer Firefox. This is the server, not your personal playground. I can't count the number of times I've heard of a critical system going down, and the root cause was some admin who'd left the session open, with lots of unnecessary tools that had slowly gobbled up the server's memory. Honestly, one of the most underrated advantages of Server Core is that it nips that kind of behavior right in the bud. I mean, I have suggested adding electrodes to mice and shocking people who don't log off... but apparently that might lose us some customers.
From what I've seen, this tends to be more of a problem in smaller environments, and when you get to really large environments then you're frankly not going to have time to keep logging on to individual servers, anyway. At that scale, you've probably invested in automation, and what does automation use? It uses command line and APIs. Not a graphical interface. So at that scale, why waste the resources and one?
It's not all sunshine and roses though. There are a number of applications that simply won't ron on Windows Server Core, because they assume the existence of certain files or the ability to run a local management console. Microsoft suggests you should challenge such backward vendors to update their apps. Which is ironic... because Microsoft are one of the biggest offenders! Even today, a number of their flagship products still won't run on Windows Server Core. There is a sort of middle ground where you can install a limited set of graphical apps, but not the full graphical interface; but you should talk to individual vendors to make sure you're not invalidating in your support.
Another thing you may need to consider is remote support - particularly if you've outsourced to a third party. If you've outsourced to a third party, chances are they're not on your network or your domain. In fact the only access they might have to the server could be via some kind of remote desktop connection. If that's the case, then maintaining a certain number of jump boxed for the third party to log on to and use could be a good compromise.
If they know what they're doing then this shouldn't be a deal-breaker, and they should be able to resolve any issues from the command line anyway; but let's be sensible for a minute. Most Windows admins are more familiar with the graphical tools than the command line; and if you don't know exactly what you're looking for, then reading back Windows Event logs from the command line can be a pretty horrible experience. Whether they can support it this way isn't really the point. If you've got an outage, you want your support people working as quickly as possible - not fighting against a lack of tools. So an element of pragmatism here can be sensible.
So, should you go Windows Server Core? Well, let me flip that around for a minute and ask "Why wouldn't you go Server Core?". There are genuine reasons. If you have software compatibility issues, remote support challenges, or skills gaps, then those are real issues that might prevent you going Server Core. If they don't apply, then Server Core is more secure than the Desktop Experience; and that is a pretty compelling reason to consider it.