Over the coming weeks, we’ll be publishing more on Windows Server 2016 and the key capabilities coming in the next wave of Microsoft datacenter solutions. In this installment we’ll be looking at Nano Server, the new headless deployment option for Windows Server. Nano Server offers a dramatically reduced footprint, resulting in lower servicing requirements and improved security. Along with Windows Server Containers, Nano Server is a key element of the modern application platform features coming in the next version of the operating system.
Windows Server 2016 contains multiple features designed for application innovation, and specifically for modern or “born-in-the-cloud” applications. In this blog we’ll discuss how you can port your applications to Nano Server, whether it is a server app or a management tool or agent, everything discussed in this blog applies to any code that needs to run locally on Nano Server.
To find out more about Nano Server from Jeffrey Snover, Microsoft Technical Fellow, check out the video here:
Nano Server is available as the OS for:
- Physical machines
- Virtual machines
- Hyper-V Containers
- Windows Server Containers
When used in any of these configuration Nano Server has the same API surface available for running applications. The Nano Server API surface is a subset of what is available in Server Core and Server with a Desktop Experience. As a subset, any application, tool, or agent that is written to run on Nano Server will run without modification on Server Core or Server with a Desktop Experience.
The design pattern for Nano Server is for headless server apps running locally and separation of any and all GUI, which will be run remotely from the code that runs on Nano Server. Rich GUIs should be written following the standard Windows UI design guidelines but written to be fully remoteable. For Nano Server apps, the GUI must run remotely on a Windows client or Windows Server with a Desktop Experience installation and perform all necessary actions over the network.
With Nano Server this is the first time Windows Server has its own developer experience. Unlike Server Core which is just a list of APIs on MSDN, Nano Server has integration with the Windows SDK and Visual Studio, we did also provide a Nano Server API list on MSDN.
For Nano Server there is a Visual Studio project template. When you create a new project you can select Nano Server as your target and you will get full IntelliSense and error squiggle support so you know if an API you are using is available in Nano Server or not.
With Visual Studio you also get full remote debugging experience. The template and scripts to help setup remote debugging are posted on the Nano Server blog.
Nano Server also includes .NET Core, the Open Source modular subset of the .NET Framework. In addition to allowing PowerShell Core to run on Nano Server, .NET Core on Nano Server provides the ability to run ASP .NET 5 and any managed code applications written to .NET Core. More details on .NET Core and documentation on what is supported in .NET Core is available on GitHub
The Win32 API has grown and evolved over the last 20+ years. There are multiple APIs and different layers of Win32 that provide the same or very similar functionality, for example to access the Registry or the local file system. Which API used has often been a matter of which the developer was most familiar with or came up first in a search. In Nano Server these APIs are still functional but have been moved to a lower level DLL. This allows code that uses these APIs to still work on Nano Server but because the API has moved to a new DLL you’ll have to change your linking and recompile. Reverse Forwarders provide shims for the original DLL that forward the API call to the new DLL allowing your code to run as is.
Reverse Forwarders are an optional package on Nano Server and not installed by default – see the Nano Server deployment guide for steps to include this package. Included in the Reverse Forwarder package are shims for
It is important to note that not all APIs these DLLs expose are shimmed, only those that are functional in Nano Server. Any APIs your code may call, for example a GUI API, that doesn’t exist in Nano Server will return an error not implemented exception.
Reverse Forwarders do not eliminate the need to port your code to the subset of the APIs available in Nano Server. What they do provide is the ability to get your existing version of your app running on Nano Server and allow you to do the porting work as part of your next version.
Using Reverse Forwarders, many of the Open Source Application Frameworks run on Nano Server today. These include:
- Python 3.5
- Java (OpenJDK)
- Ruby (2.1.5)
As well as various applications, such as Chef, Nginx, and MySQL.
Porting Apps to Nano Server
If you have an existing application that you want to make work on Nano Server, you can use the following steps that we have used to get various apps and tools running on Nano Server.
To port a Win32 app to Nano Server:
- Install a Nano Server image with the Reverse Forwarder package installed using the deployment guide.
- Run and test your app on Nano Server
- If the app successful runs, then install a Nano Server image without the Reverse Forwarders
- Run and test your app on Nano Server
If your app successfully runs in step 4, your code is only using APIs in Nano Server and is good to go.
If your app runs in step 2 but fails in step 4 your code is using an API that exists in Nano Server but has been moved. The next version of your app should be relinked to the new DLL.
If your app doesn’t run at all you can use one of the following mechanisms:
- Use the debugger while running your app to see what API calls are failing
- Use Visual Studio, create a new Nano Server project, load your code into the project, review your code for the red error squiggles to identify any APIs you may be using outside of Nano Server.
- Use our native code scanning tool to analyze your app to see what APIs you are using outside of Nano Server. In ~60% of cases it will suggest alternate APIs that you can use. This will be posted on the Nano Server blog in the next few weeks.
Porting Managed Code to .NET Core
As mentioned earlier, there are a lot of .NET Core resources and documentation available on MSDN and GitHub that can help you to port. The most important of these is the API Portability Analyzer that will tell you which of the .NET APIs you are using are not available in .NET Core.
Installing Apps on Nano Server
Nano Server does not include MSI as an installation technology due to dependencies and the open ended nature of MSI custom actions. Instead, Nano Server has a new declarative Appx-based installer called Windows Server App (WSA) Installer. In the next technical preview, WSA is only available in Nano Server but will be available in Nano Server, Server Core, and Server with a Desktop Experience for Windows Server 2016 so you can use the same installer for your server app on any installation option.
WSA extends the AppX schema to add Windows Server specific extensions required to install many server apps, such as supporting NT Service installation. As a set of extensions to the AppX installer, WSA does not support custom actions, so will not have the reliability and uninstall issues of MSI.
WSA as a set of extensions to AppX, provides support for everything available in AppX, such as file and registry values, as well as using the same AppX PowerShell cmdlets to install and uninstall. The server specific extensions that will be supported in the upcoming technical preview are NT Servers, COM Object registration, and WMI. We will be adding extensions to WSA for Performance Counters and ETW Events.
More detailed information on WSA will be posted to the Nano Server blog in the coming weeks.