Installing Windows Server Apps on Nano Server
The initial public announcement of Nano Server earlier this year aroused a lot of interest and questions, in particular on how to package an application and deploy it to Nano Server. Assuming your application has been already refactored to be compatible with Nano Server (if not, please follow the Developer Experience blog to create or port your application first), we now introduce Windows Server Apps (WSAs) to provide a way, based on APPX, to package and install an application on Nano Server.
Why not another version of Windows Installer (MSI)?
WSAs are packaged as APPX packages and deployed using the APPX deployment framework. This is fundamentally different from a Windows Installer (MSI) package. Why didn’t we re-use MSI in Nano Server, given its wide usage in the Windows world? There is a reason. MSI is built primarily for local installation, so remote installation can be problematic. Custom actions in MSI may invoke GUI or other non-headless-friendly that are not desirable with the headless and zero-footprint nature of Nano Server. Thirdly, MSI does not support offline installation, which is one of major goals for Nano Server in the long run. With these drawbacks, we have consciously made the decision to not include MSI support in Nano Server. Instead, we extended the declarative APPX installer to package WSAs. We also clearly separated installation from configuration, with the latter handling post-installation configuration specific to machines or users, using Desired State Configuration (DSC) or other configuration management technologies.
APPX Extensions for Windows Server
Windows APPX is an installer framework designed to install and service applications safely and reliably, using a declarative manifest. We have extended the APPX installer to support and promote Windows Server-specific extensions as first class citizens. The Windows Server-specific extensions that are currently supported are: creating and starting an NT service, registering a WMI provider, and creating classic COM object. With APPX, there is no support for custom code in your setup, instead, you only need to declare these extensions in the manifest. Let the APPX installer handle system-level changes and provide reliable servicing for you.
A few specific characteristics that distinguish WSAs packages from Windows Store app packages are:
The Windows Server-specific APPX extensions are only available on Windows Server, not on Windows Client. And WSAs using this installer will be available on all editions and installation options of Windows Server.
WSAs run in machine-wide full trust mode, in contrast to Windows Store apps, which run in an App Container restricted environment.
WSAs cannot be submitted to the Windows Store.
In Windows Server 2016 Technical Preview 4, the APPX Windows Server extensions are only available on Nano Server. However, our plan is to have all of the Windows Server installation options support the new extensions for Windows Server 2016 release. In this Technical Preview 4, you will find basic support for the following:
Files – files copied to a fixed location, i.e. under %ProgramFiles%\WindowsApps.
NT services – you declare an NT service along with its properties and parameters, and the APPX installer then creates the service with the required configuration for you. Driver related services are out of scope for now and continue to live in an INF.
WMI providers – you declare the WMI provider with the MOF file. The APPX installer registers the WMI provider for you.
Classic COM Classes/Interfaces/AppIDs – The APPX installer registers the COM Classes/Interfaces/AppIDs according to content declared in the manifest.
Intra-package dependencies – for instance, in the manifest you can declare an NT service that depends on another service, a WMI provider that depends on a COM object.
APPX installer does not allow direct registry entry declaration in the manifest. Registry entries must associate to an APPX extension, such as NT service, WMI provider, or COM object.
Bear in mind though, we are still at the beginning stages of our journey. We will continue to work on the Windows Server extensions including servicing, as well as working on more extensions.
First glimpse of WSA in a sample manifest
Let’s take a look at an APPX manifest with Windows Server extensions. The first part defines two NT services where one depends on the other.
The next part defines a WMI provider that depends on a COM class.
When to use APPX based WSAs
Let’s recap when it’s suitable to move to APPX. The following aspects of WSAs fall very well into APPX’s umbrella:
Your installation involves system/OS level changes
You desire reliable uninstall and servicing
Your application declares a dependency on Windows features or framework packages
Let’s flip the coin to check when it’s not yet suitable to move to APPX:
Your current setup runs custom code that is not yet in one of the Windows Server APPX extensions. In this case, some deep refactoring may be needed. Again, we do not support custom code running during the installation time, because this can cause an unpredictable result and it will not fully uninstall. If you believe the custom code is commonly used by Server applications and would like to see it be supported as a first class citizen in the manifest, please let us know.
Your setup needs GUI and/or user input. Because Nano Server is a headless OS, any GUI-based application has to be refactored to follow the client-server model that allows for remote installation, and for the GUI to be run on the client.
Driver install is not yet in scope for APPX. For now, driver installation will be handled separately via DISM.
Your application package depends on another software package. The APPX installer currently does not support cross-package dependencies.
Your application needs to manage a package repository. For instance, your setup requires downloading of some executable from one site, and some other from a different site. You may explore PackageManagement for solutions to these scenarios.
This may sound like a lot of restrictions, but this is because APPX based WSA aim to provide reliable installation and servicing. These restrictions will lead to a more consistent and reliable app installation experience for Windows Server applications.