Windows Server 2016 Nano Server – Installation and Management

Time to continue our conversation about that “scaled down even further” Server 2016 installation option. In my previous article, I covered general concepts around Nano Server, now I want to switch gears and talk about more practical aspects: installation and management. At the end of the day, you would agree that the best way to learn new technology it is trying to use it – this way you will be exposed to its strengths and weaknesses directly, and can get the real understanding of whether it works for you or not. Though at this point even Microsoft admits that despite all its greatness, at the moment, Nano Server has quite limited utility as it supports only a small subset of roles and features out of those which you can find in full GUI version of Windows Server.

I want to start with installation as it is quite natural to install thing first and then learn how to manage it. As I mentioned in my previous blog post you can’t find Nano Server as an installation option in Windows Server 2016 Setup Wizard, instead you perform installation of Nano Server by means of creating VHD on another computer from PowerShell, and next this VHD can be used to create Hyper-V VM or as a boot drive for a physical server.

Windows Server 2016 disk includes Nano Server directory which contains Nano Server image, a PS module and package files for the roles and features:

Importing PS module provides cmdlets you need to create and edit Nano server images. Let’s create our first Nano Server now. This folder contains NanoServerImageGenerator subfolder which needs to be copied locally before we can start provisioning Nano Server. Alongside it you may see base Nano Server image WIM file and Packages folder. Nano Server, being a zero-footprint installation type, does not contain any roles and features in it and it does not even have Install-WindowsFeature cmdlet because it uses PowerShell core (aka PSCore which is based on .NET CoreCLR). The way for you to get anything added to Nano Server is packages. You can preload them taking from installation media or get them from the online repository.

If you want somewhat simpler installation process you may consider using Nano Server Image Builder which already has been covered on StarWind Blog but here I just explain how you can do it without additional tools. All you need to do is to run PowerShell ISE in elevated mode and then switch location to your local copy of NanoServerImageGenerator directory from which you can import all required modules (Edit-NanoServerImage, Get-NanoServerImage, New-NanoServerImage). And after this, you can create VHD with Nano Server and this longest part of Nano Server installation takes just a few minutes:

Pay special attention to DeploymentType switch – this is what differentiates whether your VHD can be used for VM or physical machine (essentially this switch specifies set of drivers to inject). I also strongly recommend to provision your Nano Server “inside” of your domain (i.e. from domain member machine) and using account which has rights to add computers to domain – then your Nano Server will be joined to domain with easy DomainName switch which takes care about offline domain join procedure for you, otherwise you will be forced to deal with this procedure manually later, creating and copying blob file to your Nano Server. Make sure you save this script for further use. Note that extension of virtual disk file will define whether your VM will be Gen1 or Gen2.

Next, it is literally one line of PowerShell and you will be able to start your first Nano Server Hyper-V VM (note that we using -Generation 2 switch as we created VHDX file on the previous step):

PowerShell-challenged people can just use New Virtual Machine Wizard for this part attaching existing VHDX in the process. Make sure you used Set-Location (for example Set-Location ‘C:\Hyper-V’) in case you don’t want to specify the full path to VHDX file in command above and want your VM to be neatly placed in your dedicated folder for VMs. Command mentioned above should be executed on Hyper-V host of course. From this moment on you may access Hyper-V manager and run VM you created (staying in comfort of PowerShell session and starting VM from here is also an option). Once VM is started you can open up VMC to it, and lo and behold Nano Server Recovery Console showing you that your Nano Server is domain joined already:

We are done with installation now. But installed like that our box is of no use – just because we have not added any packages yet. Remember that Packages subdirectory in NanoServer folder of Server 2016 installation media? Despite some of the packages have almost the same names as normal Windows Server roles they are not exactly the same, and cannot be installed in the same way. This is how Add Roles and Features Wizard reacts to Nano Server with no packages added:

But once you add some packages this wizard will be able to list them and even add/remove sub-features:

You normally add roles specifying packages either during initial provisioning of your NanoServer VHD or after it, using the following syntax:

This example allows us to add services to offline image though nothing prevents us connect to our Nano Server and install roles online:

An Example above adding IIS packages. After this has been done we have something on our box which can be used and managed:

Now a bit about management. When it comes to Nano Server management it is no surprise that Nano is all about remote management. How else could it be done with a headless server without interactive logon capability? It seems that Microsoft got tired of preaching about managing servers remotely and not burden their resources with fancy GUI consoles and management tools, so now you get the ultimate push for that – you have an OS which just not allows that. But on remote management side you have it all:

• Server Manager
• Hyper-V Manager
• Failover Cluster Manager
• PerfMon, Event Viewer, etc.
• PowerShell Core (refactored PowerShell running on top of .NET Core)
• RSMT

As you can see most of existing MMCs are there and work with Nano, though pay attention that we have only PS Core which at least initially provides only subset of PS cmdlets but Microsoft works on expanding the number of those. You also have WMI V1 and V2, and old school commands like ipconfig, hostname and many others which also still work. There is also new web-based GUI for Nano named Server Management Tools and available through Azure subscription. It requires you to set up Server Management Tools Gateway to be able to manage your on-premise servers (see related blogpost @ StarWind Blog which discusses this tool). The Key thing to know about this tool is that it includes replacements for so-called local-only tools such as Task Manager, Registry Editor, Device Manager and so on and that it provides unified management, allowing you to manage Nano Server, Server Core, and Server with GUI machines. As this is the case with Exchange web management this tool is too based on PowerShell and WMI running in the background.

In the end, what we have at our disposal is configuration via PowerShell DSC (Nano cannot be managed by Group Policy! – read more here), remote management/automation via Core Power Shell and WMI, and good capabilities for integration into DevOps toolchains. I think it is worth to elaborate a bit on PowerShell Core. Essentially this is a version of PS refactored to run on CoreCLR which has full PS language compatibility and remoting (Invoke-Command, New-PSSession, Enter-PSSession, etc.). It has most core engine components and support for all cmdlet types: C#, script, and CIM. You will also see that with PS Core Get-WMIObject is not available, but it has a replacement in the form of Get-CIMInstance.

From little experience, I have so far with Nano, I can say that albeit MSFT invested into providing management of Nano Server roles via RSMT consoles, there are way too many things you going to use PowerShell for (e.g. copying data using PS remoting, getting updates applied on Nano box), it will be a pain for those who still not like using it and joy for proficient PowerShell users who already hooked on its power and simplicity.

Just to finish off with initial practice I suggest you try and create the cluster out of two Nano Servers. All you need to do is use steps above to create second Nano Server and then use old and familiar Failover Cluster console to configure your cluster in no time:

While playing with Nano Server you will see that not all things work as you get used to while running Full Server installation and you need to do some research here and there, but, oh my goodness (can’t help using this phrase after watching some of Nigel Poulton’s Docker training videos 🙂 ), its reboot time is impressive – this is something you going to like for sure. Just to give an example – reboot is so quick that if I forgot to start my DHCP server before starting Nano Server it is faster for me to reboot Nano Server than connecting to it to the firing of ipconfig /renew. To reiterate what I said at the beginning of this post the only shortcoming of Nano Server is its limited use cases at the moment, but for the things it can handle it does it with remarkable efficiency. I have not yet heard about any ISV rebuilding their Windows Server based software to run on top of Nano Server, but from what I can gather most of the ISVs which have both cloud and on-premise versions of their products just starting to evaluate Nano as a base OS for their cloud software offerings.

I hope this article gave you just enough information to get started with Nano Server.

Related materials:

• Manage Nano Servers from Server Management Tools in Microsoft Azure
• How to Protect your Data on Nano Server using Storage Replica?