MSIX automatic updates and authentication

Occasional Contributor

Hello everyone,

we recently started using MSIX with the automatic updates and made great progress in a short time. Our business would like change all our products from standalone MSI to MSIX with automatic updates, but one thing we need is different versions for specific customers (depending on the contract type). The package flighting concept in the microsoft store sounds like what we wan't to achive. I tried to achieve this, with using an azure webservice as the update source, which returns the correct package for the customer. I got the service to run and it works, but as soon as I enable authentication (Azure AD) on it, windows can't download the package and displays an generic error message ("An error occurred while accessing the file from the web") during appinstall / update.


Is there any way to enable authentication on the update url or achieve customer specific update streams?

thanks and best regards,


9 Replies
best response confirmed by John Vintzel (Microsoft)

Hey @Martin82 


The AppInsatller file currently doesn't support user authentication. This is a feature in our backlog and we hope to get to it soon.


Tanaka (MSFT)

Hi@Tanaka_Jimha ,

thx for your reply back in January. I've checked a few sources about msix development, but couldn't find anything about this. Do you have an update or can you point me at some alternatives how to implement customer specific versions with automatic updates?


thx and br,




Hi @Martin82,


Can you please elaborate on "customer specific versions". Do you mean being able to distribute certain versions of your package depending on who is trying to install the app?




Hi@Tanaka_Jimha ,


yes, thats exactly what we want to achieve. We produce about 4-6 Versions of our desktop products per year, but there are dependencies on external services and databases, so we can't roll out the update for everyone at the same time. (And some updates need our consulting colleagues, and so we have to enable the update per customer after the preparation is done).


During writing this reply, I found a documentation for manual updates with the package manager. I'm not sure when the capabilities to use http-Uris for AddPackageAsync where added - the documentation still stays only local file shares are supported - but it seems we can use this, instead of the authentication.


I'll try it out sometime in the future, but it looks like we don't need the authentication anymore.







Edit: made this a separate post


I'm wondering if this backlog item will solve my issue, which is I want to host the web-based distribution page for my UWP app in an Azure web app behind Easy Auth so that only users in the linked Active Directory can access the installation download. 


Easy Auth works as expected to require login to the web page, but the App Installer experience fails with 'An error occurred while accessing the file from the web. Please try downloading and opening the file locally.' I'm guessing this same issue will impact the automatic update functionality of the UWP app as well.


Curious if 'AppInstaller user authentication' would solve this problem, or if it will be an authentication experience after the MSIX package has already been downloaded.

Hi @Tanaka_Jimha, is there any news?

In looking at this thread, while it might be nice if the AppInstaller file functionality included an auth feature, I'm not sure we need it.

Typically in any kind of packaged deployments, the package is user agnostic and the tooling provides authentication. The AppInstaller file is used as something sent to be installed, so auth might not be needed here. Instead, I think that authentication should be implemented by the "hoster" on the actual MSIX file. So if UNC file share that means ACLs, and for Http/S some sort of logon permissions. The latter might be harder to do, but I'm assuming that this is an enterprise situation that would be using UNC.

Hi @TIMOTHY MANGAN, Excuse me but I don't understand you.
Referring to the following link
The MSIX installer does not work when Azure AD authentication is enabled.

OK. I don't test appinstaller in a scenario where AAD auth is required, but I've certainly done AAD auth based MSIX installs so I know that much works. But, assuming it can work, you likely would have the files in Azure Files, and user based access should be able to be placed there. I'd also guess some web portal work could be done to provide different files for different users from the same request, if you did that you could have one web link that points to different appinstaller files (and therefore different MSIX versions) on a per-user basis..