All You Need to Know About Microsoft Windows Nano Server

Introduction to Microsoft Windows Nano Server

Today, I want to talk about Microsoft Windows Nano Server. Nano Server is a headless deployment option for Windows Server, coming in 64‑bit only. For many, it will look very confusing at first, and many will quickly look at it and decide it is not for their environment. I hope to convince you to look further and to give you as much information and guidance as possible.In fact, when you are thinking about your on‑premises datacenter, your first thoughts should be to decide if you can run the intended workload on Nano Server, and if not, if you can run it on Core Server. A server with the full UI should only be used when the other two options aren’t possible.

In addition, when your company need to develop a new application, now is the time to figure out if you can do this with Nano Server. One of the advantages of Nano Server is that it will run on many other platforms and your application will be ready for the future.

The best way to explain Nano Server is to dive into the history of Windows Server and how it has evolved over the years.

Nano Server is a headless, 64‑bit‑only deployment option for Windows Server 2016. Microsoft created this component specifically with key scenarios in mind: Nano Server was created to serve as cloud fabric and infrastructure (Hyper‑V host, clustering, networking, storage) and as a deployment option for applications that are — as they call it — born in the cloud (Platform as a Service v2 and ASP.NET v5 applications).

It’s important to know that this deployment option is really headless. The moment you decide to deploy a supported role (such as Hyper‑V), you need to realize that this lives outside of Nano Server. There are absolutely no binaries or metadata inside this server. Even the drivers come as a package that you can install on top of it. This makes this server option perfect for those that want to deploy only what they need and keep everything else as minimalistic as possible.

Nano Server is ideal for some key scenarios in your environment such as:

  • Hyper-V host
  • Storage host for Scale-Out File Servers
  • DNS Server
  • Web server (IIS)
  • A host for applications specifically designed for this
  • Container host

And this is just the beginning. I can’t predict the future, but image if I can deploy Nano Servers for my specific core infrastructure such as Active Directory, DHCP, DNS (which already works today) and so on. This would save me a lot of management trouble and resources.

When you read further, you will see that Nano Server will give you some challenges in the way you deploy, configure and manage it. But before you do that and decide it’s not worth the trouble, let’s explore the advantages of deploying Nano Server in your environment.


Reboots for a Windows Server are something we learned to live with for many years. IT administrators all around the world are familiar with Patch Tuesday. However, in many cases, it creates many headaches. While you will never be able to remove patches and updates, a headless solution will definitely require less patches.

Less patches don’t mean less security. Because there are less components to patch, the attack vector also decreases. Many attacks are done on components that simply do not exist anymore in the server core, especially when you come to think of GUI elements. Microsoft did some research in 2014 to list the differences:


Figure 1 shows the number of important bulletins, critical bulletins and reboots required in 2014 for Nano Server, Server Core and the Full Server option. As you can see, there are quite a bit of differences. In addition, the maintenance work that needs to be done on Nano Server is lower than for the other options. It should also show that when you can’t choose Nano Server, Server Core is your best option.

Server images

Further in this document, you will notice that we will create small images of servers. Those of you who need to manage server image libraries will welcome Nano Server because it will use less disk space. Again, Microsoft provided us with numbers, as you can see below:


Figure 2 shows the differences in setup time, disk footprint and VHD(x) size between Server Core and Nano Server. You can imagine that these numbers are even higher on the Full Server flavor.


Finally, you will also notice a huge difference in resource consumption. There are fewer processes running, and the boot IO and kernel MB in use are all lower on Nano Server, as you can see in Figure 3:


Figure 4 shows the differences in the amount of drivers loaded, services running and ports open between Server Core and Nano Server:


Many of you may think that the last figure should fall under security and not resources and you are not wrong. Microsoft does exactly the same. However, less services and drivers loaded also means that less resources are necessary, so I could argue that the last figure should fall under both security and resources.


While the above numbers are certainly not final and are only from the measurement Microsoft came up with in 2014, you should be able to see that using Nano Server can deliver some huge improvements and advantages. And if using Nano Server is not possible, then Server Core should be your choice. I personally expect these numbers to improve even further. Although the way you manage Nano Server will be different than how you have always managed Windows Server operating systems, the advantages are higher than the disadvantages. In the end, you will notice that managing Nano Server certainly isn’t that difficult and it is just a matter of getting used to it.

When you start, you have to realize that Nano Server is not an installation option. It cannot be selected during setup as you are used to with other versions of Windows Server. The binaries are found on the installation media but you need to create a “base-image” first before you can deploy it. There are many ways to create that image, so let’s start here with a quick way to get things going.

A virtual Nano Server

