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.
Welcome back to the Pro Tech Show - the place for tech, tips, and advice for IT pros and
decision makers. Alright then. 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. Now 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 affected 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. By the way, if you find this sort of content useful then
give it a like, and don't forget to subscribe for future videos. Let's talk
about updates. 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. Let me show you.
I've put together a quick lab for this with two servers. On the left we have
Windows Server with the Desktop Experience, and on the right we have Windows Server
Core. To show you how you can manage each of them, I'm going to install the DNS
server role and create a DNS record. Let's start with the Desktop Experience.
From server manager I'm going to add the DNS role and click my way through the
wizard.
This shouldn't take too long, but I'll skip the end to save time. All right,
here we are. You can see the server has the DNS role installed now and I can
open the DNS manager to administer it. Let's quickly add a DNS zone.
And then we can add a record as well.
There we go - nice and easy. Now, let's see how we do the same with Server Core. As
you can see, all you get here is the command line. If I want to administer this
server directly I can do so here. I can switch to PowerShell and install the DNS
server role like so. That's not particularly difficult, but managing the
records can be a bit of a pain so I'm not going to do this. I'm going to log
off and go back to my Desktop server. Now I'm back in server manager, and I'm going
to go to "all servers" and add my Core server.
Once it refreshes, I'm able to manage both servers from the same place. once I've
done that, I can basically repeat the process from before. The only thing I
need to do differently, is remember to select my Core server from the list. Then
it's the same wizard to install the DNS server role.
We've skipped the end again, and you can see both servers now showing as having the
DNS role installed. In the same way I can open DNS manager to administer my
Desktop server, I can do exactly the same thing to manage my Core server. Let's
add a zone to this one too.
And a DNS record as well. The process is exactly the same,
I'm just running the 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 behaviour 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. Now I've shown you how managing Server Core can be
virtually the same as managing the desktop version; but that is when I was
on the same domain and network. 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.
Now 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. Something else you might want to consider, is clicking on one of
these videos over here. Let's face it, if you're still watching I mustn't have done a
terrible job, and you might enjoy one of these as well. If you found this video
useful, then give it a thumbs-up before you go, and don't forget to subscribe for
future videos. Thanks for watching, guys. See you next
time!