Freigeben über

Installing Windows Server Apps on Nano Server

  • Artikel

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.

Comments

  • Anonymous
    November 19, 2015
    Hands on Packaging and Installing WSAs to Nano Server.
  • Anonymous
    November 25, 2015
    Is it correct to assume these are installed in a per-machine rather then per-user context?
  • Anonymous
    December 01, 2015
    Will we see these Appx "extensions" on other platforms? Server, Desktop? Is this using AppV under the covers like project Centennial? Assuming this is per-machine and has enough extensions to deploy a reasonably complex application this seems like the best "bridge" I've seen so far to transition off MSI and into a more closed/declarative model.
  • Anonymous
    December 08, 2015
    Yes WSA is installed per machine as full trust, not per-user. The server specific extensions only apply to Server SKUs, including NT Service, COM object, WMI providers, not applying to desktop SKUs. Under the hook like Project Centennial, it is all APPX based framework, using declarative manifest file to specify these extensions, and let the APPX install do the system level changes.
  • Anonymous
    December 16, 2015
    Hello,

    A few questions -

    1. Will the Appx installer / extension support opening specific firewall ports on the server?
    2. How will appx handle upgrades? Can we safely assume the information stored in registry/configuration files etc. will be retained? It's very important for our customers to not lose their configuration after performing upgrades.
    3. Currently, users can use a single MSI to install any supported combination of supported features. Do we need to provide multiple Appx with all the supported feature combinations so that the users can install the specific appx?

    Thanks,
    Atul.
  • Anonymous
    January 14, 2016
    Hi Atul, I try to answer your questions here.
    1. this is part of configuration and will need to be handled after installation by the app itself.
    2. it is our intention to keep configuration after upgrade. This involves lifetime management of each app, including how to cleanly re-start app's process, services, besides keeping related configuration, etc. We are still working on it.
    3. WSA is targeted at a headless scenario where there is no interaction from the user to specify the feature combination. The original MSI will need some refactoring on how to target without user interaction.
  • Anonymous
    January 21, 2016
    As organizations move toward modern DevOps practices, the role of the operating system needs to evolve
  • Anonymous
    March 23, 2016
    Hi,

    Could someone help me in figuring out the location of fgwixappxextension.wixext.dll? i couldn't find in WIX toolset.

    Thanks
    • Anonymous
      May 11, 2016
      I think you need to buy the extension from FireGiant.
  • Anonymous
    April 07, 2016
    Hi, My Nano Server service application is logging events to Windows Event Log via ETW. Right after installation of the service, it needs to register an event manifest file (*.man file) which contains the definitions of all possible events the service will log. Manually, the registration is done using "wevtutil.exe" command. Can you add support in AppX manifest to automate this requirement? The automation should also include editing the *.man file itself to put there the absolute path of the service *.exe file to inform ETW who will generate the events.
    The same question was asked in MSDN forum 2 years ago but no reply so far:
    https://social.msdn.microsoft.com/Forums/Lync/en-US/371fbdef-b7b2-44d1-9734-002a4ff45e7b/register-etw-events-provider-for-my-app?forum=winappswithnativecode

    Thanks
    • Anonymous
      May 12, 2016
      We do have the ETW extension now supported in TP5. Please look at the sample manifest to see how you can declare the ETW provider there (https://blogs.technet.microsoft.com/nanoserver/2016/04/27/wsa-updates-in-ws-2016-tp5/). We also support absolute path from the WSA installer. This is done at the installer side that when you define the ETW provider in the manifest, WSA installer will register it by calling wevtutil.exe with /rf, /mf, /pf switch.
  • Anonymous
    September 27, 2016
    What are Extensions available with Nano server RTM/GA build ??
  • Anonymous
    March 09, 2017
    In which way this is really better than inventing "own wheel". For example, script which makes a copy of files from a shared folder and then creates Windows Service.Does WSA handle cases like locked files by some process? How can I deploy my windows service under some custom credential with WSA? I think without features like "dependencies" this is pretty useless. Also, quite a lot of technologies provide ways to add custom hooks before installation and after (Chocolatey as it based on NuGet, Linux packages). Even though when you deal with these hooks you put responsibility on the person which develops package I don't think that it is bad. Scripts could be reliable and if someone makes fragile scripts that's his own issue.Do you provide any features to combine DSC with WSA so I can make deployment simple? For example, describe which APPX I want to have installed with DSC and simply apply DSC to some server (something like https://msdn.microsoft.com/en-us/powershell/dsc/packageresource).