Copy the files NanoServerImageGenerator folder from the windows server 2016 ISO (or installation media) to a location of your choice. In my case, this will be under F:\NanoServer\


Open Windows PowerShell, Windows PowerShell ISE (or the tool of your choice) as an administrator and navigate to the folder where you have copied your scripts.


Before you can start, you’ll need to import the NanoServerImageGenerator module. Browse to the directory where you placed the files and then import the module.

The command to do this is:
Import-Module .\NanoServerImageGenerator -Verbose

Note: The “verbose” is not necessary, but it will show you all the work that is done while importing this module. As you can see, three functions have been imported. We will go into detail about those later.

Now you can create the first VHD that you can use in a virtual environment. Don’t worry about the different parameters yet; I will dive deep into those next. What you are doing here is creating a simple VHD, setting an administrator password and including Hyper-V guest drivers.

New-NanoServerImage -Edition Datacenter -DeploymentType Guest -MediaPath (path to root of media) -BasePath .\Base -TargetPath .\NanoServerVMs\NanoServerVM.vhd -ComputerName (computer name)

Edition can be a standard or a datacenter build (for more information on editions:

  • DeploymentType (guest or host) defines whether it will be virtual or physical
  • Mediapath is the path where the contents of the ISO are (either copied to disk or mounted as ISO)
  • BasePath is the folder where the Nano Server WIM and packages will be placed
  • TargetPath will be the folder where the VHD (or VHDX) will be created
  • ComputerName is where you define the name of the computer

We will go further into details about those parameters later on.

In my case, this becomes:

New-NanoServerImage -Edition Datacenter -DeploymentType Guest -MediaPath D:\ -BasePath .\Base -TargetPath .\NanoServerVMS\Nano01\Nano01.vhdx -ComputerName Nano01


After entering the password, the system will start creating the VHD.


After creation, the only thing left to do is to create a VM in Hyper-V and attach the VHD(X) to it.

This is how:
Open Hyper-V Manager and select New - Virtual Machine
Press Next on the Before You Begin page


On the Specify Name and Location page, choose the name of the VM (this is not the computer name, but rather, the name that will be visible in Hyper-V Manager) and location where you want to store it and press Next.


On the Specify Generation page, choose the generation. If you chose to deploy a VHD, then choose Generation 1. If you want to deploy a VHDX, then choose Generation 2. Press Next


On the Assign Memory page, adjust the startup memory and decide whether you want to use Dynamic Memory or Static Memory. Press Next


On the Configure Networking page, select the network that you want to connect to and press Next.


On the Connect Virtual Hard Disk page, select Use an existing virtual hard disk, point to the created VHD(X) and press Next.


On the Complete page, review your settings and press Finish.


This is, of course, completely possible with PowerShell. I will show you an example of how to do this in the next chapter, Advanced installation/Deployment options.

A physical Nano Server

While most of the examples in this paper will be virtual Nano Servers, some of them will certainly run on physical servers. When you use Nano Server as a Hyper-V node (either clustered or not), it is necessary for it to be a physical server. For the purpose of this paper, I actually run nested Hyper-V so I can simulate this behavior. However, in a real world environment, this probably won’t be the case.

The procedure to create a VHD for a physical machine is more or less the same as it is for a VM. I used the following command:

New-NanoServerImage -Edition Datacenter -DeploymentType Host -BasePath .\Base -TargetPath .\NanoServerVMS\NanoPhys01\NanoPhys01.vhd -ComputerName NanoPhys01 -OEMDrivers —Compute -Clustering

The difference between this command and the command for the VM is that I already added some roles — packages such as compute and clustering — and also added the OEMDrivers package to include drivers. In the next chapter, I’ll talk about these packages in more detail. Another important note is that I actually didn’t need to specify the — MediaPath anymore because I already had a base image created. After this is done this once, I can keep using this base until there are updates to the media.


Another difference is that I am not going to connect the VHD to a VM. Instead, I will deploy that VHD onto a physical server.

If that physical server already has an operating system, I can simply copy the VHD to that server, mount the VHD and then run bcdboot d:\windows. Finally, unmount the VHD and restart the server. I should be able to boot into the Nano Server VHD.

Of course, if you prefer to dual boot, you can always use bcdboot to add a boot listing, but this probably won’t happen very often. In most cases, you want to deploy it on a clean, empty server. In that case, I suggest you read the following two blog posts that explain other methods you can use (and may prefer). Again, because this is not the scope of this paper, and most people will have their own deployment preferences, I won’t dive deeper into here.

  • Deploying Nano Server to a Bare-Metal Machine using a WIM and WinPE
  • How to use WDS to PxE Boot a Nano Server VHD