Windows Server 2016 Nano Server – Just enough OS model

We are in 2017 now, and it’s about fourth month since Windows Server 2016 has been RTMed in September 2016. By now, everyone probably heard about one of the big new features of Windows Server 2016 – Nano Server, new installation option which you can’t select during setup 🙂 . But I think there is still a lot of “why” and “how” questions around Nano Server. In this blog post, I will try to provide a bit of a history and compare Nano Server with other installation types.

You can think of Nano Server as a “just enough OS” to run your workloads. Nano Server is extremely lightweight even if compared with Server Core installation option combined with Features on Demand. And in case you wondering why it is not listed in Windows Setup wizard this is because image must be customized with drivers (just enough OS means just enough drivers too, even guest drivers are not included in default image and are injected when you prepare an image for VM deployment).

In response to industry trends (cloud, virtualization, containers) and to changes in the overall approach towards the way we think about infrastructure and applications, Microsoft changes the way we think about base OS with intent to make it more agile and flexible in the form of Nano Server which is a zero footprint, purpose-built version of Windows Server 2016. But to get a full picture it is worth looking at all possible Windows Server installation options we have today and their history.

Starting from Server 2016 your installation options for Windows Server include Full Server, Server Core, and Nano Server. Full Server is something we all know for a long time: it has full GUI along with 32/64 bit support along with all roles and features and this results in large VHD size, long setup time, and what is even worse, it also implies large attack surface. Building robust and convenient GUI took a while for Microsoft but by the time this GUI become highly developed and addictive to the most IT professionals (optimistic person can replace most with some here) it also become clear that server GUI is poison: it hogs limited server resources and increases attack surface when it is run on server. Somewhat less obvious problem with server GUI is that sometimes it hinders building remote management tools: some business logic becomes so ingrained into GUI that it makes difficult to make remote management tools decoupled from locally running GUI, creating a trap which makes it impossible to get rid of GUI on the server, and move completely to remote GUI only. Just because certain things can be accomplished only when you log on and use GUI locally. In addition to this, clients keep assailing Microsoft with questions on how can they get rid of things on Windows Server which are not needed for primary workload/service running on it, yet cannot be removed completely. This lead Microsoft to commence their work on Server Core, which started in 2004.

In terms of building/development approach, Microsoft builds Server Core starting from the top, i.e. by removing GUI and other things from Full Server and end final version was released with Windows Server 2008. Server Core has been a bit of a shock after about 30 years of life with constantly evolving Windows GUI when it was so abruptly removed. And that discomfort so scared lazy admins that despite all obvious benefits, like reduced attack surface and installation foot-print, they were reluctant to use this installation option. It took adding ability to move back and forth between GUI and Core along with an ability to have a compromise in the form of Minimal Server Interface for those indecisive persons preferring sitting on the fence. Server 2012/2012 R2 attempted to took this even a bit further with Features on Demand option – name of this feature is a bit counterintuitive, but essentially it allows you to remove unused features completely with binaries so that there is no trace of them on your local disk. To me, the important factor of making Core palatable was an evolution of PowerShell which is now mature enough to make administrator’s life convenient irrespectively of the presence of GUI. With Server Core the predominant philosophy is that GUI is good when you run it remotely (crash of GUI management tool on a client or reboots to patch it do not add up to services downtime).

If we visualize things, then before the arrival of Nano evolution of Windows Server in relation to GUI looked like that:

Back in 2014 Cloud Platform System was released by Microsoft which is marketed as “Azure-consistent cloud-in-a-box for your virtualized Windows and Linux workloads” and running on 1-4 racks with Dell hardware using System Center and Windows Server. It was one of the things which proved that conventional Server Core installation just does not cater well enough for the cloud scenario due to long and frequent reboots which adding up and causing unacceptable downtime. Just think about Hyper-V host reboot triggering reboots of thousands of VMs hosted on it – with Server Core it is either unacceptable high downtime or administration nightmare in attempts to schedule live migrations to mitigate this. This crystallized the need for something different. And the needs were the same for Azure platform, hence we got Nano Server.

