WAS runtime installer shows deployment result of ERROR_INSTALL_POLICY_FAILURE during install on WS2019

[riverar]

Describe the bug
When attempting to install the WAS runtime on Windows Server 2019 (17763.1), package deployment fails but with a cryptic ERROR_INSTALL_POLICY_FAILURE with no further details/guidance. (In this case, Windows Server was not configured to support sideloading.)

(I understand 0.8-preview support is non-existent. Just making sure these issues are in the backlog.)

Steps to reproduce

1. .\ProjectReunion-0.8Preview-Install-x64.exe
2. Observe results

Deploying package: Microsoft.ProjectReunion.0.8-preview_8000.146.628.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.ProjectReunion.0.8-preview_8000.146.628.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.ProjectReunion.Main.0.8-preview_8000.146.628.0_x64__8wekyb3d8bbwe
Package deployment result : 0x80073cff
One or more packages failed to install. Result: 0x80073cff

Attempting to install the raw main package results in more informative output:

...
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CFF, To install this application you need either a Windows
developer license or a sideloading-enabled system.
Deployment of package Microsoft.ProjectReunion.Main.0.8-preview_8000.146.628.0_x64__8wekyb3d8bbwe with package origin
Unknown failed because no valid license or sideloading policy could be applied. A developer license
(http://go.microsoft.com/fwlink/?LinkId=233074) or enterprise sideloading configuration
(http://go.microsoft.com/fwlink/?LinkId=231020) may be required.
NOTE: For additional information, look for [ActivityId] 4aca43e7-81dc-0000-dcb7-ca4adc81d701 in the Event Log or use
the command line Get-AppPackageLog -ActivityID 4aca43e7-81dc-0000-dcb7-ca4adc81d701

ProjectReunion-0.8Preview-Install-x64.exe
Windows Server 2019 (17763.1)

[DrusTheAxe]

In this case, Windows Server was not configured to support sideloading

TL;DR by design. Is this a problem or just a surprise?

Per the (release channels decision](#637) only Stable releases are supported. Some recent changes to the build pipeline now (intentionally) only send Stable releases to be Store signed as only Stable releases are Supported and Store distributed. Non-stable releases are signed but require sideloading to be enabled to 'just install' (no need to add their certificate to the machine's certificate store).

@BenJKuhn @kythant @DefaultRyan at a minimum this needs to be cleared communicated. The Channel decision needs to spell out what form of signing is applied and if sideloaded is necessary (another column on the "Approved final release channels" table?). Or wherever Channels are documented, but the only place I could find was the Discussion post. @andrewleader shouldn't there be a docs\Channels.md with this this information?

[riverar]

The experience is sub-par. Remember, unpackaged apps will either be:

1. trying to install the runtime with their app or --
2. pushing the user to get the runtime (e.g. via a dialog that says "runtime not installed, go get it here")

In the first scenario, there's no list of expected error codes for the runtime installer so the developer will have not have special handling for ERROR_INSTALL_POLICY_FAILURE and will just confuse the user with generic error/HR. Or just enter some error loop.

In the second scenario, the user will be directly exposed to the runtime installer. Its text is not user-friendly.

[zaryaf]

need to spell out what form of signing is applied and if sideloaded is necessary

In the prerequisites for unpackaged app deployment, we are communicating that sideloading is needed and instructions on how to do that. Agreed that we need to communicate that out elsewhere.

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps#prerequisites

[zaryaf]

The experience is sub-par.

Agreed that the result (success/error) outputs need to optimize for understandability to ensure developers know what actions to take. Regarding #2, are you specifically referring to a dialog we already have or a dialog we may present to the user in the event the developers is unable to install the runtime?

[dkbennett]

The user shouldn't be directly exposed to this installer, this is for 3rd party setups to use, and for developers to use for testing. We will have a different (or more robust) solution for end-user intended installer, if one is necessary.

This particular error: ERROR_INSTALL_POLICY_FAILURE should not occur for 'stable' released store-signed packages, but does in this case because it is not a stable release. To deal with this, developers would need to download the MSIX packages and install the certificate from the package, which is a bit of a pain. For non-stable releases we should have the certificate more readily available and instructions for sideloading enablement, so I think this is largely a documentation issue for preview versions of the installer.

[riverar]

Regarding #2, are you specifically referring to a dialog we already have or a dialog we may present to the user in the event the developers is unable to install the runtime?

Both. The API should have a way to silently return an error or show a built-in one to avoid developers from having to create their own.

The user shouldn't be directly exposed to this installer, this is for 3rd party setups to use, and for developers to use for testing. We will have a different (or more robust) solution for end-user intended installer, if one is necessary.

If one is necessary? Is another in the works? Seems really late to still be ideating on deployment -- is this going to be ready for 1.0? Last I checked, the 1.0 plan was to support machine wide install and not force app devs to ship WARuntime bits with their app.

[BenJKuhn]

It seems like this discussion has split into two topics. The first is that previews don't work by default on WS 2019 due to sideloading policy. Previews are signed as Microsoft code (authenticode) but are not signed as trusted store apps. This is consistent with the spirit of sideloading vs. installing released, maintained applications. Previews should require permission to install non-production code. I realize sideloading isn't exactly the same, but it's a good approximation. This should be captured in documentation, and it sounds @zaryaf has that covered now.

The second discussion is around the error code. That's the correct error code for this situation. I'm not really sure what to change there. The situation that triggers it is unique to in-development applications using App SDK previews and unique to server SKUs, making it somewhat niche. @riverar, given that context, let if you still have input on how to make this experience better please reactivate this issue and add your thoughts.

"if one is necessary". We're constantly evaluating how to ensure that a wide range of applications can leverage the App SDK with as little friction is possible. @dkbennett is acknowledging that this is an area that we're continuing to evaluate, take feedback on and ideate on to make sure that the App SDK is available to as many apps as is practical. These efforts are not constrained to the 1.0 release.

Thanks

Ben