Unlike Server Core, Nano Server was built from the bottom – Microsoft took Windows kernel and started to add things to it. So, despite it looks like extreme removal of stuff from Full Server, it has been an addition of things on top of Windows kernel. Interestingly, early builds of Server Core were very close to Nano, but Microsoft considered market demands carefully and realized that market was just not ready for this back then.

Leaving aside question, whether this was a removal of things from Full Server or adding things to Windows kernel we should admit that majority of people will be comparing Nano with Full Server and Server Core. And then it will look like the extreme removal of components we used to have. But, it seems we removed enough in Core, what else we can remove to make it Nano? In fact, quite a lot:

First of all, Nano Server is headless, which means you don’t have a local log in capability: Winlogon component which is responsible for handling the secure authentication sequence and loading the user profile on logon has been completely removed. You manage Nano Server only by means of remote management and this is the most prominent change you will notice right off the bat.
32-bit support (it means better security as things ensuring that backward compatibility can be exploited by certain attack types – just read up Why the 64-bit Version of Windows is More Secure article to learn more about this)
RDP and entire graphic stack
All roles and features now live outside of Nano Sever (meaning you can say good bye to that notoriously big WinSxS folder). If you need to put something on Nano Server you use standalone packages that install like applications
No MSI support (as it has certain GUI dependencies), WSA – Windows Server App, is replacement for that (not only for Nano)

This results in numerous gains listed in the table below. All in all, with Nano Server you have an ability to purpose built your OS so that it has only things required for intended workload. Sort of micro OS for micro services era.

* Patches data based on all critical patches released in 2014

Not reflected in the table above is incredibly fast installation time which decreased from about 20 minutes for Full Server to just 40 seconds (!) to spin up Nano Server (5 minutes for Server Core). And a decrease in the number of running services and loaded drivers is equally impressive. Obviously, with all these removals we are getting fast provisioning, smaller attack surface and less things which need to be configured (and can be misconfigured 🙂 ). VHD boot time of this installation type is under 5 seconds.

What you can run on Nano:

Hyper-V, Storage (SoFS), Clustering
IIS, DNS
Core CLR and ASP.NET 5

It is also worth noting that we have full Windows Server driver support on Nano (i.e. drivers are the same as for any other installation type of Windows Server 2016).

You can’t run Domain Controller on Nano and honestly, like for many others one of my first ideas was to put DC on Nano Server. But Nano Server designed for large scale, and really high-volume multi-node things which you want to provision very quickly – you just don’t need such a big number of Domain Controllers in your environment, which may justify running it on Nano Server (of course there could be technical difficulties to make this role work on Nano, but mainly it is intended use case design decision, if you please). Though Microsoft keeps getting requests for DC on Nano Server mainly on the grounds of Nano Server’s reduced attack surface which is highly desirable for DC.

Now when we discussed all available installation types of Windows Server 2016 we can sum up usage scenarios for them in the table below.

Some conclusions. Microsoft now recommends Full Server GUI only for SMB environments or for an RDS host servers, server Core is still default installation option which is great for infrastructure services (AD DS, Hyper-V, FS, Print Servers, Web Servers, Core Networking Services), some back-end products (SQL Server) and existing enterprise applications. Starting from Server 2016 Nano Server is the best choice for infrastructure services, cloud components also called“born-in-the-cloud” apps. Azure stack will be using Nano Server for compute and storage hosts. Generally, Microsoft positioning this installation type as a future of the datacenter and new foundation for all components which provides a Just Enough OS model for all applications. With release of Windows Server 2016 we can start getting familiar with it right now to be prepared for the future.

I will cover some practical aspects, such as installing and managing Nano Server in one of my next blog posts.

While preparing this blog post and exploring Nano Server capabilities, I’ve used great resources from two leading online learning providers CBT Nuggets and Pluralsight and information from Microsoft web sites. Especially useful for me were Pluralsight course Play by Play: Nano Server by Jason Helmick and Andrew Mason and CBT Nugget’s course What’s New in Server 2016? By Garth Schulte.